Five ways to maximise Android device compatibility

Don't just be satisfied with a working Android app. Learn five essential development techniques to maximise application compatibility across Android’s massive range of devices…

Android App compatibility FIG 1

While you won’t always be able to completely avoid making assumptions, you need to minimise the ones you do make and understand the trade-offs of making them. Certainly there are times when you’ll want (or need) to make strategic decisions to limit your application in certain ways, but the less you do this, the more users you’ll be able to cater to.

You do, however, need to consider which differentiators apply to your project. As part of the design process, you should determine which application features are most likely to encounter differentiators in order to support them. For example, you need to be (at least somewhat) aware of the various screen sizes and resolutions available on Android devices. Sometimes, a good graphic designer can craft an Android user interface that looks great across all screen resolutions, aspect ratios and orientations (this, however, is a discussion for another day). Other times, they’ll simply want to make subtle adjustments based on specific criteria, which brings us to our first technique for supporting different device configurations.

Android applications can include alternative resources to load only when the device environment matches a set of criteria, including screen specs, input methods, language settings and device state. Layouts, graphics, strings and dimension values are common resource types to tweak based upon device settings.

An application might include alternative string resources that load only if the device is running in a foreign language. Similarly, developers might include alternative layout resources to load depending on whether the device is in portrait versus landscape mode, or different graphics to load based upon the screen size, aspect ratio or pixel density of the device. The Compatible project includes a number of alternative resources (Fig 4).

The application includes:
1. Different icon graphics for low, medium and high density screens.
2. A default layout and an alternative layout file for portrait-mode orientation.
3. Default strings (English, perhaps) as well as French string resources.
4. Dimension resources for small and large screens as well as default dimension values.

Alternative resources are stored in the resource hierarchy using special directory name qualifiers. The Android operating system does the rest, loading the appropriate resources based upon the device settings and state. For a complete list of qualifiers, see the Android Dev Guide on Providing Alternative Resources. Ideally, you design your application to use the use the smallest number of resources possible to keep the application package footprint reasonable and for maintenance purposes.

The Android SDK has been updated more than half a dozen times in the past two years. Exciting new APIs have been added, others have been deprecated. Classes have been renamed, functionality has changed. While it’s great that the Android development team is on top of things, this also means that users are running different versions of the platform. Some are stuck on older versions due to hardware limitations, while others are on the bleeding edge with their hot, new devices. Unfortunately, if a developer chooses only to support one group of users, they’re cutting out potentially 50% or more of the market – not good.

This means that developers routinely have to build applications that support multiple versions of the Android SDK, either simultaneously or by developing separate applications for each version. We tend to shy away from the whole idea of developing different versions of the same application for subtly different devices because this causes all sorts of maintenance and support headaches.

Since we refuse to bow to the whims of a specific device differentiator, instead we do our best to incorporate its quirks into our application designs. So let’s look at three ways in which developers can stick to a single codebase and support device differences simultaneously…

The manifest file is used to define the configuration details of an Android application. It can also be used to specify any system requirements necessary for the application to run properly. Developers can specify which versions of the Android platform an application supports within its Android manifest file using the <uses-sdk> tag. The <uses-sdk> manifest tag is enforced by the Android operating system. It is also used by the Android Market to filter applications to the appropriate devices.

Continue to page 3…

[twitter username=”linuxusermag”]