ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Java Programming for Palm OS

by Matthew E. Ferris
03/15/2001

The landscape for coding Palm OS applications with Java is far from uniform or level. There are several different APIs currently available, each of which gives a different degree of access to the underlying Palm OS API. Perhaps the most well known of these is the one from Sun Microsystems; it is not the only one. This article is not a tutorial on Palm programming with Java -- each solution discussed has its own challenges and quirks -- but, rather, an overview of what tools are available for developers. We will survey the landscape to discover what you can expect when developing Palm OS applications with Java.

The Sun Solution: KVM, Configurations, and Profiles

The KVM is the Kilobyte Virtual Machine, so named because its memory footprint is measured in kilobytes rather than the megabytes that the Java Virtual Machine requires. Because of these stringent memory requirements, the functionality of the KVM is but a subset of the full JVM. You can get a full breakdown of what is and is not supported from the Javasoft site, but notable omissions include reflection, JNI, custom classloaders, as well as an altered security mechanism.

Sun has formulated a game plan of providing both configurations and profiles to meet the needs of device programming. A configuration is an API that is designed to provide a basis for a broad and general category of devices, all sharing similar characteristics, such as limited memory, occasional network connectivity, and low power consumption, probably running on batteries. A configuration defines a "lowest common denominator," in terms of Java libraries, for these devices. As such, it is, by design, general and abstract. There are currently two configurations available for the Java 2 Micro Edition, the CLDC and the CDC. The latter is for devices a bit more powerful than a Palm and is outside of our scope. The former, which stands for Connected Limited Device Configuration, addresses devices like PDAs, two-way pagers, and even cellular phones. The CLDC includes a subset of classes found in the J2SE but with some important differences. For example, the CLDC's java.lang.Object contains no finalize method because of the garbage collection mechanism employed by the VM on small devices. You should remember that a particular class may be present in the API, but particular methods may be absent.. Refer to the documentation to ensure that what you're counting on is actually there.

A surprise for many developers upon beginning to develop with the CLDC is that it does not include support for floating point numbers. This is the default implementation of the KVM; the KVM is written in C and can be ported to many platforms. It lacks floating point support because of the underlying hardware often used for smaller devices, including 8-bit processors that do not support floating point arithmetic.

A profile is specific, concrete, and targets a more specific class of device than a configuration, including user interface and event handling elements, which are not present in the configuration. Currently there are no publicly available profiles for the Palm OS or PDAs.

The Java Community Process has a PDA Profile that has been in progress for some time now. The developer community is still waiting for an early access release of the PDA profile. If traffic on the KVM interest mailing list is any indication, there is some frustration owing to the elusiveness of this early access release.

In the meantime, what can a developer who wants to follow the KVM/Sun solution do? The release of the CLDC included a minimal set of classes which one could think of as an extremely primitive profile for the Palm OS. Be warned that Sun does not endorse using these classes for any commercial development, nor do they plan any updates to this API. But in the absence of the PDA profile, developers are using the classes. Commonly known as Kjava, it includes a number of GUI classes: CheckBox, RadioButton, TextBox, List, etc. In addition to these, there is the Spotlet class, which is used for event handling and includes callbacks to the Palm OS for trapping stylus taps, "hard" key presses, and so on.

A class that uses kjava to display a simple string of text and a Button might look like the following.:

import com.sun.kjava.*;

public class HelloKjava  extends Spotlet
{
private static Button OKButton;
public static Graphics g = Graphics.getGraphics();

public static void main(String args[])
{
        HelloKjava hk = new HelloKjava();
}
public HelloKjava()
{   OKButton = new Button("OK", 84, 140);
        register(NO_EVENT_OPTIONS);
        drawScreen();  

}
public void penDown(int x, int y) {
                 if (OKButton.pressed(x,y)) {
                         System.exit(1);
        }
}
public void drawScreen()
{
         g.clearScreen();
         g.drawString("Hello KJava",20, 10);
         OKButton.paint();
}
}

There's also a com.sun.kjava.Database class, which is a way to get at the Palm Database (pdb) API. That said, it's extremely primitive and doesn't give full access to everything in a pdb. It only allows the setting and getting of byte arrays; it doesn't allow keyed access other than by record id (an integer). Since the Database only understands byte arrays, to give your data meaning you will need to parse the byte array into meaningful fields.

The Kawt Solution

Kawt is an implementation of the Abstract Window Toolkit for the KVM and is the work of Michael Kroll and Stefan Haustein, both of whom serve on the expert committee for the PDA Profile. Kawt offers an API set more familiar to the Java programmer. For example, it uses the common layout managers (with the exception of GridBag) for placing components on the screen, and then it allows you to set listeners for those components. In other words, the Spotlet mechanism is not involved. Button, Panel, Label, TextField, and other AWT classes are all available. In addition, there are custom classes: FtpShel, TabbedPane, and GifLoader. There is also a java.io.File class which is an abstraction of a directory and file structure that uses a standard pdb (Palm Database File) to store the data.

Using Kawt, we can say hello in the following way:

import java.awt.*;
import java.awt.event.*;

public class HelloKawt extends Frame implements ActionListener
{
   Button OKBtn = new Button("OK");
   Label lbl = new Label("Hello Palm");

   public static void main(String args[])
   {
      new HelloKawt();
   }
   
public HelloKawt()
{
   OKBtn.addActionListener(this);
   this.add("South", OKBtn);
   this.add("Center", lbl);
   pack();
   this.show();
}

public void actionPerformed(ActionEvent ae)
{
   System.exit(1);
}

}

While Kawt gives you a better set of classes than kjava, it's actually based on kjava and, therefore, lacks a database class other than kjava's.

This is a problem for serious Palm development. In general, any commercial application will require the data stored on the device to later be synchronized with the desktop. Synchronization of a kjava.Database is problematic because it does not contain the categories that the HotSync software expects, nor does it allow access to the attribute bits that each "native" palm database file contains at the start of each record. Even with the release of the PDA Profile, this is unlikely to be addressed, since the profile targets PDAs in general and not the Palm OS in particular. Nevertheless, the Kawt team has done a great job at making it easy for a neophyte Palm programmer to get started with Java. You can obtain a copy of Kawt at www.kawt.de.

Pages: 1, 2

Next Pagearrow