In the past, mobile warriors were the only ones who relied on portable information technology. Since PalmOS, RIM, and WindowsCE devices penetrated corporate walls, it’s no longer unusual to have over 60% of corporate employees using PDAs and handheld devices for time management.

Indeed, Franklin-Covey, one of the world’s largest providers of time-management tools, adopted the medium and made it a large part of their overall toolkit.

As with all great technologies that improve productivity, it’s taken the enterprise quite a bit of time to catch up and analyze what’s happening right under their noses. So employees have fortified themselves with the ultimate arsenal for the dissemination of corporate information. Now comes the real trick for corporate IT departments – how to build and deploy applications on PDA/handheld platforms that support management’s goal of providing employees with corporate information when they’re away from their desktops.

This will truly be one of the most complex endeavors for IT departments (since the proliferation of desktop operating systems). There are three versions of Palm operating systems, two of RimOS, and three of WindowsCE. Each version has varying capabilities and functions. In addition, Palm has licensed their operating system to other vendors who have added their own capabilities for their own devices. Kyrocera and Handspring are two examples.

The industry faced a similar situation when Java first arrived on the scene with a solution for cross-platform application development. Well, once again Java is offering an opportunity for cross-platform application development on PDAs and handheld computers.

The Java 2 Micro Edition (J2ME) is a Java 2 platform used in small footprint devices, such as PDAs, phones, and appliances. The goal of J2ME is to separate the set of usable APIs into groups based upon device functionality. These groups are defined as “profiles” and allow applications to be designed for specific sets of capabilities.

There’s basically one choice for developers who want to build cross-platform applications for RIM and PalmOS devices: the Mobile Information Device Profile (MIDP). I doubt anyone reading this article would expect to find a WindowsCE solution here, although I won’t rule out that an implementation of MIDP for WindowsCE might already exist.

The Application
After downloading and installing the sample applications that come with the MIDP implementation for PalmOS from Sun’s Web site (http://java.sun.com/products/j2mewtoolkit/ ), I decided to build a J2ME application (MIDlet). This entailed studying the MIDP specification, which provided some basic direction but also required significant testing with the individual platforms to really understand how they would impact the user.

The application I chose to build is called SecurePad. I chose it because I hate locking my Palm (since it makes it a real pain to use), but I don’t want confidential information in the open if I should lose my device. SecurePad requires the user to enter a password before being placed in a memo pad list screen. That password is then used to encrypt/decrypt all messages for that session. This approach yielded some interesting side effects, as it allowed me to have a different password for each note if I so chose.

The key to SecurePad is the integration with Palm conduits, which allows the entire pad to be uploaded from or downloaded to the desktop without first being decrypted. This is a critical part of building an end-to-end Palm application as it’s possible for the Palm to corrupt data or need a hard reset, which would erase everything in memory.

The Results
J2ME applications definitely don’t look or feel like native PalmOS applications. After years of hearing that Java applications don’t look and feel like Windows applications, this should come as no surprise to Java developers. My biggest complaint was that all field-based input had to be provided through the use of a Form object, which requires the form to occupy the entire screen. And there are only a small, fixed number of items to choose from for screen objects, but the basics such as lists, buttons, and images are there.

Note: The current MIDP version used for the Palm also needs to operate on cellular phones and similar types of equipment that have a lot less screen space and a very mundane entry system. The Sun community is working on a different profile that fits a much more powerful class of devices.

SecurePad uses a basic XOR encryption scheme and operates directly on byte arrays. Still, this modest amount of memory access and mathematical computation appears to make my Visor Prism seem like an IBM PC XT loading up Lotus 123 off a floppy disk. I’ve since been testing with a C++ version of the application and the encryption/decryption algorithm works considerably faster than under Java.

Palm’s Java interface for developing conduits is an extremely useful tool. From the Palm Web site I was able to download the Conduit Development Kit (CDK), which includes the Java interface, documentation, usable sample code, and a redistributable component for installing and using Java conduits on users’ desktops. All things considered, it took only a few hours to transform their TEXTCOND sample application into a usable conduit for SecurePad (see Figures 1–3).

The How-To
To build an end-to-end application for the PalmOS in Java you’ll need the following items:

1. The PalmOS emulator and a PalmOS ROM file: If you have a serially connected base, you can download the ROM from your own Palm device. If you have a USB-connected base, it may be difficult to download the ROM from your Palm to your desktop.

2. The J2ME Wireless Toolkit: The toolkit ships with emulators for cellular phones and can integrate into the PalmOS emulator.

3. The Java VM for PalmOS 1.0: This VM conforms to the MIDP and you’ll need to install this on your Palm before you can load and run MIDlets.

4. The Palm Conduit Development Kit 4.0

The J2ME Wireless Toolkit (J2MEWTK) supports Sun’s Forte development tool; however, I was unable to get the complete environment working and found it easier to use Sun’s KToolbar application that ships with the J2ME Wireless Toolkit. The KToolbar application performs the necessary builds of the application and creates the .JAD manifest file for the MIDlet.

The J2MEWTK also comes with tools to transform .JAD and .JAR files into .PRC files for uploading into the Palm. An automated tool comes with a graphical user interface that can be launched though the J2MEWTK utilities. However, this application frequently failed and I ended up generating the .PRC from the command line. This is a very important point if you’re using a conduit with your application, since the creator ID on the Palm application is used to identify which conduit to call upon synchronization. The command-line application is the only way to apply a creator ID to your MIDlet. We’ll review this further when discussing how to build the end-to-end application.

Developing the application
A key thing to know about designing your J2ME application for the PalmOS is that when the application exits, it’s over. As you read through the documentation you’ll see that the MIDP profile supports a paused state for the application. This initially led me to believe that the Palm application would run in the background and, therefore, I designed the first incarnation of SecurePad around that thought.

Now, having delved a little deeper into the workings of the Palm, I understand that it’s the responsibility of the application to store and retrieve its state upon exit and reentry. However, J2ME developers will need to use a database record to make this happen because MIDP doesn’t provide access to the properties database on the Palm, which is where this information would typically be stored.

All MIDlets start by extending the javax.microedition .midlet.MIDlet class. This enables the Palm to launch the application. Once launched, it’s up to the developer to set the current screen. Building a MIDlet reminded me of the Macintosh Hypercard programming motif – essentially, screens are stacked and unstacked with the current screen controlling which screen should be next. This is only one model; the user could have the controlling class make all decisions on screen based on state information.

If the application requires persistent storage on the device, the MIDP provides the RecordStore, a nice abstraction of the underlying database mechanics of the Palm. It’s a fairly good representation of the Palm’s native database management capabilities and is extremely easy to use. However, just like JDBC, remember to close your database before exiting the application. I witnessed some strange behavior on the emulator when previous instances didn’t close the RecordStore.

Listing 1 illustrates how to create a new form and read records from the database.

For debugging I used the phone emulators during development stages since they leveraged KToolbar’s console to deliver messages sent to System.out and System.err. The Palm emulator won’t perform this function, making debugging very difficult. To debug the few things on the Palm that I had to, I built Alert dialogs and displayed them.

Preparing the application for deployment
After the application is built and tested, the KToolbar application will generate a .JAD and .JAR file for you. These files will be stored in the application’s bin directory. To synchronize this application with your Palm, create a .PRC file. The J2MEWTK contains a utility in the C:\J2mewtk\wtklib\devices\PalmOS_Device directory to transform .JAR files into .PRC files. The following command performs this task for you:

java -jar C:\J2mewtk\wtklib\devices\PalmOS_Device\
MakeMIDPApp.jar -creator [creatorID] \
-JARtoPRC [JAR file] [main class]

For example:

java -jar C:\J2mewtk\wtklib\devices\
PalmOS_Device\MakeMIDPApp.jar -creator spad \
-JARtoPRC SecurePad.jar com.comtellect.securepad.SecurePad

(Don’t enter the \ in the above command, it’s just there to illustrate that the command is entered on a single line.)

Designing and building a conduit in Java
The CDK allows developers to use the Java programming language to build applications that will synchronize data with the Palm. This is a very powerful tool that has a proprietary API and allows full use of the J2SE environment.

There are two distinct components to building the conduit:

1. Installing the conduit into the HotSync Manager environment

2. Accessing data on the Palm during a HotSync operation

There’s an API that allows developers to call the HotSync Manager functions for registration and removal. The CDK comes with a graphical utility for Windows called CondCfg.exe. This program lists all the current conduits registered and allows you to add and change their details.

Conduits have two entry points, one for configuration and one for execution. When the HotSync Manager locates an application database with a matching creator ID in its registry, it executes the conduit associated with that ID. Upon execution, the HotSync Manager calls the open() function on your conduit. Pay attention to the direction of the synchronization as it’s passed in. This parameter is set by the user through the HotSync Manager if your conduit allows configuration.

The SyncManager object enables the conduit developer to read and write database records directly inside the Palm. However, the conduit must know the format of the database records in order to operate over them. Listing 2 illustrates uploading or downloading information on the Palm.

Conclusion
RIM will be shipping a fully functional version of their MIDP implementation, providing developers with a wider array of platforms to deliver their J2ME apps to. Eventually, both RIM and PalmOS will hopefully gain more powerful profiles based on the CDC. MIDP is now based on the CLDC.

While writing this article I quickly became aware of how much is involved in building an end-to-end application for the PalmOS. In the end, I focused on some key points I thought would help speed developers on their way and covered some of the hurdles I encountered to get my application to run. Overall, the experience of building an end-to-end Palm application in Java was a worthwhile and useful experience.

Author Bio
JP Morgenthal is CTO for Ikimbo and an expert on the design and implementation of distributed systems for the enterprise, and underlying technologies: Java, XML, enterprise application integration (EAI), and, business-to-business (B2B).

jpm@ikimbo.com

	


Listing 1

	public MemoList (SecurePad parent) {
		super("SecurePad", List.IMPLICIT);
		m_parent = parent;

	//  The command listener handles all input from the form
		setCommandListener(this) ;

	//  Commands are represented as both buttons and menu items.  
	addCommand(new Command("New", Command.OK, 1));
	addCommand(new Command("Exit", Command.EXIT, 2));
	addCommand(new Command("Help", Command.HELP, HELP_PAGE));
	addCommand(new Command("Erase", Command.SCREEN, DELETE_RECORD));
		try {
	// The following code opens a RecordStore and iterates over the records twice
	//  One flaw in the design is that nextRecordId() increments the record pointer
	// forcing us to iterate once for record IDs and once for the actual data

	secureRMS = RecordStore.openRecordStore("SecurePad", true);
	if (secureRMS.getNumRecords() > 0) {
	RecordEnumeration re = secureRMS.enumerateRecords(null, null, true);
	for (int i=0; i < secureRMS.getNumRecords(); i++) {
		int recID = re.nextRecordId();
		recordIDs.addElement(new Integer(recID));
			if (recID > highRecId)
				highRecId = recID;
				}
				re.reset();
		for (int i=0; i < secureRMS.getNumRecords(); i++) {
			String title = new String (re.nextRecord());
			append(Utils.makeTitle(title), null);
				}
				re.destroy();
			}
		} catch(Exception e) {
	Alert a = new Alert("SecurePad", e.toString(), null, AlertType.INFO);
		a.setTimeout(3000);
	Display.getDisplay(m_parent).setCurrent(a);
		}
	}

Listing 2

	// The following routine writes data from the desktop to the handheld
	public void writeToHH() {
	DataInputStream din;
	SecurePadRecord rec;
	DbList list[];
	int db, count, i;

		try {
	din = new DataInputStream(new FileInputStream(props.localName));
	  db = SyncManager.openDB("SecurePad-spad", (short)0,
    (byte)(SyncManager.OPEN_READ | SyncManager.OPEN_WRITE 
	| SyncManager.OPEN_EXCLUSIVE));
      rec = new SecurePadRecord();

       SyncManager.purgeAllRecs(db);

            count = din.readInt();
			Log.out("Count: "+count);
			byte [] record = new byte[1024];
            for (i=0; i<count; i++) {
				int recLength = din.readInt();
				try {
					Log.out("Record Len:"+recLength);
					for (int j=0; j<recLength; j++)
						din.read(record, j, 1);
				} catch (EOFException e) {
					e.printStackTrace();
				}
				rec.setId(i);
				rec.setIndex(i+1);
				rec.setMemo(new String(record, 0, recLength));
				SyncManager.writeRec(db, rec);
			}
			din.close();
			SyncManager.closeDB(db);
		} catch (Exception e) {
			e.printStackTrace();
		}

	}

	// The following routine writes data from the Handheld to the desktop
	public void readFromHH() {
        DataOutputStream out;
        SecurePadRecord rec;
		DbList list[];

        int db, count, i;

		try {
            // Create our output file
            out = new DataOutputStream(new FileOutputStream(props.localName));

            // Open our handheld DB
     		Log.out(props.toString());
            db = SyncManager.openDB("SecurePad-spad", (short)0,
    (byte)(SyncManager.OPEN_READ |SyncManager.OPEN_WRITE|
	SyncManager.OPEN_EXCLUSIVE));

            // Find out how many memo records there are in the MemoDB
            count = SyncManager.getDBRecordCount(db);

            // Since we are just printing, we can re-use a single MemoRecord
            rec = new SecurePadRecord();

            // Loop over all records

            out.writeInt(count);
            for (i = 0; i < count; i++) {

                // Recond a record
                rec.setIndex(i);
                SyncManager.readRecordByIndex(db, rec);

                // Print it out to file
                String recData = rec.getMemo();
                out.writeInt(recData.length());
                out.write(recData.getBytes());

            }

            // Close DB
            SyncManager.closeDB(db);

            // Close file
            out.flush();
            out.close();


        } catch (Throwable t) {
            // If there was an error, dump the stack trace
            // and tell the log we failed
            t.printStackTrace();
            Log.abortSync();
        }
	}