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. Lags during onTouchEvent on Motorola DROID

I have several complaints from Moto DROID users who experience lags
while touching.

In my app I implement the recommended workaround with two threads and
Thread.Sleep( 35 ) . It worked and works perfectly on my G1 and on
some other Google devices. But for DROID I hear many complaints.

As I don't have a DROID, could someone please tell me if there is
still a need for this workaround? Or shall I have to do anything else?


2. NDK all from within Eclipse

I was going to post this to the group but figured I'd write up a how-
to on my website instead.  Basically, here's how you configure Eclipse
to do nice C/C++ editing and automatically build your native code for
you on-save.  It also automatically refreshes your lib directory and
consequently ADT puts it straight into your APK.

I'll post this to the NDK dev group as well.  I can't believe I didn't
set that up sooner.  It cut my native development time in half.  Let
me know if you have problems/questions with it.


3. Same servicein multiple APKs, only want "best one" to launch

4. onKeyUp in 2.0 gets called even when focus is in a TextView

5. Error creating dex file while building using ANT

6. Unit Tests

7. screen size compatibility