What is Content Provider

Today I will continue my "What is *Android component*" series and tell you about one of the essentials parts of an Android application a content provider.

Previous posts from this series:
What is Activity
What is Fragment

The problem

First of all, let's consider the problem that this component is meant to solve.

It's often useful for applications to retrieve data from other apps on the smartphone. Many pre-installed Android apps have the data that can improve the user experience of other apps. 

For example, phone book has information about the people that are probably your friends and it can be used by social networking app like LinkedIn to connect with someone you know in this social network.

User dictionary has information that can help users type faster by providing them with the most used words when they use a custom keyboard.

So, it would be convenient to have some tool that can share those kinds of data.

Something that would provide a consistent interface across all the apps on an Android device.

The solution

The solution came from the pair Content Provider and Content Resolver. These 2 Android components not only solve the problem but give much more benefits for an Android developer, but first things first.

Content Provider

What is great in Android SDK is that most of the components' names speak for itself.

Basically, all the Content Provider does is provide access to the content of some app.

There is a database in the core of a Content Provider and Content Provider adheres concepts of encapsulation and hides the structure of the underlying database and provides its' own methods to work with it.

To request data from a Content Provider you should know a Uri so that it knows what kind of data you want. Usually, in the implementation, a content provider uses UriMatcher to distinguish different types of queries.

For example, you can request all weather for particular location using something like this content:/com.weatherpp.app/mounain_view but when you need weather for particular date you may need to use another Uri, probably something like this content:/com.weatherpp.app/mounain_view/06/17/16 and Content Provider is meant to understand what you want using this Uri and give you this data. (By the way, com.weatherapp.app part is called content authority)

Content provider should implement an interface that allows to insert, update and delete data from the database. To be precise, all content providers extend the ContentProvider class but I don't want to go into implementation details to keep things abstract and easy to understand.

Content Resolver

Content Resolver is a thing that determines which content provider to query using the Uri you give to it.

How does resolver do this? It's pretty easy, to be fair. Remember the content authority? This com.weatherpp.app thing. Before using a content provider you should register it in the system through your app's manifest and provide its' authority. And using this authority Content Resolver can understand which provider you want to use, somewhat similar to how a content provider decides what piece of data you want to query.

It's worth to mention that unlike content provider you don't need to implement content resolver. It's already implemented and built-in in the system. You can get it using context.getContentResolver() in your application.  

When to use Content Provider

So in which situations you should use content provider?

As I said, content provider gives many benefits to developers besides sharing data between apps. So in my opinion answer is: anytime you're working with a database.

To explain my answer, let me tell you about the benefits.

Abstraction

The first, and I think the most important, benefit is an additional level of abstraction between the database and an object using data.

Abstraction, as I see it, is always a good thing because it allows you to think in terms of the problem domain and not think about small, tricky details of implementation.

Encapsulation

This thing kinda supports abstraction, without encapsulation abstract things are not abstract.

Encapsulation also saves you from thinking about structure and implementation of your database operations.

Scalability

This is an outcome of abstraction. First of all, you can be sure that if you have different layers of abstraction changes in low-level implementation won't affect high level. 

So when you add a table to a database or new column to a table you don't need to change all the code that uses this database/table you simply change you provider's code or don't change anything at all.

Flexibility

Actually, you're not required to expose all your data to other apps if you're using content providers.

So you can use it for your convenience and if you want to expose it you can do it by changing only one line in the manifest. You change it and voila you have your very own API.

Consistency

If you use content provider you have a consistent interface for all your data operations such as insert, delete, and query. And it's consistent not only inside your application but inside the whole platform.

And as Reto Meier said once

If you chose to not use content providers, well you chose poorly.