Shouldn't the OP also consider implementing all data access over the net with a ContentProvider and then using a managed Cursor to access it? It seems to me that would remove the need to frequently check for null, since the managed Cursor will manage many of the lifecycle issues for him.
On Apr 28, 4:04 pm, Doug <[email protected]> wrote: > On Apr 28, 12:43 pm, Dianne Hackborn <[email protected]> wrote: > > > On Thu, Apr 28, 2011 at 3:31 PM, Eric <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
