Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I think I found the explanation. I only needed to read the doc more carefully (thanks to @lentz for one of the links); see <a href="http://developer.android.com/training/basics/activity-lifecycle/recreating.html" rel="nofollow">here</a> and <a href="http://developer.android.com/guide/components/tasks-and-back-stack.html" rel="nofollow">here</a>:</p> <blockquote> <p>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.</p> <p>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.</p> </blockquote> <p>The above explains behaviour (3) in my question.</p> <blockquote> <p>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.</p> </blockquote> <p>The above probably explains behaviour (1) and (2).</p> <p>What I don't see is <em>why</em> 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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload