Much has been written about fragmentation in Android – the fact that there’s a practically limitless variety of screen sizes, shapes and resolutions available on devices running the Android operating system as well as many different versions of the Android OS running on those devices. In addition there are devices running highly-customized versions of Android such as the Amazon Kindle and Barnes & Noble Nook tablets adding further diversity to the landscape.
Every argument about which mobile platform is “better” or easier to develop for will inevitably evoke fragmentation as a major hurdle to be overcome in Android development. However, in our experience developing the Ancestry app this has just not been the case. Working with a diverse set of device requirements requires a different approach than one would take with a monoculture like iOS, but it’s not necessarily a more difficult approach. By following a few basic principles, fragmentation has become for us a minor issue at worst.
Don’t reinvent the wheel
The version of Android OS that is most prevalent on currently active devices is 2.3, and it saw its last major update about two years ago. Since then there have been multiple new versions of the OS released adding significant functionality through a number of new APIs. Do not presume that you have to ignore these new features merely because they are only present in a newer API or that you’ll have to write your own equivalent features from scratch in order to get them on older devices. Google provides a Support Library that encapsulates many of the most useful additions to the Android SDK, such as fragments and View Pagers. The Ancestry app uses fragments heavily and with the Support Library we are able to provide that functionality on devices running Android OS versions as old as 2.1.
In addition, several intrepid developers have built additional libraries for areas that Google doesn’t already support. Jake Wharton’s ActionBarSherlock is the marquee example of this; it’s a drop-in replacement for the native ActionBar API that cleverly uses the native Action Bar on devices that are new enough to support it while creating its own Action Bar for older devices that is indistinguishable from the native one. Another useful library, also written by Jake Wharton (we owe that guy a fruit basket or something), is NineOldAndroids. This library brings many of the new animation features introduced in Android 3.x to older versions.
Google also makes all of the Android source code freely available so if a library is not yet available to support the new API feature that you want, it’s often possible to copy the source code for that feature into your project and get it running on all of your supported platforms with minimal tweaking.
If there’s just no practical way to duplicate the functionality you desire across all device versions, it’s a simple matter to create a code path that only executes on devices with the new feature you would like to use using the Build.VERSION.sdk_int constant to detect the version of Android running on the user’s device. This allows you to still provide the optimal experience for newer devices while degrading gracefully on older ones.
Varying OS versions is not the only fragmentation issue; there are also concerns about supporting multiple screen sizes, and how to test all of these various configurations. In upcoming posts I’ll discuss these issues and how we manage them at Ancestry.com.