Shared publicly  - 
 
#android #developers   #fragmentation   #it   #lives   #change   #elusive  

I always get tickled when an article appears that tries to downplay fragmentation on Android especially when the author claims to be a developer or says that it no longer is possible with Android. 

:: Sigh :: 

So I swooped in again to set the record straight from my developer perspective having used every version of Android v1.0 on up. I won't go into my detailed response, but you can view it in the comments and from this direct link:
http://phandroid.com/2013/02/27/android-ios-fragmentation/#comment-814520916

In short, for fragmentation to be significantly minimized for developers the SDK needs to be separated from the firmware & OS / hard release cycles such that the SDK can be updated without bumping the firmware in a similar manner that the Google Play store can be updated to all applicable devices. 

There are more modern engineering approaches that allow this.. I've been working on cracking that nut for a while.

*And queue blatant self promo* This is exactly the solution TyphonRT provides to Android and beyond via a highly modular and component oriented middleware framework on top of all versions of Android and J2SE creating a "meta-SDK".. :)
7
Nick Shvelidze's profile photoMichael Leahy's profile photo
 
crApple fanboys don't have enough CPU power to understand it
 
There are fanboys on both sides I'm afraid.... Reality currently indicates that fragmentation for Android is not going away.. Some aspects may be getting better, but that is up to increased quality assurance before shipping. 

I suppose since I put a lot of time into my response to the article... I'll post my comment to the blog post below here too so it doesn't get lost:

------------------------------------------------------------------------

>So maybe that F-word isn’t so scary now after all. Does it still have you trembling in your boots?

From a user perspective it's great that Google Play is getting updated to all devices.

Having used Android since v1.0 and every API level here is my developers perspective... Trembling, no... Aware that it will never go away... yes... And here is why and what real fragmentation is from a developers perspective:

(granted it gets more technical now)

At the core real or hard fragmentation are the bugs / flaws that are inherent at each API / OS level of Android that require explicit workarounds. There are arguably worse flaws in the past and things are getting better in general, but not everything is caught all the time before a new OS / API level ships.

In a nutshell:
People are fallible -> people write software > deadlines loom -> the SDK is hard locked to firmware / OS versions -> there is always potential for hard fragmentation.

Examples of major flaws that affected my world:
1. Deficiencies & incomplete testing of the OpenGL ES 2.x Java API in 2.2 due to code generation and improper follow up testing.

2. Major regression in 3.0 / 3.1 for the Java NIO API for some methods which cause an endian swap condition. The duplicate() method was changed / flawed; asCharBuffer() is always going to be flawed because internally it calls duplicate(). It took me 50 hours to find the root cause to why my OpenGL apps failed due to the use of NIO / duplicate() when I got the G-Slate / 3.0. I've never seen the Android team fix a bug quicker once the source was identified (~2 hours), unfortunately those changes didn't make 3.1

Workarounds.. For the first one if one wants to support 2.2+ from one unified OpenGL ES 2.x API one has to use a 3rd party wrapper and never use the official API. For the second if you have access to source code using NIO and need a duplicate view of a buffer then there is a way to do it without the forced endian swap. If you don't have access to the source code say using a 3rd party library for networking or whatever you are out of luck. This NIO flaw is only in 3.0 / 3.1 and doesn't affect the API from version 1.0 of Android or any others. Unfortunately "asCharBuffer()" will always be flawed and there is no workaround on Android 3.0 / 3.1.

Luckily, I can't point to major / hard fragmentation bugs 4.0+. In fact 4.x was the first major version of Android that didn't have "show stoppers". Some minor quibbles / bugs here and there.

-----------------

From a more fundamental direction there are always aspects of soft fragmentation with the Android SDK since it is constructed in a very traditional OOP (Object Oriented Programming) manner where the API expands additively over each API level / OS version. This regards small / slow tweaks + extra functionality that isn't going to be back ported. There will always be this kind of soft fragmentation with Android requiring developers to conditionally target API versions with different paths if new functionality is desired to be used. Case in point.. Just check out the View documentation and play with the API level selector which shows which new methods are added at each API level:
http://developer.android.com/reference/android/view/View.html

New functionality at API levels: 1, 2, 3, 4, 5, 7, 8, 9, 11, 12, 14, 15, 16, 17

17 is the latest / Android 4.2.x and there was significant handy new functionality added since API 16 / 4.1.x at least for optimizing animation in certain situations. I like to highlight the View class because it is central to writing standard Android apps. In this case for the most part new methods / functionality is additively added with each API level. Luckily there are only minor deprecations at API level 14 & 16.

For soft fragmentation developers usually just pick a minimum API level and stick to it. New apps may choose a new minimum API to use the latest features. At least this is the common case for app development. The worst situation is embedding conditional logic in an apps code to branch and do different things at API levels as maintainability suffers greatly.

------------------------

>"Why, then, does fragmentation no longer matter? Simple: Android is now designed for it."

This is simply not true. Nothing has changed in the core ways Android is being developed and hard and soft fragmentation for developers is not going away anytime soon. Hard fragmentation can be reduced, but that really comes down to managing better testing / quality assurance with new OS releases; the track record has been spotty in the past, but seemingly is on a better course presently. Soft fragmentation is just inherent to the engineering methodology / approach taken to extending Android. OOP / additive SDK development is what it is; not everything gets back ported.

The author mentions about the Holo UI, "A Holo UI for Android 4.0+, and a regular UI for non-Holo devices."

I do want to provide some info on a neat effort out there that back ports the Holo UI to Android 2.1+.

https://github.com/ChristopheVersieux/HoloEverywhere

Combine the above effort with either the stock ActionBar back port or ActionBarSherlock and one can create apps that look / run uniform across Android 2.1+ for the most part.

----

Ultimately, for fragmentation to be significantly minimized for developers the SDK needs to be separated from the firmware & OS / hard release cycles such that the SDK can be updated without bumping the firmware in a similar manner that the Google Play store can be updated to all applicable devices. I've been chanting this war cry from the get go...

There are more modern engineering approaches that allow this.. I've been working on cracking that nut for a while.
Add a comment...