Dianne, have you stepped back from this position? I hope so. While I understand and agree that #onTerminate is not an option, Application#onCreate is very useful. I typically use it to kick off async events that I want to to occur each time the app is started. By tying it to Application#onCreate instead of to an Activity, I'm not twisted into knots by the Activity lifecycle.
An example is to fetch the latest updates for the app from some web site. Its not critical when or even how opften it occurs, it just needs to occur and App#onCreate is the logical place. On a side note the standard Java implemetation of the singleton pattern (ie as a stateful static) has been on the outer for most of the last decade. IMO it was one of the reasons that made Spring dependency injection so attractive (along with clear config). Objects need lifecycle, the clearer and more dependable the better. William On Nov 1, 4:07 am, Dianne Hackborn <[email protected]> wrote: > That said, my recommendation to everyone is to just not subclass > Application. This gives you *nothing* you can't do in other, better ways. > In particular, a singleton directly represents what is really going on (it > lives for the life of the process after the first need for it) and helps > keep code more modular. > > I regret that the Application class was ever introduced; it was a compromise > to make people more comfortable with there being some kind of traditional > "main application" concept, but in fact it doesn't really fit in with how > Android works so ends up just causing problems. -- 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
