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.
