4

since i noticed the class SimpleCursorAdapter is deprecated and I should now take advantage of the new Loader APIs, which I really like, however when I tried to do so, I found out that CursorLoader works only with ContentProvider.

Now my question is, do I really need a content provider? Even the official guide says:

You don't need to develop your own provider if you don't intend to share your data with other applications. However, you do need your own provider to provide custom search suggestions in your own application. You also need your own provider if you want to copy and paste complex data or files from your application to other applications.

And I think I dont need any on this + it therefore creates unnecessary complexity. So .. what should I do, hack my own CursorLoader to work only with my database like this (CursorLoader usage without ContentProvider), which, honestly i dont really like, or should i just suck it up and conform to making a provider?

Thanks!

Community
  • 1
  • 1
urSus
  • 12,492
  • 12
  • 69
  • 89
  • This [**blog post**](http://www.androiddesignpatterns.com/2012/07/loaders-and-loadermanager-background.html) explains why you shouldn't use the `managedQuery` and `startManagingCursor` methods. The `SimpleCursorAdapter` class is not deprecated (one of the constructors that creates the `SimpleCursorAdapter` is deprecated though). – Alex Lockwood Aug 15 '12 at 14:00
  • Yea sorry my bad, thats what I though. Thanks for your reply. – urSus Aug 15 '12 at 14:09
  • Possible duplicate of [When to use a Content Provider](http://stackoverflow.com/questions/4936712/when-to-use-a-content-provider) – Aabesh Karmacharya Aug 19 '16 at 20:33

2 Answers2

4

You can write a Loader (or use CommonsWare's SQLiteCursorLoader) to query your SQLiteDatabase directly instead. The documentation is correct in that you don't really need a ContentProvider if your app only requires simple access to local data (as opposed to sharing that data with different processes/applications).

That said, the ContentProvider does offer a few benefits. For example, you need one to implement a SyncAdapter or a search interface with the SearchManager. I try to incorporate these into my applications so I find myself implementing ContentProviders all the time. The ContentResolver also provides an easy means of providing global notifications to the underlying data source when changes are made. For example, the CursorLoader will register a ContentObserver on its Cursor, causing the Cursor to receive a notification when you call ContentResolver#notifyChange(Uri uri, ContentObserver observer) on the given Uri. If you were to load data directly from your SQLiteDatabase instead, setting this up would require a bit more work.

Alex Lockwood
  • 83,063
  • 39
  • 206
  • 250
1

Both options are as good as the other. It's a matter of preference.

Personally I think that using content provider for apps that won't share anything to other application annoying and a pain-in-the-behind, but there's a valid advice I've heard in an interview (it was from the developer of those big startup types of apps, like Pocket or Flipboard) that said: "even if might sound complicate on the beginning, do the code the Android way because it will be time/effort saver in the future" I reckon the advice in focusing on the facts that using the recommended way, get supported, bug fixed and easier expansible faster.

Budius
  • 39,391
  • 16
  • 102
  • 144
  • It's not really a "matter of preference"... there are ups and downs to each approach. A `ContentProvider` will pretty much work no matter what (since it is pretty much just a wrapper around the actual data source), but implementing one would just be extra work for you if you didn't actually need it. – Alex Lockwood Aug 15 '12 at 15:26