Android ContentProvider and Google IO Rest Talk

To all,

If you watch the Goog开发者_高级运维le IO session on building Android REST apps they are suggesting in all three design patterns to use Content Providers regardless if you need to share data or not.

If you look at the Content Provider class doc at http://developer.android.com/reference/android/content/ContentProvider.html they say you only need to use a content provider if you plan on sharing your data with other applications.

My application does NOT need to share any data with other applications so is using a Content provider overkill? And if so why does the Google IO REST video imply that it should be used in all scenarios?

-= Update =-

Talks are here https://dl.google.com/googleio/2010/android-developing-RESTful-android-apps.pdf.

There's no real right or wrong answer to this question but I'm strongly in the use a content provider camp for the reasons below.

You get a well-defined, easy-to-use CRUD interface for your data. Once you've written a Contract and your Provider methods, it's just a couple of lines to start retrieving data. When you come to work on the project later, or you hire another developer, you'll be up to speed in minutes.

Lots of classes in the Android framework are designed to work with content providers. In particular, CursorLoaders are brilliant, and you'll have to do a fair amount of work to emulate their functionality on your own. Good luck with managing the cursor lifecycle within an activity, in addition to writing all of your own data retrieval code and asynchronous tasks. There are various nuances and things to take care of. This will take a while.

Updating or inserting rows often? It's pretty easy to notify ListViews and other Cursor consumers of changes via the ContentProvider. If you're not using a ContentProvider, you'll have to write your own Observers and manage it yourself.

Want to integrate the Quick Search Box, or apply some powerful filtering to a ListView? Again, it's simple if you're using Cursors and ContentProviders, and a whole load of work if you're not.

If, in future, you decide to open up your data to other apps, you'll end up writing a ContentProvider anyway. Remember, you can still use ContentProviders without allowing other apps to modify your data.

I could (and may) expand on this post further but hopefully you get the idea. Google use providers in great apps like iosched for a reason.

In my experience, implementing a Content Provider can be a lot more work then simply working with a database directly. One of the reasons Google could say that an application should use a content provider could be because they believe in expansion. An app that implements a Content Provider would have an easy time expanding its data to other apps.

Because it is a REST talk, another reason could be because Google is starting to focus on a lot of cloud storage ideas. If you can implement a Content Provider, you can change your data retrieval functionality while still keeping a lot of your existing code. A Content Provider generally separates the data retrieval functionality from the actual data, leaving it much more flexible. If you wanted to switch your data to the cloud, it would be much easier having implemented a Content Provider within your application.

In my opinion though, most applications don't need to query the large amounts of data that make cloud storage desirable. It depends on the application, but I think you'll be OK avoiding a content provider if your data is meant to be kept in-house.