Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Give Your Mobile Workforce Offline Muscle with the MIDP Record Management System : Page 3

MIDP offers the ability to store data locally on the device. This is a distinct advantage over browser-based approaches, especially when the user moves out of network coverage. Find out how to use the MIDP Record Management System (RMS) to store application data for offline browsing.

Iterating Query Results
Support for iterating over query results lies within the RecordEnumeration interface. An object supporting this interface is returned by calls to RecordStore.enumerateRecords().

Consistent with Java iterators, RecordEnumeration can test to see if there is a next record in a sequence with a call to hasNextElement(). If this method returns false, the end of the result set has been reached. A call to nextRecord() will return a byte array of the next record in the sequence. There is also a method nextRecordId() that returns only the ID of the next record, rather than the entire record.

While iterating a RecordEnumeration, it is quite possible that another thread might change a record in the result set. In cases where a call to nextRecord() results in an attempt to access a deleted record, an exception is thrown. To avoid this problem, RecordEnumerations can set a 'keep updated' flag to be notified of when additions and deletions take place on the underlying RecordStore. This flag can be set as part of the call to RecordStore.enumerateRecords() (as discussed previously) or by calling keepUpdated(true) on the RecordEnumeration after the query has been obtained. Special care should be taken when using this flag, however. Because the RecordEnumeration must rebuild its index whenever an add or delete takes place on the underlying RecordStore, you could incur a performance penalty.

Listening for RecordStore Changes
In the last section I discussed a way for RecordEnumerations to stay synchronized with the underlying data should records be added or deleted. The RecordEnumeration uses an event listener to support this feature. Other areas of an application can use the same technique by implementing the RecordListener interface and adding it to a specific RecordStore by calling addRecordListener(). Notifications will be sent to a listener whenever a record is added, deleted, or changed. A simple example of a RecordListener is shown below. An instance of this class must be placed on an open RecordStore by calling addRecordListener().

class ChangeNotifier implements RecordListener{ public void recordAdded(RecordStore recordStore, int recordId){ try { System.out.println( "Added a record to "+recordStore.getName() + "id="+recordId); } catch (RecordStoreNotOpenException x) { x.printStackTrace(); } } public void recordChanged(RecordStore recordStore, int recordId){ try { System.out.println("Changed a record in " +recordStore.getName() + " id="+recordId); } catch (RecordStoreNotOpenException x) { x.printStackTrace(); } } public void recordDeleted(RecordStore recordStore, int recordId){ try { System.out.println("Deleted record from "+ recordStore.getName() + " id="+recordId); } catch (RecordStoreNotOpenException x){ x.printStackTrace(); } } }

Making RecordStores Available to Other Applications
As of MIDP 2.0, RecordStores have the ability to publish RecordStore access to other MIDlet suites. This can be an advantage for sharing data between applications. A RecordStore is made available to other MIDlet suites on the device by calling setMode() on an open RecordStore.

The setMode() method takes two parameters. The first parameter must be either AUTHMODE_ANY, which grants access to any application, or AUTHMODE_PRIVATE, which allows only the owning MIDlet suite (the suite that created the RecordStore) to access RecordStore. The second parameter is a boolean that indicates if applications can have write access to the RecordStore. This allows a MIDlet suite to provide other applications read-only access. The owning MIDlet suite always has write access regardless of the AUTHMODE setting.

What's in Store?
In addition to providing ways to manage data within a RecordStore, the RecordStore class offers some methods to find out what RecordStores are available, how much storage space is available, and so forth. A call to the static method RecordStore.listRecordStores() returns an array of String containing all the names of the RecordStores available to the MIDlet. Other useful instance methods are listed in Table 2.

Table 2. Some Instance Methods for Discovering Information about the RecordStore.

getSize() Returns the size in bytes that a RecordStore currently occupies
getSizeAvailable() Returns the amount of storage, in bytes, that a particular RecordStore could consume.
getVersion() Returns a version of the RecordStore. The version is incremented each time the state of the RecordStore is modified by addRecord(), deleteRecord() or setRecord().
getLastModified() Returns the time and date (in long format) of the last time the RecordStore was modified by addRecord(), deleteRecord() or setRecord().

The RMS provides a simple and clean API for storing data locally on a device. Mechanisms for sorting and filtering data are provided as well as a means for monitoring changes that other threads may be making to a particular RecordStore. As of MIDP 2.0, applications can now share RecordStore data. This feature allows applications to cooperate through the data layer to exchange information.

David Hemphill is the Lead Architect at Gearworks, a Minn.-based company that specializes in wireless workforce automation. He is also the co-author of "Java 2 Micro Edition" (Manning). David is also a member of the Sun-Certified J2ME Exam expert group.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date