Android Fragmentation: a Developers Persepective
One of the largest single criticisms of Android often mentioned by Iphoners is the fact that there are so many different combinations and interations of Android and handsets that it becomes almost impossible to develope applications that will work on all of them.
Thanks to a tweet from Google’s Reto Meier I have finally been able to find a sane, response to this courtesy of Chris, the developer of the Replica Island App.
In his post, he lauds the fact that thanks to Android he was able to get his app on 13 different types of devices, without physically having to test on each device.
I don’t have regular access to all this hardware to test on, so when a phone comes my way I jump on it, install the game, and try it out. Excepting basic support for multiple screen sizes and input systems, I don’t have any device-specific code.
There is always going to be some minor differences in the way that the applications run, with some giving a much faster video performance, differences in the way that the controls operate or the screen size. The fact that you can use the same code on so many new and upcoming handsets, demonstrates that having a great app now is going to pay off in ever increasing returns.
Obviously the issue of which Android operating system is running is also something that needs to be noted, and thanks to Google’s Device Dashboard, developers can fully understand what softwar their users are running. At the moment, its shows a virtual 3 way split, between 1.5, 1.6 and 2.01. From the news thats been around, most devices are intending or have already made the jump to 2.01, so I think that this will become a non issue within the next couple of months.
The future is bright, so developers what are you waiting for?
No related posts.
One Comment »
Leave a comment!
The Android SDK has been thought and tooled to allow developers to anticipate devices differences.
When coding for Android, you have to anticipate that your app might run on different screen sizes and different input methods. All of these are abstracted in the API so you don’t have to fight with hardware-specific issues (drivers & co). I think it’s really not an issue, at least not more than designing a Swing UI for different OSes and window sizes.
In my point of view, designing an app which runs on most configurations only require good knowledge of usability concerns. You know the constraints beforehand, so you have to design your app accordingly.
Sure, with the iPhone, you know exactly where your app is landing… this is one of the benefits of a locked platform, developers can hardcode more things.
Before the iPhone, you had to fight with J2ME or many other specific development libraries (mophun…), and having a single J2ME app running correctly on different devices was quite a nightmare.
At least, Android leverages Java programming knowledge which is quite widespread and the dev kit is usable on ANY operating system. This is the best opportunity so far to develop a single application which can be used with minimal tests (greatly helped with the polymorphic emulator) on a large number of different devices from different manufacturers.