A few quick questions I tend to ask people using services:

1) Do you really need a service? If all you want to do is some
background processing that is transient in nature, a regular thread is
OK. It will be killed eventually when your app is no longer on-screen
but maybe you can deal with that.

2) Do you really need IPC? AIDL and intents are easy to use .... for
what they are. If your service is intended to only be used by your own
application, you can simplify a lot by simply passing pointers around:


  http://osdir.com/ml/AndroidDevelopers/2009-02/msg02636.html

Remember that a service is really just a lifecycle abstraction. It's a
shame that the documentation strongly implies that you MUST use rpc to
communicate with them, when that isn't true.

3) Are you using intents to give work to the service? If so, what is
the lifetime policy of the service? Binding provides this for you,
submitting intents does not. In particular, realize that it's scarily
easy to leak services by having them enter a state in which they wait
for work forever. Make sure there's always a timer running that will
shut the service down if it has nothing to do - and make sure that
it's set up in onCreate() *not* onStart(). Your service is not
guaranteed to ever receive onStart ... if it's killed by the kernel
OOM killer and then restarted, it'll receive onCreate but not onStart.

Hope that helps!

On May 6, 9: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?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to