Android Development-api Guide-tasks and fallback stacks

Task and Back Stack

English Original: http://developer.android.com/guide/components/tasks-and-back-stack.html
Acquisition (update) Date: 2014-12-16

In this article

1. Save Activity Status
2. Managing Multiple Tasks
   1. Specify startup mode
   2. Handling affinity
   3. Clearing the fallback stack K
   4. Start a task

Related articles

1. Multitasking the Android

See

1. Android Design: Navigation
2. <activity> manifest elements
3. Overview screen

An application typically contains multiple Activity. Each activity should be designed around a class of action, which the user can execute and initiate other activity. For example, an email app can list all new messages with one activity, and when the user selects one, a new activity is opened to show the details.

Activity can even initiate activity in another app on the current device. For example, if the current application needs to send an email, you can define a Intent to execute the "send" action, which can contain some data, such as the email address, the body, and so on. An Activity belonging to another application that has been declared capable of handling such Intent will then be opened. Now it is an email Intent, so the "new Mail" (compose) activity of the email application is opened (if there are multiple activity support for that class Intent, then the system will let the user choose one of them). When the email is complete, the previous activity will be restored, and the email activity looks like part of the current app. While multiple Activity may come from different applications, by putting them into the same Task, the Android system can provide a seamless and consistent user experience.

A task is a collection of multiple activity that interacts with the activity when the user is working on it. These Activity is credited to the fallback stack ("Back Stack") in the order in which they were started.

Most tasks start with a self-screen (Home). When a user taps an icon (or a shortcut icon on the Home screen) in the application list (application Launcher), the application's Task enters the foreground. If the app's task does not exist (the app has not been used recently), a new task is created, and the app's main ("main") activity is opened as the root activity of the fallback stack.

If the current activity initiates another activity, the new activity is pushed to the top of the stack and gets the focus. The previous Activity is still stored in the stack, but is in a stopped state (stop). The current state of the user interface is saved when Activity is in a stopped state. When the user presses the fallback key, the current activity is ejected from the top of the stack (destroyed), and the previous activity is restored (resume) (the previous user interface State is restored at the same time). The order of activity in the fallback stack will never change, only press in (push) and eject (pop)--is pressed into the top of the stack when the current activity is started and pops up when the user leaves with a fallback key. This way, the fallback stack runs in a "last in, first out" manner. Figure 1 shows the status of the fallback stack at various points in time, in the form of a timeline.

Figure 1. , each new Activity in the Task adds an item to the back Stack accordingly. When the user presses the fallback key, the current activity is destroyed and the previous activity is restored.

If the user presses the fallback key continuously, all activity in the fallback stack is popped up and displayed until the user returns to the home screen (or initiates the activity of the task). This task disappears when all Activity is popped out of the stack.

Figure 2. Two tasks: Task B interacts with the user in the foreground, and task A waits for a wake-up in the background.

Figure 3. Activity A is instantiated multiple times.

A task is a whole unit that, when a user launches a new task or returns to the home screen, the current task can go to the background. When the task is in the background, all of the Activity is in a stopped state, but the fallback stack for the task remains intact as shown in--2, and the task loses focus during the other task's focus. The task can return to the foreground again, so the user can go back to the state you just left and continue working. For example, assume that there are 3 activity--in the fallback stack for the current task (a task), and there are two other Activity below. At this point, the user presses the Home key and launches a new app from the list of applications. When the home screen appears, a task enters the background. When the new app starts, the system will open another task (b task) and the Activity in the new app will be stored. When the new app is finished, the user returns to the home screen again and chooses to perform the app that launches the a task. Now, the a task returns to the foreground-the three activity in the stack is still intact, and the activity at the top of the stack resumes running. At this point, the user can still cut back to the B task, either by returning to the home screen and choosing the appropriate app icon, or by selecting the task in the recent Task List (overview screens). These are examples of Android multitasking.

Note:The background can hold multiple tasks at the same time. However, if the user also needs to run many background tasks, the system may destroy the background activity to free up memory, which can result in the loss of the activity state. See subsequent chapters Activity status.

Because the activity order in the fallback stack never changes, if an activity allows multiple instances to be launched by a user, the newly created instance is pushed to the top of the stack (instead of opening an Activity instance that is already on top of the stack). As a result, an Activity may be initialized multiple times (even in different tasks), as shown in 3. At this point, if the user rolls back with a fallback key, each instance of the Activity is displayed back in the boot order (including the user interface's original state). Of course, you can modify this way if you don't want the Activity to be instantiated more than once. The modified method will be discussed in subsequent chapters managing multiple tasks.

The following summarizes the default characteristics of Activity and tasks:

• When activity a starts activity B, activity A is stopped, but the system still retains its state (such as the scroll bar position and the text entered in the form). If the user presses the fallback key in activity B, activity A resumes operation and the status is restored.
• When the user presses the Home key to leave the task, the current Activity is stopped and the current task is transferred to the background. The system saves the status of each Activity in the task. If the user resumes the task by launching the app icon in the future, the task will go back to the foreground and the Activity at the top of the stack will resume running.
• If the user presses the fallback key, the current Activity is ejected from the fallback stack and destroyed. The previous Activity in the stack will resume running. When the Activity is destroyed, the system does not retain its state.
• Activity can be instantiated multiple times, and can even be in different tasks.

Navigation design

Refer to the Android Navigation Design Guide for how jumps work between Android apps.

Save Activity Status

As described above, the system will save its state by default when Activity is stopped. This way, when the user returns, the user's interface remains the same as when they left. However, you can-and should -use a callback method to proactively save the state of your activity in case the activity is destroyed and rebuilt.

When the activity is stopped (for example, a new activity is initiated or the task is moved to the background), the system may completely destroy the activity for the purpose of freeing up memory. This will cause the Activity's status information to be lost. If this happens, the system still remembers that the Activity has been placed in the fallback stack. But when it is at the top of the stack, the system must rebuild it (not restore it). In order to prevent the loss of the user's work content, you should take the initiative to save the content, by implementing the Activity's onsaveinstancestate () callback method.

For details on how to save the Activity status, see document activities.

Multi-task management

As described above,--android all the activated Activity into the same task and a "after-first-out" stack. This management task and fallback stack works well for most applications, without having to worry about how the activity relates to the task and how the fallback stack pops up. Sometimes, however, it may be necessary to change the usual way of running. Perhaps an activity needs to start a new task (rather than being put into the current task), or you need to bring up an existing instance (instead of creating a new instance at the top of the fallback stack) when you start the activity, or when the user leaves the task and only needs to keep the root Activity, All other Activity in the fallback stack is cleared.

Furthermore, more needs can be achieved by using the attributes of the <activity> manifest element and the flag bit attribute in the Intent of the incoming startactivity () .

The <activity> properties that can be used here are mainly:

• Taskaffinity
• Launchmode
• Allowtaskreparenting
• Cleartaskonlaunch
• Alwaysretaintaskstate
• Finishontasklaunch

The available intent flags are:

• Flag_activity_new_task
• Flag_activity_clear_top
• Flag_activity_single_top

The next section describes how to use these manifest properties and Intent flag bit properties to define the Activity's relevance to the task and how they work in the fallback stack.

In addition, the following is a separate discussion of how tasks and Activity are represented and managed separately in the recent task list. For more information, see Overview screen. In general, you should let the system determine how tasks and Activity are represented in the recent task list, without having to change it.

Warning:Most apps should not change the way activity and tasks work by default. If you are sure that you need to modify the default mode, be cautious and ensure that the activity is started and other activity FallbackThe availability of the key when it returns. Be sure to test for navigation that might conflict with the user's expected effects. Defining the startup mode

The startup mode defines how the new instance of Activity is associated with the current task. There are two ways to define the startup mode:

• Using the manifest file

  When you declare an Activity in a manifest file, you can specify how it will be associated with the task when it is started.

• Using the flag bit property in Intent

  When you call startactivity () , you can include a flag in Intent that indicates how the new Activity (or not) is associated with the current task.

Thus, if activity a initiates activity B, activity B can define in manifest how it is associated with the current task (if one exists), and activity A can also specify the association of activity b with the current task 。 If both are defined, the request for activity A (defined in Intent) takes precedence over the definition of activity B (in the manifest file).

Note:Some startup modes in the manifest file are not available in the Intent flag. Conversely, some patterns in Intent cannot be defined in manifest. Using the manifest file

When you declare an activity in a manifest file, you can use the Launchmode attribute of the <activity> element to set the relationship between the activity and the task.

The Launchmode property indicates how the activity initiates the task. The Launchmode property can be set to four startup modes:

"Standard" (default mode)

The

default value. The system creates a new activity instance in the task that initiates the activity and points the Intent pass path to it. The Activity can be instantiated several times, each instance can belong to a different task, and multiple instances can exist in the same task.

"Singletop"

If an Activity already exists with an instance and is at the top of the current task's stack, the system calls the existing instance's onnewintent ()method to pass Intent to an existing instance instead of creating a new Activity instance. Activity can be instantiated several times, each instance can belong to a different task, multiple instances can exist in the same task (but only if the activity instance at the top of the fallback stack is not the activity).

For example, assume that a task's fallback stack contains root activity A and activity B, C, D (the order is a-b-c-d;d at the top of the stack). Then came a Intent that started Activity D. If activity D's startup mode is the default "standard", a new instance of the Activity D class is started, and the contents of the stack become a-b-c-d-d. However, if activity D's startup mode is "Singletop", the existing Activity D instance will receive this Intent through onnewintent () because the instance is at the top of the stack-- The contents of the stack still remain a-b-c-d unchanged. Of course, if this Intent is to start activity B, a new instance of activity B will still be added to the stack, even if activity B's startup mode is "Singletop" .

Note:When a new instance of an Activity is created, the user can press FallbackKey to return to the previous Activity. However, if an existing instance of Activity is used to process a Intent that has just arrived, the user cannot use FallbackKey back to onnewintent ()The Activity state before the arrival of the Intent.

"Singletask"

The

system creates a new task and puts the Activity instance into it as the root member. However, if the Activity already exists in another task, the system calls the Onnewintent () method of the existing instance to pass the Intent to the existing instance instead of creating a new instance. Only one instance can exist for this Activity at the same time. Note: Although the activity initiates a new task, the user can still use the fallback key to return to the previous activity.

"SingleInstance"

except that the system does not put other Activity in the same task as the current instance, others are the same as "Singletask" . Activity is always the only member of its task, and any activity it initiates will be placed in other tasks.

For example, the Android browser app declares the Web browser Activity to always open in its own separate task--set <activity> to singletask mode. This means that if an app submits Intent to open an Android browser, its Activity will not be placed in the same task as the app. Instead, start a new task for the browser, or the browser is already running in the background, as long as the task is moved into the foreground to process the new Intent.

Whether the Activity is started in a new task or in another existing task, the user can always return to the previous Activity with a fallback key. However, if you start an Activity with a startup mode set to Singletask and there is already an instance of it in a background task, the background task will switch to the foreground as a whole. At this point, the current fallback stack contains all the Activity in the task that goes into the foreground, and the position is at the top of the stack. This scenario is shown in Figure 4.

Figure 4. How the startup mode Activity for "Singletask" is added to the fallback stack. If the Activity is already in a background task with its own fallback stack, the entire background fallback stack is brought to the foreground and placed at the top of the current task.

For more information on using the startup mode in the manifest file, see the <activity> element documentation, which details the Launchmode property and its available values.

Note:UseLaunchmodeThe startup mode that the property is set for activity can be overridden by the INTENT flag bit property that initiates the activity, as described in the next section. Using the Intent flag bit property

When you start the activity, you can include the corresponding flag bit in the Intent passed to startactivity () to modify the activity's default relationship with the task. The flags that can be used to modify the default startup mode include:

Flag_activity_new_taskStart the Activity in a new task. If the activity you want to start is already running on a task, that task will be transferred to the foreground and the last saved state will be restored, and the activity will beonnewintent ()The new Intent is received in the method.

This process is the same as the "Singletask" startup mode in the previous section.

Flag_activity_single_topIf the activity to be started is the current activity (at the top of the fallback stack), the existing instance will receive aonnewintent ()Called instead of creating a new instance of the Activity.

This process is the same as the "Singletop" startup mode in the previous section.

Flag_activity_clear_topIf the activity to be started is already running in the current task, a new instance is no longer started, and all activity above it is destroyed and thenonnewintent ()Incoming Intent and resumes Activity (not at the top of the stack)

This mode does not have a corresponding value in the Launchmode property.

flag_activity_clear_top are often used in conjunction with Flag_activity_new_task . This means that the activity that already exists in the other task is first found, and the activity is placed in a location that responds to Intent.

Note:If the Activity's startup mode is configured to"Standard", it is removed from the stack first, and a new instance is created to handle the Intent. This is because the startup mode is"Standard", a new instance is always created. Handling affinity

Affinity represents the task that the Activity expects to be put into. By default, the same represents the task that the Activity expects to be put into. By default, all Activity in the same app has the same affinity value. As a result, all Activity in the same app is expected to be in the same task by default. However, you can modify the Activity's default affinity value. Activity in different applications can share the same affinity value, and activity in the same application can also give different task affinity values.

You can modify the activity's affinity with the taskaffinity attribute of the <activity> element,

The taskaffinity property is a string value that must be unique and differs from the default package name defined by the <manifest> element, because the system uses this package name as the affinity value for the default task applied.

Affinity will work in the following two scenarios:

• The Intent that started the Activity containsFlag_activity_new_task。

  By default, a new activity is started and placed in the task that invokes startactivity () and is pressed into the top of the fallback stack where the caller is located. However, if the Intent that is passed to startactivity () contains the flag_activity_new_task flag, the system looks for another task and puts the new ACTIVITY in it. This is often a new task, but not necessarily. If the affinity value of an existing task is the same as the new activity, the activity is placed in the task. If not, a new task is created.

  If this flag causes the Activity to initiate a new task, then when the user presses the Home key to leave, some action must be taken so that the user can return to the task. Some applications, such as notification managers, always let Activity start in other tasks rather than putting it into their own tasks. Therefore, they always put the flag_activity_new_task> flag in the Intent to StartActivity (). If your Activity can be started by an external application using this flag, note that the user will return the task at startup in a relatively independent way, such as through the start icon (the root Activity of such a task has a category_launcher Intent Filter, refer to the next section to start a task).

• When an Activity's Allowtaskreparentingl is set to "true".

  In this case, when a task enters the foreground, and the activity's affinity value is the same, the activity can be moved from the start-up task into the task.

  For example, suppose a travel application contains an Activity that predicts weather based on the selected city. Its affinity is the same as other Activity in the same application (the entire app defaults to affinity), and it allows you to reassign the task by this property. When the activity of another app launches this weather forecast activity, it will be in the task for this app. However, when a travel application's task enters the foreground, the weather forecast Activity will return to its task and appear in it.

tip: If a. apkThe file contains multiple "apps" that may need to betaskaffinityproperty to specify the affinity value of the Activity in each app. Cleanup fallback stack

If a user has been away from a task for a long time, the system will keep only one root activity and remove all other activity. When the user returns to the task, only the root Activity is restored. The reason the system does this is because after a long time, the user is supposed to give up the work that was done before, and return to the task in order to start a new job.

You can use some of the properties of your Activity to change the way you handle this:

Alwaysretaintaskstate

If this property of the root Activity in the task is set to "true" , the default cleanup method will not proceed. Even after a long time, all the activity in the task will be kept in the stack.

Cleartaskonlaunch

If this property of the root activity in the task is set to "true", the stack is cleaned up to the root activity as soon as the user leaves and returns the task again. In other words, exactly the opposite of alwaysretaintaskstate . Every time a user returns to a task, they see the initial state, even if they just leave for a while.

Finishontasklaunch

This property is similar to Cleartaskonlaunch , except that it takes effect on only one Activity, not the entire task. This can cause any activity to disappear, including root activity. If this property of the Activity is set to true, only the contents of the current session in the task are preserved. If the user leaves and then returns to the task, it does not exist.

Start a task

You can set an Activity as the entry for a task by sending an Action "Android.intent.action.MAIN", category " Android.intent.category.LAUNCHER " intent can be. Like what:

<activity ... >
<intent-filter ... >
<actionAndroid:name="Android.intent.action.MAIN"/>
<categoryAndroid:name="Android.intent.category.LAUNCHER"/>
</intent-filter>
...
</activity>

This Intent filter will display the activity's icon and text label (label) as the application's startup icon, and the user can initiate the activity and return to the task at the time of creation at any time thereafter.

The second feature is important: the user must be able to leave a task and then come back to use the Activity of the startup task. Therefore, the two startup modes that indicate that the activity will start the task each time: "Singletask" and "singleinstance" should be only for Action_main and the Activity of the Category_launcher filter can be used. Imagine what would happen if such a filter were not given: a Intent initiates an Activity in a "Singletask" mode and creates a new task that the user has worked on for some time in this task. Then he pressed the Home button. The current task goes into the background and becomes invisible. The user is no longer able to return to the task because there are no corresponding items displayed in the application list (application Launcher).

For those Activity that you do not want the user to return, set the finishontasklaunch of the <activity> element to "true" (see cleaning the fallback stack.)

For more information on how to display and manage tasks and Activity in the recent app list, see Overview screen.

Android Development-api Guide-tasks and fallback stacks