I have just compiled an existing app with the latest SDK 5.4.0 GA and was surprised to see some weird issues that look like performance issues but I am not sure.
I use an activity indicator (Ti.UI.createActivityIndicator) while time consuming things like loading data in memory or fetching data from the app server take place, and with the new SDK the animation is really choppy. The same app under the exact same conditions but compiled with 5.3.1 GA shows the activity indicator nice and smooth so it is something related to the 5.4.0 GA.
Any idea what it might be and if this is a bug or something I might need to change in terms of configuration?
I have tried switching the run-on-main-thread property but it had no impact.
The overall performance of the app does not appear to be impacted - hard to tell really.
No such issues with iOS.
Any suggestions?
Related
I'm trying to find the Metrics Launch Time of my app by using Xcode Organizer but it does not show the result of the 3 most recent versions. Only for older versions.
I'm using Xcode 12.2 (12B45b), and even after upgrade to 12.3 (12C33), still doesn't work!
Does anyone run into the same problem and know how to fix it?
TLDR: Versions with limited usage will not appear in the Xcode Organizer Metrics.
We were curious why this is happening to our app aswell. We had 52 releases in 2021 and the Battery Usage section from Xcode Organiser Metrics menu shows us only 5 of them, while Scrolling section shows only 4 at the moment of writing this answer.
After doing some research and watching this WWDC20 session on Diagnose performance issues with the Xcode Organizer I have learned that apple is using some usage threshold for each version of the app to determine wether it should show up in the metrics or not. According to the linked session, in Xcode 12 they have lowered the required usage threshold by a factor of five.
Another thing is that now you will see a limited usage icon attached to versions which have passed the new threshold but their usage is still low enough so you will need to be aware of the margin or error while analysing those metrics.
So even though the threshold have been lowered, it's still not really helpful If you update the app often like we do. Which is sad since we are not really able to provide improvements to these metrics since we do not really know with what we are dealing with. Let's hope future versions of Xcode will at more information about how much usage is enough, because apparently tens of thousands of users on a version are literally not enough for it to be included on a list.
Resources:
Diagnose performance issues with the Xcode Organizer
I notice that desktop support isn't mentioned in NativeScript's future roadmap any more.
Has this been dropped for good, or is it still on the cards?
If it is still on the cards, for when is it planned?
NativeScript under Progress ownership
While NativeScript was owned by Progress, desktop support was never a priority; developer surveys did not show strong enough demand for it, and the NativeScript Core team were stretched too thinly to tackle it as a curiosity.
Of interest, before the death of Windows Phone, NativeScript did get very far on implementing a Universal Windows Platform runtime for NativeScript: https://github.com/NativeScript/windows-runtime
The NativeScript iOS runtime (https://github.com/NativeScript/ios-runtime for JSC, https://github.com/NativeScript/ns-v8ios-runtime for V8) is also close to delivering Catalyst support, although it's essentially undocumented for now.
I spoke with the NativeScript iOS runtime team and they said it would be pretty trivial to generate JS bindings to macOS (AppKit/Cocoa), too – though one would still have to implement all the UI components as AppKit ones, so it would only be the start of the journey.
Unofficial support
Kamen Bundev (on the Progress/Telerik NativeScript team) has been building a Qt-based desktop implementation of NativeScript as a hobby project for a long time:
https://github.com/bundyo/nativescript-platform-desktop
It has access to Node.js's APIs rather than, say, the Obj-C runtime on macOS, however.
NativeScript under nStudio ownership
NativeScript was recently handed over to nStudio, who may have a different stance. This question did in fact receive an official answer recently on Twitter:
They have also expressed love for the idea of creating Windows 10 apps with it (the tweet links to this issue, https://github.com/NativeScript/NativeScript/issues/8643):
My personal speculation
Note that I do not work for nStudio, and the dust is still settling after the NativeScript handover, so everything from here is just speculation:
So I think there's no question that the passion is there – the real question is whether they have the resources to back it. I personally think that there won't be any movement on it anytime soon, as nStudio need at least a few months just to get used to driving the NativeScript ecosystem and sorting out the long-standing open-source frictions. I think that they'd absolutely welcome a community-driven effort on this, of course. I imagine that by 2021 they'll feel more ready to take on projects of that scale.
The readme.md at https://github.com/NativeScript/windows-runtime says that the Windows runtime for Nativescript is in proof of concept stage, and then lists what I understand to be very deep language features that are not implemented yet.
The tone on the https://www.nativescript.org/blog/nativescript-runtime-preview-for-windows-10 announcement seems a bit more enthusiastic about the current feature set.
Being able to use Nativescript on Windows Phone (and any other platform) is incredibly appealing.
TJ, a core team member, recently posted on the forums about this:
Hey #NezzaGrey,
Thanks for reaching out, and awesome that you’re liking NativeScript :smile:. >Straight to the point though—we’re not actively working on UWP support because >1) it’s a ton of work to add a new platform and commit to supporting that >platform indefinitely, and 2) we’re not seeing nearly enough demand from our >community to justify taking on that work.
That doesn’t mean that UWP support in NativeScript will never happen, but it’s >not coming in the short term because we’re just not seeing the demand. That can >always change though. I’d encourage you to add your use case to the GitHub >issue open for adding UWP support in NativeScript: >https://github.com/NativeScript/NativeScript/issues/254. Yes, the issue is >somewhat ancient, but we really do pay attention to well-thought-out comments >during roadmap discussions.
I’ll note two other things. First, our initial work on making a Windows runtime >is completely open source and available on GitHub: >https://github.com/NativeScript/windows-runtime. We’d love to have community >?>help to make the new runtime a reality.
Second, one option you have is to build your iOS and Android apps with >NativeScript and Angular, and to use our code sharing approaches (see ?>https://www.nativescript.org/blog/code-sharing-between-web-and-mobile-with->angular-and-nativescript1) to share your Angular code with other apps. You >could take that approach to share Angular code between your NativeScript apps >and your UWP apps if you use something like Electron. This approach isn’t >ideal, as you’d probably prefer to build a completely native UWP app, but it’s >something to consider if you’re open to using Electron.
Anyways, hopefully you found some of this helpful. If you have any other >questions feel free to follow up.
Source: https://discourse.nativescript.org/t/windows-uwp-support/2659/3
I've been working on a React Native app on an Android tablet for my current contract and it's now going through its Alpha phase. For the most part it's working very well, it's responsive, performant, and mostly stable.
There's one issue that keeps occurring though which I'm having trouble tracking down. It seems very random since I've seen it happen on nearly every screen in the app all at times.
When transitioning to a new screen, I just get a blank white screen. Seems like the javascript just doesn't get loaded and the UI never loads. This happens in both our debug dev versions, and our bundled release versions.
Some things to note about the architecture
Android 6.0
React 15.4.1
React Native 0.39
Flux 3.1.0
I know this isn't a lot to go on so I'm mostly looking for people that may have experienced this problem (that wasn't related to the development server issues) and what they had found as a cause in their app. Hoping to get some suggestions of what to look at or possibly how to even troubleshoot what's causing this.
Oh one other thing, If I background the app when a white screen happens, then select the app from my running apps list, the screen loads just fine and I'm able to continue using the app as if nothing happened.
Sorry for the vagueness here but I'm really at a loss and looking for any kind of suggestions.
Thanks!
I would like to know if it is possible to run an Elasticsearch server on a mobile device (android / iphone / ios) and if so, how I should go about doing it.
In my case, the reason for doing it is to have an offline database on the device that is easily searchable (with all elasticsearch advanced functions)
Optionally, I would maybe also use elasticsearch's cluster/replication capacities to keep the offline data on the device synced with a server.
Well, maybe (at least on Android, for iPhone the answer is no). Others have discussed it not certain that anyone has succeeded. The Android Dalvik is a JVM, just missing some things that are typically not required for mobile apps. In theory you should be able to try to compile ES and run it on Android. However, you are likely to run into issues with missing libraries and apis that ES requires, so it all depends on how comfortable you are diving in to ES source code to resolve them.
This previous discussion might be of help, you might try to reach out to those on the thread to see if anyone succeeded:
http://elasticsearch-users.115913.n3.nabble.com/ElasticSearch-HTTP-Server-on-Android-td4056423.html
I'm also looking for a fulltext search engine for Offline First mobile apps.
I haven't developped anything yet, but I think the easiest solution can be using the Clucene Library (a C++ version of Lucene) as fulltext search engine instead of ElasticSearch (which is based on Lucene - Java).
In fact, we don't need all the features of Elasticsearch for the mobile, such as webserver, restfull api, etc...
You can find some work around on Google:
https://github.com/asheeshv/CLucene-iOS-Android-Win8
https://github.com/saturnman/clucene-iOS
https://github.com/hurongliang/clucene-ios-example
Still looking for a Cordova/Phonegap solution...
Hope it can help.
Edit:
I have found this tool that provide Offline First capabilities in Javascript.
It will work with Cordova/Phone Gap and maybe with ReactNative:
http://elasticlunr.com/
No, you can't , at least for now there is no official build that can run in mobile devices.
Can you not use regular ajax calls in your app to connect to elasticsearch? I'm not sure if it would be the best way but that's how I have it going.
There is the ElasticSearch4Android project that seems to try to do just that, but I am not sure it is not dead.
It has total 6 commits 3 years ago.
Maybe we can put one shoulder there, and help build it.
I will contact the author to see what is the state of the project.