Introduction to EPOC Java Development
by Richard Bloor
EPOC Java Fundamentals
The EPOC platform differs in some significant ways from the environment which most
Java developers will be familiar with. Before we look at Java development on EPOC we
briefly review these differences and the challenges presented to the Java developer in building
for the EPOC platform.
Classpath
Unlike other systems on which Java is deployed EPOC does not have the concept of
environment variables that define the Classpath. The standard and extension classes are
therefore given fixed locations:
on an EPOC device in ?:\system\java\lib\classes.zip for the standard classes and
?:\system\java\ext\ for extension classes
on the emulator ?:\lib\ and ?:\ext\ for standard and extension classes respectively.
Within the standard emulator set-up these are on the mapped J drive.
Finally in both cases the directory containing the application is also searched for
classes.
The drive location on an EPOC machine can be any physical drive with the following
order of precedence, d: (any Compact Flash card), a:, b:, c: (the internal RAM drive), e: then
in alphabetical order through to z: (the internal ROM drive). Therefore, on a machine without
a CF card any classes loaded in RAM (C drive) are used in preference to those on ROM (Z
Drive).
It is however possible to override the defaults in two ways, by using the command line
parameters:
-classpath, to override (and replace) the default classpath, or
-cp, to add the specified directories to the beginning of the default classpath.
Current Directory
EPOC does not implement the concept of a current directory that many other operating
systems have. Therefore when a Java application is launched directly from the DOS
command line in the emulator there is no current directory to inherit. Rather the current
directory has to be specified with the -cd parameter when the application is launched.
Normally however an application is run from the Extras Bar within EPOC. When this is
done the current directory is set to the location of the application, which on the emulator is
?:\epoc32\wins\c\system\apps\appname\ and ?:\system\apps\appname\ on an
actual device.
Special Considerations for Java on EPOC
The development of Java applications for EPOC requires some special consideration to be
given to the unique features of EPOC. The devices that are powered by EPOC are limited
when compared to conventional Java environments, these limitation may including:
input options, e.g. no keyboard or alternatively no pointer device
screen size
memory and/or
processing power
Care needs to be given to accommodating these differences.
Screen Size
One of the main and most obvious differences with developing Java for an EPOC device
is screen size. EPOC applications also do not use the title bar that is so familiar on Windows.
Care therefore needs to be taken in structuring the application and laying out screens to make
best use of the limited space.
Screen Elements
The screen elements differ between EPOC and other systems on which Java runs. The
example program simply displays a set of standard widgets, text area, buttons etc. When run
on a Windows PC it looks like this:
Whereas the same code run in EPOC looks like this:
You will notice that there is a fault in the current EPOC JVM where elements of a
checkbox and select list do not inherit the background colour.
The source code for the example application is provided here.
User Interface
Not only do the elements of an EPOC screen differ from those on more common
platforms so does the users interaction. Also it needs to be considered that the EPOC user
may not be familiar with the Windows paradigm for user interaction. For example:
screen buttons should be accompanied by a keyboard shortcut (as there may be no
pointer device)
screen buttons should be complemented with options available from the menu (again
because of pointer limitations)
EPOC does not use double clicks to activate, rather a select and second touch activates
the item
as interaction is thought a pen (rather than a mouse) dragging and dropping is difficult
and tool tip and similar roll over features are impractical (is the pen pointing to select or
pointing to show a tool tip?)
Performance Considerations
Any EPOC device will have a limited amount of CPU, memory and possibly
communication bandwidth compared to the traditional platforms Java is developed for. As a
result it is necessary to give more consideration than usual to any aspect of the code which
may make excessive demands on these resources. Optimising an application is about
compromise, minimising application size can be to the detriment of performance, creating
objects early means increased start up time but benefits subsequent performance while
increasing background memory usage.
One area that is somewhat unique to EPOC and would not normally need the same
consideration in Java development is power usage. For example, rather than creating a loop
which polls (and therefore runs continually consuming excessive battery power) a blocking
loop or events should be used, as the processor is inactive until the event occurs.
Symbian Extension
Symbian have provided several additional classes to assist with achieving an EPOC look
and feel, overcoming shortcomings of current JVM or provide access to EPOC functionality.
These utility classes are described here on the Developer Network site.
Native Methods
The EPOC implementation of Java allows for the development of Native Methods using
JNI. To develop these it is necessary to also utilise the C++ SDK. Further discussion of
Native Methods is beyond the scope of this article.
Next: EPOC Java Development Process
|
