Jim McKeeth recently blogged about the results of submitting an “empty” FireMonkey app to the apkudo online Android testing service.
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.
Non-Functional Quality
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.
Concrete Examples
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.
Full Disclosure
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.
“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.”
This not true. First interest is for developpers. But even for users in a same family you can have IOS and Androïd devices.
Well done, you just identified one of the exceptions (I shall generously allow that there may be more than this one) that my statement already acknowledged. “Vast majority” isn’t “Everyone, without exception”. 🙂
My primary interest in Delphi’s cross platform mobile support, and why I’m not as interested in most of the alternatives, is the ability to have a single source project that can be deploy to both Android and iOS.
It’s possible that you are correct and the vast majority of Android and/or iOS USERS don’t care about cross platform support. With the possible exception of users and/or companies that use both devices.
However, I doubt that you are speaking for the vast majority of DEVELOPERS who are interested in mobile development.
Being interested in cross platform mobile support is the first mistake imho. It’s a seductive prospect, that’s for sure.
Which is why I acknowledge this and make the specific point that it appeals to developers. You seem to be under the impression that I wasn’t aware of this or that I was ignoring it. Perhaps you didn’t actually read the post in full ? 😉
But just to knock this straw man well and truly over, I do not claim to speak for the “vast majority” of developers. I do suspect that the number of developers happily coding away with different tool for their platforms does vastly outnumber the Delphi developers who have been clinging on desperately waiting for EMBT to hand down the single-source tablets from on high – a veritable niche within a niche.
I will say however that a developer who puts single-source at the top of their list reveals in doing so that they don’t yet understand what mobile development entails.
And with Android continuing to out-sell iOS devices, the time will soon come – if it is not already here – when being able to write the best possible app for an Andoird device could be far more important than having a mediocre app which can run on both Android and iOS.
Good luck writing an Android widget that will compile from a single source to run on an iOS device.
Ah, but you can with Delphi: Since It’s impossible on Android with FireMonkey and impossible on iOS because the platform simply doesn’t support the technology, here is the source you need:
How could I have been so blind ? You sold me. 😉
“I do not claim to speak for the “vast majority” of developers”
I know. You claimed to speak for the vast majority of Android and iOS users. You could say I was gently correcting Daniel’s comment.
Just because you are on some kind of personal crusade doesn’t mean you need to be defensive.
I also pointed out a potentially large exception to that vast majority you were speaking for.
And I suggested that it’s developers, and not users who are more interested in cross platform support.
I suggested it first. Nah-nah-ne-nah-nah. [blows raspberry] 🙂
My point is that when considering this “feature” you must also consider everything else that the particular approach promising “cross-platform support” entails, especially when the company offering the cross platform support have only one response to any concerns raised about their approach which boils down to “Oh, we don’t think you should worry about that“.
Just as the tailors re-assured the Emperor not to worry about not being able to see the fine new clothes they had made for him.
What makes you think I’m not considering all of the implications, both pro and con?
I’ll leave you to your personal crusade of negativity, already in progress.
I didn’t write the article for you, Bruce. Quite the opposite. It was written for people with an interest in and a willingness to confront the real world. There was no delusion that it would in any way be relevant to those already lost to the seductive appeal of the comfortable delusions peddled by Embarcadero.
You will no doubt find much to appreciate in the unequalled finery of the Emperor’s new clothes. 😉
I missed this little gem…
You say this as if you’re not. I do wonder why you even bother reading my blog. I suspect is it to see just who dares go trit-trot-trit across your bridge. 😉
If I’m the only person who thinks you’re pursuing a vendetta, then I guess it’s just me…
“I do wonder why you even bother reading my blog”
Sometimes I wonder, too.
“It was written for people with an interest in and a willingness to confront the real world.”
The implication being what exactly?
I will point out that your argument involves taking frequent shots at Embarcadero and Delphi. I think you’ll have a hard time finding any place where I do anything similar with RemObjects or Oxygene.
I’ve explained my beef plenty of times. Nothing to hide there and no attempt to deny it despite your snide implication to the contrary.
Also I never said or implied that you had a vendetta against RO or Oxygene. I do find your juvenile inventions tiresome.
I seem to remember you denying being negative more than once.
I didn’t say you accused me of a vendetta. I’m saying that your obvious vendetta shouldn’t be necessary to make your points (shaky though some of them may be).
And taking personal shots is just sad.
I have denied only ever having been negative.
I have denied being relentlessly negative.
“Personal shots” ? Priceless.
Go home Bruce, you’re drunk again.
Are you censoring replies now?
Nope. Never have, never will.
Unlike your bossom buddies at Embarcadero. 😉
Then I sincerely apologise for blaming you for something that I must have messed up.
Your backhanded comment aside, I do appreciate that you do not filter comments
What was the comment that got lost ?
Nothing meaningful. Something about denial.
I enjoy reading your blog posts altho at times it seems like you have a personal vendetta against EMBR. That much said, I think that most of your criticism is justified.
As I’ve explained before, there is an axe to grind but quite apart from that I have a principled objection to supposedly intelligent people treating other supposedly intelligent people as if they are idiots.
Oxygene for Java was the major step imo. Android did work soon, JVM works, the Oxygene language is progress there. You are not limited to the old Java language since many companies try to bind customers via their own language. Babylon … again. And you have the good JDBC level 4 drivers … I could live with that combination, … the Mac is different imo, that’s just mine.
http://blogs.remobjects.com/blogs/sebastiang/2011/12/15/p3522
From Sebastian on Tomcat and Oxygene.
“3 successes + 242 failures = 245”
I think you transposed the successes vs failures.
LOL – yep. Thanks. 🙂
As long as you run on the vanity lines from Galaxy, HTC and Nexus, you will have covered most of the market, in particular the paying market. Betting on App sales from people who got cheap hardware cause it was free with the contract is probably a fool’s wish.
You have stats to back up the claim that it is the owners of expensive devices that spend the most on apps ? In all seriousness that would be an interesting report to read. Link ?
It is also rather odd to suggest that Delphi developers need not worry as long as they focus on the “boutique” end of the market. This is surely the part of the market which is also likely to be most demanding. The least likely to accept an app which doesn’t make full use of their vanity device because the developer was more concerned with getting an app out quickly and cheaply from one single source project that was unable to make full use of the devices than they were about providing the best possible app for each platform.
This is comparing apples and oranges, is it not?
Jim said quite clearly – which you acknowledge, I know – that he chose those devices which should be compatible with Delphi based on the OS version. He also said this represents 89% of the market, as far as can be determined.
So his score of 87.5% represents a total potential market of 77.9% (87.5% of 89%) of all the users out there. That may be high – it probably is – but that’s what he’s trying to measure.
Whereas your metric is the number of different devices it supports. No matter if each device has 1 user or a couple of million, they all get equal weight. It is an interesting number, but I would suggest not as relevant to most people.
[Third attempt to post this, so please delete any previous entries which may have got through! Thanks]
Not quite right I think.
He get’s 89% on 87.5% of the devices that apkudo supports, which has nothing to do with the devices in the market. In fact, you might argue that the fact that apkudo supports this range of devices as indicating that other stats about the supposed market are themselves misleading. Why would apkudo bother maintaining the more than 50% of devices which are deemed irrelevant by everyone ?
Perhaps it is only certain development tools companies that deem them irrelevant ? Google certainly haven’t pulled support for them from their SDK.
I am not suggesting this as definitive evidence that those other stats are wrong, merely pointing out that it seems rather odd, if they are accurate.
The point being that the exclusion of those devices is the unavoidable consequence of using Delphi, not the demands of his app.
The point also being that the 11% (in his sample size) of failures that he dismisses as just par for the course when testing with apkudo does not appear to be as normal as he suggests and so not so easily regarded as having nothing to do with the presence of the FireMonkey runtime in his “empty” app.
Any chance you post the full list of the 245 devices in the report you generated? It would be interesting to see it – I couldn’t find it on the Apkudo site, though it must be there somewhere.