Android foundation summary part 3: introduction to task of activity

This article mainly introduces the third part of the basic summary of Android: the task of activity is related, which has a certain reference value. If necessary, you can learn about it.

Today, let's talk about the task related content of activity.

Last time we talked about the four startup modes of activity, we already learned about some task technologies. Today I'll introduce them to you again. Task is a container with stack structure, which can place multiple activity instances. When an application is started, the system will create a task for it to place the root activity; By default, when an activity starts another activity, the two activities are placed in the same task, and the latter is pushed into the task stack where the former is located. When the user presses the back key, the latter pops up from the task, and the former is displayed in front of the screen. Especially when starting activities in other applications, the two activities seem to belong to the same application to the user;

System tasks and tasks are independent of each other. When we run an application, press the home key to return to the main screen and start another application. In this process, the previous task is transferred to the background, the new task is transferred to the foreground, and its root activity will also be displayed in front of the screen. After a while, press the home key to return to the main screen, and then select the previous application, The previous task will be transferred to the foreground. The system still retains all activity instances in the task, and the new task will be transferred to the background. If the user takes actions such as stepping back at this time, it is an internal operation of the task.

Let's talk about task related knowledge today, mainly including the following points:

1. Affinity of activity

2. Several common flags of intent

3. < activity > task related attributes

affinity：

Affinity is like an ID card for an activity. It can tell the task that it belongs to; Multiple activity theories with the same affinity belong to the same task. The affinity of the task itself depends on the affinity value of the root activity. Where does affinity apply? 1. Re select the host task for the activity according to affinity (work together with allowtaskreparating attribute); 2. Intent uses flag during the process of starting an activity_ ACTIVITY_ NEW_ Task tag to find or create a new task with corresponding affinity according to affinity. We will explain it in detail later.

By default, all activities in an application have the same affinity, which is inherited from the application (refer to the taskAffinity attribute of < Application >), and the default affinity of the application is the package name in < manifest >. We can set the taskAffinity attribute value for < Application > so that it can be applied to all < activities > under < Application >, You can also set taskAffinity for an activity separately. For example, in the browser provided by the system, the package is com.android.browser, but < Application > defines a taskAffinity attribute value:

Intent several common flags:

Several flags are defined in android.content.intent, the most important of which are as follows:

1.FLAG_ ACTIVITY_ NEW_ Task: when the intent object contains this tag, the system will look for or create a new task to place the target activity. When looking for it, it will match according to the taskAffinity attribute of the target activity. If the taskAffinity of a task is the same, the target activity will be pressed into the task. If the search fails, a new task will be created, Set the taskAffinity of the task as the taskactivity of the target activity, and place the target activity on this task. Note that if the taskAffinity of all activities in the same application uses the default value or is set to the same value, it is meaningless to use this flag for the jump between activities in the application, because the current application task is the best host of the target activity. We will demonstrate this feature through an example:

We will create two new projects named AppA and APPB, and create firstactivity and secondactivity respectively. We are going to jump from firstactivity in APPB to secondactivity in AppA. The secondactivity in APA is configured as follows:

Then, the jump code of firstactivity in APPB is as follows:

We want to demonstrate several steps: 1. Click the firstactivity button in APPB to jump to the secondactivity in AppA; 2. Press the home key to return to the main screen and start APPB again in the main menu; 3. Press the home key to return to the main screen and start AppA in the main menu. The demonstration process is shown in the figure:

We added flag_ NEW_ Task tag. Let's take a look at the demonstration results:

2.FLAG_ ACTIVITY_ CLEAR_ Top: when the intent object contains this tag, if an activity instance is found in the stack, empty the activity above the instance to make it at the top of the stack. For example, if our firstactivity jumps to secondactivity, secondactivity jumps to thirdactivity, and thirdactivity jumps to secondactivity, then the thirdactivity instance will pop up the stack, making the secondactivity at the top of the stack and displayed in front of the screen, leaving only firstactivity and secondactivity in the stack. The secondactivity can either receive the transmitted intent in onnewintent(), or destroy itself and restart to accept the intent. In the default "standard" startup mode, if flag is not used in intent_ ACTIVITY_ SINGLE_ Top flag, then it will be closed and rebuilt if this flag is used_ ACTIVITY_ SINGLE_ Top tag, the existing instance will be used; For other startup modes, flag is no longer required_ ACTIVITY_ SINGLE_ Top, which will use the existing instance, and the intent will be passed to onnewintent () of this instance.

Let's verify this process:

First, the activity startup mode follows the default value of "standard". Jump from firstactivity to secondactivity. The secondactivity instance is as follows:

After the jump, the secondactivity instance is as follows:

Then we add flag to the jump code in thirdactivity_ ACTIVITY_ SINGLE_ Top marking:

Both instances are shown in the following figure:

3.FLAG_ ACTIVITY_ SINGLE_ Top: when the target activity instance exists in the task and is located at the top of the stack, a new one will not be created, but this instance will be used directly. We also talked about it in the above example.

4.FLAG_ ACTIVITY_ CLEAR_ WHEN_ TASK_ Reset: if an intent contains this attribute, the activity it turns to and all activities on it will be cleared out of task when task is reset. When we return a background task to the foreground, the system will attach a flag to this action under specific circumstances_ ACTIVITY_ RESET_ TASK_ IF_ The needed flag means to reset the task if necessary, and the flag is displayed at this time_ ACTIVITY_ CLEAR_ WHEN_ TASK_ Reset will take effect. After testing, it is found that for an application in the background, if you click application in the main menu, this action contains flag_ ACTIVITY_ RESET_ TASK_ IF_ Mark needed, long press the home key, and then click the recent record. This action does not contain flag_ ACTIVITY_ RESET_ TASK_ IF_ The needed flag, so the former will be cleared and the latter will not. This mark can be shown as follows:

This tag is useful when there are split points in the application. For example, we need to select a picture in the main interface of the application, and then we start the picture browsing interface. However, when restoring the application from the background to the foreground, in order to avoid confusing the user, we want the user to still see the main interface instead of the picture browsing interface. At this time, we need to add this flag in the intent when turning to the picture browsing interface.

5.FLAG_ ACTIVITY_ RESET_ TASK_ IF_ Needed: this flag will take effect under the following conditions: 1. Create a new task to place the activity instance when starting the activity; 2. Existing tasks are placed in the foreground. The system will reset the specified task according to affinity, and the task will push in some activity instances or remove some activity instances. We combine the above clear_ WHEN_ TASK_ Reset can deepen understanding.

Task related attributes of < activity >

Several common task related attributes are defined in < activity >, which represent different behavior characteristics within the task. Let's introduce them one by one:

1.android:allowTaskReparenting

This attribute is used to mark whether an activity instance can move from the task that started it to the task with common affinity after the current application retreats to the background. "True" means it can move, "false" means it must stay in the task of the current application, and the default value is false. If a < activity > element of this activity does not set this attribute, the attribute set on < Application > will work on this activity. For example, if you want to view a web page in an application, after you start the system browser activity, the activity instance is in the same task as the current application. When our application retreats to the background, the user starts the application from the main menu again. At this time, the activity instance will be re hosted in the task of the browser application, We will not see this activity instance in our application. If you start the browser application at this time, you will find that the first interface is the web page we just opened, which proves that this activity instance is indeed hosted in the task of the browser application. Let's demonstrate this process with an example:

First, in the firstactivity of APPB, we will make the following changes to the Jump Action:

Interface when entering APPB:

At this time, we start the browser application in the main menu. The interface in front of us is as follows:

The above behavior also proves our previous conclusion. In order to explain the problem more clearly and allow you to verify it, let's demonstrate the startup process of APPB and AppA again:

For APA, on the basis of the above, you don't need to modify other places, just add an attribute to the < activity > element of secondactivity, as follows:

Then, the jump code of firstactivity in APPB is changed to:

Let's start APPB and see the following interface:

It should be noted that if APPB does not start APPB again after it retreats to the background, but directly starts AppA, the above phenomenon will not occur. The rehost action occurs during the restart of APPB.

The rendering of Android: allowreparating is as follows:

2.android:alwaysRetainTaskState

This attribute is used to mark whether the application task remains in its original state. "True" means it is always maintained, "false" means it cannot be guaranteed, and the default is "false". This property only works on the root activity of the task, and other activities will be ignored.

By default, if an application stays in the background for too long, such as 30 minutes, and the user selects the application again from the main menu, the system will clean up the tasks of the application. Except for the root activity, other activities will be cleared out of the stack. However, if this property is set in the root activity, when the user starts the application again, You can still see the interface of the last operation.

This attribute is very useful for some applications, such as browser applications. There are many states, such as opening many tabs. Users do not want to lose these states. It is very appropriate to use this attribute.

3.android:clearTaskOnLaunch

This attribute is used to mark whether to clear all activities except the root activity from the task. "True" means to clear, "false" means not to clear, and the default is "false". Similarly, this attribute only works on the root activity, and other activities will be ignored.

If this property is set to "true", every time the user restarts the application, only the root activity will be seen, and other activities in the task will be cleared out of the stack. If activities of other applications are referenced in our application, and the allowtaskreparating property of these activities is set to "true", they will be rehosted into tasks with common affinity.

No picture, no truth. Let's demonstrate this process with an example. First, modify the < activity > element of the root activity of APPB, as follows:

Fristactivity interface is as follows:

Then let's jump from firstactivity to secondactivity. The results are as follows:

4.android:finishOnTaskLaunch

This attribute is similar to Android: allowreparating attribute, except that allowreparating attribute is rehosted to tasks with common affinity, while finishontasklaunch attribute is to destroy instances. If both this attribute and Android: allowreparating are set to "true", then this attribute wins.

The above is the summary of today's content. These are common knowledge. In addition, there are many more waiting for us to explore and continue our efforts.

Original link: http://blog.csdn.net/liuhe688/article/details/6761337

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.