On Sun, Oct 31, 2010 at 8:20 PM, Bob Kerns <r...@acm.org> wrote: > The Application's onCreate() method (and any static and instance > initializers) are called before ANY application component is created > or loaded. > There's no other way to make this guaranty that I am aware of. You can > come close if you put a reference to a singleton in every single > component, and remember to always do so. But that's not a good > approach -- it violates once-and-only-once. And if you're using third- > party code as part of your app, it may not be possible. Although, > admittedly, such code reuse is rare and problematic on Android, so > it's nearly always possible. >
Hm, so when do you need to just have code start running in your process first thing? Generally it needs to run for something else -- and that something else needs to make a call somewhere to get what it wants. Having that call Singleton.getInstance(context) (at which point you can do init for the first call) isn't any harder that ((Singleton)context.getApplication()), and it has some significant benefits: - Does lazy initialization so that you don't end up doing more stuff than needed when launching the process (important for first launch speed, and if you do things like receive broadcasts in the background). - Avoids Application is basically a big global. This also is far better for third party code, since if that code wants to have some global state it would be a pain to require modifying Application or having the app call into the library to init it. I don't understand your comment about violating once-and-only-once -- the whole point of a singleton is that it is one instance that is initialized the first time it is needed. There isn't actually any extra code you need to write to have it initialized, because by definition there is something there your other code needs, so the initialization can happen as a side-effect of getting access to it. > But why campaign against Application? It's a perfectly fine singleton > itself, it's just misunderstood. Fix the documentation. Deprecate > onTerminate. Suggest to people that their modularity would benefit if > they group related statics into their own singleton, and their memory > use might even improve if they then reference this singleton only > where it's needed. > I will fix the documentation. But conceptually, it just doesn't match with how you should be thinking about designing your app. -- 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
