If you are loading resources, you should strongly consider making this a "singleton per context". The resources you get for different contexts can vary due to themes and such.
If your singleton is doing things you know are global to the app -- for example loading concrete resources that can't be changed by theme or configuration, and loading shared preferences under an explicit name -- then truly making it a singleton is fine. Just have the call to get the singleton take a Context, and when called the first time and constructing the singleton use getApplicationContext() on that to keep the context you will be holding in your singleton. This is essentially the context for your package, which is also your class loader, which you are singleton of. There is nothing funky or wrong with putting things together like that. So doing a singleton this way is in my mind the simplest, and as long as you know what you are doing and these are the semantics you want there is nothing incorrect or not robust about it. On Tue, Oct 12, 2010 at 12:15 PM, Chuck Lega <chuck.l...@gmail.com> wrote: > Ok, I may be a bit vague, but say I want an utility class to do some > common stuff, including resources and shared prefs. Then I need a > context. If I put a SharedPreferenceListener into the class, I am lost > if I want to do something using a context when receiving the > callbacks. > > This is how I think about it now: singleton object with init(ctx). > Init is called from App, i.e. with appctx. > What would typically this (app)context not be suitable for? > > Sorry for deviating... > > /Chuck > > On 12 Okt, 21:03, TreKing <treking...@gmail.com> wrote: > > On Tue, Oct 12, 2010 at 1:37 PM, Chuck Lega <chuck.l...@gmail.com> > wrote: > > > 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(?). > > > > What listeners and callbacks are we talking about? You may want to > provide > > more, um, context (har har) about how you're using a singleton, > callbacks, > > listeners, and the Context. There's probably a better way than > initializing > > the singleton with the Context object. > > > > And making your singleton a Service may not necessarily be the most > robust > > /correct - it depends on what you're trying to achieve with this > singleton. > > > > > ------------------------------------------------------------------------------------------------- > > TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago > > transit tracking app for Android-powered devices > > -- > 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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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
