But Phantom Menace bad? Nowhere close.
Tenuous comparison aside, probably the main reason SOAP dropped out of sight was it wasn't suitable for the eventual problem domain. SOAP was fine for computer to computer (B2B) communication where it's rather important to have schemas with validation, XML signatures, bindings like Axis that generate some nice stub classes for you and all that stuff. But it's a pain in the ass when you're a bit of JS in a browser trying to process some text you just got from a server and it's too much effort to produce schemas for the sake of some snippets of data. Of course JSON has taken off so much that suddenly having a schema for validation purposes is quite important again. I bet anyone who has used JSON in a server or wherever has had to handroll validators to ensure what they're getting is correct (e.g. that a field exists or contains a number etc.). There are drafts to produce a JSON schema spec and I expect in time tools will appear that spew out stubs and validators from a schema in a manner not wholly dissimilar from SOAP. So things will turn full circle in time. Doubtless someone will proclaim that JSON is too much effort at that point and suddenly we'll all supposed to be using YAML.
It's not self-evident. There are serious jank problems while scrolling, 10-second latency problems navigating trivial apps like Settings, and nagging battery-drain problems with Android. These are the main problems the platform has.
Utter bollocks. And even if it were true (and it isn't) it does not mean the kernel is to blame so your point would still be bollocks.
Memory use isn't one of the problems: the standard phone went from 0.5GByte to 2GByte RAM a couple years ago without any significant change in app functionality, and the K release used less memory than the J release so general platform bloat is actually going backwards: the stack's memory tax is therefore less than a quarter of the standard platform size and not a big deal for emulation.
Utter bollocks again. Android has increased memory generally so more apps stay resident in memory. The less memory, the more likely it would be to purge apps. In other words it makes use of the memory for stuff.
Performance probably isn't a problem wrt the emulation because the performance problems are not flat-out CPU bound work nor mean-latency problems: doubling the mean latency would not be a big deal because android has such huge tail-latency problems. And doubling mean latency in return for cutting max latency is exactly what hard-realtime kernels like Neutrino are made for. Whether they can do this through the android stack is doubtful because the latency is probably coming from java crappo, but who knows. Anyway it's not self-evident that emulation will cause a memory problem for Android, nor that it will cause a performance/battery problem.
Utter bollocks because it presupposes your other bollocks and makes no sense in any event. The point I was making was that to emulate Android, a Black Berry device has the memory pressure of two runtimes in memory at once (the native one) and the emulated one (plus shims). It obviously impacts on memory and performance.
Emulation and battery-drain problems aren't related because they're caused by poor scheduling, bugs, held "wake locks", etc. Part of the area where bugs can exist will be replaced, so if QNX is higher-quality than Android in this replaced area it will win the battery game.
It's true that a misbehaved app can drain battery but normal drain is caused by the screen, radio and general activity. And in any event it's largely an irrelevance what kernel is underneath because an app can misbehave over any kernel. And modern kernels are wasting CPU / battery unless something above is telling them to.
It should also be self evident that if a Blackberry device has to load up a substantial chunk of an Android runtime and an emulation layer (in addition to its own services) to run an Android app that it will be neither as performant or memory efficient as a standard Android device. It has two stacks to wrangle and there might be limits on the Android emulation that cause performance issues of its own.
In fact it's hard to see why they bother emulating Android at all when they could just *be* Android. Doesn't stopping them locking it down with Knox, encrypted storage etc. It would save them a hell of a lot of effort in the long run and would broaden the appeal of a device if it actually ran the apps people wanted to use. Emulation and Amazon's store is better than nothing but it's still an extremely poor substitute for the Play store.
It does sound like an advertising pitch, but this is accurate about QNX. The OS isn't cheap, but it does offer realtime functionality. It also is designed to be quite stable to where a bug or a hang can cause tremendous disasters, be it software with X-ray machine or figuring out what position to move a set of control rods in a reactor. QNX has excellent internal security, and a decent development kit.
The thing is here it's being used for an in-car entertainment system. It doesn't have to be realtime, it doesn't have to require stability beyond what a regular kernel would offer. In fact it shouldn't matter a damn what kernel is powering the system since most of the functionality is going to be sitting in an application layer well above the kernel itself.
I'm not sure what motivated Ford to switch. Maybe QNX uses less memory or is more performant with the chipset they want to use, or is simply cheaper to licence. Or maybe the automotive industry is naturally conservative and comforted by some extra certification QNX offers that Windows doesn't. Whatever the reason, I doubt the end user experience or reliability would be appreciably different whether they had used an NT, Linux, BSD or a QNX kernel - any modern kernel would have served the software well. Whether the application itself is good is an entirely separate matter altogether.
It's not insurmountable. It's just a bad first impression.
A bigger roadblock might be that these days, bandwidth (and storage) is cheap, and so savings in image size are less relevant than they used to be.
Once its installed and running it's fine though.
In its favour the Android integration is far better - obviously. Android Studio provides all of the tools out of the box to build an Android app from end to end which includes all the packaging and signing at the end. In Eclipse you can can develop and debug easily enough but if you want an apk you have to manually invoke a dialog to package and sign APK. This is a huge pain.
Note that AS doesn't actually build anything. Everything is farmed out to a gradle script. This means you can build from AS, or the command line or even from Jenkins from the same script. This is very useful and you can your own custom tasks, unit tests and other goodness to your scripts. But... gradle is goddamned slow. As in REALLY slow. Even if you configure it spawn a daemon so it doesn't respawn all the time (yes I've done that) it's still slow. The problem is if you change a Java class it still has to run through every task checking the dependencies to see what needs to be built and it takes too damned long.
Eclipse is extremely good at incremental building so you can make a change and hit run and in seconds you're debugging. Eclipse is also superior for marking code in error - AS only tends to know about errors local to the file, e.g. syntax errors. If you call a method in another class and get the params wrong you might only be told when gradle reports an error. In Eclipse it would have told you instantly which means turnaround is so much faster. I also prefer the Java editor in Eclipse, because it knows more about your project as a whole, the code completion and hints are more immediate and useful. I'm also used to the keybindings but AS has some Eclipse keybindings so that doesn't matter too much.
Android Studio does have some excellent code analysis tools. It has Android lint integrated into the build and there are a pile of things it can search for in addition to that and in many cases will offer automatic solutions. It also has nicely integrated view and fragment editors which work better than the ones in Eclipse.
AS is a terrible CPU hog. I've noticed it eating anywhere between 5-30% of the CPU depending on what panes are open. This is a serious problem on a laptop because the fan starts whirring and the battery life suffers. The command prompt pane is the worst of all and I only assume it's killing the CPU by continuously polling. Source code integration is also inferior to Eclipse - EGit is a wonderfully mature plugin these days with some complex and useful functionality - the support for Git in AS seems quite perfunctory by comparison although it covers the basics.
So to summarise pros for AS:
- End to end builds for Android apps
- More integration for Android tools
- Excellent code analysis
- External build system making it easier to do custom tasks and automated builds.
And the cons:
- Gradle really sucks for iterative development and slows things down. It's also a massive learning curve.
- AS is a CPU hog
- Source control integration is weaker
- If you have a mixed development environment (e.g. client and server side components) or multiple targets then an Android-centric IDE might not be so good as Eclipse.