8.2. Accessing common data

So far in this chapter, we’ve focused on having our app directly interact with another app, either by using Intents to communicate with another app’s activities and services, or by loading another app’s Context and using that to access its private data or even invoke its application code. You could describe the Intent (or AIDL) based integration as an interface-level integration (often associated with service-oriented architectures), and the shared Context approach as a binary-level integration. Another common form of application integration is data-level integration, akin to what Martin Fowler called the Integration Database. By having all apps read and write from the same data store, you avoid the need for any kind of application code to sit on top and manage the integration. This style of integration is well-suited for Android, because it includes the SQLite database. Let’s take a look at how this work, starting with how to use the standard integration databases that are present on every Android device.

Technique 39: Using standard ContentProviders

The integration database idea isn’t some concept we invented for the sake of this book. It’s not even some application pattern that we’ve extrapolated from third-party apps. It’s a key part of Android itself. Not only is it used by many of the bundled Android apps, the SDK itself includes APIs for using and creating integration databases: the android.content.ContentProvider abstract class. Furthermore, it includes several implementations of ContentProvider, and you must use these for many common tasks in Android. Let’s start our discussion of ContentProviders by examining how to use one of the standard providers in Android: the contacts provider.