1. General Approaches to Handling Diversity
We have a range of possible options for handling
diversity. At opposite ends of the scale, we have the
multiple-implementations approach and the feature-drop approach. Both
are quite extreme when it comes to Java ME on Symbian OS, which has much
in common across the various devices.
The multiple-implementations approach implies
fundamentally different implementations of the same functionality and
the need to maintain multiple JARs. Taking this approach further means
that, for each device model, you need to maintain a JAR file. The
multiple-implementations approach usually starts with being uneconomical
and ends up as being impractical. It should therefore be avoided.
The feature-drop approach implies that you totally
remove a feature from the application, which is very harsh, unless it is
a case of a JSR that is not supported. That might happen on Symbian OS
but, generally, JSR support on Symbian smartphones is very predictable.
The multiple-implementation and feature-drop
approaches are more suitable for handling fragmentation than diversity.
Between these two extremes, there are a few more moderate approaches
that can be combined to produce the fewest variants to cover most
Symbian smartphones. These are techniques such as:
Detection: The Java ME capabilities can be
detected at various stages, each involving different types of required
action. We utilized detection with the Java ME Detectors suite and we use similar techniques.
Adaptive
code: Code that can handle variants in a simple way, without major
refactoring or code instrumentation is termed 'adaptive code'. The same
simple code can handle differences that may occur on devices coming from
different Symbian OS UI platforms.
Flexible
and modular design: There are endless options when you take this route.
For example, you can create abstraction layers, apply design patterns,
or decouple functionality into modular subsystems.
Now we look at various areas
in which diversity appears and examine how to handle it in simple ways
that combine those three approaches.
2. Detecting Diversity using Properties
System properties can be retrieved using the System.getProperty() method, which receives as a key the name of a system property and returns its value (or NULL
if there is no property with that key). The system properties are
logically grouped into properties that give information about the
environment, package discovery, JSR capabilities and the device-specific
properties.
You can get information about the Java ME environment (see Figure 1), for example:
microedition.profiles is a list of the profiles that the device supports. For MIDP 2.0 devices, this property contains at least MIDP-2.0.
microedition.platform
returns the identifier of the platform (e.g., you can identify whether
you are running on the Nokia N95 or Sony Ericsson W960i).
fileconn.dir.photos points to the directory where photos captured with an integrated camera or other images are stored (it returns file:///C:/Data/Images/).
You can also check versions of supported JSRs. For example, micro-edition.media.version and microedition.pim.version indicate if the optional packages are supported. If they are, a version string is returned (e.g. "1.1"), as shown in Figure 2.
You can query about JSR capabilities (Figure 3). For example, supports.mixing returns true or false depending on whether MMAPI audio mixing is supported.
There are ways to get JSR-specific information
through system properties. JSR-184 Mobile 3D Graphics API properties can
be queried with the Graphics3D.getProperties() method, which returns a hash-table of 3D graphics support properties and their values (see Figure 4a). In the Bluetooth API, LocalDevice.getProperty() should return properties that are specific to Bluetooth support such as the maximum number of connections (see Figure 4b).
The device-specific system properties can give you
additional information which is proprietary to a device or manufacturer.
For example, S60 3rd Edition FP2 and S60 5th Edition system properties
include support for telephony-related information, such as the
International Mobile Equipment Identity (IMEI) number, International
Mobile Subscriber Identity (IMSI) number, current (GSM/CDMA) network
signal strength and more.
There is a lot of information
available to you through detection, whether you detect it through a
thrown exception or through system properties. The general idea is to
use detection to configure your application's behavior. Use the
information you gain from detection to decide on the application
behavior and actions that are affected.
