How about doing option 1, but having the caller include a PendingIntent for where the result should be sent. This way the caller doesn't even need to stick around while your service is running -- it can give you a PendingIntent that launches a receiver when you send it back.
If you want to go the IDL route, I would suggest an async call, with a callback interface that is suppled and you call when done. On Wed, May 6, 2009 at 12:38 PM, jseghers <jsegh...@cequint.com> wrote: > > I've been researching how to best implement a service which performs a > network transaction and returns data to the caller. > > Clearly, this needs to happen on its own thread which means some form > of async response. I can see at least three ways of doing this--some > more complex than others. In the descriptions below, C is the caller, > S is the service. > > 1) C wraps a Handler in a Messenger object, adds this to an Intent. C > then calls startService with this intent. S extends IntentService > which runs the Intents received in a worker thread. S then sends a > message to C via the Messenger. This has the benefit of not requiring > any of the async binding process or making an IDL interface that needs > to be compiled into C. This seems to be the closes to a Handler-based > response mechanism of Local Services. > > 2) C binds to S and then uses AsyncTask<> to make a blocking call to > S. S performs the network transaction and returns the data in the > return value or an out parameter. This requires the async binding > process, but does not require a callback function since the inter- > thread communications is handled by AsyncTask<> and the worker thread > is in C's context. > > 3) Make the function called in S be completely asynchronous. S defines > two interfaces: IMyService and IMyServiceCallback. S implements > IMyService.Stub. C implements IMyServiceCallback.Stub. C binds to S > then calls S via IMyService, passing its IMyServiceCallback binder. S > spins up a worker thread and returns immediately. S then calls the > callback when it has completed the network transaction. > > I am asking for advice on which methods are most appropriate. I do not > need the the service running constantly, only when the web transaction > is required. C does not use S all the time--definitely don't want to > bind during C's onCreate. However, I would like the time from when C > determines it needs to use S to getting the results back to be as > quick as possible (i.e. adding minimal latency to the already latent > network access). > > Is there any preference to having the worker thread in C or in S? > Are there any significant problems with option 1? > > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
