views:

217

answers:

2

I've been looking through the Blackberry documentation and they outline 3 different mechanisms for persisting application data:

  1. Persistent Store API
  2. MIDP RMS API
  3. File System API

I'm wondering about the following things...

  1. What are the pros/cons of each approach
  2. Is there a maximum size of data that can be stored? I'm not so concerned about individual object size as much as total size. For example, there used to be a 64K limit for the persistent store but that has been expanded to several MB in the latest versions of the software. However, I couldn't find any details on maximum sizes that can be stored.
  3. Is one of the approaches considered the "best way" to persist data?
  4. Any other persistence mechanisms (such as SQL-Lite) that anyone would suggest?
+1  A: 

We use the persistent store API because it is truly persistent, even across device reboots. In fact it's almost TOO persistent as your persisted data is not deleted from the device when the app is deleted (unless you persist custom objects, I think). The storage space is limited only to the available flash memory - there are no per-application quotas.

EDIT: removed inaccurate comment about RMS

Marc Novakowski
that is an important distinction. it would cause big troubles if the data suddenly disapeared.it would be useful if there was an 'uninstall' event that would be sent to the application and it could then clean up its data.
yamspog
RMS data does indeed persist across reboots.
Richard
Thanks Richard, I removed that incorrect statement from the answer
Marc Novakowski
A: 

The issue with RMS is that the data often (but not always) does not persist across application upgrades. So if you use RMS, users may have to reconfigure your application every time they upgrade to a new build/version. This may or may not be a concern.

IMHO, the best way is Persistent Store (if you don't mind code signing), otherwise its RMS. One thing to keep in mind is that while PS seems much simpler, making your persistent data robust against application changes makes it complicated again. This is why I keep my configuration data classes separate from the classes that actually get persisted.

Now if you want file-style mass storage for something a bit more substantial than a cache or configuration object, you may want to look into the FileConnection API. That gives you a lot more potential storage space to work with.

octo