Thoughts About Content Providers

by Itamar Rogel » Wed, 30 Apr 2008 00:10:19 GMT

Sponsored Links
 i everyone,
Having developed for Android, I have some thoughts about the content
providers API which I think might be worth sharing; I believe there is
room for some improvements to be made to the content providers API
before it is stabilized and would be interested to hear if there are
other developers who feel the same way.

What's wrong about content providers, you ask? Well, as the API docs
put it, content providers are meant to "encapsulate data and provide
it to applications through the single ContentResolver interface. A
content provider is only required if you need to share data between
multiple applications". So, content providers are meant to allow data
sharing between applications, and as such they must perform some
encapsulation over the data. The question is - to what degree are the
content providers meant to abstract over the data representation &
storage mechanism?
This is important because it deeply affects the way the content
providers API is designed, and thus on anyone writing or using content
providers. And it doesn't seem to me that the API, as it's currently
designed, makes a clear choice on this issue.

On one hand, while most of the content providers rely on an SQLite DB
for their data storage, the API does seem to be designed in an attempt
to abstract over the SQL database. This has various implications, such
1. Not allowing natural usage of join queries, even in cases where it
might make sense. The process performing the query is at the mercy of
the implementor of the content provider - did she choose to allow for
a specific join case or not? And of course, the implementor can only
support joins in an ad-hoc way, e.g. by supplying content addresses
which represent specific cases of joins, or by detecting columns which
belong in different tables in the 'projection' argument and adding the
respective table and adjusting the SQL query correspondingly.
Naturally, not every reasonable usage can be accommodated for this
way. (Personally, I've bumped into such limitations when trying to
perform some non-trivial queries on Android's built-in contacts
2. Compiled SQL statements can't be used, reducing efficiency for
repeating queries.
3. Some useful SQL constructs (e.g. SELECT DISTINCT) aren't
4. Only string placeholders are allowed.
Direct access to the SQLite database would naturally make all these
limitations void (IPC issues aside, for a moment). In general, putting
the content provider in the accessing process' way to the data hurts
both sides: The accessing process loses flexibility and efficiency and
the content provider needs to perform various manipulations and
parsing actions in order to generate a proper SQL query to hand the
DB. And because the columns and table names are, by convention,
visible as constants, there is actually not much abstraction going on
in most cases. Of course, we do gain inherent data sharing & lookup
(courtesy of the ContentResolver), and we do want a content provider
to validate all modifying operations, but the current API is simply a
bit limiting.

On the other hand, there seems to be an implicit assumption that all
data sources are indeed backed by an SQL database (specifically, by
SQLite). E.g., say we're implementing a non-SQLite-backed content
provider. What shall we do with the 'selection' parameter of the
query() method, which is effectively a WHERE clause? As far as I can

Thoughts About Content Providers

by Chris Harris » Mon, 05 May 2008 21:55:26 GMT

  think you've hit the nail on the head Itamar.

Why shouldn't I be able to perform arbitrary SQL join queries across
arbitrary tables in arbitrary (sqlite-based) content providers? And
why should a SQL-like API exist for non sqlite-based content

Perhaps the content resolver could be enhanced to map content urls/
mime types to different content provider interfaces?

Chris Harris

Itamar Rogel wrote:

Sponsored Links

Thoughts About Content Providers

by Itamar Rogel » Wed, 07 May 2008 08:49:34 GMT

 hanks, Chris :-)

The mapping between mime-types and/or content URLs to content provider
interfaces sounds indeed like a very good idea.

I sure hope these issues will get their due attention before any API-
stable of Android is made...


Itamar Rogel, Briox

On May 5, 11:55 pm, Chris Harris <[EMAIL PROTECTED]> wrote:

Other Threads

1. popup menu on gmail


I notice there is popup menu on gmail application once you click on
the left checkbox of each message item. If there is no message
checked, this menu would disappear.  What is that menu? How to
implement it?




2. API for my map

Is there any google map api for my map?
Any possible to get my map data after authorization?

Thanks in advance!


3. Optus telco in Australia now allowing paid apps from Market

4. Help converting C# code (Isn't there anyone that will help out here)

5. Can anyone hook me up with an Exchange email account that I could use for testing?

6. Control a graphic with android buttons

7. external input device