16

I am writing an application that consists of business logic and UI parts. There is quite big amount of data to be stored and accessed/modified by both BL and UI. In most of the cases changes to the stored data should be reflected by UI immediately.

How do I decide whether I should or should not use direct DB access? content provider?

I have done some reading on the subject (1, 2) and I understand the difference between these two options.

Please share your thoughts on other aspects of the problem, such as performance, difficulty level of code development and maintainability, etc.

Community
  • 1
  • 1
Asahi
  • 13,378
  • 12
  • 67
  • 87

3 Answers3

18

In the apps that I've written, I've found that once you get past the learning curve, implementing a ContentProvider is pretty easy.

Pros:

  • No external dependencies.
  • DB connection lifecycle is handled by the ContentProvider.
  • Easily pass content URIs between Activities in an Intent.
  • Simple background queries via CursorLoader (or roll your own).

Cons:

  • Can be confusing if you don't have a good example handy.
  • If you have an enterprise Java background, ORM might be more familiar.

When I was trying to figure out how to implement a ContentProvider, I poured over the example code in Google's I/O application. Before you make a decision, I would at least spend a day prototyping one so you can get first-hand experience of the tradeoffs.

Erich Douglass
  • 51,744
  • 11
  • 75
  • 60
  • Thanks. Have you noticed any performance issues with content providers comparing to the direct DB access? – Asahi Aug 11 '11 at 20:03
  • 1
    @Asahi A content provider is a very thin abstraction. I haven't seen any performance issues in using them. – Erich Douglass Aug 11 '11 at 21:25
17

I would recommend spending that extra time and energy to write your ContentProvider. ContentProviders are not just about sharing access to data. The advantages

  • You have ways of listening to your data via ContentObservers
  • ContentProviders by themselves are not thread-safe, but it is easy to implement thread-safetly
  • Cursors can be asked to keep themselves up-to-date via the ContentProvider's notifyChange
  • You can add good abstraction without affecting your business layer. Here's an example: You use the Android contacts in your application. Tomorrow you plan on introducing your own contacts (via your own WebService). The ContentProvider can be modified to assimilate this requirement in a very graceful manner.
  • JOIN tables can be exposed very well by a nice design without cluttering your business-logic code. Check out some of the Android ContentProvider like the MediaStore or the ContactsContract. Check out their CONTENT_URI definitions

All in all, a ContentProvider is a very beautiful Android concept which is well-worth implementing. And once you have your definitions in place, it is not very difficult to add support for more data. It will then be as easy as writing your database code in a Helper class or your business-logic classes.

** EDIT ** Here's a utility which generates content provider code from model classes: https://code.google.com/p/mdsd-android-content-provider/

Vikram Bodicherla
  • 7,133
  • 4
  • 28
  • 34
9

IMO: Single APK == direct access through a persistence layer. Multple APKs (either your own or wanting to provide access to the data to others' apps) == Content Provider by simple necessity.

Earl
  • 791
  • 4
  • 9
  • let's say I do not want to share data. Can you estimate/compare effort required to develop? to maintain? possible performance issues? – Asahi Aug 11 '11 at 14:43
  • 2
    A content provider would be an additional layer of abstraction with the requisite development time, maintenance, and performance hit -- what those are depend on a number of things including, but not restricted to, the nature of your application and your skill as a programmer. Simply properly separating concerns in your app to include a persistence layer is the bare-minimum effort and would be the baseline by which performance impact would be measured. – Earl Aug 11 '11 at 14:49
  • Thanks. I cannot disagree with your answers but they're too general. Can you be more specific? Based on your experience, which apps/features are suitable for content providers and which aren't? Assume that a coder has a certain level of experience with both models. – Asahi Aug 12 '11 at 13:32
  • My original answer was extraordinarily specific. If you don't need to implement a Content Provider, do not. Simplest is best, most easily maintained, and best performing. It's a simple as that. Two other respondents disagreed for reasons that seemed relatively clear -- I would say thinking people can disagree on this topic. I would only create a content provider if required by design -- sharing data with other apps simply because adding a layer adds code that must be written, maintained, and given CPU cycles. To sum up: Those apps best suited for a content provider are those that need it. – Earl Aug 12 '11 at 13:58