Proper use of Android Services with RESTful API

I'm currently learning to develop for Android and I'm having a somewhat hard time figuring out when and how to use services. I have already seen the numerous questions asked about very similar things, but I can't quite find the exact answer to my questions.

I have an app which talks to a restful api. I fetch several lists which I would like to cache in memory and only update if the user hits a refresh button, or certain activities are created. If a list is refreshed, sometimes several activities need to be notified, so that they update their content (if they are on screen at the time). I store the data I retrieve in value objects.

On a non-android app I would usually create a sort of dataproxy class in a singleton pattern. I could ask the dataproxy to update its data 开发者_运维百科via http request, and then it would send some kind of system-wide notification as soon as the data is changed, so the interested views can all be updated. I hope this makes sense.

My question is now: How do I do this the android way? Do I bind and unbind to a dataproxy service, which I can actively ask to fetch certain data? Should I do my non-persistent caching in this service or somewhere else? Do I need AIDL, or can I just use normal objects for moving data between a service and an activity? Although I find the android dev guide pretty well written and useful, I haven't found much information on services best practice.

Thank you in advance!

How do I do this the android way?

You assume that there is a single "android way".

Do I bind and unbind to a dataproxy service, which I can actively ask to fetch certain data?

You can either bind, or send commands via startService().

Should I do my non-persistent caching in this service or somewhere else?

If you're sure that you only want it to be in RAM, I'd lean towards static data members. Make the service be the "do-er", not the store.

That being said, I'd treat this more as a synchronization pattern, with the real store being a database or directory, with a cache in RAM. Users will find this less frustrating -- under your current plan, if they are in your app, then take a phone call for a while, they'll have to have you download all the data again.

Do I need AIDL, or can I just use normal objects for moving data between a service and an activity?

If they are all in the same process, normal objects is fine via binding, or use Intent extras for the command pattern.

Now, back to:

How do I do this the android way?

Option #1: Wrap your store in a ContentProvider and use ContentObserver for changes.

Option #2: Have your service send a broadcast to your package when the data changes, so the foreground activity can find out about the change via a BroadcastReceiver registered via registerReceiver(). Other activities simply grab a fresh look at the data in onResume() -- the only one that immediately needs to know of the data change is the one the user is interacting with, if any.

Option #3: Use the binding pattern with the service, and have the foreground activity register a listener with the service. The service calls the listener when data is updated. Once again, ather activities simply grab a fresh look at the data in onResume()

Option #4: Cook up your own listener system as part of your static data members, being very very careful to avoid memory leaks (e.g., static reference to an activity or service that is destroyed, preventing its garbage collection).

There are probably other options, but this should get you started.

The Google IO session mentioned by Andrew Halloran: http://www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html

Check out the Google I/O session videos. I implemented REST api calls the easy BUT wrong way. It wasn't until watching this Google I/O video that I understood where I went wrong. It's not as simple as putting together an AsyncTask with a HttpUrlConnection get/put call.