Thanks for sharing that. I had no clue when native Java compiles to machine code became reality.
But the Android code is still too slow for being natively compiled.
Yes, but I think that's primarily just from the dev team investing less time in optimisation. Thousands of game writers get great performance out of their Android apps.
I dont think the Android would ever be as fast as the iOS on identical hardware. I still love Android and have never owned a iPhone or iPad other than the mini 4 for the plane.
FWIW, outside of Android, even before there was JIT or AOT Java compilation, it was rare that Java was bytecode and garbage collection made a difference. Unless you're running something in a continuous tight loop (like ray tracing, nuclear-explosion modelling, or, these days, bitcoin mining) your program is spending almost all its time waiting or polling for I/O or interrupts, so a difference of even 50% in code execution time might come out to 0.5% in program speed. I demonstrated that in 1998 by writing an XML parser in Java that ran faster than the C ones at the time (it was basically limited only by how fast it could read the XML file from disk).
An EFB app is just sitting most of the time waiting for something to happen. It's waiting, e.g., for a GPS position update to arrive, or for the GPU to finish drawing something, or for a new Nexrad radar update to draw. You can write a program that's very slow in C, Objective-C, or Java (or Python, for that matter), but it's usually not the programming language or runtime environment that's the deciding factor.
I can only guess that Garmin has two quite different code bases: an objective C base and a Java code base. If they truly shared 90% of the code then features (except nitty gui stuff) and release schedules would be more similar between both.
I wonder if they have a higher-level codebase that can be "translated" into Objective-C or Java, or even a tool that will "compile" Objective-C into Java code. Either of those would probably result in some messy, inefficient code. It would be for the non-hardware-dependent parts.
From a business POV I'm surprised Garmin even supports it on Android. I wonder if its partly driven by the Euro market.
I suspect they regret that decision now, from a business PoV. It might have been intended to give them a competitive advantage over FF, but I doubt they've ended up with enough Android users (like me) to justify the money they're putting into development. Killing it off now, though, wouldn't be good for their corporate reputation, so they're sort-of stuck.
And the GP iPad version isn't perfect either. 2 iOS updates and several GP updates later and i can still hang the mini 4. Its as simple as going to the SynVis or Connext page and back to the map and it locks up with a black screen. It does it 100% of every try so far. I have to kill it and restart it...twice! Another ios nit is the garmin 345. The android version establishes the bluetooth connection almost instantly. Meanwhile with the ipad I've started up, brake check, lean, taxi and about the time I've finished the run up it connects....and if it doesn't I go to Connext and get the other damn bug.
Interesting to hear. Yes, it seems there are advantages and disadvantages to both platforms. On Android, we can at least take reliable Bluetooth, built-in GPS, and not overheating for granted, even if we're running behind on new features and code optimisation.
FWIW, FltPlan Go runs quite snappily on Android. Its price is great (free), as is its coverage (includes Canada), but the Android version doesn't display SiriusXM weather from my GDL 51 yet, so I'm still paying my GP subscription.
