Linked by Thom Holwerda on Sun 15th Dec 2013 11:05 UTC
PDAs, Cellphones, Wireless

PhoneArena's Micheal H. addresses an article at Forbes:

The conclusion may sound redundant at this point, but it is fairly simple: if you want to have a discussion about Android and iOS (and there are plenty of incredibly interesting discussions to be had), think about the issues you want to cover, and break each down on their own terms. Trying to bundle arguments under and umbrella term like "fragmentation" is just lazy and it holds very little meaning at this point.

At the end of the day, I always get the feeling that the people yelling the loudest about "fragmentation" are people on the sidelines, who've never coded for Android at all. That's not to say it's not a problem at all - it's just to say that it's an area where the competition does a better job. Android's device diversity certainly creates additional challenges for Android developers, much in the same way that Apple's inconsistent App Store policies creates additional challenges for iOS developers.

Each platform has its weaknesses, but none have been as aggressively made larger than it really seems to be than Android's supposed fragmentation. Unravelling this positive feedback loop among these bloggers should make for fascinating material.

Permalink for comment 578738
To read all comments associated with this story, please click here.
View from a rookie developer
by SmallPotato on Mon 16th Dec 2013 02:09 UTC
SmallPotato
Member since:
2006-01-16

Being a rookie Android developer myself, I can say that surely there are challenges, but whether the challenges are "problems" really depends on a case-by-case basis.

For example, there is a difference in the implementation of "Settings" screens between Android 2.x and Android 3.x/4.x. For Android 2.x, we use PreferenceActivity and use the API "addPreferencesFromResource" of the PreferenceActivity to create the Settings screen. On Android 3.x and up, we use PreferenceFragment instead, and attach the fragment into an activity. Even the Android Support Library backports Fragments, PreferenceFragment is not available. Developers need to determine the running OS at runtime and implement both methods to handle all cases. Not to mention I need to test the implementation on both Android 2.x and Android 4.x systems, at least.

There are many other similar cases, but this comes to mind as I just implemented this trivial solution this weekend on my app. Surely this increases implementation costs, but what I see for now is that there is a transition period between "legacy" Android (2.x) and "modern" Android (3.x/4.x). In fact, there is not much differences between ICS or JellyBean or even KitKat. There are new features, but not radical differences in terms of API or other behavior that exists in Android 2.x. Once Android 2.x faded away, the lives of developers would be better in my opinion.

Of course I don't know what happens when Android 5.0 comes, but the current trend of Android 4.x shows that Google wants its API and behaviors to be stable for a certain period of time.

Reply Score: 6