0

I'm facing a similar issue like this one. I'm using some static class members inlcuding singletons in my aplication. When I leave the main activity using finish() and start it again, all static members are still present. It seems not to be a good soloution to call Process.killProcess(Process.myPid()); and I also don't want to need to unset all static members when I leave the application because this is error-prone when extending the application. So how would one completely quit an android application properly?

Community
  • 1
  • 1
Andreas Linden
  • 12,489
  • 7
  • 51
  • 67

3 Answers3

5

You leave the static data members alone. They are not harming anyone. Android will terminate your process when it needs the memory.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • the problem is one singleton starts a thread, and i don't want to keep it running when the application is closed. when I restart the application the thread is not restarted as i's done in the singletons constructor. – Andreas Linden Apr 17 '12 at 18:12
  • @zolex: A singleton should never start a thread. Fix your app to have an actual component (activity or service) manage the thread, and have its lifecycle methods (e.g., `onCreate()` and `onDestroy()` for a service) take care of cleaning up the thread. – CommonsWare Apr 17 '12 at 18:19
  • @zolex: All threads need to be managed by a component with a lifecycle, specifically so you can avoid the very problem you are complaining about. A singleton has no lifecycle. – CommonsWare Apr 17 '12 at 18:34
  • @zolex: There is no such concept in Android of an activity being "closed", so I will have to guess as to what you mean. If this thread is managed by an activity, fork the thread in `onResume()` and do something to cause the thread to shut down in `onPause()`. Then, when the user leaves the activity, the thread will be cleaned up. – CommonsWare Apr 17 '12 at 18:40
  • the thread is already beein stopped. the problem is to restart the thread when the app is launched again as the thread is started in the singleton constructor which is not called again as the instance is beeing kept. – Andreas Linden Apr 17 '12 at 18:44
  • @zolex: As I wrote, if this thread is managed by an activity, fork the thread in `onResume()` and do something to cause the thread to shut down in `onPause()`. Then, when the user brings up that activity again, the thread will start up again. – CommonsWare Apr 17 '12 at 18:56
1

As @CommonsWare told you can leave you static member and Android OS will take care of it and if you still need, you can overide onDestroy() and nullify all your static variables. THen it will be null when your app launches next time .

Shankar Agarwal
  • 34,573
  • 7
  • 66
  • 64
1

Just some important observations on this topic (as I think):

This is an important aspect of Android programming. Checking the activity lifecycle documentations here http://developer.android.com/reference/android/app/Activity.html does not really do justice on explaining this behaviour well - as I think.

There is the underlying class-loader concept, which loads the class incl all your initial settings of static variables. Once the activity stops and even gets destroyed it may still remain in memory!

When you now start the app again, the last state of the class will be taken - if it still can be found in memory. It is NOT the case that the class will be initialized like the very first time when the class loader loads and initialized your class.

This is also the reason why during development/debugging restarting the app really "cleans" the complete class before starting while afterwards when the app is installed and started/quit on the device you may not force a "real" start like during debugging.

Nullifying variables just increases the probability for GC. You may not force an unload afaik. So there is no way to "completely quit an app" in that sense.

One has to design the app - esp the more complex ones - around this system behaviour.

This is my understanding so far - unfortunately I have not found any good thorough documentation on this.

If I should be wrong - please forgive and correct!

user387184
  • 10,953
  • 12
  • 77
  • 147