Flexible RMS applications based on best practices of j2-based Programming

The standard Persistence Solution of the MIDP application is to use RMS. RMS is similar to a small database. RecordStore is equivalent to a database table. Each "table" consists of several records, A record is a RecordID and content represented by byte. The record number can be viewed as a "primary key" and stored in byte [] arrays.

The record operation provided by RMS can directly obtain records based on the ID, or enumerate all records in a table.

Enumeration records are very inefficient, because only byte [] data can be compared to determine whether the record is a required record. It is efficient and convenient to obtain records by ID, similar to the SQL statement "SELECT byteArrayData FROM recordStoreName WHERE RecordID = ?". However, it is usually difficult for applications to know the ID number of a record, while the "primary key" of the RMS record is limited to the int type, and Other types such as String cannot be used as the "primary key" for search. Therefore, a flexible RMS operating framework is required for applications that need to access different types of objects.

Our basic idea is that if we can use String as the "primary key" to find records, we can easily obtain the required content. For example, you can use "sys. settings "to obtain the byte [] array, and read and retrieve the settings in sequence. You can use" user.info "to obtain the byte [] array, and then break down the user name and password.

Therefore, we implement a StorageHandler class and provide a unique RMS access interface, so that other classes do not have to consider the underlying RMS operation at all, just provide a String that can identify themselves.

If we can find a table similar to a database index, we can search for a record based on the String keyword. Therefore, we use a RecordStore named "index" to store all indexes. Each index points to the ID of a specific record, and an IndexEntry is designed to represent an index:

Class IndexEntry {
Private int selfId; // IndexEntry ID
Private int recordId; // the ID of the corresponding record
Private String key; // The Key of the access record
}

Search by index, and perform the following three steps:

1. Search for the corresponding IndexEntry In the RecordStore named "index" based on the String.

2. Retrieve the IndexEntry and obtain the ID of the record.

3. obtain another RecordStore Record Based on the ID number, and then you can read, update, and delete the record.

As shown in:

Because the IndexEntry stores very little data, you can read all the indexentries into a Vector when the application starts, in subsequent operations, update the Vector and synchronize it with RecordStore.

To process 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 above, in the MIDP application, the best way to serialize a class is to use DataInputStream and DataOutputStream. Therefore, persistent classes can be easily accessed through the getData () and setData () methods. Assume that the application's UserInfo class saves the user's login name, password, and automatic login information:

public class UserInfo {
String username;
String password;
boolean autoLogin;
}

To store UserInfo into 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 getData (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, you only need to call the StorageHandler's save method:

StorageHandler.storeOrUpdate(userinfo);

To read UserInfo, call StorageHandler's read method:

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

In this way, classes that need to read or store data do not need to involve underlying RMS operations, which greatly simplifies the design of applications and enhances the reusability and maintainability of source code.