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
as:
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
database).
2. Compiled SQL statements can't be used, reducing efficiency for
repeating queries.
3. Some useful SQL constructs (e.g. SELECT DISTINCT) aren't
accessible.
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
providers?

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

Regards,
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...

Regards,

Itamar Rogel, Briox
http://www.briox.com

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



Other Threads

1. Android Library Broken

Has anyone been able to get an APK that uses an android library to
compile using ant?

This works fine from eclipse but from the command line I always get a
null pointer exception:

Buildfile: build.xml
    [setup] Android SDK Tools Revision 6

BUILD FAILED
java.lang.NullPointerException
        at
com.android.ant.SetupTask.processReferencedLibraries(SetupTask.java:
473)
        at com.android.ant.SetupTask.execute(SetupTask.java:200)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:
288)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:
106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at
org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:
142)
        at
org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:
93)
        at org.apache.tools.ant.Main.runBuild(Main.java:743)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

Total time: 0 seconds

The source code for sdk 6 is also not available.

-- 

2. SamsungFirmwares.com: No Official Froyo Updates For Spic

SamsungFirmware <http://twitter.com/SamsungFirmware>: ''NO NEW ANDROID
UPDATES FOR GALAXY SPICA I5700 STOP ON ANDROID 2.1 WORLDWIDE!''

ah sayang sekali ya.... harapan tinggal kepada kang Leshak...

-- 
Best Regards,

Nezzar Erraldin

-- 
"Indonesian Android Community [id-android]" 

3. Wiigo

4. Gps issues in real phone

5. Samsung Galaxy S Offers Best Overall Android Graphics Performance

6. OpenGL ES libraries

7. How to Change label of activity dynamically?