Java Reference
In-Depth Information
not supported by a specific device, that part of the application is never
accessed in any way. It is not instantiated or used and there must be no
direct usage of the JSR outside this module.
To encapsulate all usage of that JSR, you also need to define interfaces
between that module and the rest of the application that are the only
way of accessing the JSR (see Figure 4.9). The module is loaded and used
only after detection to check for the JSR availability (in a similar way to
JSRsDetectorMIDlet
in Chapter 3).
Interface
Implementation
Interface
App core
Java ME
Opt JSR
Figure 4.9
Implementation of graceful functional degradation
For example, your application should encapsulate all usage of JSR-
82 in a module, behind a set of interfaces that are used to send and
receive messages over Bluetooth. When your application starts, it detects
if Bluetooth is supported and instantiates the Bluetooth module, or
not. The usability of the application must also be changed and any
functionality dependent on Bluetooth should be disabled (e.g., commands
or menu items that trigger usage of Bluetooth should be disabled or
removed).
private void initBluetoothFunctionality()
{
try
{
Class c = Class.forName("javax.bluetooth.LocalDevice");
// if we reach here, JSR-82 is supported
btModule = new MyBluetoothCommModule();
// TODO: enable all Bluetooth-related functionality
}
catch (ClassNotFoundException e)
{
// JSR-82 is not supported on this handset
btModule = null;
// TODO: disable all Bluetooth-related functionality
}
}
The advantage to this approach is that the module can always reside in
the JAR. There is no need to maintain multiple versions with and without
the module. If the JSR is not supported, the module is not used. The
disadvantage is that the JAR is sometimes needlessly bigger than it could
have been.
