Introduction to Android tasks and fallback stacks

An application usually has multiple activity. Each activity is designed around a specific function that the user can manipulate and can initiate other activity. For example, an e-mail application might have an activity to render a new mailing list. When a user selects a message, a new activity is opened to render the message content.

An activity can start another application's activity. For example, if your application wants to send an email, you can define a intent to perform a send operation and carry some data: email address, message. An activity of other applications needs to be declared to handle such intent. In this case, intent is sending an email, so an email application will start (if multiple activity supports the same intent, the system will let the user choose which one to use). When email is sent out, your activity resumes, and it seems that email activity is part of your application. To maintain this seamless user experience, although the activity may come from different applications, the Android system will still keep these tasks in the same task.

A task is a collection of activities that users interact with in order to perform a particular job. The activity is placed in a stack (the fallback stack) according to the order in which it was opened.

The home screen of the device is the starting place for most tasks. When the user touches an application icon, the application's task will come to the foreground. If the application does not have a task at the time, a new task is created and the main activity is opened as the root of the stack.

When an activity initiates another activity, the new activity is placed at the top of the stack and the focus is obtained. The previous activity was still stored on the stack, but it has been stopped. When an activity stops, the system saves the current state of the user interface surface. When the user presses the return button, the current activity is ejected from the stack (the activity is destroyed) and the previous activity is restored (using the newly saved UI state). The activity in the stack is only ejected and pressed into two operations-pressed in when the current action is started, the user pops out using the return button, and in addition, the position and sequence of events in the stack will not change. In this case, the fallback stack operation conforms to the "LIFO" principle. The following diagram shows the progress of the fallback stack at different times along the timeline.

If the user continues to press back, all activity on the stack will be ejected, knowing that the user is returning to the main screen (or where the task started). When all activity is removed from the stack, the task ceases to exist.

A task is a tightly coupled unit that is moved to the background when the user starts a new task or returns to the main screen (through the main screen button). When the task goes backstage, all the activity in the stack stops, but the task's fallback stack remains intact – simply loses focus when the task is replaced by another task (as shown in the following figure). The task can be returned to the foreground, so the user can "discard" where and "pick up" it. For example, there are three activity in the stack of the current task (Task a) – two of which are below the current active. At this point, the user presses the home key back to the main screen, and then launches a new application. When the home screen is displayed, task a enters the background. When the new application starts, the system does not start a new task (Task B). When the user has finished interacting with the application, return to the main interface and select the application of Task A. At this point, task a returns to the foreground – three of the activity on the stack is intact and resumes at the top of the stack. At this time, the user can still return home key to the main screen, select the application icon of task B to switch to Task B (also through the most recent use of the application list to start). This is an example of Android multitasking.

Note: Multiple tasks can exist in the background at the same time. However, if a user is running multiple background tasks, the system may destroy the background activity to reclaim memory, resulting in the state of an activity being lost. The following section describes this.

Because the activity in the fallback stack is never to be rearrangement, if your application allows a user to start a specific activity from multiple activity, a new instance of the activity is created and placed on top of the stack. Therefore, an activity in your application may be instantiated several times, as shown in the following figure. Therefore, the user uses the fallback key to return, and the instance of each activity is displayed in the reverse order in which it was opened. However, if you do not want to instantiate an activity multiple times, you can modify this behavior. We'll discuss how to modify it later in the "Task Management" section.

Let's summarize the default behavior of activities and tasks:

When activity a starts activity b,activity a stops, but the system saves the state of activity a (such as the scroll bar position, the text in the edit box, and so on). If the player presses the return key at Activity B, the saved state is used to restore activity A.

When the user presses the home key to leave a task, the current activity is stopped and the current task enters the background. The system saves the status of all activity in the task. If the user starts the task again through the startup icon, the task returns to the foreground and restores 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 was restored. When an activity is destroyed, the system does not save the state of the activity.

The activity is instantiated multiple times, even if it is started by another task.