It can take up to nine months to deploy an entertainment (mobile) application, But that's the duration of a cell phone in this market.
-Craig Hayman, IBM (source).
Fragmentation is the inability to "write once and run anywhere". This article analyzes various aspects of fragmentation of mobile applications (sometimes called device fragmentation), such as the reasons behind it, the current state-of-the-art in tackling it, and the directions we can expect it to evolve in the future. The article is intended for both practitioners and academics seeking a reasonably in-depth understanding of fragmentation in mobile applications.
Fragmentation is the inability to "write once and run anywhere". More formally, it is the inability to develop an application against a reference operating context (OC) and achieve the intended behavior in all OCs suitable for the application. An operating context (OC) for an application is the external environment that influences its operation. While fragmentation can affect any type of application, in this article we focus on the fragmentation of mobile applications. Note that by "mobile applications" we mean installed applications, not SMS applications or Mobile Web applications.
Fragmentation stems from the diversity in OCs, which can be classified as follows:
Hardware diversity, such as differences in screen parameters (size, color depth, orientation, aspect ratio), memory size (heap, persistent), processing power, input mode (keyboard, touch screen, etc.), presence of additional hardware (camera, voice recorder), and connectivity options (bluetooth, IR, GPRS, etc.).
Platform diversity, such as differences in platform/OS (Symbian, Nokia OS, RIM OS, Apple OS X, PalmOS, Mobile Linux, Android, BREW,etc.), API standards (MIDP 1.0, MIDP 2.0, etc.), optional APIs, proprietary APIs, variations in access to hardware (e.g., fullscreen support, access to local storage), and differences in multimedia support (e.g., codecs), maximum binary size allowed, etc.
Implementation diversity, such as quirks of implementing standards (different interpretations of the standards, bugs, etc.). Incidentally, fragmentation resulting from implementation bugs/quirks is one of the most tiresome type of fragmentations, according to practitioners.
Feature variations, such as light version vs full version
User-preference diversity, in aspects such as in language, style, etc., or accessibility requirements
Environmental diversity, such as diversity in the deployment infrastructure (e.g., branding by carrier, compatibility requirements of the carrier backend APIs, gateway characteristics, opened ports, restrictions on access to outside the network etc.), locale, local standards.
As we can see from the above, one OC can differ from another due to many factors. Let us call these factors fragmentors. i.e., a fragmentor is a factor, diversity of which causes fragmentation.
The fragmentation of mobile applications is often referred to as device fragmentation, because most of the fragmentors can be traced to a particular device model. However, this is a misnomer, as fragmentation can be caused by fragmentors outside the device (e.g., branding by carrier).
Application users, developers, content providers and distributors, network operators and device manufacturers are all affected by fragmentation. Here, we look at how fragmentation affects an organization developing mobile applications.
Fragmentation complicates all disciplines (disciplines as defined in the IBM Rational Unified Process) of a mobile software project. Some examples are given below.
As a result of these complications, fragmentation increases the required effort in almost all aspects of software life cycle, driving up the cost, and lengthening the time-to-market. Other side-effects are:
It may reduce the quality of the product - Having to support a large number of OCs could complicate the application, increasing the probability of bugs. Cost considerations may tempt developers to release applications that behave in sub-optimal ways for certain OCs (E.g., an application may work well for certain screen sizes, but may appear distorted in certain other screen sizes).
It may narrow the target market - Cost considerations may force the application vendors to target a smaller market than the actual potential market it could target otherwise (see the figure above for an illustration).
It imposes barriers to entry into the mobile application market, deterring smaller players from entering the market, and hindering the growth of the market. This is because supporting a mobile application on a large number of devices is more complicated than doing the same for a desktop application of similar size.
In the current state of the practice, it is almost impossible to write a single version of a mobile application that can run on every (or at least a majority of) mobile device available. Practitioners say that sometimes one can end up having 400 or more different versions for a single application [source: De-frag2006]. It is also generally accepted that fragmentation is a complex issue that cannot be solved easily, or completely [sources: De-frag2006, JW2004]. Since it is the diversity that drives fragmentation, a closer look at diversity may provide us with clues as to how to deal with fragmentation. Diversity can be thought of as belonging to one of the two types below.
Above analysis hints that one approach to reduce fragmentation is the elimination of accidental diversity. Measures such as better standardization (e.g., less optional APIs, more detailed specifications), stricter enforcing of the standards (e.g., using API verification initiatives, Technology Compatibility Kits) can help in this regard. Major players in the mobile application industry (such as platform vendors, device manufacturers, and operators) have a critical role to play in this front of the war against fragmentation. Such an effort in the Java ME arena is the Mobile Service Architecture (see [MSA] for more info).
On the other hand, essential diversity is here to stay. The pragmatic response here is to find ways to reverse the resulting fragmentation. Let us call this de-fragmentation. Note that de-fragmentation is NOT eliminating diversity. Rather, it is the process of making the application behave as intended, on all target OCs.
This section summarizes how today's mobile developers go about de-fragmenting applications. Click here for a more detailed version of this section, with graphical illustrations of each approach.
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
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
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.
Arguably, traditional applications (i.e., desktop applications, web applications/sites) have to deal with more diversity in OCs than mobile applications. For example, if resizing is allowed, a traditional application can have many more screen sizes (here, screen size = area occupied by the application) compared to available screen sizes in mobile devices. However, one does not hear about an equivalent of a fragmentation problem in the traditional application domain. Possible reasons for this include:
Issues: Should we treat MAPL different from a traditional product line? What lessons can we learn from traditional product line world that we can apply to an MAPL?
The Mobile Web is the Internet (both web sites and web applications) as accessed from mobile devices connected to a public network. Web site contents (usually in XHTML or WAP) may get fragmented, due to diverse display capabilities of devices. Mobile-Web applications, when compared to non-Web (i.e., local) mobile applications, has the advantage that most of the processing is done on the Web server, unaffected by the diversities in the OC. The application UI still operates on the device, and prone to fragmentation just as any other mobile application. Since the UI is generated by the Web server on-the-fly, a mobile-Web application has the option to use a run-time form of the DERIVE-MULTI approach, where the OC-specific version is generated on-the-fly and sent to the device. One interesting avenue to explore is the applicability of UI=Markup+Stylesheet approach used in Mobile-Web to manage UI fragmentation in local mobile applications.
SMS applications too live on the server-side, accessed via SMSes sent from phones. Therefore, the fragmentation of SMS applications is less compared to installed mobile applications.
Theoretically, a Java ME application is able to run on any Java-enabled mobile device. This means a Java ME application can target a much wider range of OCs as compared to non-Java applications, making it susceptible to more fragmentation. In addition, the "freedom for differentiation" (which is not entirely a bad thing) allowed in Java ME world is another reason behind the high-level of fragmentation of Java ME applications.
As non-Java platforms (e.g., Symbian) are created for a smaller range of devices, platform vendor can have tighter control over aspects such as implementation diversity, reducing the fragmentation within the platform. However, developers may still have to develop a Java ME equivalent as well, if a wider range of OCs is to be targeted. Another problem area for non-Java applications is that unlike Java ME applications which run on an abstract virtual machine, non-Java applications directly access the underlying firmware/hardware, and could fragments more due to diversity in the hardware/firmware.
Fragmentation in the Android
platform appears to be less at the moment, but this could be simply because it is
not yet used in a wide range of OCs. The
Open Handset Alliance
(OHA), who is backing Android, have signed a "non-fragmentation agreement" [source].
Depending on the details of this agreement, this could stop various
implementations of Android being incompatible, taking away one of the causes
of fragmentation (I stress, just one) .
Here are some notable/interesting opinions about fragmentation, voiced by those interested in the problem...
From the panel discussion at Java mobile and embedded developer day session [JMEDD08]:
"Part of our skill set as a company is that we understand and can deal with
fragmentation issues. This is for both application development and the
provisioning side of things but it still drives me mad. Sometimes the choices
the manufacturers and network operators make seem retarded and I end up very
--From the blog: Jason Delport's Mobile Observations
... this guy stood up and said "but... err, some of us have a real business
based on and thanks to fragmentation"
-- C. Enrique Ortiz, (in Jason Delport's Mobile Observations blog)
"Device fragmentation makes our products (not only games) a lot more
expensive than say Web Flash Games. The energy we had to put into our porting
solution and the extra work during development is at least as much as the raw
game development time. Hence our pricing cannot compete with pricing for web
development. Plus it is a huge, unnecessary hurdle for newcomers. Due to device
fragmentation, setting up a store for mobile games and applications needs deep
knowledge of the matters. It's not like everyone can create software and sell it
through their homepage (or wap page). Also, most tried and tested concepts
(shareware, demoware...) fail due to device fragmentation, the inability to copy
free software from one device to another (which is again due to device
fragmentation and to a certain extent to DRM locks) and an easy to use and fair
worldwide payment system"
--Reto Senn (Bitforge)
"One aspect I like about
this document is the
acknowledgment that device fragmentation exists, it is here to stay to a large
extent and people from the academia can deal with it (instead of making believe
that the problem does not exist as W3C has obviously been doing for 3 years
--Luca Passani (in Oxford University Next Generation Mobile Applications Panel)
"I like to remind myself why is fragmentation actually an issue; Because it
impacts on the developer's ability to make money. If as a developer I could
focus on a single handset that had sufficient volume, and get a decent price for
my application that the end user is looking for, all would be great, and why
would I care about fragmentation. (Some developers are doing this with the
Series 60 environment) Or, if as a developer, I actually got to keep 50% of the
revenues, rather than 10 -25% I might have a chance. Unfortunately, neither of
these cases look like they will be changing anytime soon"
--Richard Mardon (in Oxford University Next Generation Mobile Applications Panel)
"...in a typical development cycle, porting and testing can consume from 40
to 80 percent of your time, depending on your level of experience and on the
number of devices you need to support."
--Bruno Delb (in [DevXPP2006])
"... This problem (of fragmentation due to platform diversity) is not unique
to Java ME – it exists in many other areas of the standards world – and the
solution is well understood: an “umbrella specification” needs to be created
that will define a minimum set of component APIs that must be included in
compatible implementations and that will also eliminate optionality from the
--Patrick Curran (in [JDJMES08])
"... I think I've experimented with all the techniques. I personally think that the DERIVE-MULTI techniques are well adapted for one-shot products, like Games, while the SINGLE-ADAPT are more adapted to long term product that require constant evolution."
-- Thomas Landspurg (in TomSoft blog)
Tom Godber (in [TMF2008], on the importance of customization): "...For a professional installed application that will see frequent and prolonged use, optimizations are 100% critical to the project's success. The interface must react exactly how the user expects it to, looking and feeling familiar whilst also presenting an attractive, professional and branded appearance."
“Some mobile application vendors take a chance claiming compatibility with a
wide range of devices, and then handle possible issues via technical support and
free-of-charge software upgrades.”
-- Anders Borg (in an email response to this article)
De-fragmentation is reversing fragmentation. De-fragmentation is NOT eliminating diversity. Rather, de-fragmentation is the process of making the application behave as intended, on all target OCs. E.g., MANUAL-MULTI is a de-fragmentation approach, so is SELF-ADAPT
Device fragmentation: The fragmentation of mobile applications is often referred to as device fragmentation, because most of the fragmentors can be traced to a particular device model. However, this is a misnomer, as fragmentation can be caused by fragmentors outside the device (e.g., branding by carrier).
Fragmentation is the inability to "write once and run anywhere". More formally, it is the inability to develop an application against a reference operating context (OC) and achieve the intended behavior in all OCs suitable for the application.
Fragmentor: A fragmentor is a factor, diversity of which causes fragmentation. E.g., screen size, maximum executable size
Installed (mobile) application: An application installed in the mobile device (i.e., not a mobile web application or an SMS application)
Mobile Web application: An application accessed using a mobile device, over the Internet. A mobile web application runs on a server, and the mobile device only acts as a browser-like client.
Operating Context (OC): An operating context (OC) for an application is the external environment that influences its operation. Therefore, the OC for a mobile appliation is defined by the hardware/software environment in the device, as well as the target user, and other constraints imposed by various other stakeholders (such as the carrier). For example, consider the following two OCs targeted by a mobile application: [OC1: target device=Nokia N90, target user=subscribers of carrier A] [OC2: target device=Nokia N90, target user=subscribers of carrier B]. Here we assume that the application code needs to be different for OC1 and OC2, perhaps because it needs to access an carrier-specific API. Note how both operating contexts are for the same physical device.
SMS application: An application accessed using a mobile device, using SMS as the mode of communication
Originally, I wrote this article for the benefit of my students starting research projects in the area of mobile application fragmentation. In realizing the wider applicability of the article contents, I have now evolved it to a form intended for anybody with an interest in application fragmentation issues, but particularly for developers entering the mobile application development arena, and for researchers venturing into research in this area.
I plan to continuously evolve and expand this article as my research in this area progresses. Among other things, I plan to do a comprehensive evaluations of the tools/techniques currently used to manage fragmentation.
I would love to hear from you about what you think about this article; Any
tools/techniques/approaches/observations I have missed? Any point above you
this link to post your feedback, or to see what
others had to say... All feedback will be gratefully acknowledged in the
You can also contact me directly at damith[at]comp.nus.edu.sg
I'm Damith C. Rajapakse. I work as a lecturer at National University of Singapore, School of Computing. My research interests include various aspects of engineering mobile applications. My home page is http://damith.info
[share this on: Reddit | Digg | del.icio.us | Fark | Slashdot | Stumbleupon]
[http://mobilefragmentation.info - All rights reserved - Version 2.6 - 28th April 2008]