Konstantin Knizhnik, McObject

A customer approached McObject, asking us to re-implement a professional sports recruiting application, or "midlet" (the common term for an application written for a Java ME MIDP, or Mobile Information Device Profile, specification).

The midlet, which we'll call "ProScout" for convenience, enables a sports recruiter to manage information about prospects using a mobile device -- for example, to collect and review data with a cell phone while sitting in the bleachers at a high school basketball game.

An initial version of the midlet had already been developed in Java ME for a Blackberry device, with data management provided by an embedded relational database system that used the SQL application programming interface.

The customer was disappointed in the application's performance, which is why they asked for a new midlet using Perst Lite, McObject's open source, object-oriented embedded database for Java ME. My task was to re-develop ProScout for the Blackberry and also for the Nokia S60 mobile device platform (See Figure below) (I also intended to deploy it on my Nokia S40 cell phone, the 6230i).

The project offered the opportunity--albeit on a limited scale--to test Java's "write once, run anywhere" promise, as it applies to Java ME mobile devices. Developers choose Java largely because their application bytecode can deploy within the Java virtual machines provided on many operating system/hardware combinations, with few or none of the porting challenges required by applications written in C/C++ and some other high-level languages.

Would this hold true when moving our midlet between Java ME devices, or would limitations imposed by the different device manufacturers require changes to the source code?

As it turned out, our Java ME midlet moved between different vendors' devices, and between diverse devices from Nokia, relatively seamlessly. We encountered just two device-specific potential stumbling blocks, both tied to manufacturers' implementation of the Record Management System (RMS), a persistent storage mechanism in Java ME.

We addressed this limitation in our source code for the Blackberry, and the solution redeployed without a hitch on the Nokia S60 device; however, our RMS-specific code had to be fine-tuned once again to deal with a new constraint that popped up in the Nokia S40 environment.

Re-implementing the midlet
The first step in this project was to re-implement the sports recruiters' midlet for the Blackberry, using Perst Lite for embedded data management. My primary tool, as in all Java ME mobile device projects, was the Sun Java Wireless Toolkit, which is designed for building, running and debugging midlets.

The Sun Java Wireless Toolkit contains no editor or code generating tool -- you can use any editor you like. Developers of midlets who want an integrated development environment most frequently use Eclipse (with its special extension for J2ME), Borland JBuilder and another IDE. I used a simpler solution, the GNU emacs text editor, for the actual coding.

For code testing throughout the midlet development process, I used the device emulators provided by the manufacturers (Blackberry and Nokia). For Nokia, I used the Nokia Prototype SDK for Java Platform, Micro Edition, which contains emulators for both the S40 and S60 devices (the two specific emulators were _S40_DP20_SDK_6230i and Series_60_MIDP_SDK_2_1).

The advantage of using Perst Lite in a Java ME application is that it provides persistence for application objects: the midlet does not need to pack/unpack an object to/from its underlying byte array in order to store the object. Perst Lite also provides a set of collection classes (indices) that allow efficient location of objects by key (that is, by index, including spatial indices).

As an object-oriented database, Perst Lite doesn't impose SQL processing and query optimization overhead. Perst Lite uses only standard Java ME features so it can be used with any Java ME compatible device.

Databases rely on the RMS as a "back end" for physical storage, and on the Blackberry device, it turned out the manufacturer limited RMS storage size on the platform to 64KB. This was insufficient, considering the amount of data that our customer contemplated storing in the database. As it turns out, such an RMS storage limitation is very common among different manufacturers' mobile devices.

< Previous Next >