Can I perform this Android query with ContentResolver.query()? (LEFT JOIN and CASE)

eidylon picture eidylon · Jun 14, 2011 · Viewed 16.4k times · Source

I am looking to perform the following query (in pseudo-code) on Android:

SELECT C.ID, C.NAME, CASE ISNULL(G.GROUPID,0) = 0 THEN 0 ELSE 1 END INGROUP
FROM CONTACTS C 
LEFT JOIN GROUPMEMBERSHIP G ON G.CONTACTID = C.ID AND G.GROUPID = ?

I am looking to select the ID and Name of ALL contacts in the system address book, via the default Contacts ContentProvider, along with a 0/1 field indicating whether the contact is a member of group ? .

I could of course get all contacts easily enough, then loop through and query the membership separately easy enough in my Adapter class, but I'd imagine performing the two queries as one outer joined query would yield much better performance.

Can I do this with the standard high-level string-projection and ContentResolver.query() method? Or would this kind of query require digging into more direct SQL execution?

Answer

jcwenger picture jcwenger · Jul 1, 2011

Edit: Okay, so this doesn't actually solve the question asked, because eidylon is tied to an existing ContentProvider as mentioned in their question. However, this does cover how you do a JOIN if you own the ContentProvider source and API. So I'll leave it for those who want to know how to handle that case.


This is easy! But unintuitive... :)

query(Uri uri, String[] projection, String selection, 
String[] selectionArgs, String sortOrder)

Okay, so what is URI? Typically, you have one URI per table.

content://com.example.coolapp.contacts serves data out of your CONTACTS table. content://com.example.coolapp.groupmembers serves data out of your GROUPMEMBERSHIP table.

But URI is really just a string. Use it however you like. Make a block of code in your ContentProvider that responds to content://com.example.coolapp.contacts_in_group. Within that block of code in the ContentProvider, you can get raw access to your SQLite DB, unfettered by the limited query() data model. Feel free to use it!

Define your selection fields however you like. They don't have to map to table column names -- map them how you need to, in order to get your parameters in.

Define your projection how you need -- It may contain columns from both tables after the join.

Bing, you're done. Google does this same model internally in their own code -- Go look at the Contacts provider API -- you see "bla.RawContact" and "bla.Contact" and etc as content URIs. Each serves data out of the same table in the DB -- the different URIs just provide different views of that same table!