>From Dianne, > 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. > > As far as using Application to clean up statics -- this simply doesn't > really make sense, for the reasons above.
I confess to using an Application subclass to clean up statics in my application and I would be glad to repent if I knew how. Dianne, is there a sample application in the SDK (or elsewhere) showing the best practice for collecting statics in a static singleton? The SDK documentation about singletons at http://developer.android.com/resources/faq/framework.html seems to suggest the use of an Application subclass: "There are advantages to using a static Singleton, such as you can refer to them without casting getApplication() to an application-specific class, or going to the trouble of hanging an interface on all your Application subclasses so that your various modules can refer to that interface instead. But, the life cycle of a static is not well under your control; so to abide by the life-cycle model, the application class should initiate and tear down these static objects in the onCreate() and onTerminate() methods of the Application Class." On Oct 31, 2:07 pm, Dianne Hackborn <hack...@android.com> wrote: > Only one Application per-.apk-per-process is created, ever. If you use > android:process to have multiple .apks sharing the same process, each .apk > will have its own Application instantiated in the process. If you use > android:process to have an .apk run in multiple processes, each process will > get its own Application instance. > > Application.onTerminate() is *never* called. This function is there for > environments where processes are emulated, which is not any production > device or the emulator. But it doesn't matter that it isn't called > because... well, Application lives for the lifetime of the process, and the > process goes away by the OOM killer killing it, which cleans up Application > and everything else related to the process without any user space code for > it running. > > Now it is conceivable that there is some case where if a process is left > completely empty (with no app components) for a while, and GCs, the data > about the loaded process may get GCed as well and have to be recreated. I > don't see how this can happen off-hand (there are a number of ways > non-weak-references are held between these things), but I can't say for > certain there is no such bug here. > > 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. > > As far as using Application to clean up statics -- this simply doesn't > really make sense, for the reasons above. For a legacy application with > statics that can't be re-used again in the same process, your only choice is > probably to just self-kill your process when the user leave the game. That > is, when the game activity is finished. If you can reset your statics after > the game is over, then at least instead of killing it you can do that when > the activity is finished. But this needs to be driven by Activity, not > Application. > > On Sun, Oct 31, 2010 at 12:34 AM, Mark Murphy <mmur...@commonsware.com>wrote: > > > > > In a comment on an epic StackOverflow question-and-answer, a gentleman > > who I will call Tim has outlined a scenario he says he is running > > into, one I have some difficulty believing. > > > Reading somewhat between the lines, the flow would appear to be this: > > > 1. User taps on an activity icon in the launcher > > 2. Process starts up > > 3. Application object is put in that process -- and a custom > > Application object loads an NDK library which initializes some > > statics/singletons > > 4. User uses application > > 5. User abandons application (e.g., HOME) > > 6. Later, user returns to application, before the first process is > > killed or recycled for use with another app > > 7. A second Application object is created, in the same process, before > > the first Application object is called with onTerminate() > > > This screws things up for Tim's app -- apparently, it does not deal > > with pre-initialized statics/singletons well. They were presumably > > counting on onTerminate() to let them clean up the NDK space. As a > > result, they are relying upon killProcess() (somehow...unclear under > > what conditions they might call this) to force their own process to go > > away, so their statics get cleaned up. > > > Step #7 is what confuses me. I can see a new Application object being > > created, but only if the first Application object were terminated. I > > don't see any NDK-related bugs out on b.android.com that seem to match > > this complaint, though in principle it might cause problems for > > non-NDK apps as well. > > > Has anyone encountered a new Application object being created in a > > process before the old one is terminated? > > > Thanks! > > > -- > > Mark Murphy (a Commons Guy) > >http://commonsware.com|http://github.com/commonsguy > >http://commonsware.com/blog|http://twitter.com/commonsguy > > > Android 2.2 Programming Books:http://commonsware.com/books > > > -- > > 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
