A customer approached McObject, asking us to re-implement aprofessional sports recruiting application, or “midlet” (the common term for an application writtenfor a Java ME MIDP, or Mobile Information Device Profile, specification ).
The midlet, which we'll call “ProScout” for convenience, enables asports recruiter to manage information about prospects using a mobiledevice — for example, to collect and review data with a cell phonewhile 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 systemthat 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 PerstLite, McObject's open source, object-oriented embeddeddatabase for Java ME. My task was to re-develop ProScout for theBlackberry and also for the Nokia S60 mobiledevice platform (See Figure below ) (I also intended todeploy it on my Nokia S40 cell phone, the 6230i).
The project offered the opportunity–albeit on a limited scale–totest Java's “write once, run anywhere” promise, as it applies to JavaME mobile devices. Developers choose Java largely because theirapplication bytecode can deploy within the Java virtual machinesprovided on many operating system/hardware combinations, with few ornone of the porting challenges required by applications written inC/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 manufacturersrequire changes to the source code?
As it turned out, our Java ME midlet moved between differentvendors' devices, and between diverse devices from Nokia, relativelyseamlessly. We encountered just two device-specific potential stumblingblocks, both tied to manufacturers' implementation of the RecordManagement 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 dealwith 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 sportsrecruiters' midlet for the Blackberry, using Perst Lite for embeddeddata management. My primary tool, as in all Java ME mobile deviceprojects, was the Sun Java Wireless Toolkit, which is designed forbuilding, running and debugging midlets.
The Sun Java Wireless Toolkit contains no editor or code generatingtool — you can use any editor you like. Developers of midlets who wantan integrated development environment most frequently use Eclipse (with its specialextension for J2ME), Borland JBuilder and anotherIDE. I used a simpler solution, the GNU emacs text editor, for theactual coding.
For code testing throughout the midlet development process, I usedthe device emulators provided by the manufacturers (Blackberry andNokia). For Nokia, I used the Nokia Prototype SDK for Java Platform,Micro Edition, which contains emulators for both the S40 and S60devices (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 thatit provides persistence for application objects: the midlet does notneed to pack/unpack an object to/from its underlying byte array inorder to store the object. Perst Lite also provides a set of collectionclasses (indices) that allow efficient location of objects by key (thatis, by index, including spatial indices).
As an object-oriented database, Perst Lite doesn't impose SQLprocessing and query optimization overhead. Perst Lite uses onlystandard Java ME features so it can be used with any Java ME compatibledevice.
Databases rely on the RMS as a “back end” for physical storage, andon the Blackberry device, it turned out the manufacturer limited RMSstorage size on the platform to 64KB. This was insufficient,considering the amount of data that our customer contemplated storingin the database. As it turns out, such an RMS storage limitation isvery common among different manufacturers' mobile devices.
Creating multiple storages
However, RMS does permit the creation of multiple storages — each witha unique name — using its RecordStore.openRecordStore method. Toovercome the 64kb limitation, we created a solution called”multistorage” in which Perst Lite creates an array of discretestorages (for example proscout.dbs.1, proscout.dbs.2, proscout.dbs.3,…).
Each storage corresponds to a particular segment of the databasefile. When Perst Lite needs to access a page of data from the databasefile, it first calculates in which storage this page is located, and itloads this page from RMS storage. Perst Lite also automatically detectssituations when data does not fit in storage, and adds new storage.
After the midlet coding, including integration of the Perst Litedatabase and the multistorage workaround described above, theapplication was compiled into byte code using the javac compiler fromSun's JDK, which can be executed from within the Sun Java WirelessToolkit.
The final steps for ProScout (as for any midlet) were to pack themidlet (including database-specific files) inside a .jar file, using ajar-tool, and pre-verifying the .jar file using a pre-verifier, againwith standard JDK tools accessed from the Sun Java Wireless Toolkit.
When deployed in the Blackberry device, performance wassignificantly better than the version of the application using the SQLrelational database, almost certainly due to elimination of SQLprocessing and query optimization overhead.
The next task was to deploy this midlet on Nokia devices — both onmy own Nokia 6230i (S40 device, 2nd Edition) and on the ultimate targetdevice, the Nokia E61i (S60, 3rd Edition). In re-deploying this midleton the Nokia E61i device, I can say that Java ME completely fulfilledJava's promise and motto of “write once, run anywhere.”
I loaded the existing .jar file containing the ProScout midlet andPerst Lite embedded database into the Nokia S60 emulator, and it ranflawlessly. No recompilation was required. Performance was comparableto the Perst Lite-based midlet running on the Blackberry device.
This midlet for the Nokia E61i included the multistorage solution. Forthe Nokia E61i, multistorage was not actually needed. The device placesno limit on RMS size — RMS storage can grow as large as the physicalstorage medium allows. But the multistorage code imposes almost nooverhead, so we left it in place. Since many devices do limit RMS size,the presence of multistorage adds to code portability, which is a majorreason for developing in Java in the first place.
In a second implementation of ProScout for the Nokia E61i, though,we did eliminate multistorage, along with additional code that tieddatabase physical storage to the device RMS.
This alternative version based its storage on the Nokia E61i'ssupport for JSR 75, a Sun optional Java ME specification, including anAPI, that requires the presence of a specific library (provided in theSun Java Wireless Toolkit), and a switch in midlet configuration.
JSR 75 gives Java ME devices access to data that resides natively onmobile devices (such as in address books, calendars, etc.) as well asto file systems residing on mobile devices (primarily to allow accessto removable storage devices, such as memory cards).
For devices that support JSR 75, the developer can choose whether toimplement the JSR 75 package, or the standard RMS package, for physicaldata storage. A major advantage of JSR 75 is that it allows one tocreate and work with database files located where one chooses on thedevice, for example, on a flash memory card.
These files can be prepared on a PC and copied to the desiredlocation on the phone. In contrast, the format and location of RMSstorage is opaque. In phones where there is some file system (such asan operating system's file system), RMS storage is usually created insome private subdirectory of the midlet and no other midlet can haveaccess to this storage.
Another benefit of JSR 75 is that any size limitation imposed by themanufacturer's RMS implementation, such as the 64KB imposed on theBlackberry device, becomes irrelevant: storage size can grow to thelimit imposed by application or storage medium.
So our ProScout midlet offers the choice between standard RMSstorage or JSR 75 storage based on the need for maximum portability(RMS is present on all Java ME devices, while not all support JSR 75),the requirements of the target platform (namely, does it support JSR75), and user needs such as storing database files on removable mediaand in user-specified file system directories.
Based on these criteria, the developer can choose perst-rms.jar orperst-jsr75.jar. The Perst Lite interface in both cases is the same, sothere are no differences in the midlet using these libraries, exceptthe specification of the database path. In the case of JSR75 it can besomething like “file:///SDCard/uniar.dbs”, while in RMS it is just thename of the storage.
When I ported the ProScout application to the S40 device, some minoralteration of the code was needed, again having to do with the recordmanagement system. My particular S40 device does not support JSR 75.And, its RMS storage is limited to 32KB, so clearly, multistorage wouldbe a requirement.
However, this device presented an additional twist, in that its RMSimplementation was capable of working with just one opened storage at atime. This was incompatible with the original multistorage mechanism,which allowed multiple open storages. It was solved with additionalcode that enables Perst to automatically detect and close all storagesexcept the one being used at a given moment.
With that change, deployment on my Nokia S40 Second Edition cellphone was no problem. So is the revised midlet now perfectly portable– can it, for instance, run on any Nokia Second and Third Editiondevice?
The answer is that to support all of Perst Lite's features, MIDP 2.0and CLDC 1.1 are required. This specification covers all Nokia 3rdEdition devices, and most 2nd Edition devices. Some 2nd Editiondevices, however, use MIDP 2.0 and CLDC 1.0.
The only feature used by Perst Lite and not available in MIDP1.0/CLDC 1.0 is floating point support. Perst does not itself use anyfloating point arithmetic, but it allows persistent classes to includefloating point fields, and therefore it has code to serialize andde-serialize floating point data. This capability depends on CLDC 1.1,and would need to be stripped out in order to create a version of PerstLite that can support CLDC 1.0.
Customizing Perst Lite in this way would be relatively easy (
Konstantin Knizhnik is a developer with