Introduction to Java Development on the Symbian Platform

Introduction

Since the release of a Java 1.1.4 JVM for EPOC R5 in 1999 Symbian have been working towards making Java the development language of choice for the Symbian platform. The release of Version 6 of the platform made some significant steps towards this goal, with inclusion of PersonalJava, a reference implementation of JavaPhone and a visual interface to some of the application deployment tools.

Most recently Symbian have announced that they have licensed ARM’s Jazelle technology, the first company to do so. Jazelle allows Java bytecode to be run directly on an ARM processor without a JVM. This not only improves performance but saves significantly on memory making Symbian an even more attractive platform for Java deployment.

When V6 of the Symbian platform was first released there was no hardware on which to run applications. Now the Nokia 9210 has been release and reliable sources suggest several more devices will be available by the end of this year (2001) or early next.

The Symbian Java Challenge

The Symbian platform presents the Java developer with a number of challenges because of several differences from the more familiar PC environment. The challenges include:

allowing for the look and feel guidelines for each DFRD,
limited screen size,
limited system resources, and
the Symbian platform application installation and launching mechanism.

In this article we will review these challenges by:

looking briefly at the environmental features and issues which need to be considered,
review the unique process associated with running and installing an application.

Then finally we take a look at what new features Symbian will be adding to their Java implementation in the future.

Getting Started

The two tools essential for developing Java for the Symbian platform are a Symbian platform Java SDK and a Java development environment for Java 1.1.x.

Symbian Platform SDKs

Each of the DFRDs has its own Java SDK, however at the time of writing only the Crystal and Quartz Java SDK are available.

The Quartz SDK can be obtained by registering on the Symbian Developer Network web site after which it is available for downloading. (You can also order the SDKs on CD-ROM from Symbian for a small handling charge.)

Symbian have not yet released a generic SDK for the Crystal DFRD, however Nokia have made available a version targeted to their recently launched 9210 communicator. The SDK is available to approved developers by applying on the Forum Nokia and is posted out on CD.

Each SDK contains an emulator for its DFRD. This is accompanied by full documentation, some example programs and the utilities for creating program icons, the files required to run the application, help and installation files.

To run any of the SDKs Symbian recommended the following minimum specification PC:

400 Mhz Pentium processor,
128Mb RAM,
500 MB of free disk space, and
Windows NT 4 (although Windows 98 can be used).

In addition, to view the on-line documentation a Web browser supporting frames is required and for browsing the HTMLHelp file Microsoft Internet Explorer version 4 or higher is needed.

Registering on the Symbian Developer Network also gives access to a number of other useful resources, including a Java knowledgebase, white papers, additional examples and utilities. The Nokia Forum contains both complementary and additional information, including style guides for 9210 development, FAQs and a discussion forum.

Java SDK

A Java development tool supporting up to Java 1.1.8 can be obtained from SUN or any commercial Java ADE supporting PersonalJava can be used.

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.