Device fragmentation is a major problem for mobile development. If you haven’t thought about how to cope with device fragmentation your mobile development efforts will fail big time!
What is Device Fragmentation?
Device fragmentation means that there is no dominant mobile development technology, instead there are a bunch of unrelated technologies. Currently we have iOS, Android, Blackberry, Bada, mobile web (including HTML5 variants). And that list changes every couple of years as consumers purchase new (smart) phones. Consequently none of the current technologies had a serious market share four years ago. The rate at which consumers are buying new phones means that it is unlikely to see any convergence in the next five years. There are simply too many companies trying to carve out their stake of the smartphone market by adding their own technology with associated development tools. Device fragmentation holds true even if you focus on one technology. For example iOS developers have to take into account iPhone’s (3G up to 4GS) iPads and iPod touch. Android developers have a much worse time with variations on screen size, keyboards and even custom handset operating system builds.
Ignorance is bliss!
A lot of people simply ignore device fragmentation. I’ve heard the following statements (But never from anyone actually developing for mobile):
- Device fragmentation doesn’t exist because the W3C says so
- HTML5 will solve everything, eventually
- Everyone has an iPhone nowadays
- Everyone has a Blackberry nowadays
- Microsoft will smash all competition and everyone will have a Windows phone
I used to try and explain why the above is false, and sometimes i would just smile like the cheshire cat and wait for my blood pressure to drop to acceptable levels. That was until i ran into the following well thought out overview of strategies to cope with device fragmentation. It’s a couple of years old but still holds true: Fragmentation of mobile applications (by Damith C. Rajapakse). It outlines nine stragies to cope with fragmentation on mobile devices. Better still, it has nice diagrams that you can show to your boss. There are three main strategies and a bunch of variations. The abbreviation OC means Operating Context = hardware/software environment:
The most primitive de-fragmentation technique is by manually developing distinct versions to suit each different OC. Let’s call this approach MANUAL-MULTI. These distinct versions will be largely similar, but also different in subtle ways, in response to subtle variations in the OCs. Copy-paste-modify techniques are commonly used to “port” the application to various OCs.
MANUAL-MULTI approach results in duplication of work , thereby increasing the required effort in many aspects of software development (e.g., imagine fixing a bug in 400 different versions!). There are two alternatives that try to minimize such extra effort:
1. Derive OC-specific versions from a single code base (DERIVE-MULTI)
2. Use a single version to serve multiple OCs (SINGLE-ADAPT)
In this approach we derive OC-specific versions from a single code base. This derivation may happen in three ways: selective packaging, using meta-programming, or using a domain-specific generator.
a) Selective packaging (SELECTIVE): Variations are localized into interchangeable components (e.g., classes, files, etc.). A build script (or a linker) creates one version for each OC, picking out only the components required for that particular OC.
b) Using meta-programming (META): This approach uses meta-programming (and similar code manipulation techniques) to specify how to derive OC-specific versions of the application. There are two ways of achieving this: the EMBED approach and the INJECT approach.
The EMBED approach embeds OC-specific variations in the source files using meta-programming directives/tags. A preprocessor derives multiple versions by processing these directives/tags.
The INJECT approach requires the developer to write the OC-specific instructions separated from the application code. A preprocessor combines the generic application code with the OC-specific instructions to derive OC-specific versions.
c) Automatic generation (GENERATE): In this approach, multiple versions are automatically generated by a generator that knows how to adapt a software (written in a generic way) to suit a specific OC. Instead of merely following directives embedded by the programmer, generator uses its inbuilt knowledge in the generation process, requiring less manual coding than the META approach.
The essence of this approach is that we build a single version that can work on multiple OCs. This approach can be further sub-divided into two: FITS-ALL and ALL-IN-ONE.
a) FITS-ALL: Develop a one-size-fits-all application that sidesteps all variations between OCs. There are two ways to accomplish this:
i) AIM-LOW: Use only the features supported in the same way in all OCs. For example, the UI will be designed to fit the smallest screen size of the targeted device range. This approach is sometimes referred to as the “lowest common denominator” approach.
ii) ABSTRACTION-LAYER: Use an abstraction layer that hides variations. The application will be developed using the API of the abstraction layer.
b) ALL-IN-ONE: Make the software adapt at run-time to a given OC, using one of the following two techniques.
i) SELF-ADAPT: The application discovers information about the OC and adapt itself to the OC at run-time
ii) DEVICE-ADAPT: The software is written in an abstract way, and the device decides how to adapt it to the prevailing OC, at run-time. This approach is commonly applied when dealing with fragmentation in the UI part of an application.
If you are a mobile developer its interesting to think about which one you are using. Happy reading!