On Apr 28, 12:43 pm, Dianne Hackborn <hack...@android.com> wrote: > On Thu, Apr 28, 2011 at 3:31 PM, Eric <e...@alum.mit.edu> wrote: > > In addition, my app has a large volume of data displayed in many > > Activities, not just one set of server data / one Activity. > > 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. 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. Doug -- 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
