Java ME: De-fragmentation Technical Overview and Design Guidelines Index

Print-friendly Version

Together SUN and Orange have worked to produce this set of guidelines for Java ME Platform programming that aim to reduce the practice of generating a distinct executable version (jar file) of an application for each and every phone.

This practice of creating so many versions is not only costly and wasteful of resources it is confusing to the end user and it inhibits the growth of the market for Java ME Platform.

These guidelines look at some of the causes of fragmentation, and offer suggestions as to how an application may be written to achieve the optimal balance of application performance and coverage of a large number of phones.

So, to use these guidelines, look at the capabilities that your application needs, for example screen output. Look at the guidelines for re-sizing images, determine what tolerances will work for your application, and apply the techniques to use one image to cover a range of varied screen sizes where the variation is relatively minor. The same can be done to cover different keypad inputs.

Generating one version to cover all phones is unlikely, but the fewer versions means a wider market and lower costs.

So to maximize the number of compatible devices per version, identify the platform and context that is relevant to the application. Then, for each point of variability, choose the technique to handle it. There is no general rule for selecting variability handling techniques, since some techniques may have different impact on different kind of applications.

In presence of a context or device variation likely to impact the number of versions of an application, we have identified six main options to work around it:

1. Incorporate target specific source code fragments and use a pre processor to generate target specialized builds. We call this technique pre processing (PP)
   
   
2. Write an abstraction layer and target-specialized sub-components. We call this technique linking (LINK).
   
   
3. Re-implement the software component with the variable behaviour. E.g. a small GUI on top of the Canvas item. We call this technique re-implementation (IMPL)
   
   
4. Abandon usage of the software component with the variable behaviour. We call this technique drop (DROP).
   
   
5. Application determined runtime adaptation (subjectively initiated adaptation - SUBJ) e.g. to query the platform particularities and adapt to them, such as screen size.
   
   
6. Data-driven runtime adaptation (objectively initiated adaptation - OBJ) e.g. soft key codes.

Sun and Orange have produced these guidelines to implement these techniques.

Not all the techniques always apply to all the causes of fragmentation, some techniques are irrelevant for some variation points.

This technique mainly consists of generation of several compilation ready source codes from a single pseudo source code root. Pre processing tools (like CPP for C/C++ in Unices) allows building target specific executables using conditional compilation. More advanced techniques exist, mainly Aspect Oriented Programming (AOP).

This technique consists of building an abstraction layer hiding the variability points and provides target specific re-implementations of the abstracted sub-components. We call this technique LINK, because in C/C++ fashion fragmentation is resolved at object linkage time, which is Java ME Platform turns out to be building of the JAR file.

This technique consists in a consistent re implementation the software component showing the variable behaviour. In the Java ME Platform, the main usage of this technique is re implementation of a small GUI on top of the Canvas item. It is sometime combined with LINK when the re-implementation is varies form one target to another.

This technique consists of abandoning the feature of the application relying on the functionality showing the fragmented behaviour. In the Java ME Platform, the main usage of this technique is abandon of sound.

Subjective initiated adaptation of runtime behaviour of the application against the platform is the techniques where the application is alone capable to query the platform particularities and adapt to them. In the Java ME Platform, a simple example usage of this technique is adaptation to screen size.

Subjective initiated adaptation of runtime behaviour of the application against the platform are the techniques where the application needs to be indicated by an external information what runtime behaviour it had to adopt in order to adapt to device particularities. In the Java ME Platform, a simple example usage of this technique is soft key codes.

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.