I started this research article to answer the following questions: what are the limitations of using shared preferences as data storage for simple apps and games? is there an official word not to use them for more than simple key value pairs? is there a maximum limit to the amount of data that can be stored using this scheme? Should I explore other data storage options? What does it mean by internal storage and external storage? Should I instead use files to save my dynamic data?

Although there is sqllite resident on android, it is lot of work to go between java objects and a relational database. Even in the simplest case of using wonderfully crafted o/r mapping tools or libraries, it is still lot of work. So I looked for a work around. This led me to use gson/json combination to go between java objects and json strings. These strings can then be stored in shared preferences. Some of my colleagues have tested this and found it really working well for 10s of kilobytes of data. This is quite sufficient for simple games and apps.

Here is what I found

There are 5 ways to data storage in Android: 1) shared preferences 2) internal files 3) external files 4) sqllite 5) network storage in the cloud.

shared preferences are internal to the application and device. this data is not available to other applications. User cannot directly manipulate this data by mounting on to a usb port. this data is removed automatically when the application is removed.

internal files is very similar to shared preferencces except that these are standalone files that you can write to with out any predefined structure. Shared preferences is structured key/value pair data and follows a few other semantics imposed by Android for using them as preferences. I suppose I could easily switch to internal files from shared preferences as they are pretty close. Importantly I haven't found a "compelling" or "impending" reason to swtich with urgency.

external files are stored on the sd card. these become public files that other apps incuding the user could see outside the context of your application. For my app I don't believe this is applicable the data doesn't make sense outside of the context of the application. These are not user created images or documents that the user want to see independently. I may go this route if I had been storing data in the order of 10s of megabytes. this is not the case so I am not constraining the device significantly.

Sqllite is good but I don't have the bandwidth to go through the cumbesome coding for release 1. For subsquent releases this is an excellent option as I can be much faster and use much less power. this is the ideal state. but if the app becomes really popular we will take this step. However one must code so that this switch can happen with minimal change to the rest of the application. One way to do this is to have an explicit service layer that separates persistence aspects completely outside of the logic. These databases also are private to the application and not available to the outside apps.

Network storage is not an option at all as I need the app to work when disconnected. There may be suppplemental opportunities to use parse.com or a similar BAAS (Backend as a service) platform to do some of that.

Hope this helps someone else out there in the cloud as well.

So the bottom line is I am going to stick with the shared preferences, gson/json for release 1. Internal file storage is a reasonable good behavior. But I am not compelled to be good so quickly. Go to sqllite in a year or two if it gathers GOOD moss.

See the rest of the notes for links and supporting research.