04 Understanding Android Content Providers

content providers

Here is an example of a thread local pattern

This research on using SQLite on Android will address the following: a) How do I create a database? How do I populate it? b) How do I read from the database? c) How do I update and delete from it? d) How do I do transactions, if allowed at all? e) Are there utilities similar to JPA or Hiberante or CoreData? f) How do I run DDL scripts? g) How do I migrate data? h) How do I create a service layer that abstracts transactions much like session beans in java?

You will be surprised how GSON can propel your mobile app productivity especially release 1 candidates. In this approach you will represent the persistent state of your apps as JSON. You will use the "Beautiful" tool called GSON from google to convert your application objects to JSON and persist the resulting JSON string either in a shared preference or on internal storage as files.

This approach is really suitable for writing apps really quick. It is not unreasonable to release apps with in 1 to 2 weeks once you get seasoned at this. This would probably take a month or two otherwise. You may get a 2 to 3 times advantage on simpler apps.

Even when you consider complex apps you may get significant advantage while you are prototyping the idea and test it out on a limited release.

This semi article which will eventually be part of our upcoming Expert Android book documents the necessary elements and present the code snippets and answers the questions I ran into as we researched this topic.

This article answers the following questions

What does Android recommend for data storage options? The Official line!
The JSON solution
What is GSON?
  What is GSON's homepage?
  Is there a user guide for GSON?
  Can I save nested objects?
  Can I save nested collections of objects?
  How are characters in strings escaped?
How do you add external jar files to Android APK file?
What are shared preferences?
Difference between getSharedPreferences and getPreferences?
How to get a context independent of an activity?
Where are shared preference files stored?
How do you save JSON to a shared preference file?
What does the saved preference file look like?
How do you read JSON from shared preferences back as Java Objects?
How does escape characters work in android preferences?
What is internal storage?
How do you save to internal storage?
How do you restore objects from internal storage?
Should you use external storage like the SD card?
What are the useful references while working with this approach?
How do you code such a way that you can migrate in the future to SqlLite?
What Next?

You can represent the data storage needs of your application as a root level java object. Then use GSON to convert it to a JSON string. Once available as a string you can store it either in the shared preferences or in the private storage. Read this article for details.

Key content provider docs

There are 2 intended purposes for shared preferences in Android. First of these is a persistence mechanism to quickly remember user preferences for android apps. In that context Android has a declarative framework for generating the UI and also the persistence of the values chosen in the UI.

The second use is an extension of the first minus the UI. In this context preferences are merely key/value pairs that are stored by the application at any point of its life with no constraints of the UI.

Inventive programmers have finagled the second usage pattern to store arbitrary java objects as JSON strings and persist them using the preferences key/value pair APIs.

See the ProAndroid series to understand the first two usage patterns well. The book also shows how home screen widget state can be maintained in preferences.

In the upcoming Expert Android book I am going to write about the unintended, but quite useful, json usage pattern using the shared preferences.

This article is a quick rehash of the links and the code snippets that I am collecting which in due time will make their way to the Expert android book.

On SyncAdapters

This document is a collection of research notes on Android Loaders. These are managed asynchronous objects that help to retrieve data by activities and fragments as these later objects go through their life cycle. You will find here links to key guides on loaders, links to key classes, a key set of questions, answers to some or all of those questions, clarification on the order and timing of callbacks, sample code, and more notes as this documents is maintained as I know more.

Sample Implementation of a Provider

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.

Storing Android Data in the Cloud through Parse

Traditional Android Preferences