Jim reports that an “empty” FireMonkey app failed on only 13 devices out of 118, claiming an impressive 89% success rate.
It made me curious to see what the same exercise with Oxygene would yield.
Just in case that graphic isn’t clear: That’s just 3 failures from 248 tested. 3 results appear to have gone missing (3 successes + 242 failures = 245, not 248), but if we assume those missing results were also failures then we get a success rate of 97.5 % of the available devices. Not bad at all.
If we apply the same criteria to Jim’s FireMonkey results, the success rate doesn’t look as good as it first did. Although Jim explains that some devices were excluded by the runtime requirements of FireMonkey he chooses not to say how many devices that was. But let’s assume it was the same 248 devices that were available for my test.
With 105 successes and 248 devices, the comparable FireMonkey success falls from 89% to just 42.3 %.
You can of course spin these numbers however you wish to fit a particular desired story, as we have seen – you can, for example, more than double a 42% success rate into 89% !
But sometimes such manipulations are a bit too obvious to be ignored, so rather than thinking too much about how to interpret such results Embarcadero would prefer you not to think in those terms at all.
It’s all a bit ironic really, considering that they keep trying to find statistics that make a point that they simultaneously insist is irrelevant.
No, they would much prefer that instead of worrying about all the Android devices your apps will not work on, that instead you think about all the iOS devices that it will (and again, kindly ignore those iOS devices that it won’t).
In fact, Jim says exactly that:
Instead of focusing on the small percentage of Android devices you are missing with Delphi XE5, I’d instead invite you to consider the millions of iOS devices you can target from the same code base. Including iOS 7!
Note the not-so-subtle attempt to plant firmly in our minds the belief that the failures are only a “small percentage” (again: “please don’t think about this, just take our word on it“) there is a problem with encouraging this sort of thinking.
Whilst it sounds attractive to a developer to contemplate the total population of different devices they can compile their app for from “a single codebase”, this is not a feature that can be sold to potential users – i.e. customers.
It is a “non-functional quality”, to borrow a term from another post by a different Embarcadero employee, dismissing concerns about application size as just such a “non-functional quality” (in that case utterly failing to address the very real concerns that app-bloat can lead to in the mobile space).
Odd that a non-functional quality is dismissed (incorrectly imho) on the one hand and yet a different non-functional quality offered as a “feature” on the other.
It is not of course entirely an irrelevant point. Although a non-functional quality, the cost of development is a factor. And I am sure everyone is very grateful to Embarcadero for keeping their customers development costs to a minimum.
But having a cost-effective, multi-device platform is no guarantee of success. No matter how attractive the development environment to the developer, users do not choose applications on the basis of such considerations.
The fact that an Android app also runs on iOS is of no interest to the vast majority of Android users nor vice versa for iOS users.
The fact that an Android or Cocoa app does not – and perhaps cannot – support all of the features that the particular platform provides for on the other hand, or that an app doesn’t feel like it really quite “fits”… such things will be a concern.
As developers, we should be concerned not with what it is possible for us to do in some idealised, code writing vacuum, but what our users need and want us to do for them.
I am by no means an experienced Android developer but even I can already see areas where FireMonkey faces some serious – possibly insurmountable – difficulties, at least on the Android platform. These, or similar, quite possibly on iOS too.
I just posted the final instalment in my camera app series using Oxygene. In this final part I added support for an intent filter.
Implementing the behaviours required goes far beyond simply styling some UI elements. Your code is required to interact directly with the object model of the application. In even a simple case such as presented by my camera app, a FireMonkey implementation will involve some really not very pleasant JNI code.
And in a more complex scenario – implementing multiple activities where one is the entry point for an intent, separate from your main activity – as far as I can see, it is currently impossible and will require some additional infrastructure support in the FireMonkey runtime, if this is even possible at all within the constraints imposed on an NDK based application.
Similarly, Android widgets – currently not just difficult but simply impossible, as far as I can determine, using FireMonkey.
If this is mistaken and these things are possible, I would be most interested to see some examples.
Of course, Embarcadero are perfectly correct. An application that doesn’t implement these things will run perfectly well without them on iOS as well as Android, and perhaps this additional non-feature will be enough to make up for the lack of real features.
I also submitted my camera app to apkudo with some disturbing results. It fails on all but 4 devices. Ouch! 🙁
The vast majority of failures were the result of my app explicitly requiring Android 3.0 or above (for the ActionBar UI). Everything pre-Android 3.0 is excluded by this decision. Of course, I can implement ActionBar support for earlier devices (down to 2.1) if I wanted to, and even older than that if I provide an alternate, non-ActionBar UI within the app. It’s up to me. There are no minimum requirements imposed on me.
But currently as a consequence of the self-imposed Android 3.0 requirement, only 32 of the testable devices are supported. I knew perfectly well that I was taking a rather cavalier attitude to compatibility concerns, focussing on an app that worked on my particular device.
But 4 / 32 is still pretty horrifying and a little disappointing. 🙁
On the bright side, this is something I can fix if were minded to, and provides an opportunity for me to learn some more lessons about developing for Android which will stand me in good stead for the future.