|
Newsletters
|
|
|
|
|
Symbian Platform Java Fundamentals
The Symbian platform differs in some significant ways from the environments most Java developers will be familiar with. Before we look at a simple example application for Quartz and the Java development process we will briefly review these differences and the challenges presented to the Java developer in building for the Symbian platform.
Symbian Platform Environment
There are two features that most developers would assume exist, but are not present on the Symbian platform. These features are:
- environment variables defining Classpath, and
- default definition of the working directory.
Classpath
Unlike other systems on which Java is deployed the Symbian platform does not have the concept of environment variables that define the Classpath. The standard, shared and extension classes are therefore given fixed locations:
- on a Symbian platform device in ?:\system\java\lib\classes.zip for the standard classes, ?:\system\java\classes\ for shared classes and ?:\system\java\ext\ for extension classes,
- on the emulator ?:\lib\, ?:\Classes and ?:\ext\ for standard, shared and extension classes respectively. Within the standard emulator set-up these are on the mapped J drive.
When an application is run, in addition to searching these fixed locations, the directory containing the application is also searched for classes.
Classes can be store on any physical drive present on a device. When searching for classes the following order of precedence is used, d: (any Compact Flash card), a:, b:, c: (the internal RAM drive), e: then in alphabetical order through to z: (the internal ROM drive). The classes found on the highest priority drive are the ones used. Therefore, on a device 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 specified directories to the beginning of the default classpath.
Current Directory
The Symbian platform does not implement the concept of a current directory as many other operating systems do. Therefore when a Java application is launched to the emulator from the DOS command line 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 platform's interface. When this is done the current directory is set to the location of the application, which on the emulator is ?:\Symbian\v6.0\emulator name\epoc32\wins\c\system\apps\appname\ and ?:\system\apps\appname\ on an actual device.
Java and the DFRDs
Before starting a Java development the first decision which needs to be made is which DFRD or DFRDs the application will be for. Not only do the unique features of the DFRD need to be considered but thought also should be given to the target market for that device. In addition, devices in a family may also have ergonomic differences which effect application design and targeting, as in the Crystal DFRD that allows for both touch screen and keyboard navigation.
For example, you may want to develop a vector graphic package. You might decide to only develop it for Crystal devices for the following reasons:
- it has no practical use to users of a Pearl smartphone and the smaller screen on some devices would make its use impractical,
- the users of Quartz devices are most interested in personal and web information and unlikely to have sufficient interest in the product.
Symbian Java Extensions
Symbian provide several additional classes to assist with creating applications which conform to the style guides for each DFRD. In Quartz these are AboutDialog, GridPanel and QFrame. Similar classes exist for Crystal.
QFrame is an extension of the standard awt Frame to provide Quartz look and feel by:
- placing a frame between the toolbar and status bar,
- adding the default menus, and
- creating a number of views using standard awt CardLayout.
GridPanel is an extension of the standard awt Panel to provide relative positioning of items within a Panel.
AboutDialog is used to create a simple dialog to display information about an application from the application's menu.
The following example code briefly illustrates the use of these extension classes. The code its self simply displays a number of standard screen elements and does nothing really functional.
package com.symbian.devnet.quartz.qjava;
import com.symbian.devnet.quartz.awt.*;
import java.awt.*;
import java.awt.event.*;
/*
* This example program gives a simple demonstration of a Java program
* for Quartz
*/
public class QJava extends QFrame implements ActionListener
{
/* Add a new menu item to the QJava menu to close the application */
MenuItem mnuExit = new MenuItem("Exit");
/*
* Constructor to create an QJava, receiving a parameter defining the
* number of cards to be created.
*/
public QJava(int _numCards)
{
super(_numCards);
Panel pt = getCardAt(0);
pt.setLayout(new BorderLayout());
String[] desc = {"A Java demonstration",
"illustrating Quartz UI components",
"and look and feel of AWT components",
"in Quartz"};
createAboutDialog(desc);
appMenu.add(mnuExit);
mnuExit.addActionListener(this);
setVisible(true);
}
/**
* Captures the events, in this case only the shut down menu
* item
*/
public void actionPerformed(ActionEvent ae)
{
if (ae.getSource().equals(mnuExit))
{
shutDown();
}
}
/**
* Starts up the application.
*/
public static void main(String[] args)
{
/**
* Introduces a delay of 20 seconds to allow the emulator
* to load before the application starts running
*/
if (args.length > 0)
{
String s = args[args.length-1];
if (s.equals("sleep"))
{
try
{Thread.sleep(20000);}
catch (InterruptedException ie)
{}
}
}
/** Create a new copy of QJava with 2 cards
*/
QJava qTest = new QJava(2);
/** Items to be displayed on the frame are defined
*/
GridPanel cardToSet = new GridPanel();
Checkbox MyCheck = new Checkbox("Check!");
TextArea Textarea1 = new TextArea(7, 25);
Choice myChoice = new Choice();
cardToSet.add(Textarea1, 0, 1);
cardToSet.add(MyCheck, 0, 2);
myChoice.addItem("Dark");
myChoice.addItem("Medium");
myChoice.addItem("Light");
cardToSet.add(myChoice, 0, 3);
qTest.setCardAt(cardToSet, 0);
qTest.displayCardAt(0);
/** As the card the items are to be displayed on is already visible
* we refresh it using an explicit cast
*/
GridPanel cardToGet = (GridPanel)qTest.getCardAt(0);
}
}
|
When run the application looks like this:
and the about dialog displays the following:
Performance Considerations
Perhaps the most important technical design issue with a Symbian platform application is performance. Compared to a desktop machine any Symbian platform device will have a limited amount of CPU, memory and possibly communication bandwidth. 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.
As optimization is ultimately about compromise, each application will require unique optimization, for example:
- the application footprint might be minimizing but at the expense of run time performance,
- objects might be created early, increasing start up time and background memory usage but benefiting subsequent performance.
However for all portable applications optimization will be a far more significant task than for desk top applications, where the availability of resources is more forgiving to suboptimal code.
An aspect of performance unique to portable devices and therefore not normally given consideration in desktop applications, is power usage. For example, a loop which polls runs the CPU continually, consuming battery power, it is better to use blocking loops or events, as the processor is inactive until the event occurs.
Native Methods
The Symbian platform implementation of Java allows for the development of Native Methods using JNI. To develop these it is necessary to also utilize the C++ SDK. Further discussion of Native Methods is beyond the scope of this article.
Next: The Symbian Java Development Process
|
|
|
