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 578799
To read all comments associated with this story, please click here.
RE: Not a developer indeed
by nej_simon on Mon 16th Dec 2013 18:55 UTC in reply to "Not a developer indeed"
Member since:

No offense, but by this statement you also made it quite clear you are not a developer yourself.

The key reason developers care so greatly about "fragmentation" is because developers target minimum API levels.

For example, due to the massive amount of people that still used Windows XP for eons, the typical Windows desktop application could not really target Windows Vista+ features without cutting off a significant section of the market.

In HTML terms the equivalent is that a website has to support IE 9, which means half the CSS3 and HTML5 features remain out of grasp until it dies off.

]And for phones if 25% of Android phones still use old versions of Android, then the base API level targeted has to be that much lower.

Yes, in all cases above you could code things in a way that you can access them anyway, but this significantly increases development complexity and time. Features that can be officially unavailable in an API does not at all have the same kinds of costs.

That's not really the case. If you develop web sites you typically develop for modern browsers and then use polyfills to account for missing features in older browser. It's more work but it certainly doesn't significantly increase complexity or development time as the difficult part is already done by the people who develop the polyfills. You can get quite far by just including respond.js and html5shiv, 2 lines of code, when porting a responsive HTML5 website to IE8 (yes, I've done this a few times).

For android the situation is better because google maintain the android support libraries which provides several new APIs for older versions of Android. So you can target a more recent API level and still have the app run on older devices. And it's officially supported by google and not particularly difficult to use.

Reply Parent Score: 5