Thanks, 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: > I 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: > > Hi 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 > > see, our options are mainly: > > 1. Implement the WHERE parsing & filtering logic by ourselves - would > > require some work for us to reinvent the wheel. > > 2. Ignore the WHERE clause and instead perhaps give some REST-like > > URIs for some specific specialized queries we predict usage for - like > > is done i.e. in apps-for-android. This is fine, but obviously creates > > a less consistent & pleasant experience for developers using our > > content provider. > > 3. Apply the query (including the WHERE clause) on a temporary memory- > > backed SQLite DB built for this purpose. This would allow flexible > > queries, but would probably be an inefficient overkill on a mobile > > phone. Also, our data model might not fit the relational model so > > well. > > 4. Specify a different, simpler format for the 'selection' parameter. > > Easy to do, but inconsistent with the API and less nice for a > > developer using our content provider. > > > The rest of the content provider API isn't particularly adequate for > > non-DB-backed content providers as well, i.e. the whole notion of > > 'columns' and 'projection' isn't necessarily relevant for a document- > > centric data store. I think there are many cases where we wouldn't > > want a content provider to rely on an SQLite DB - it might rely on a > > remote data source, an RDF triple store, some other storage mechanism > > which is optimized for some specific type of data, etc... > > > Now, if we're building an SQLite-backed content provider, we can just > > hand the WHERE clause as-is to SQLite, but then a user-supplied > > parameter would rely on a specific table structure, negating much of > > the abstraction's power (if we change our data scheme in the future, > > we'll have to perform some preprocessing before handing the query to > > SQLite)... Additionally, our data scheme is pretty much exposed > > anyway, as we will (by convention and for convenient usage) define > > constants for the columns, and we're probably just taking the user's > > other query parameters (projection, selection arguments & sort order) > > and handing them more-or-less verbatim to SQLite as well. What then do > > we gain by limiting the developer using our content provider to the > > API of the ContentResolver's query() method, except data sharing & > > lookup? We can provide the missing features mentioned above and still > > maintain the same abstraction level. > > > So, to summarize my view - the content providers API isn't designed in > > a way that makes a clear choice about the abstraction level. True SQL- > > bound content providers lose efficiency & convenience while exposing > > quite a bit of their data scheme, and non-SQL-bound content providers > > must bend to fit to the required API, which might result in an > > inconsistent usage experience for a developer accessing that content > > provider. > > > I think this can be remedied in several ways, including: > > > A. Offer a basic, generic content provider mechanism, where a specific > > content provider can implement one (or possibly more than one) of a > > few pre-defined interfaces - e.g. the two basic and most important > > interfaces would probably be one that is SQL-centric and one that is > > document-centric. In future versions of the platform, additional > > interfaces may be added - e.g. a triple-store centric one. This option > > introduces the developer to additional content provider interfaces to > > work against, but I think it's better than having a single content > > provider interface that is limited and behaves differently for > > different content providers. > > > B. Enrich the content provider API in a way that allows efficient > > usage of SQLite, but allows non-SQLite-backed content providers to > > just ignore the extra methods / parameters (I don't think this is > > elegant, but it will work). > > > C. Some other creative way that someone here would suggest :-) > > > I hope there's some Google Android team member reading this... Anyone > > has thoughts about this? > > > Itamar Rogel, Briox > >http://www.briox.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
