Thanks for great input! I guess the Application object may be a simple way to store some common data, but when implementing an Util/Mgr-like class with state and context I think a separate class is to prefer. Passing context with each call may be "clean", but does not cover all cases. For instance, say I register a listener in the singleton. The callbacks to the listener does not contain a context, and I am back at square one again...
So, I guess init-ing the singleton with a context is the simplest way, and making it a service the most robust/correct(?). /Chuck On 12 Okt, 03:01, Dianne Hackborn <[email protected]> wrote: > On Mon, Oct 11, 2010 at 2:29 PM, Al <[email protected]> wrote: > > Consider extending the Application class and using that to store > > objects which are required throughout activities. As Dianne said, you > > are less likely to leak a context if you use that. > > The Context you have from extending Application is the same context you get > with Context.getApplicationContext(). I generally recommend that people use > singletons instead of extending Application, and the semantics of Context > here isn't different between the two > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > 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 [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
