distinguishing factor of J2ME over browser-based approaches is the ability to store data on the device. This allows networked applications to be useful even in the absence of a network connection because data can be stored locally on the device for off-line browsing. Additionally, a user can modify data while out of coverage and the application can store the changes and transmit them to a server after the device regains a network connection. In some cases an application may be able to handle the device-server network data synchronization activities in the background, allowing the user to move in and out of network coverage while remaining productive. In fact, the user may not even ever be aware that network coverage was lost.

This article focuses on the Record Management System APIs (RMS) available in the Mobile Information Device Profile (MIDP). The RMS can be used to store data directly on a device for offline browsing and storing other application-related data. These APIs are found in the package javax.microedition.rms.

Can I Get a Byte?
At the heart of the RMS is something called a RecordStore, which is a container that holds a set of related records. RecordStores are referenced by name and each record is an array of bytes with an integer ID that marks its location within the RecordStore. Figure 1 shows the basic layout of the RecordStore architecture.

Figure 1. Inside the RecordStore: A MIDP RecordStore has a name and is composed of 1 to N byte array records.

The RecordStore class provides a means for performing standard CRUD (Create, Read, Update, and Delete) operations as well as some methods for sorting and filtering. As records are added each record is automatically assigned the next available record ID. In most cases, record IDs are assigned sequentially, starting at 1. However, as records are added and deleted throughout the life of a RecordStore, the next available ID is not always guaranteed to be the next number in a sequence. The lesson here is to not make assumptions as to what record ID is being assigned to a particular record.

Using the RecordStore
In order to use a RecordStore it first must be opened. If the RecordStore does not exist, it must be created as well. The following line of code can do both of these operations.

RecordStore rs = 
    RecordStore.openRecordStore("MyStoreName", true);

The first parameter indicates the name of the store to open. The second parameter tells the method to create the store if one by the specified name is not found. A reference to the open RecordStore is returned.

Once the RecordStore is open it can be used to store data. The following lines of code add a record, retrieve the record, update it, and then save it again before closing the RecordStore.

byte[] dataBytes = "Hello World".getBytes();
int key = rs.addRecord(
  dataBytes, 0, dataBytes.length);
byte[] readBytes = rs.getRecord(key);
String updatedRec = new String(dataBytes) + " two";
byte[] updatedBytes = updatedRec.getBytes();
rs.setRecord(
  key, updatedBytes, 0, updatedBytes.length);
rs.closeRecordStore();

The last operation in this example is a call to close the RecordStore. This is critical in order to make optimal use of the RMS resources. On an actual device, there is usually a limit to the number of RecordStores that can be open at the same time.

Note that when dealing with records that all data must be converted to a byte array format. This is the data structure for a RecordStore. When data is read from a RecordStore it is always returned as a byte array and usually must be converted to something more useful in order to work with it.

These are the basic operations needed to work with RecordStore. However, in the examples shown so far, the index to the RecordStore record was always known. In most applications a RecordStore will first need to be queried to find records containing the correct data. The next section discusses the RMS architecture and how this can be accomplished.