views:

31

answers:

1

I've been watching Virgil's presentation at the Google I/O on REST-heavy applications.

Google I/O 2010 - Android REST client applications

Though the notepad tutorial makes database calls directly from the UI layer, Virgil suggests making database calls in a Service.

At the moment, my Activity's onCreate method uses an extended ContentProvider to access an SQLite database to query a Cursor to attach to the Activity's ListView.

I'd like to move this code into a Service. Easy enough. My question is, what is the appropriate way to transfer the Cursor back to the UI layer? I've seen many questions posed and there always seems to be someone suggesting there is a more appropriate way to do it. What is that way?

More specifically, I so far gather that the Activity should register as some sort of listener. When the Cursor is retrieved in the Service, a notification is set to the UI layer to access it. Where does the Service shove it so the Activity can grab it?

Also, my considered architecture is to have an extended Service, which is called by Activities. Inside this Service, database transactions will be made through the use of an extended ContentProvider, any listening Activities will be notified, and threads will be launched to hit web services. So, I have 1 extended Service, 1 extended ContentProvider and several extended Threads for different web services. Does this seem acceptable?

A: 

I am simply using the managedQuery call inside my Activity to get the Cursor. It's a fairly light operation and I don't think it will hold up the UI.

I've created a Service which then calls a web service to find new data. If new data is found, it is placed in my database and sendBroadcast is called. My Activity has a registered BroadcastReceiver which hears the broadcast and calls requery() on the Cursor.

Andrew