When to use a Content Provider

I would argue it is definitely a good idea to use a ContentProvider even if you don’t intend to make it public.

It’s good practice to provide the extra level of abstraction over your data to make it easier to change internally. What if you decide to change the underlying database structure at a later time? If you use a ContentProvider you can contain all the structural changes within it, where as if you don’t use one, you are forced to change all areas of the code that are affected by the structural changes. Besides, it’s nice to be able to re-use the same standard API for accessing data rather than littering your code with low-level access to the database.

Also, there is always the chance that you might want to expose your data in the future. If you don’t use a ContentProvider up front, it will be much harder to retrofit it in at a later date.

Then, there’s the other parts of the Android where ContentProvider‘s are required/recommended such as when using SyncAdapters and if you want an App Widget that involves data access for instance.

In summary, there is very little overhead involved in writing a ContentProvider up front (once you have learned the API which is a good idea anyway) so it makes sense to do so, even for private data.

Leave a Comment