I have used the paradigm of the singleton as taught in this chapter in my app for a list of elements I download from a server. I recently noticed that when the app is terminated by hitting the back key, and onDestroyView and onDestroy are indeed executed, when I restart the app the singleton from the previous execution is STILL INTACT!
According to what I have found online this has to do with the singleton being part of the process even though the activity has been destroyed. So I find myself a bit confused.
I have several alternatives:
- I can check the size of the singleton in onCreate and if it is non-zero then clear it, and allow it to be populated naturally OR
- I can clear it in onDestroy and this prevent it from lingering beyond the Fragment/Activity life
I just want same deterministic behavior of the app everytime. I have found if I wait long enough or force stop the app, the process is reclaimed and a subsequent invocation of the app would start up and the singleton would appear empty, so I cannot rely on the singleton’s contents from a previous run of the app being there, but I do need to take measures “in case it is there”.
Is this consistent with your understanding of singleton in the Android environment?
ONE MORE THING
I also found that extending and using the Application class for your globals, singletons, etc using the android:name tag via the Application portion of the manifest has the same issues. The subclass of Application’s constructor and onCreate methods are NOT called when the app is restarted in the situation where the process it was running in is still alive. So that as well is not a way to get deterministic results everytime as far as initialization and application state.
I found using the following hammer to control my app’s termination very helpful:
However you can’t just go and put it in the onDestroy() method of your root activity of your app - otherwise on configuration changes it will torch the whole app. Since hitting the HOME key will onPause your app, and a config change like rotation will run you through to onPause, onStop, and onDestroy before a startup cycle (onCreate) etc, the only true way to have control of when your app is really terminated so that you can control the conditions on real app startup is to offer an app shutdown menu option or intercept the BACK key and once everything you really want persisted is handled appropriately, use the hammer above to wipeout the process.
This guarantees that when the app is subsequently started you will get a clean process, singletons will not magically have residual data from a previous run of the activity and its associated fragments, and any constructor or onCreate overrides of the Application subclass will be invoked when the app starts up.
Of course the alternative to all of this is to have your own code within Activity or Fragment onCreate() methods detect statics, globals, and singletons that have old data in them when they shouldn’t during app startup and to wipe them programmatically. Rather than polluting every activity or fragment I chose the one big hammer approach. It’s amazing how Android’s trying to keep things in memory actually has actually resulted in forcing programmer’s to manage initialization of statics in a very unwieldy fashion - many would call it a regression in runtime environment technology but it would be a fun debate at a seminar…