The Persistent Store is an API in the BlackBerry® Java® Virtual Machine that allows storage of Java Objects to the flash memory, without serialization, with support for transactions, and integration with the Backup and Restore mechanism. For further background, see the recommended links at the end of this article.
Persistent Store Best Practices
1. Define a custom PersistentObject Root class
When your application is removed, the system is able to immediately clean up the Persistent Store data if yoiu have defined a Persistent Object root as a class in your application. If you instead use a core class like Vector, the system can not immediately clear the memory.
2. Make your root class fully extendable by enclosing one or more dynamic data structures
Using a class like Hashtable or Vector inside a custom containg class will give your Persistent data storage the ability to grow and change based on future application needs. You should strive to avoid making any changes to the package or classes that comprise your Persistent data storage. Any change will make the previous versions data inaccessible.
3. Avoid custom data classes for individual data elements
Use the standard types like String, Integer, Long, etc and use them in a flexible way so that you do not have to change your implementation. For example, if you need to store user data, define static Strings outside of the Persistent area which are your data keys. then use one of the core Persistable classes to hold the data values. This approach will require minimal additional Persistent Classes to be added to the system, and there is a limit on how many it can support. It will also avoid changes to the Persistent data storage model which will make your application easy to upgrade and able to retain the data from older versions.
4. Call setContent() only once
Use commit() to persist changes to an object and setContent() only when initializing your Persistent Root object. The setContent() method is expensive and unnecessary use of it will adversely affect the device performance. Following the previous guidelines, allows for use of a single Root object which is set once, and is never changed while the application is installed.
5. Be judicioius in calling commit()
As this method affects the entire tree of Persistent objects, you should not call it excessively. Use transactions when making a number of changes, and note that calling commit() on an object that contains Persistable objects will cause all it's contained objects to be committed as well.
6. If you have to make a change to extend existing Persistent Data Structures
The Best practice is to devise a structure that requires no changes, but if you must change an existing Persistent structure, you will lose all stored data when the user updates the application. To avoid this, keep the existing Persistent code and create a new package space which implements a more future proof structure. When the application upgrades, you will have access to the old data and can migrate it to the new format. Then remove the old data when it's been persisted in the new way.
7. If you have more than one app using similar Persistent Data Structures
A conflict will arise if you use the exact same Persistent structure between applications. Normal classes don't have this problem because they are hidden inside separate application modules, but Persistent classes are assigned to the Root Process by the JVM, and if the classes are identical you will see a MultiplyDefinedError. To avoid this, change the package name to reflect the application.
Store Persistent Data on the BlackBerry smartphone, introductory article: