Like the author, I have been writing Android software for a while (nov 2009). However, I completely disagree with his conclusion.
When I think "fragmentation", device sizes and configurations are the least of my worries, although the tooling around this area is very poor and needs improvement. The real fragmentation issues are things involving bugs which are hard to work around, like
* Froyo having a number of NIO bugs (ByteBuffer.AllocateDirect & selectors) (which were fixed later on)
* Samsung GPS driver not filling in Location.getTime()
* HTC Desire and others having broken Bluetooth stacks
Or advice from Google like:
"Apache HTTP client has fewer bugs on Eclair and Froyo. It is the best choice for these releases. For Gingerbread and better, HttpURLConnection is the best choice."
I have always found Android and its tools to be extremely buggy. Then take into account you are going to have to maneuver around all of these bugs not for one version of the OS, but essentially every version put out for the past 2 years. Many bugs are from Apache Harmony, a huge pile of turd, which is defunct.
Also, fragmentation comes in other forms entirely, like the Kindle Fire, which does not pass CTS and does not have all of the android APIs (I see the possibility of Google subsidizing a low cost ASUS tablet as a move against this existential threat).
Additionally, the newly published design guidelines are for ICS and above, but most developers will target Froyo-ICS. Its quite a challenge making an app which follows these guidelines if you are also targeting pre-ICS devices. So even the guidelines are "fragmented".
I'm really looking closely at how Windows Phone does. Its becoming more difficult to write non-trivial apps for Android unless you can afford a bunch of phones to test on, or use one of the testing services like Perfecto.
But there is potentially a startup opportunity here. Perhaps someone could create a database that lets you drill down, by API, to see which phones have issues. It would be great if lint hooked into this database and gave me a list of phones to exclude in the market, if I didn't feel like working around them.
I dissagree as I haven't had a lot of problems with the apps I've worked on. But maybe it's because of the APIs I've used, some of them are probably more solid than others, I never had to use NIO or Bluetooth.
As far as the design guidelines, there is a compatibility library that lets you use them back to 1.6.
When I think "fragmentation", device sizes and configurations are the least of my worries, although the tooling around this area is very poor and needs improvement. The real fragmentation issues are things involving bugs which are hard to work around, like
* Froyo having a number of NIO bugs (ByteBuffer.AllocateDirect & selectors) (which were fixed later on) * Samsung GPS driver not filling in Location.getTime() * HTC Desire and others having broken Bluetooth stacks
Or advice from Google like:
"Apache HTTP client has fewer bugs on Eclair and Froyo. It is the best choice for these releases. For Gingerbread and better, HttpURLConnection is the best choice."
I have always found Android and its tools to be extremely buggy. Then take into account you are going to have to maneuver around all of these bugs not for one version of the OS, but essentially every version put out for the past 2 years. Many bugs are from Apache Harmony, a huge pile of turd, which is defunct.
Also, fragmentation comes in other forms entirely, like the Kindle Fire, which does not pass CTS and does not have all of the android APIs (I see the possibility of Google subsidizing a low cost ASUS tablet as a move against this existential threat).
Additionally, the newly published design guidelines are for ICS and above, but most developers will target Froyo-ICS. Its quite a challenge making an app which follows these guidelines if you are also targeting pre-ICS devices. So even the guidelines are "fragmented".
I'm really looking closely at how Windows Phone does. Its becoming more difficult to write non-trivial apps for Android unless you can afford a bunch of phones to test on, or use one of the testing services like Perfecto.
But there is potentially a startup opportunity here. Perhaps someone could create a database that lets you drill down, by API, to see which phones have issues. It would be great if lint hooked into this database and gave me a list of phones to exclude in the market, if I didn't feel like working around them.