Fragmentation of Mobile Applications

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).

Summary

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.

Introduction

What is it?

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.

Causes of fragmentation

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.).

• Software diversity:

  • 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).

Why should we care?

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.

• Business modeling: Business analysts have to figure out the optimum set of OCs for the application to target. Questions such as the following may need to be answered.
  • Is device D1 a suitable platform for application A1?
  • Is it worth fitting application A1 to operating context OC1? Resulting in further questions such as "What is the extra effort required to fit A1 to OC1?" and "What is the size of the market represented by OC1"?
• Requirements management: Interaction between the user and the application may differ based on the OC, complicating the usecase specification. The vast number of different OCs is likely to result in many exceptional and alternate flows. Analysts may need to have an in-depth knowledge of the OCs.
• Analysis and design: The system architecture, and the detailed design, should be able to accommodate not only all the variations demanded by different OCs targeted at the time, but also future OCs the application will be exposed to during its lifetime.
• Implementation: Implementers need to fit the application to all the targeted OCs. Questions to answer include
  • What do I have to do to fit application A1 to fit operating context OC1?
  • How does OC1 differ from OC2? Which OCs can be served by a single version of the application?
• Testing: The application need to be tested for all targeted OCs. It may not be enough to test on device emulators, as real devices sometimes behave differently from the emulators.
• Project management: Fragmentation of the application will complicate the project planning. For example, having to accommodate new (and unexpected) OCs will complicate project scheduling.
• Configuration and change management: Having a large number of SKUs (Stock Keeping Units) will clearly impact this discipline. As more devices enter the market continuously, and platform software continues to evolve, the application may require porting to new OCs, requiring substantial changes to the existing code base.
• Environment: The software process has to be augmented to cater for additional complications introduced by fragmentation. Additional tools will have to be brought into the process, to tackle various fragmentation issues.

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.

What can we do about it?

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.

• Essential diversity: This is the diversity that differentiates a product/service in some useful manner. This kind of diversity is intentional and often unavoidable. For example, users will continue to differ in their preferred size for a device, and the device manufacturers will continue to differentiate the devices in terms of size.
• Accidental diversity: This is the diversity that - does not serve any useful purpose, is often introduced unintentionally, and is often avoidable. For example, diversity due to API implementation bugs/quirks is unintentional, avoidable, and does not serve any useful purpose

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.

A quick guide to the rest of this document

• Different approaches to de-fragmentation
  • MANUAL-MULTI, DERIVE-MULTI, SINGLE-ADAPT
  • Observations
• Other facets of the fragmentation problem
  • Fragmentation in traditional applications
  • Fragmentation and product lines
  • Fragmentations in the Mobile Web and SMS applications
  • Java Vs non-Java applications
• Future of the fragmentation problem
• What others say...
• Related resources
  • Tools/techniques
  • Online articles
  • Tutorials/guides
  • Data sources
  • Some statistics
• Glossary
• About this article
  • How it came about and where it is going...
  • Giving feedback
  • Acknowledgements
  • About the author

Different approaches to de-fragmentation

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.

MANUAL-MULTI

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)

DERIVE-MULTI

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.

SINGLE-ADAPT

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.

Other facets of the fragmentation problem

Fragmentation in traditional applications

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:

• Ease of controlling diversity: In some situations, adjusting your OC to fit the application is a viable alternative to adjusting to application to fit the OC. For example, it is possible to limit resizing the application, or to force the user to use a “recommended” browser/resolution for a given application.
• Less stringent resource restrictions: One indirect reason for fragmentation in mobile applications is the need to make the best use of already-scarce resources in a mobile device. For example, the UI should make the best use of the rather small screen, and the application should be optimized to work within the small memory space available in the device. But a PC has access to more resources than a mobile device, and it is not necessary to optimize an application to tightly fit into the OC in a PC. Hence, a SINGLE-ADAPT approach has a better chance of  succeeding when applied for traditional applications. For example, a Web applications can use the processing power of the host machine to generate customized UIs for each user, from a single code base, at run-time (i.e., an ALL-IN-ONE solution). Furthermore, an AIM-LOW solution in the traditional application domain has a better chance of acceptance than in the mobile application domain. For example, a traditional application built for the low resolution of 800x600 may deliver a reasonably acceptable user experience for users having better resolutions, while a mobile application that is built for a very small screen may disappoint many users with bigger screens.
  

Fragmentation and product lines

• Size of the product/product line: An MAPL typically has a higher number of members, and the size of the product is smaller than most traditional applications. This reduces the cost effectiveness of the MANUAL-MULTI approach in a MAPL.
• Starting point: A traditional product line may start with a single application for a single customer, and later it may (or may not) evolve into a product line, based on customer demand. An MAPL already starts with having to develop multiple members.
• Variability: Differences between MAPL members tend to be finer-grain and more predictable (e.g., most differences between OCs are already known).

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?

Fragmentation in the Mobile Web and SMS applications

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.

Java Vs non-Java 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) .

Future of the fragmentation problem

• Increased capability of devices: This results in less-stringent resource restrictions, which can lead to less fragmentation, as explained in this section. For example, ALL-IN-ONE applications can harness the extra resources to become adaptable for more OCs.
• Desktop-class mobile applications: As devices become more capable, there is more potential for feature-rich, mission-critical (and consequently larger, and more complex) applications to move to the mobile platform. This is likely to exacerbate the fragmentation problem. Specifically, it will increase the effort required to fit one application to multiple OCs.
• Growing number of new device models: Even released applications will continues to fragment, as more and more new OCs need to be supported. This fragmentation may be hard to predict, or plan for. It also becomes necessary to identify OCs no longer cost-effective to support.
• Drive towards more standardization: While hardware and software vendors can try to tighten specifications (e.g., MSA), and enforce more stringent implementation of specifications, certain aspects of the diversity will be hard to avoid. For example, it is not practical to prevent device vendors from including additional hardware/software in the device.

What others say...

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]:

• Fragmentation is a big problem, and a tough problem to solve (this opinion was voiced by many participants), and it won't be solved anytime soon. It is multi-faceted and not yet understood fully. For example, different people use the term "fragmentation" to mean different things. First, we need to define the problem clearly.
• Economics play an important role in our ability to overcome fragmentation. For example, carriers are exacerbating the fragmentation problem by imposing various restrictions to gain economic advantages.
• Developers need access to fragmentation-related information (e.g., how many phones support a given feature?)  and better tool support to access such information (e.g., through the IDE).
• A "benevolent dictator" approach (rather than the more democratic approach currently used in defining standards) may be able to reduce some of the optionality in standards, but then again, this is just one of the causes of fragmentation.

"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 frustrated."
          --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 now)"
          --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 component specifications"
       --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)

Related resources

Tools/techniques

• Netbeans Mobility Pack is a plugin to the Netbeans IDE. It  can be used to write, test, and debug Java mobile applications. It tackles the device fragmentation by enabling developers to edit and compile custom configurations for each device.
• Eclipse Mobile Tools for Java Platform (MTJ)  is a project to extend eclipse platform to support Java mobile application development. The purpose is to develop both frameworks that can be extended by tool vendors and tools that can be used by 3rd party mobile java application developer.
• J2MEPolish  is a collection of tools for developing J2ME applications. Among other things, it includes build tools for creating application bundles out of one source project - for multiple devices and multiple locales, and a device database which can be used to adjust your application to different handsets with Preprocessing.
• Antenna provides a set of Ant tasks to compile, preverify, package, obfuscate, and run Java mobile applications targeted at the MIDP. A small preprocessor allows to generate different variants of a MIDlet from a single source.
• TiraJump is a combination of technology and knowledge for planing and executing mobile content deployments. Its device knowledgebase contains information about 1000+ devices and maintains specific guidelines to help adapted content pass operator submission and certification programs. Tira Jump automatically packages payloads based on operator requirements such as folder structure, file naming and supported handsets.
• Device Anywhere  is an online service that provides remote access to hundreds of real handsets, on live worldwide networks, remotely over the Internet, to develop/port/test mobile applications. 
• Paxmodept Java ME (J2ME) Application Provisioning Platform : A platform that includes a Java ME specific device profiling component which ensures that the requesting device always gets an appropriate application version.
• Mobile Service Architecture (MSA) : MSA is a Java ME optional package that defines the next generation Java ME platform. MSA gives an application developer an expected set of APIs/JSRs implemented on an MSA-supported device. The optional features that are defined in specifications have clarifications attached to them to remove some of the optionality or better clarify any ambiguities. MSA is also expected to reduce the amount of work of having to create different versions of an application and needing to test those different versions. MSA doesn't define a quality level for the implementation, which is up to all device manufacturers to define and meet, but it defines a set of APIs that must be made available for application developers to use, making it easier for the application to be supported across over MSA supported devices [MSASDN].
• Cactus is a tool for rapidly creating extremely customized user interfaces, and has fine-grained control over the behavior of these interfaces. Cactus also works around some common bugs or limitations of handsets, and eases the porting an application across a wide range of devices.
• DetectRight: a search engine for mobile device specifications, an API, a device detection engine and a toolkit for mobile device development
• MoSync :  MoSync comes with a set of device profiles to help developers deploy their C/C++ applications to the wide range of mobile devices. These profiles define the characteristics and capabilities of each individual mobile device and are used during build time to dynamically tailor the application for each device. Each device profile holds device information such as the screen size, memory capacity, and available features, such as Bluetooth. When building MoSync applications, you specify which features your application requires, eg. Screen width larger than 100 pixels and Bluetooth availability (or the vendors/models you want to target), and MoSync automatically customize the application for the relevant devices.
• Volantis Suite of Mobile Content Applications™ a mobile content platform to deliver customized contents across multiple channels. Volantis enables a single application or service to provide contents consistently across thousands of different devices.
• Alembik is a search engine to find addressable phones, depending of the features of the application
• Celsius is a suit of tools aimed at easing the pain of porting JavaME applications
• JavaGround's Xpress Suite is a solution for mobile application development and deployment, aiming to enable worldwide distributions on all mobile platforms. It supports automatic conversion from JavaME to BREW.
• Some other relevant tools: Intohand's ICAPS, Innawork's alcheMo

Disclaimers:

Online articles

• [DevXAOP2006] Use AOP to Help Get Mobile Content to Market Faster - A DevX article by Allan Lau
• [CNET2005] A CNET article about fragmentation : 'Write once, run anywhere' not working for phones by Ben Charny
• [CJP2006] An in-depth analysis of fragmentation in JavaME applications (2006): Compatibility and the Java™ Platform
• [JDJMES08] Patrick Curran's article "Mobile and Embedded Spotlight" in Feb'08 Java Developer Journal has a section on fragmentation
• [JMEDD08] A video recording of the Java mobile and embedded developer days 2008 session on fragmentation (If the link doesn't work, go to this page and click on the video titled "Fish Bowl & Wrap")
• [JW2004] A JavaWorld article about fragmentation: The fragmentation effect: A look at how device fragmentation influences J2ME application development by Allen Lau
• [MSASDN] An SDN "Ask the experts" session about Mobile Service Architecture
• [OPMINI2006] Developer case study: Managing Java fragmentation, Opera Software's Java ME browser client
• [TMF2008] The Truth About Mobile Fragmentation, a blogpost by Tom Godber

Tutorials/Guides

• [DevXNB2005] A DevX article on how to Tackle Device Fragmentation with NetBeans and the NetBeans Mobility Pack by Jim White
• [DevXPP2006] Automate Your J2ME Application Porting with Preprocessing - A DevX article by Bruno Delb, illustrating the use of Antenna to preprocess J2ME applications
• [De-frag2006] Java ME: De-fragmentation Technical Overview and Design Guidelines Index  
• [GAP2007] The article "Global Authoring Practices for the Mobile Web" by Luca Passani  contains good practices to follow when writing contents to suit multiple devices 
• [MobWeb2007] DotMobi's "Mobile Web: Developers' Guide (Part I)" discusses many aspects of the fragmentation problem with respect to optimizing web sites for mobile devices
• [MSDN2007] An MSDN tutorial explaining how to develop a WinCE application in a device-independent manner: http://msdn2.microsoft.com/en-us/library/bb278110.aspx
• [NBMP2007] A look at how the NetBeans mobility pack tackles fragmentation : http://www.netbeans.org/kb/55/mobility-devicefragmentation.html

Data sources

• [ADMOB] Monthly statistics about the popularity of mobile phone models from Admob
• [JMEISS] A list of known issues in JavaME devices, hosted at http://j2mepolish.org : http://www.j2mepolish.org/devices/issues.html
• [LDJME] List of devices supported under JavaME: http://developers.sun.com/mobility/device/device
• [MOBREF] Monthly statistics about device/vendor market share from Mobref
• [MPW] Mobile Phone Wizards AS, a fully-functional Device Description Repository (DDR) containing a large publicly accessible database of detailed handset information, including a facility to generate various statistics.
• [WIREF] A collection of statistics about cell phone usage from Wirefly.org
• [WURFL] The Wireless Universal Resource File (WURLF), an XML configuration file which contains information about capabilities and features of many mobile devices, by Luca Passani

Some statistics

• Web-enabled mobile phones now extend the expected global reach of the Web to three times that of today, touching one-third of the population of the planet (source: T-Mobile, Credit Suisse First Boston and Pyramid Research report, as quoted in [source: mobWeb2007])
• The number of Internet-enabled mobile devices today is as twice as many as the number of Internet-connected personal computers (PCs). By 2010, it’s expected that half of the planet’s population will have access to the Internet through a mobile device (source: Informa Telecoms & Media (2007), as quoted in [source: mobWeb2007])
• There are over 700 different Java-enabled device models have been released so far (according to [LDJME])
• According to the J2MEPolish device database, there are over 40 different screen sizes in use today.
• In this article Stuart Dredge quotes Greg Ballard (CEO of Glu, a large mobile gaming company) as saying that for the game Transformers, Glu made 25,000 versions for different handsets, operators and languages

Glossary

• Adaptive: an adaptive application (in this context) is a one that has used the de-fragmentation approach called SINGLE-ADAPT

• 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).

• Device-independent: portable

• 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

• Fragmented: affected by fragmentation. If an application, when written against a reference OC, behaves in unintended ways in at least some OCs, then it is fragmented.

• 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.

• Portable: A portable mobile application is a one that is not (or minimally) affected by fragmentation, or already  de-fragmented

• Porting: porting is the process of fitting a fragmented application to a new OC (or more). Porting involves one or more de-fragmentation techniques

• SMS application:  An application accessed using a mobile device, using SMS as the mode of communication

About this article

How it came about, and where it is going...

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.

Giving feedback

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 disagree with? Please follow this link to post your feedback, or to see what others had to say... All feedback will be gratefully acknowledged in the article.
You can also contact me directly at damith[at]comp.nus.edu.sg

Acknowledgements

• A number of sources listed under "Related resources" helped in shaping this article. In particular, the naming of various approaches (DERIVE-MULTI, etc.) was inspired by [De-frag2006]
• The analysis above on "essential diversities" and "accidental diversities" borrows from Fred Brooks' seminal book "The Mythical Man-Month", in which he talks about "essential difficulties" and "accidental difficulties" of software development.
• Thanks to http://community.java.net/mobileandembedded/ for featuring this article on their website
• Contributions/feedback/encouragement from the following persons helped towards improving this article:
  Anders Borg (Abiro), Bertrand Louveau (MobileDistillery), Bhojan Anand  (National University of Singapore), Chris Abbott (DetectRight), Himath Dissanayake (OrangeHRM Inc), Kutila Gunasekera (Monash University), Jason Delport (Paxmodept),  Luca Passani (WURLF)  Mihai Fonoage (Florida Atlantic University), Michelle Nguyen (National Uni. of Singapore), Reto Senn (Bitforge), Ruchith Gunaratne (hSenid Software Intl), Roland Gülle (Sevenval AG) Terrance Barr (Sun Microsystems), Thomas Landspurg (Webwag, In-Fusio), Tom Godber (Masabi), Tom Hume (FuturePlatforms)

About the author

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]