Android invasion

Today’s post was written by guest blogger Richard Reece. Richard is a senior consultant with Rocket Farm, specializing in both iOS and Android application development.  We asked Richard to talk about his strategy for handling device fragmentation when developing for Android.  Here are his thoughts:

Some of this will be client dependent, but here’s my perspective on handling Android fragmentation. The main driving goal is to get to an MVP, or minimum viable product.
Device testing: If available, target the two to five devices that have topped the target market over the past year. One testing device should be a Nexus 5 (or 4) — it is a Google device and serves as a reference design. My primary development device is a Nexus 5.
The emulator also supports a wide range of configurations, layouts, and processors, though it is limited because it won’t represent the actual hardware implementation of every manufacturer.
OS versions: The last chart of this TechCrunch article is the most important; there’s a strong correlation between a country’s GDP and the penetration of the latest versions of Android.
Given the dominant structure of the US mobile market — with new or upgradable phone options at the start of each two-year contract cycle — probably 80 percent or more of the US market has an Android OS that is less than years old. This translates, roughly, into version 4.1 (Jelly Bean) onwards (though if one has Jelly Bean it’s probably been upgraded to 4.3).  A quick look at AppBrain stats comes up with the same number.
OS and development: My strategy is to develop, test, validate, and get to MVP on the latest OS version (currently 4.4.2, which has a 20 percent adoption rate). This is where the market is going, and the devices are notably faster and “sexier” for testing and demo purposes. Once the client accepts the features and flow, I’ll fold in testing on earlier versions like Jelly Bean and make any necessary adjustments. From 4.1 through 4.4 there shouldn’t be too many issues, but there are libraries and work-arounds available if any issues are found.
The idea is to reduce the risk and time spent developing compatibility work-arounds for features the client may wind up changing or not accepting or caring about. In the end, the client may just want to support the latest version if the cost of making a specific feature backwards-compatible is too high.
I don’t recommend going further back than 4.1 unless there’s a very compelling business reason supported by solid market data.
Architecture: Android does provide quite a few built-in/best practice structures for
handling multiple screen sizes. We follow these, within the constraints of the selected OS version. As with iOS, most Android layouts will scale to fill the screen; depending on the layout and the device, the
UI/UX may not be optimal, but it will run.
Graphics: Minimum of four versions of everything at recommended sizes. Might require more for new screens.
Layout: Use the recommended layout structures (“Fragments”) that can be used in the
phone, then tweaked for tablets to take advantage of the larger amount of screen real estate. The tricky part comes with some of these large phones: Is it a tablet or a phone?
Hardware: This is the “unknown unknown” territory, where our code meets a hardware implementation. Sometimes OEMs indicate they support an API but return 0 (no data) — the API passes the Android compatibility/acceptance test, but will not provide the data we want. Documentation on such issues is often sparse or non-existent. Stack Overflow is usually the best source here: Someone, somewhere in the world has probably encountered the feature/bug before.
So the development strategy is to pay a lot of attention to the areas where our code meets deeper-level hardware control; test and research via Stack Overflow to see where there might be an issue even if we don’t see it our test devices; then add defensive code to make sure things won’t collapse if the outlier is encountered.