Skip to main content

Bogeymen and Android fragmentation

Posted by fabriziogiudici on June 3, 2010 at 5:33 AM PDT

Via DZone, yesterday I read this statement from Android's Open Source & Compatibility Program Manager, Dan Morrill:

"The thing is, nobody ever defined fragmentation or rather, everybody has a different definition. Some people use it to mean too many mobile operating systems; others to refer to optional APIs causing inconsistent platform implementations; still others use it to refer to locked down devices, or even to the existence of multiple versions of  the software at the same time. Ive even seen it used to refer to the existence of different UI skins. Most of these definitions don't even have any impact on whether apps can run!

Because it means everything, it actually means nothing, so the term is useless. Stories on fragmentation are dramatic and they drive traffic to pundits' blogs, but they have little to do with reality. Fragmentation is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn."

While it's true that if you listened to every blog, forum post, twitter feed on the earth you'd conclude that all the technologies around are just plain crap, and objections should be motivated and explained, I find totally unacceptable that a corporate official, who's addressing a community of developers, simply dismisses an alleged problem by word playing. "Because it means everything, it actually means nothing, so the term is useless. ... Fragmentation is a bogeyman, a red herring, a story you tell to frighten junior developers. Yawn.".  Re-thinking of it, irritating is probably a better attribute for these statements.

I've been hearing about Android fragmentation since a few time, even from reputable professionals I know, but at the time I wasn't in the position of understanding it - because at the time I wasn't able to develop on Android. In the about six weeks of "experience" I've accumulated so far, I thought I wasn't facing with any big problem related fragmentation; until this morning - and it's amazing it happened by chance, just the day after reading Morrill's statements.

But let me first give a definition of fragmentation, so that we stop playing with words. I think there's a definition that would be accepted by most people, and it's: fragmentation is that thing that raises integration testing costs because of the need of multiple, non-emulated target platforms; eventually up to an unsustainable point. It's what JME has been bashed for: there's so many different optional JME JSRs on the market that in order to be reasonably sure that my application runs on most of them - at least the most popular ones - I must buy/hire/access a large number of them. Sure, fragmentation is also related to the existence of many different target phones, but that is a price we have to pay unless we want to fall in the "walled garden" paradigm by Apple . no, thanks, I prefer the open market.

Ok - so what happened to me this morning? I was talking with Andrea Polci from JUG Lugano, during a pause of Jazoon. He downloaded blueBill Mobile for Android and tried it on his HTC Magic running Android 1.5. First surprise: the application icon didn't show up. Second horrible surprise: the application crashed after navigating to a specific screen.

The details about the bugs are available at my issue tracker under the codes BBMA-77, BBMA-78, BBMA-80. In a few words, there were problems with two icons that couldn't be found, one of the two causing the crash. Let's assume it was 100% my fault (details on the issue tracker), so there are no extra discussions and we stay on the point. Tests are supposed to find bugs; so why on the hell both problems didn't and don't reproduce with the Android emulator, where I manually test my application before any release with Android 1.5, 1.6 and 2.0 (in addition to my Droid/Milestone with 2.1)? I mean: an emulator is obviously not the real thing, but I expect differences to stay in the various aspects of the integration with the real world (network connections, GPS, battery...) not with the mere loading of an embedded resource.

Everybody can check it, as my application is open source - so you can confirm that I'm not a bogeyman (there were a few children here in the hall of Jazoon, as part of the venue is still working as a cinema; they didn't seem to be frightened by my presence). I found and fixed the problem only because I accessed a real piece of equipment. But if I discover that I need to access multiple pieces of equipment with different versions of operating systems, even for such a trivial thing such an icon, wouldn't this fall into the definition of fragmentation that I gave a few paragraphs above?

There's something more that I have to add, concerning things that Google could do to improve things, rather than try to hide problems, but I'll leave it for another post.

 

Related Topics >>

Comments

is it Android specific? No.

You got the following:
E/AndroidRuntime( 2669): Caused by: java.io.FileNotFoundException: res/color/primary_text_light.xml

We are using Eclipse and standard JDK.
When testing applets in local environment, we forget sometimes about mechanics of extracting resources from jars.
It should be done via classloader, you can't just load file from file system.

But loading from file works fine locally!

And only when you deploy applet jars, you are facing the problem.

As far as I know, there is no way to force appletviewer to 'ring' when not using classloader on client side.

So, it is not Android's exclusive behavior.

Hi zaal. Apart from the fact

Hi zaal. Apart from the fact that the Android emulator is supposed to be at a more isolated level than just an appleviewer, your diagnosis is not related with the problem. That primary_text_light.xml is not referenced by my code, but it is used by the runtime. So, it's an error of the runtime. It turned out that the problem wasn't even related to that file - so it's a sort of erroneous and misleading diagnostics - but from an icon resource of my application that wasn't stored where it should be. It was in a standard location that wasn't part of the standard at the time of Android 1.5 - nevertheless, the Android 1.5 emulator seems to be faulty and uses it.