1

I thought when I exit the app on the device and it is not visible anymore in the taskmanager the app would restart from the very beginning when I start it again.

But for some reason my app keeps some variables from the previous run and does not really restart correctly.

This happens only if restarted on the device itself. Restarting with Eclipse starts the app correctly from the very start initializing all variables.

Why is this? Is my assumption wrong that when exiting the app all classes and variables will be destroyed?

Many thanks

user387184
  • 10,953
  • 12
  • 77
  • 147
  • 1
    What do you mean by 'closed' or 'exiting'? Do you mean after navigating away from an Activity? – skynet Dec 08 '11 at 17:47
  • can't post my complete app code. The app is closed completely - at least it is not visible in taskmanager. – user387184 Dec 08 '11 at 17:50
  • A similar issue is discussed here http://stackoverflow.com/questions/8149017/why-the-application-still-exists-in-memory-after-exiting-it – Marc Van Daele Dec 08 '11 at 17:55
  • Thanks to Marc Van Daele for the reference - It is really surprising to learn that an app activity does not really get killed! What does that mean for developing an app? Do I really have to assume that ALL the activities might remain or only certain activities? Is there no way to really destroy them so the disappear and HAVE TO BE CREATED from the very start? – user387184 Dec 08 '11 at 18:00

1 Answers1

1

Well, it's more complicated than just that.

First of all, you will not see the normal Android application lifecycle when you're running it in the debugger. Killing and restarting the app will indeed start you from the beginning. The normal Android app lifecycle is not very intuitive to developers, though. Normally, if a user 'backs' out of an app to the Android home-screen, one would expect your app to be killed once there are no Activities alive. This is not the case. The Android OS will keep your application alive in memory until memory pressure causes it to release the app. This is done because if the user 'opens' the application again, it will start up much, much faster. I'll point out that your Application's onDestroy() method will actually never be killed, because that surprises some developers too.

If, however, you still have Activities alive, but they are in the background, and the Android needs memory, it will kill your activities, but will call onSaveInstanceState before doing so. This will give your Activity an opportunity to save its state in a Bundle, and in fact, most of this will be done for you by the default implementation. At this point, if all of your Activities are killed, your application will be killed, but the Android will still hold onto the saved state and from the user's point of view, the application is still alive (it will still show up in the list of active applications). When the user returns to the application, the Android will re-construct the top-most Activity (onCreate will be called, but with the Bundle that contains the contents that were saved with onSaveInstanceState) and display it to the user. As the user pops Activities off the stack again, the ones below will be re-constructed, etc, etc.

Avi Cherry
  • 3,996
  • 1
  • 26
  • 31
  • First of all, many thanks for the detailed explanation. Oh well, this makes EVERYTHING really complicated. Is there a reference which explains this in more detail and how to handle this? I really need to learn more about this! – user387184 Dec 08 '11 at 18:06
  • Well, start off with the JavaDoc page for [Activity](http://developer.android.com/reference/android/app/Activity.html). It has a large amount of information on the lifecycle of an Activity. Notably, read the section that explains "Killable" states of an Activity and "Activity Lifecycle". For the "Activity Lifecycle", read #3, which describes what I did about background activities. Your best long-term strategy is to design your Activities to behave like little self-contained applications that have the ability to save and restore their state. That will get you most of the way there. – Avi Cherry Dec 08 '11 at 19:18
  • Yes, I also found the Activity-Lifecycle to be one of the most important chapter to read so far - just didn't realize this new aspect anywhere yet. Thanks - now I will have to revisit all my Activities under this new insight... – user387184 Dec 08 '11 at 19:37
  • I played around a little concerning this issue - isn't it true that all we need to worry about are static variables. All instance variables will be recreated after finish - static might or might not depending on if their activity is still in memory. This would emmensely simplify the whole question? Any thoughts on that? – user387184 Dec 08 '11 at 22:41
  • Well, look at it this way: the typical lifecycle of an activity will be the same regardless of if it was created in response to a user clicking a button that causes a new activity to be created and pushed onto the stack, or as a result of the OS 'resurrecting' an Activity that was killed due to memory pressure. The only difference that you're going to see is in the contents of the Bundle that's passed to onCreate. – Avi Cherry Dec 08 '11 at 23:34
  • But more specifically, @user387184, instance variables will only be recreated if they are created in your regular lifecycle code of onCreate, onStart, onResume, etc... If you have changed a variable on the Activity based on the action of a UI element on that Activity, like an onClick handler, that variable will NOT be the same when the Activity is re-created! If you want it to be saved, you will need to save it in onSaveInstanceState and restore it on onCreate. Does that help? – Avi Cherry Dec 08 '11 at 23:39
  • so in summary one could do finish() in combination with cleaning static vars in onDestroy() and/or saving state in onSaveInstanceState(). Another important question I still have is: is there any order which finished activity actually gets cleaned or is this purely random (which I would assume). So I will test all that and summarize in my answer... – user387184 Dec 09 '11 at 07:22