MIDP applications have to run seamlessly on many devices. You’ve already seen how this can be a challenge in the user interface arena. The trick there was to use abstract concepts that would be mapped to the screen by a device-specific implementation.
MIDP’s approach to persistent storage is basically the same. Your application could run on a device with flash ROM or battery-backed RAM. MIDP applications don’t really care; all they know about are small databases called record stores. It’s up to the device’s MIDP implementation to map record stores in some reasonable manner to whatever persistent storage is available.
These are small amounts of data we’re talking about; the MIDP specification dictates that the minimum amount of persistent storage is only 8KB. The record store mechanism is highly effective for these small amounts of persistent storage.
In MIDP, persistent storage is centered around record stores. A record store is a small database that contains pieces of data called records. Record stores are represented by instances of javax.microedition.rms.RecordStore. The scope of a record store can either be limited to a single MIDlet suite or be shared between MIDlet suites. Said another way, you can either restrict a MIDlet to only access record stores that were created by a MIDlet in the same suite, or you can explicitly allow MIDlets from multiple suites to share a record store . Figure shows the relationship between MIDlet suites and record stores.
Record stores are identified by a name. Within a MIDlet suite’s record stores, the names must be unique.
Figure rivate and shared record stores between MIDlet suites
Source : ISBN (pbk): 1-59059-479-7
No comments:
Post a Comment