Device Fragmentation of Mobile Applications

This page is a part of the article on Device Fragmentation of Mobile Applications

Different approaches to de-fragmentation

In this section, let us look at how today's mobile developers go about managing fragmentation.

MANUAL-MULTI

The most primitive way of managing fragmentation 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 alternative approaches 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.
Issues: Can we easily localize all such variations into interchangeable components? Techniques used here (e.g., dynamic binding) may impact run-time performance.
E.g., When using J2ME Polish, we can put an image file in the resources/ScreenSize.240+x320+ folder, and J2ME Polish will include this image for devices with a screen size of at least 240x320 pixels.

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.
E.g., NetBeans Mobility pack uses a concept called preprocessor blocks to specify OC-specific code segments.

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.
E.g., Tira Jump uses aspect oriented programming techniques to INJECT OC-specific variations. It lets developers write the application code against a reference OC and derives OC-specific versions by “weaving” OC-specific variations into it.

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 manually embedded by the programmer, generator uses its inbuilt knowledge in the generation process, requiring less manual coding than in the META approach.
E.g., alcheMo tool promises to automatically generate BREW format applications from JavaME applications.

Issues: Not all variations can be automatically deduced by a generator. Once generated, the generated versions may need to be maintained separately (if further manual modification are done to the generated code).

While the three approaches under DERIVE-MULTI still result in multiple versions of the application, there is only one code base to work on, and therefore the effort required may be less than in MANUAL-MULTI. In particular, we no longer need to manually maintain duplicate copies of the same source.

Further issues (related to the three DERIVE-MULTI approaches):
• More sophisticated design techniques (and sometimes additional notations) may be required, adding to the complexity
• Good tool support required
• We may still have to test each version separately

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. This approach is sometimes referred to as the "lowest common denominator" approach.
E.g., designing the UI to fit the smallest screen size of the targeted device range.
ii) ABSTRACTION-LAYER: Use an abstraction layer that hides variations. The application will be developed using the API of the abstraction layer.
Issues: Overhead added by extra layer of abstraction.
E.g., TWUIK UI library promises to let developers write a single UIs that can adapt for multiple OCs.

Issues: Both above approaches risk underutilizing capabilities of the devices (E.g., The UI it may cover only part of the screen, or an optional feature may not be available through 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.

Issues: Runtime adaption affects space/time efficiency; The software will be bigger-than-necessary, and slower-than-necessary for most OCs in the target range

Observations

A combination of the above approaches can be used within a single application, using one of the approaches for each variation point. In fact, such a philosophy is central to the approach recommended by the "Java Orange Collaboration" [source: De-frag2006]:

A developer willing to maximize the number of compatible device per version must identify the platform and context variability points which are relevant to the application. Then, for each of those variability points, the right variability handling technique must be selected. There is no general rule for selecting variability handling techniques, since some techniques may have different impact on different kind of applications.

Issues: What are the trade-offs between the above approaches? How do we choose a range of OCs to target?

Click here to go back to the main article...