Android Development Series, Part 2: Keeping Your Apps Compatible

Android Development Series, Part 2: Keeping Your Apps CompatibleWell, it looks as if I am continuing this series, so on to the next topic: compatibility. Android is developed at a speed that far outpaces traditional software (as is the norm with most Google products), so every few months there might be some major changes you need to deal with in your application. That’s easy to stay on top of, though, as once an app is written, keeping it up to date with the latest version of Android is fairly straightforward and well-documented.

But what if you are creating a new app, or you’re updating a really, really ancient app and want to keep it compatible with all Android versions, past and present, even across major architecture changes? Google acknowledged that this would inevitably happen, so the Android team released the Android Compatibility Library (now known as the Support Library). Within, it contains various chunks of the modern Android framework broken down so that it can be used in older Android versions. With the help of this suite of support classes as well as a few other tips and tricks, your Android app can stay compatible across many different Android versions as well as up to date with the latest design patterns.

The Support Library

As was stated before, the Android team released the Support Library to assist developers in writing applications that could easily and smoothly span across multiple Android versions while taking advantage of the latest features in the framework. Perhaps the biggest example of this is Fragments. The Fragments API was added in Android 3.0 (Honeycomb) in order to provide a solution for the growing number of varying screen configurations. Using Fragments to split up your user interface allows you to mix and match pieces of UI and logic in multiple screens of your application while, at the same time, reusing the bulk of your existing code. With the introduction of the Support Library, the advantages of Fragments have been brought to earlier Android versions, and can be used to spruce up the UI and user experience (UX) of any application. Perhaps this most definitely comes in handy for Android tablets that run a version of Android earlier than Honeycomb, enabling them to make better use of their large screens.

The Support Library also features various implementations of patterns specified in the Android design guidelines. Perhaps most notably there exists ViewPager, which allows you to swipe between multiple views (looks and works great in cooperation with Jake Wharton‘s ViewPagerIndicator Library). The support package also allows access to Honeycomb’s Loader API, which enables painless multi-threading for your application while integrating nicely with the UI.

The Action Bar

One of the most prominent changes that Honeycomb brought with its introduction is that of the Action Bar, a central location for application navigation and operation. The Support Library, however, does not provide an implementation of the Action Bar for use in Android versions prior to Honeycomb. So what is there to do? Turn to the community, of course. Specifically, turn again to the amazing Jake Wharton and the ActionBarSherlock Library, which uses the native Action Bar implementation on versions of Android that provide it while falling back to its own implementation when an application is run on earlier Android systems. If you want to write a modern Android application, the Action Bar is without a doubt one of the most crucial components, so make sure it is present across any configuration your app might come up against.

Some Other Tips

When programming your Android application, you might encounter a situation where you need to use a method provided by a new platform version that does not exist in prior Android versions. The solution is to check the platform version of the device running your app at runtime, like so:

/* Perform ICS method */
} else {
/* Perform backwards-compatible method */

It’s as simple as that.

Another thing you should make sure to do is set the target SDK version in your application’s AndroidManifest.xml to the latest version possible, which at the time of this article’s writing is 15. Also, if you can help it, do not set a maximum SDK version. Android is built to be, for the most part, forwards-compatible, so unless your application does some really funky stuff, you are probably safe to assume that it will run fine on future Android versions. If it turns out that it does not, simply push out an update to your app when the time comes — no harm done.

And with that, this article comes to a close. I hope this series is being enjoyed so far. Also, feel free to let me know in the comments what the LockerGnome community would like to see written about! Next time, who knows? I’ll talk about preparing your Android application for space.