Flexible RMS application for J2ME programming best practices

Programming

The standard persistence scheme for MIDP applications is to use RMS. RMS is similar to a small database, RecordStore is equivalent to a database table, each "table" consists of a number of records (record), a record is a record number expressed in int RecordID and byte[]. The record number can be thought of as the "primary Key", byte[] array that stores the content.

RMS provides records that enable you to obtain records directly from an ID, or to enumerate all the records in a table.

Enumerating records is very inefficient because you can only compare byte[] data to determine whether the record is the one you want. Getting records by ID is efficient and convenient, similar to the SQL statement "select Bytearraydata from Recordstorename WHERE recordid=?". However, it is often difficult for an application to know the ID number of a record, and the "primary key" of the RMS record is limited to the int type and cannot be found using other types such as string as the primary key. Therefore, for applications that need access to different types of objects, a flexible RMS operational framework is required.

Our basic assumption is that if you can use string as a "primary key" to find records, you can easily get what you need. For example, an application setting can obtain a byte[by "sys.settings" and read out the settings sequentially, and the user login information can be obtained by "User.info" to the byte[] array, and then the user name and password are decomposed.

Therefore, we implement a Storagehandler class that provides a unique RMS access interface so that other classes do not have to consider the underlying RMS operation at all, simply by providing a string that identifies itself.

If we can implement a lookup table similar to a database index, we can find a record based on the string keyword. Therefore, we use a recordstore named "Index" to store all indexes, each of which points to the ID of a specific record, and a indexentry is designed to represent an index:

Class Indexentry {
private int selfid; ID of the Indexentry
private int RecordID; ID of the corresponding record
Private String key; Access key for Record
}

Based on index lookup, 3 steps are performed:

1. Finds the corresponding indexentry in the recordstore named "Index" based on string.

2. Remove the indexentry and get the record ID number.

3. Get another RecordStore record based on the ID number, and then you can read, update, and delete the record.

As shown in the following illustration:

Because Indexentry saves very little data, in order to speed up the search, you can read all the indexentry into a vector at the start of the application, update the vector in subsequent operations, and keep the recordstore synchronized.

To handle different types of data, all classes that can be accessed through Storagehandler must implement a storable interface:

Public interface Storable {
String Getkey ();
void GetData (DataOutputStream output) throws IOException;
void SetData (DataInputStream input) throws IOException;
}

As mentioned earlier, in a MIDP application, the best way to serialize a class is to use DataInputStream and DataOutputStream. Therefore, classes that need to be persisted can be easily accessed through the GetData () and SetData () methods. Suppose the application's class UserInfo saves the user's login name, password, and information about whether to log on automatically:

public class UserInfo {
String username;
String password;
Boolean autologin;
}

In order to save UserInfo to RMS, you need to implement the Storable interface:

class UserInfo implements storable {
    String username;
    String password;
    Boolean autologin;
    public String Getkey () {return "User.info";}//provide a unique identifier
    public void get Data (DataOutputStream output) throws IOException {
        Output.writeutf ( username);
        output.writeutf (password);
        Output.writeboolean (autologin);
   }
    public void SetData (DataInputStream input) throws IOException {
         username = Input.readutf ();
        password = Input.readutf ();
        autologin = Input.readboolean ();
   }
   //getters here ...
}

To save UserInfo, simply call the Storagehandler Save method:

Storagehandler.storeorupdate (userinfo);

To read the UserInfo, call the Storagehandler Read method:

UserInfo UserInfo = new UserInfo ();
Storagehandler.load (userinfo);

In this way, classes that need to read or save data do not have to involve the underlying RMS operation, greatly simplifying the design of the application, and enhancing the reusability and maintainability of the source code.