Tuesday, April 10, 2012

Android. Content provider or Database?


Since I've seen a presentation from Google IO I'm a bit confused in the question, if it's better to use content providers or databases. Or it makes no difference if I don't want to share any data with other applications.



If I've understood it right, content providers based on SQLite DBs and it's also possible that content of them is only accessable for my application.



Can you give some explanations?



Thank you very much,



Mur


Source: Tips4all

2 comments:

  1. IMHO, content providers are solutions in search of worthwhile problems.

    There certainly are worthwhile problems, particularly for cross-process data publishing. For example, you need to use a content provider to supply search suggestions to a Quick Search Box.

    However, for internal use within an application, I am still skeptical. The benefits (e.g., the single threading that Robert mentions) IMHO are outweighed by the costs (e.g., reduced flexibility compared to SQLite and rawQuery()).

    One of these days, I expect that the cartoon light bulb will shine over my head, as I finally figure out what the core Android team was thinking with respect to content providers. That certainly has happened for other areas of Android. At the moment though, the thought balloon over my head is filled with question marks, not light bulbs.

    If you do implement a content provider, bear in mind that they are accessible by other applications by default. You need to include android:exported="false" in the <provider> element to make them private to your app.

    ReplyDelete
  2. Using a content provider will give you a more modular design, and make your life easier if you at some point in future would like to reach the data from other applications.
    If you are certain that the data will only ever be needed from one application, you might as well operate directly on the database.

    There is one particular SQLite limitation you should be aware of and that is that SQLite is single-user only. What this really means is that you will need to guard your database from being accessed from multiple threads at the same time. This is generally not a problem in a content provider, since they almost always have a single-threaded implementation.

    ReplyDelete