I hope that this example demonstrates how a simple rethink of the
application usage and some minor changes in the code to make it more
adaptable would give the same user experience on different Symbian OS
In general, Symbian OS is customized by phone manufacturers; there-
fore, there could be subtle differences which impact the usability of your
application. Plan the UI to ensure that users on different UI platforms
can use the application as intended. A rethink of the application usage
and more adaptive code are proven techniques that you can apply before
resorting to more radical changes.
4.4 Handling JSR Fragmentation
Fragmentation of JSRs is a problematic issue in Java ME, in general: your
application requires a certain JSR for its functionality, yet that JSR is not
supported on the target device. There are no magic solutions that you
can apply, even when it comes to Symbian OS. If a JSR is not supported
on a certain device, there is not much you can do about it. However,
Java ME on Symbian OS gives phone manufacturers a large common set
of JSRs, on the scale of the set of MSA 1.1 Component JSRs. That reduces
the amount of JSR fragmentation considerably for Java ME applications
targeting Symbian smartphones.
There is a difference between the Java ME platform being formally
compliant with MSA and the Java ME platform supporting the set of
MSA 1.1 JSRs. A Java ME platform that supports all MSA Component
JSRs but does not comply with all MSA clarification is still not MSA-
compliant. Without playing down the lack of compliance, the major
importance for a developer is probably the availability of JSRs. Unlike
many low-end platforms, which support only MIDP 2.0 or JTWI, the
latest Symbian smartphones are already compliant with MSA Subset and
support additional Component JSRs that bring them closer to MSA Fullset.
In reality, JSR fragmentation will always exist to some extent.
We discuss two guidelines on how to handle JSR fragmentation
according to the modularity of your application. In the graceful func-
tional degradation approach, your application can execute without the
unsupported JSR, although with degraded functionality. In the optionally
replaceable module approach, your application can remain at the same
functional level by using another JSR, which is supported.
4.4.1 Graceful Functional Degradation
All references and usage of a JSR that may not be supported need to
be encapsulated within a bounded part of the application. If the JSR is