2.App Components-Activities/Tasks and Back Stack

1. Tasks and Back Stack

　　An application usually contains multiple activities. Each activity should be designed around 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 email. When the user selects an email, a

　　　　new activity opens to view that email.

　　An activity can even start activities that exist in other applications on the device. For example, if your application wants to send emails, 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.

　　A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack (the "back stack"),

　　　　in the order in which each activity is 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 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.

　　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.

　　　　

　　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

 

　　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.

　　

　　To summarize the default behavior for activities and tasks:

　　　　<1>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.

　　　　<2>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.

　　　　<3>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.

　　　　<4>Activities can be instantiated multiple times, even from other tasks.

2. Saving Activity State

　　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 should proactively retain

　　　　it by implementing the onSaveInstanceState() callback methods in your activity.

 

3. Managing Tasks

　　<1>with attributes in the <activity> manifest element

　　<2>with flags in the intent that you pass to startActivity().

 

4. Defining launch modes

　　Launch modes allow you to define how a new instance of an activity is associated with the current task

　　<1>Using the manifest file