03-25-2010 01:30 PM
I'm looking into developing a BB Java app, currently figuring out local storage. The app will be for public use.
Does anyone have advice about when it's best to use the SD card vs the persistent store? Is there a good best practices or advice document out there somewhere?
This application will have two kinds of data: preferences and what would be data files on a desktop system.
I've read up on using the persistent store, and it seems like a good option because of the level of control over the data for synchronization and such. But I notice that some OSS BB apps only use the SD card, not the persistent store.
If I'm going to deploy the app to the general public, I know that I'm dealing with many configurations and also with limits set by corporate policy (assuming such users could even install the app). So any advice on navigating these issues with respect to storage would be greatly appreciated.
Solved! Go to Solution.
03-25-2010 01:44 PM
The persistent store is fine for most purposes.
If the transient data is very large, or must be copied to the device via the USB cable, then perhaps the SD card should be considered.
However, many/most folks do not have an SD card.
03-25-2010 02:06 PM
Agree with RexDoug. Unless you have a good reason to do otherwise, I would use Persistent Store. But do use SD Card for flat or large files, so perhaps your preferences could go in Persistent and you data files go in SD Card.
If a corporate customer is allowed to install a 3rd party app, then they will probably allow access to both SD Card and persistent store. But most corporates I know won't allow installation of 3rd party apps.
03-25-2010 02:09 PM - edited 03-25-2010 02:12 PM
You may also want to consider different issues with security.
Data stored in the Persistent Store are not encrypted by default (I believe you can register with content protection mechanisms though), but can be access-controlled (see ControlledAccess API for Persistent Store) with the control enforced by the OS so that only code signed by a particular private key can access the data. Data stored on the filesystem (especially the SD Card) can be transparently encrypted and access-controlled (similar to the access-control offered by the Persistent Store) using the DRM forward-lock mechanism. The encryption/decryption is transparent and can be enforced via the EnchancedFileConnection API. Files encrypted by this mechanism can only be decrypted by the handheld that encrypted them. Furthermore, I suspect (not sure) that such files cannot be decrypted while the handheld is locked.
Then there's the slit-pipe connection issue. I'm not 100% sure, but I believe file connections to SD card and internal storage are treated as connections into the "local network"/"company network" as opposed to the "Internet". Thus, if your application opens file connections and also opens network connections via the Carrier (and Wi-Fi?) it may not be allowed to do so when the no-split-pipe-connections rule is enforced by the BlackBerry Firewall. I don't recall when this rule applies in this scenario and on what OSes, but it's definitely something that may happen on some handhelds. Persistent Store does not suffer from this issue.
P.S. In v5.0+ handheld software you have another option: SQLite database(s) that can be encrypted and/or access-controlled and stored on an SD Card or in internal memory. I presume the same security mechanism is used as for normal files on SD card and internal memory.
03-25-2010 02:20 PM
Re the split-pipe issue, my experience with that suggests is that in fact the SD card is treated as external. So an application using non BES/MDS connection (WAP, WiFi for example) can access the SD Card, whereas one using the BES/MDS connection could get split pipe when processing data from the SD Card. This is not something I have ever bottomed out, and I only ever saw it on 4.6 Bold devices, so perhaps it is no longer an issue. But it is certainly something I would test with corporate customers.
03-25-2010 02:31 PM
If file connections to SD Card are treated as external, then file connections to internal storage/memory should also be treated as external on handhelds where this internal storage/memory can be exposed as a USB Mass Storage device (e.g., Bold 9000) -- would be interesting to confirm this. Moreover, if the reason for treating these storage media as external is so that the users cannot steal corporate data by removing/mounting these media at home, then it would make sense not to treat DRM-forward-locked file connections as external, because only the handheld should be able to decrypt the resulting .rem files.
03-25-2010 02:37 PM
The testing where I saw this problem was using a BES/MDS connection but reading/writing data on to the 'external' (removable) SD Card and I had not used any security on it, so I presumed that the device was worried someone could pinch the card and so the data. Just a theory, not something I've had occasion to try again, so have not bottomed it out. Also have not found any documentation for this behavior.
03-25-2010 05:33 PM
Folks, thanks for all this. I hadn't considered the split pipe problem.
What do you all think about serializing to XML, which would be stored in either the persistent store or the SD card - depending on either my own experience or user choice. It's probably slower than storing a Hashmap in the persistent store, but might add flexibility.
I have the Javolution XML serializer working on even 4.2.1 devices, but only in the simulator so far.
03-25-2010 07:36 PM
The idea has merit, as long as the performance is up to it.
One of the problems with persistent store is that the data structure (i.e. Objects) that you store in it must remain the same, If you change the signature of a persisted object, by creating a new version of your app and say adding some new variables to your persisted Object, the app can no longer read the old Object - its data doesn't match the new format. However if you store XML data, you will just parse into the new format, so you can be more flexible.
I would suggest that if you have this working on the Simulator you will have no problems getting it working on the device. .
03-25-2010 08:28 PM
Another option for avoiding the version problem with persistent store is to use a Hashtable to store everything. I do this using Strings as keys and whatever persistable data structure I need as values (usually just String or Integer objects, but sometimes arrays or what-have-you.) The key strings can be organized hierarchically to resemble something like an XML document.
The advantage of this is that if I need to revise (or even competely re-do) my persistent data for a new version of the app, the OS doesn't complain. (I make sure that one of the values in the Hashtable is a version identifier for the persistent data scheme, so I can upgrade the persistent data as needed.)
I actually subclass Hashtable so that if my app is uninstalled, the persistent store will disappear with it.