The J2ME record management system (RMS) provides a mechanism through which MIDlets can persistently store data and retrieve it later. In a record-oriented approach, J2ME RMS comprises multiple record stores. An overview of J2ME RMS and MIDlet interfacing is given in Figure 1.
Figure 1. Overview of J2ME RMS and MIDlet interfacing
Each record store can be visualized as a collection of records, which will remain persistent across multiple invocations of the MIDlet. The device platform is responsible for making its best effort to maintain the integrity of the MIDlet's record stores throughout the normal use of the platform, including reboots, battery changes, etc.
A record store is created in platform-dependent locations, like nonvolatile device memory, which are not directly exposed to the MIDlets. The RMS classes call into the platform-specific native code that uses the standard OS data manager functions to perform the actual database operations.
Record store implementations ensure that all individual record store operations are atomic, synchronous, and serialized, so no corruption of data will occur with multiple accesses. The record store is timestamped to denote the last time it was modified. The record store also maintains a version, which is an integer that is incremented for each operation that modifies the contents of the record store. Versions and timestamps are useful for synchronization purposes.
When a MIDlet uses multiple threads to access a record store, it is the MIDlet's responsibility to coordinate this access; if it fails to do so, unintended consequences may result. Similarly, if a platform performs a synchronization of a record store with multiple threads trying to access the record store simultaneously, it is the platform's responsibility to enforce exclusive access to the record store between the MIDlet and its synchronization engine.
Each record in a record store is an array of bytes and has a unique integer identifier.
The
javax.microedition.rms.RecordStore class represents a RMS record store. It provides several methods to manage as well as insert, update, and delete records in a record store.Managing record stores
To open a record store, the
openRecordStore() method of javax.microedition.rms.RecordStore is invoked. public static RecordStore openRecordStore(String recordStoreName, boolean createIfNecessary) opens a record store with the given name recordStoreName. If there is no record store of that name, invoking this method creates one.If the record store is already open, this method returns a reference to the same record store object.
Listing 1. Open a RecordStore
RecordStore rs = RecordStore.openRecordStore("MyAppointments",true); |
Once all operations are done, a call to
closeRecordStore() closes the record store with the given name. When a record store is closed, it is disabled for further operations.Listing 2. Close a RecordStore
Rs.closeRecordStore(); |
A named record store can be deleted by invoking the
deleteRecordStore() method.Listing 3. Delete a RecordStore
RecordStore.deleteRecordStore("MyAppointments"); |
Inserting records
The MIDlet invokes the
addRecord() method of javax.microedition.rms.RecordStore class to insert a new record into the record store. This is a blocking atomic operation and returns the recordId for the new record. The record is written to persistent storage before the method returns.public int addRecord(byte[] data, int offset, int numBytes) inserts a record represented by an array of bytes data with offset as its starting index and numBytes as its length.Listing 4. Insert a record
String appt = "new record"; |
Updating records
Updating a particular record involves getting a handle for that record and setting new information.
public int getRecord(int recordId, byte[] buffer, int offset) returns the data stored in the given record in the byte array represented by buffer. public byte[] getRecord(int recorded) returns a copy of the data represented by recordId. public void setRecord(int recordId, byte[] newData, int offset, int numBytes) sets new information, a stream of bytes (newData) with offset as its starting index and numBytes as its length, at the record location represented by recordId.Listing 5. Update a record
String newappt = "update record"; |
Deleting records
The MIDlet invokes the
deleteRecord() method to delete a record from the record store.public void deleteRecord(int recordId) deletes the record represented by recordId. The recordId for this record is not subsequently reused.Listing 6. Delete a record
Rs.deleteRecord(1); |
The J2ME API provides certain interfaces to interpret the data stored in a record store. This process involves comparing records to determine their relative sort order. It also involves the filtering of contents depending on given conditions.
Comparing records
The MIDlet implements the
RecordComparator interface and defines a compare (byte[] rec1, byte[] rec2) method to compare two candidate records. The return value of this method must indicate the ordering of the two records.Listing 7. Comparing records and determine relative sort order
Int compare (byte[] b1, byte[] b2) |
Enumerating records
The
RecordEnumeration interface is responsible for enumerating records in a record store. It logically maintains a sequence of the recordIds of the records in a record store. The enumerator will iterate over all of the records (or only a subset, if an optional record filter has been supplied) in an order determined by a record comparator. If neither the filter nor the comparator are specified, the enumeration will traverse all records in the record store in an undefined order.Listing 8. Enumerating records
RecordEnumeration re = rs.enumerateRecords(null, null, false); |
Filtering records
The MIDlet implements the
RecordFilter interface, defining a filter that examines a record to see if it meets application-defined criteria. The application implements the RecordFilter's match() method to select the records to be returned by the RecordEnumeration.Listing 9. Filtering records
Public boolean matches(byte[] candidate) |
In this section, we'll demonstrate the functioning of J2ME RMS by building a phone appointment diary. This application will allow users to set appointments at certain dates and times, cancel appointments, or view a list of appointments already set. A quick screen view is shown in Figure 2.
Figure 2. The phone appointment diary at work
A complete list of user interface elements which comprise the various screens and screen elements of this application is available in the MID Profile API documentation that accompanies the J2ME Wireless Toolkit; for more detail on these elements, check out an earlier article I wrote for developerWorks (see the Resources section below for links to both).
A record store can store a record as a stream of bytes. In our application, the date and time entered by the user are concatenated into a string, converted into bytes, and stored.
Listing 10. Add a new appointment to the database
Public boolean matches(byte[] candidate) |
Similarly, the application retrieves the record as a stream of bytes and converts it into a string. The string is in a ####AAAA format, where # denotes numbers representing time information and AAAA denotes characters representing a description of the appointment. The application parses the string to get the date and time information and displays them in a user-desired format, such as
description - mm/dd/yyyy hh:mm AM_PM.Listing 11. Retrieve a record from the record store
byte b[] = rs.getRecord(j); |
Listing 12. Parsing data obtained from record store and displaying in a user-desired format
if (Character.isDigit(str.charAt(i))) |
The user is allowed to select certain appointments and delete them from the record store. Since the deleted
recordId is not reused so as to maintain the original sequence in records, the record is marked as invalid by a distinctive string pattern.Listing 13. Mark a record as deleted
String deactive = "@"; |
As the application displays a list of appointments, it detects the string pattern of those invalid records and skips them.
Listing 14. Skip invalid records
if (!(str.startsWith("@"))) |
One of the important aspects of this application is the user interface. The various screens are as follows:
- Welcome form: The welcome form displays a list of appointments already set and notifies the user if no appointments have been set. It provides various options to continue or exit the application.
- Menu form: The menu form provides the user with the options to view an appointment, set a new appointment, or cancel an appointment, among others.
- Display form: The display form displays the list of appointments already set.
- Set form: The set form provides a date selection field and an input text field to provide the details of a new appointment. When the user chooses to save, the information is stored in the database.
- Delete form: The delete form lists the set of appointments and provides the option to select one or more. If the user chooses to delete, the set of selected appointments is marked as invalid in the record store.
CommandListener and ItemStateListener interfaces that allow the application to respond to various events. ItemStateListener allows the application to receive events that indicate changes in the internal state of:DateField, an editable component for presenting date and timeTextField, an editable text componentChoiceGroup, a group of selectable elements
Listing 15. Acquire values from the screen
// The date value is set to a variable when the |
Listing 16 contains the complete listing for the sample application. See my previous article on J2ME in the Resources section for instructions on downloading a device emulator that will allow you to run this program on your desktop.
In this article, we covered the ability of MID applications to persistently store and retrieve data; the mechanism is modeled after a simple record-oriented database. The J2ME API
javax.microedition.rms package provides a developers treasure chest of methods and interfaces to utilize this unique feature of MID application. You should now be able to integrate data storage into your own micro Java applications.
