On Thu, Apr 28, 2011 at 7:04 PM, Doug <beafd...@gmail.com> wrote: > > Another way you can approach this is to have a singleton that arbitrates > > access to the service -- it binds through the application context, and > has a > > reference count of the current activities using it, to know when to > unbind. > > (If you care about unbinding, you very well may not.) Then each > activity > > gets this singleton, sets a callback, and update its UI when receiving > the > > callback. If the singleton is already bound to the service, it performs > the > > callback immediately. > I'll add that if this scheme is used, the calling activity must > absolutely unregister its callbacks in onStop() or the singleton- > arbiter will leak the activity because the callback will contain an > implicit reference to the activity. This situation can arise if users > are allowed to navigate away from an activity (back or forward in the > stack) without waiting to receive a response from the remote service. >
You can do it in onPause(), onStop(), or onDestroy(), depending on how you want to structure your activity. You just want to make sure you do it at some appropriate point in the lifecycle. Well. Honestly, it may not even be that important. If your service isn't actively doing stuff while it is created but just responding to requests from clients, there would be no harm in just binding to it in the first activity and never unbunding. When all activities are in the background, the service is only as important as the most important activity bound to it (if the service isn't itself started), so the process will be managed in the exact same way is one that just had background activities, and when the process is killed any outstanding service connections it create are canceled. (Though I guess, thinking about it, if this is all you are doing with a service, there is probably no benefit a service is giving you anyway. A service would only actually be helping if you had started it so it would actually keep your process running in the background. If you aren't starting the service, trying to use a service here is just more complexity that is completely not needed.) If you want to avoid activity leaks AND have an activity that's not > currently started handle a response, you'll have to completely > decouple the activity instance from the singleton-arbiter. The way I > did this for my purposes was to have the activity (or service) receive > notification from the remote service via a broadcast containing a > unique id for that request. > I would strongly recommend staying away from using broadcasts to communicate with services. Actually doing this in a way that is secure is non-trivial -- you need to define a signature-only permission that the send of the broadcast requires and your application requests. (Unless you are directly sending the broadcast to a receiver declared in your manifest, but that is likely not going to be of any help for this situation.) My number one rule: follow the local service sample where you have everything running in one process. This makes things *so* much easier, and it is trivial to do callbacks from the service to your app the same way you would in writing normal code. In effect all the service is doing here is just telling the system that you are doing something that you want it to keep you around for. -- 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
