Android task and back stack development documentation translation-1

Task and Back Stack

An application usually contains multiple activities.
Each activity shoshould be designed around und a specific kind of action the user can perform and can start other activities.
For example, an email application might have one activity to show a list of new emails.
When the user selects an email, a new activity opens to view that email.
An application usually contains multiple activities.
Each activity should be designed to focus on a user-executable action that can be opened by other activities.
For example, an email application may have an activity to display the new email list.
When you select an email, a new activity is opened to view the email.

An activity can even start activities that exist in other applications on the device.
For example, if your application wants to send an email, you can define an intent to perform a "send" action and include some data, such as an email address and a message.
An activity from another application that declares itself to handle this kind of intent then opens.
In this case, the intent is to send an email, so an email application's "compose" activity starts (if multiple activities support the same intent, then the system lets the user select which one to use ).
When the email is sent, your activity resumes and it seems as if the email activity was part of your application.
Even though the activities may be from different applications, Android maintains this seamless user experience by keeping both activities in the same task.
An activity can even open an activity that exists in another application on the device.
For example, if your application wants to send an email, you can define an intent to execute a send action and contain some data, such as the email address and information.
In other applications, the activity that declares that it can handle such intent will open.
In this example, intent is used to send emails, so the "compose" activity of an email program will start (if multiple activities support this intent, the system will ask the user to select which one to use)
When the email is sent, your activity will resume and the activity of the email looks like a part of your application.
Although the activity may come from different applications, Android maintains this seamless user experience by keeping the activity of the two applications in the same task.

A task is a collection of activities that users interact with when Ming a certain job.
The activities are arranged in a stack (the "back stack"), in the order in which each activity is opened.
A task is a collection of activities that interact with users when a user executes a task.
These activities are organized into a stack (back stack) in the order they are opened)

The device Home screen is the starting place for most tasks.
When the user touches an icon in the application launcher (or a shortcut cut on the Home screen), that application's task comes to the foreground.
If no task exists for the application (the application has not been used recently ), then a new task is created and the "main" activity for that application opens as the root activity in the stack.
The Home page of a device is the starting position of most tasks.
When you touch an icon in the launcher application (or a shortcut on the Home page), the task of the application will come to the foreground.
If there is no task for this application (this application has not been used recently), a new task will be created and the "Main" activity of the application will be opened as the root activity of the stack.

When the current activity starts another, the new activity is pushed on the top of the stack and takes focus.
The previous activity remains in the stack, but is stopped.
When an activity stops, the system retains the current state of its user interface.
When the user presses the Back button, the current activity is popped from the top of the stack (the activity is destroyed) and the previous activity resumes (the previous state of its UI is restored ).
Activities in the stack are never rearranged, only pushed and popped from the stack-pushed onto the stack when started by the current activity and popped off when the user leaves it using the Back button.
As such, the back stack operates as a "last in, first out" object structure.
Figure 1 visualizes this behavior with a timeline showing the progress between activities along with the current back stack at each point in time.
When the current activity opens another activity, the new activity will be pushed to the top of the stack and get the focus
The previous activity is still in the stack but in the stopped status.
When an activity is in the stop state, the system will keep its current UI state
When you press the back key, the current activity pops up from the top of the stack (the activity will be destroyed) and the previous activity changes to the resume status (the previous UI status is restored)
The activities in the stack will never be rearranged. In the stack, only the push and pop-up activities are allowed. When the current activity is started, the push is pushed to the stack. When the user leaves the stack with the back key, the push will pop up.
In itself, the back stack operation is similar to the object structure of "back-to-first-out ".
This behavior is displayed in the timeline of each vertex in a timely manner between multiple activities and the current back stack.

Figure 1. A representation of how each new activity in a task adds an item to the back stack.
When the user presses the Back button, the current activity is destroyed and the previous activity resumes.
Shows how each new activity in a task adds an entry to the back stack.
When you press the back key, the current activity is destroyed and the previous activity is restored.

If the user continues to press Back, then each activity in the stack is popped off to reveal the previous one, until the user returns to the Home screen (or to whichever activity was running when the task began ).
When all activities are removed from the stack, the task no longer exists.
If you continue to press the back key, each activity in the stack will pop up and expose the previous activity until the user returns to Home (or the activity that runs when the task starts)
After all the activities are removed from the stack, the task no longer exists.

A task is a cohesive unit that can move to the "background" when users begin a new task or go to the Home screen, via the Home button.
While in the background, all the activities in the task are stopped, but the back stack for the task remains intact-the task has simply lost focus while another task takes place, as shown in figure 2.
A task can then return to the "foreground" so users can pick up where they left off.
Suppose, for example, that the current task (Task A) has three activities in its stack-two under the current activity.
The user presses the Home button, then starts a new application from the application launcher.
When the Home screen appears, Task A goes into the background.
When the new application starts, the system starts a task for that application (Task B) with its own stack of activities.
After interacting with that application, the user returns Home again and selects the application that originally started Task.
Now, Task A comes to the foreground-all three activities in its stack are intact and the activity at the top of the stack resumes.
At this point, the user can also switch back to Task B by going Home and selecting the application icon that started that task (or by touching and holding the Home button to reveal recent tasks and selecting one ).
This is an example of multitasking on Android.
A task is a closely integrated unit. When a user opens a new task or browses the Home screen, the task can be moved to the background"
In the background, all the activities in the task are stopped, but the back stack of the task is complete. When another task occupies the position, the previous task only loses focus, as shown in.
Tasks can be returned to the foreground, so users can return to the places where they left.
Suppose: for example, the current task (task A) has three activities in its stack, two of which are under the current activity.
Press the Home Key and start a new application from the launcher application.
When the home page appears, the task enters the background.
When a new application is enabled, the system starts a task (Task B) for the new application with its own activity stack)
After interacting with the new application, the user returns to Home and selects to start the original application of task.
Now, Task A comes to the front-end. The three activities in the stack are not changed, and the activity at the top of the stack starts again.
At this time, you can go to Home and select the application icon to start Task B to switch back to Task B (or press the Home Key to display the most recent task, and then select)
This is an example of multitasking on android.

Note: Multiple tasks can be held in the background at once.
However, if the user is running your background tasks at the same time, the system might begin destroying background activities in order to recover memory, causing the activity states to be lost.
See the following section about Activity state.
Note: multiple tasks can enter the background at the same time.
However, if you run many tasks in the background at the same time, the system may destroy the background activity to restore the memory, leading to the loss of activty status.

Because the activities in the back stack are never rearranged, if your application allows users to start a special activity from more than one activity, a new instance of that activity is created and pushed onto the stack (rather than bringing any previous instance of the activity to the top ).
As such, one activity in your application might be instantiated multiple times (even from different tasks), as shown in figure 3.
As such, if the user navigates backward using the Back button, each instance of the activity is revealed in the order they were opened (each with their own UI state ).
However, you can modify this behavior if you do not want an activity to be instantiated more than once.
How to do so is discussed in the later section about Managing Tasks.
Because the activities in the back stack will never be rearranged. If your application allows users to open a special activity from more than one activity, A new activity instance is created and pushed to the stack (instead of bringing any previous activity instance to the top of the stack)
In itself, an activity in your application may be instantiated multiple times (or even from different tasks), as shown in
Similarly, if the user uses the back key to navigate back, each activity instance will be displayed in order of opening (with their own UI status)
However, if you do not want an activity to be instantiated multiple times, you can modify this behavior.
If the modification is made, it will be discussed in the management task section below.

To summarize the default behavior for activities and tasks:
Default behavior Summary of activity and task

When Activity A starts Activity B, Activity A is stopped, but the system retains its state (such as scroll position and text entered into forms ).
If the user presses the Back button while in Activity B, Activity A resumes with its state restored.
When the user leaves a task by pressing the Home button, the current activity is stopped and its task goes into the background.
The system retains the state of every activity in the task.
If the user later resumes the task by selecting the launcher icon that began the task, the task comes to the foreground and resumes the activity at the top of the stack.
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.
Activities can be instantiated multiple times, even from other tasks.
When Activity A enables Activity B, Activity A enters the stop state, but the system keeps the Activity in its own State (such as rolling position and text input form)
If you press the back key in Activity B, Activity A will be restored along with its own status.
When you exit a task by pressing the Home key, the current activity is stopped and its task enters the background.
The system maintains the status of each activity in the task.
If you select the launcher icon to start the task, the task enters the foreground and restores the top activity in the stack.
If you press the back key, the current activity will pop up and be destroyed from the stack.
The activity in the previous stack is restored.
After an activity is destroyed, the system does not maintain the activity status.
The activity can be instantiated multiple times or even from other tasks.

Save activity status
As discussed above, the system's default behavior preserves the state of an activity when it is stopped.
This way, when users navigate back to a previous activity, its user interface appears the way they left it.
However, you can-and shocould-proactively retain the state of your activities using callback methods, in case the activity is destroyed and must be recreated.
As discussed above, when the activity enters the stop state, the system protects the activity state by default.
In this way, when the user navigation goes back to the previous activity, it will display the UI
In any case, you can also consciously use the callback function to save the status of your activity. In this example, the activity is destroyed and must be re-created.

When the system stops one of your activities (such as when a new activity starts or the task moves to the background), the system might destroy that activity completely if it needs to recover system memory.
When this happens, information about the activity state is lost.
If this happens, the system still knows that the activity has a place in the back stack, but when the activity is brought to the top of the stack the system must recreate it (rather than resume it ).
In order to avoid losing the user's work, you shoshould proactively retain it by implementing the onSaveInstanceState () callback methods in your activity.
For more information about how to save your activity state, see the Activities document.
When the system stops an activity (for example, a new activity is opened or the task is moved to the background), the system may destroy the activity if the system memory needs to be restored.
In this case, information about the status of the activity will be lost.

If this happens, the system still knows that the activity occupies a position in the back stack, but when the activity is taken to the top of the stack, the system must re-establish it (rather than reuse it ).
To avoid losing your results, you should consciously implement the onSaveInstanceState () callback function in your activity to maintain your results.
Author: su1216