Keeping object's state when user presses "Back" button

Question

I have an app in which I programmatically create an EditText view. I assign an ID to that view using setId()

myEditText.setId(100);

so that Android automatically saves that object's state when pausing/stopping the app (as I was advised to do here). It works in these cases:

• (1) When I leave the app using the "Home" button: if I then come back to the app, the object's state (displayed text) is restored, as expected.
• (2) On a screen orientation change (which involves Android automatically destroying the activity and restoring it through a Bundle). The object state is also kept.

However, it doesn't work in this case:

• (3) When I leave the app using the "Back" button: if I then come back to the app, the EditText object is empty.

Any explanation as to why this happens? Does Android really distinguish between leaving the app with "Home" and with "Back"? According to the documentation, the object's state should be automatically preserved, through a Bundle, even when the activity is destroyed. And that clearly happens in case (2). But not in case (3)!

If this is normal behaviour, how could I have the app's state automatically saved and restored when the user presses "Back"? I know I could use the SharedPreferences for that, but I'd rather have Android do that automatically, just as it does in cases (1) and (2).

This happens at least in Android 4.0 and 4.2 (I haven't tested others).

Answer 1

I think I found the explanation. I only needed to read the doc more carefully (thanks to @lentz for one of the links); see here and here:

When your activity is destroyed because the user presses Back or the activity finishes itself, the system's concept of that Activity instance is gone forever because the behavior indicates the activity is no longer needed.

If the user presses the Back button, the current activity is popped from the stack and destroyed. The previous activity in the stack is resumed. When an activity is destroyed, the system does not retain the activity's state.

The above explains behaviour (3) in my question.

However, if the system destroys the activity due to system constraints (rather than normal app behavior), then although the actual Activity instance is gone, the system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the activity using a set of saved data that describes the state of the activity when it was destroyed. The saved data that the system uses to restore the previous state is called the "instance state" and is a collection of key-value pairs stored in a Bundle object.

The above probably explains behaviour (1) and (2).

What I don't see is why the user pressing Back should be interpreted as "the activity is no longer needed" ("its state needs not be preserved"). But that's a different matter.

Answer 2

You really should study activity life cycles as there are many many ways to solve the problem. Since your activity is typically pulled off of the stack and destroyed when you navigate back one quick but not necessarily the best way is to make sure your activity flagged as singleTop or singleInstance in the manifest that way it is not pulled off of the stack and recreated when you navigate back and forth. You could also use the singleton Application class. Or pass the text back and forth as params. Or use a database. Or use MVC or some other programming paradigm that will allow your views to be destroyed and recreated with out the data populating them going with it. Lots of "or's". Study activity life cycles and then look at how you have your application architecture setup already and choose the method that will work best for you.

http://developer.android.com/training/basics/activity-lifecycle/index.html

http://developer.android.com/guide/components/tasks-and-back-stack.html