Task Stack for Android

Transfer from http://blog.csdn.net/liuhe688/article/details/6761337

The ancients learned to ask no power, less time to grow old. The paper came to shallow, and it was preach to be known. Southern Song Dynasty, "Winter Night Reading" Yù Pei (Yu zi)

The software industry is the same, how many predecessors spared no effort to appear in the software industry, the prosperity of the scene, which has become a lot of master figures. Today we stand on the shoulders of great men, there will naturally be a lot of advantages, but do not forget, to the technical awareness of the improvement, still need us to practice, to practice.

Today, let's talk about task-related content for activity.

The last time we talked about the four startup modes of activity, we've learned a bit about task technology, and I'll introduce you today. A task is a container with a stack structure that can place multiple activity instances. Starting an application, the system creates a task to place the root activity; By default, when an activity initiates another activity, two activity is placed in the same task, and the latter is pressed into the task stack where the former resides. When the user presses the back key, the latter is ejected from the task, and the former is displayed in front of the screen, especially when the activity is launched in other applications, two activity is as if the user is the same application, and the system task and task are independent from each other, and when we run an application, Press the home button to go back to the main screen, start another application, the process, the previous task is moved to the background, the new task is transferred to the foreground, its root activity will be displayed before the screen, after a while, press the home button back to the main screen, and then select the previous application, The previous task is moved to the foreground, and the system still retains all the activity instances within the task, and the new task is moved to the background, and if the user moves back and forth, the action is done inside the task.

Today we will talk about task-related knowledge, the main points of the points:

1.Activity Affinity (Affinity)

2.Intent a few common flags

3.<activity> and task-related properties

Affinity

Task is like its identity card for activity, it can tell the task, it belongs to a member of this task, and the multiple activity theory with the same affinity belongs to a task, The affinity of the task itself is determined by the affinity value of the root activity. What is the occasion for affinity application? 1. Select the host task (in conjunction with the allowtaskreparenting attribute) for the activity according to Affinity; 2. Intent uses FLAG_ACTIVITY_NEW_ when initiating an activity A task tag that finds or creates a new task that has a corresponding affinity based on affinity. We will explain it in detail later.

By default, all activity within an app has the same affinity, which is inherited from the application (reference <application> Taskaffinity property). While application default affinity is the package name in <manifest>, we can set the Taskaffinity property value for <application> so that it can be applied to <application All <activity> under >, or you can set taskaffinity for an activity individually. For example: In the system's own browser, the package is Com.android.browser, but <application> customizes a taskaffinity property value:

2. <application android:name="Browser"
4. android:label="@string/application_name"
6. android:icon="@drawable/ic_launcher_browser"
8. android:backupagent=". Browserbackupagent "
10. android:taskaffinity="Android.task.browser" >

Intent several common flags:

Several flags are defined in Android.content.Intent, the most important of which are the following:

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, The search is matched against the taskaffinity attribute of the target activity, and if the taskaffinity of a task is found to be the same, the target activity is pressed into the task, and if the lookup is fruitless, a new task is created, The taskaffinity of the task is set to the taskactivity of the target activity, and the target activity is placed on this task. Note that if the taskaffinity of the activity in the same app uses the default or both sets the same value, it doesn't make sense to jump between activity in the app using this tag because the current application task is the best host for the target activity. Below we will demonstrate this feature through an example:

We created two new projects, named Appa and APPB, respectively, and we were creating firstactivity and secondactivity, and we were going to have APPB in firstactivity jump to Appa. The secondactivity configuration in Appa is as follows:

2. <activity android:name=". Secondactivity ">
4. <intent-filter>
6. <action android:name="Android.intent.action.APP_A_SECOND_ACTIVITY" />
8. <category android:name="Android.intent.category.DEFAULT" />
10. </intent-filter>
12. </Activity>

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

1. Intent Intent = new Intent ("Android.intent.action.APP_A_SECOND_ACTIVITY");
2. StartActivity (Intent);

We're going to show a few steps: 1. In the APPB firstactivity click the button to jump to Secondactivity;2 in Appa. Press the home button to return to the main screen and start the appb;3 again in the main menu. Press the Home key to return to the main screen and start the Appa in the main menu. Demo Process:

Start the APPB application again:

To start the Appa application:

We found that after jumping from APPB to Appa secondactivity, the secondactivity instance appears to be embedded in the APPB, but does not affect the normal operation of Appa, as shown in the following:

Then we change the code of the Jump:

1. Intent Intent = new Intent ("Android.intent.action.APP_A_SECOND_ACTIVITY");
2. Intent.setflags (Intent.flag_activity_new_task);
3. StartActivity (Intent);

We've added the flag_new_task tag, and we're looking at the demo results:

Start APPB again:

Start Appa:

We see the difference, when we start APPB again have not seen the Appa in the start of the secondactivity, and the start of the Appa is directly seen, indicating that the secondactivity instance is not within the APPB task, Instead, a task is created, and the affinity of the task is the secondactivity default affinity, because Appa secondactivity affinity is inherited from application, So when Appa starts, it will find the task directly instead of creating a new task. Let's take a look at the analytic diagram:

2.flag_activity_clear_top: When the intent object contains this tag, if there is an activity instance found on the stack, the activity on top of the instance is emptied, so that it is on the stack. For example: Our firstactivity jumps to secondactivity,secondactivity jump to thirdactivity, and thirdactivity jumps to secondactivity, Then the thirdactivity instance will be ejected from the stack, so that the secondactivity is at the top of the stack and displayed before the screen, leaving only firstactivity and secondactivity in the stack. This secondactivity can either receive the intent in onnewintent (), or it can be destroyed and restarted to accept the intent. In the default "standard" startup mode, if the flag_activity_single_top tag is not used in intent, then it will be rebuilt after closing, if this flag_activity_single_top tag is used, The existing instance is used, and for the other startup modes, no more flag_activity_single_top is used, it will use an existing instance, and intent will be passed to the onnewintent () of the instance.

Let's examine this process:

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

When jumping from thirdactivity to secondactivity, the jump code is as follows:

1. Intent Intent = new Intent (This, secondactivity.   Class);
2. Intent.setflags (Intent.flag_activity_clear_top);
3. StartActivity (Intent);

Then jump after the Secondactivity instance as follows:

From the serial number you can see that these two instances are different, proving that it has been destroyed and re-processed.

Then we add the flag_activity_single_top tag to the jump code in Thirdactivity:

1. Intent Intent = new Intent (This, secondactivity.   Class);
2. Intent.setflags (Intent.flag_activity_clear_top | Intent.flag_activity_single_top);
3. StartActivity (Intent);

The two instances are as follows:

If we do not want to add flag_activity_single_top, then change the secondactivity startup mode to three other than "standard", the effect is the same as above, will not create a new instance.

3.flag_activity_single_top: When a target ACTIVITY instance exists in a task and is at the top of the stack, no new one is created and the instance is directly exploited. We have also mentioned in the above example.

4.flag_activity_clear_when_task_reset: If a intent contains this attribute, The activity that it turns to and all the activity on that activity will be purged from the task when the task is reset. When we return a back-end task to the foreground, the system will have a flag_activity_reset_task_if_needed tag attached to the action in a particular case, which means that the task is reset if necessary, flag_activity_clear _when_task_reset will take effect. After testing, for a background application, if the main menu click on the application, this action contains flag_activity_reset_task_if_needed tag, long press the home key, and then click the recent record, this action does not contain flag_activity _reset_task_if_needed tags, so the former will be cleared, the latter will not. For this mark, you can show:

This tag is useful for applications where a split point exists. For example, we use the main interface to select a picture, and then we launched the image browser interface, but the application from the background back to the foreground, in order to avoid confusing users, we want users still see the main interface, rather than the image browsing interface, At this point we are going to add this tag to the intent when we go to the image-browsing interface.

5.flag_activity_reset_task_if_needed : This tag will take effect in the following cases: 1. Create a new task to place the activity instance when the activity is started; 2. The existing task is placed in the foreground. The specified task is reset based on affinity, and the task presses into some activity instance or removes some activity instances. We combine the above clear_when_task_reset to deepen our understanding.

Task-related properties for <activity>

There are several common task-related attributes defined in <activity> that represent different behavioral characteristics within a task, and we'll go through each one:

1.android:allowtaskreparenting

This property is used to mark whether an activity instance can move from the task that initiates it to a task with a common affinity after the current application has retired, "true" means that it can be moved, "false" means that it must be in the currently applied task. The default value is False. If a <activity> element of this activity does not have this attribute set, this property set on <application> will work for this activity. For example, to view a Web page in an app, after launching the system browser activity, the activity instance is in the same task as the current app, and when our app is back in the background, the user launches the app from the main menu again. At this point the activity instance will be re-hosted into the browser application's task, and the activity instance will not be seen in our application, and if you start the browser application at this point, you will find that the first interface is the Web page we just opened, proves that the activity instance is actually hosted within the task of the browser application. Let's take a look at this process with an example:

First, in APPB's firstactivity, we will make the following changes to the jump action:

1. Intent viewintent = new Intent (Intent.action_view, Uri.parse ("http://www.google.com.hk"));
2. StartActivity (viewintent);

interface when entering APPB:

After starting the Web interface:

Then we press the Home button, is the current application back to the background, we return to the main menu, restart APPB, the interface is as follows:

At this point we start the browser application in the main menu, and the interface that appears in front of us is this:

The above behavior also proves our previous assertion, in order to explain the problem more clearly, but also in order to let the people themselves can be verified, the following we would like to demonstrate again APPB and Appa boot process:

For Appa, on the basis of the above, do not modify the other place, just for the secondactivity <activity> element to add a property, as follows:

1. <activity android:name=". Secondactivity " android:allowtaskreparenting=" true ">
2. ...
3. </activity>

Then, change the firstactivity jump code in APPB to:

1. Intent Intent = new Intent ("Android.intent.action.APP_A_SECOND_ACTIVITY");
2. StartActivity (Intent);

We start APPB and see the interface:

Then click on the button to jump to Appa in the secondactivity, the interface is as follows:

At this point, the secondactivity in APPB and Appa are in the same task TaskID is 28, then we press the home key and start APPB again in the main menu. We found that Appa's secondactivity was missing, and what we saw was:

Then we start Appa, which is what we will not see it's firstactivity, but see it's secondactivity:

Usually two applications have their own task, their taskid certainly different, but here the Secondactivity show TaskID and appb the same, we think maybe we understand that it was appb migration, No new activity instances were generated when Appa was started. At this point, if we press the Back button, Appa will immediately exit, proving that there is only one activity instance in the Appa task, which is the secondactivity instance.

It is important to note that if APPB back into the background, do not start the APPB again, but directly start the Appa, will not appear the above phenomenon. The re-host action occurs in the process of APPB starting again.

Android:allowreparenting is as follows:

2.android:alwaysretaintaskstate

This property is used to mark whether the applied task remains in its original state, "true" means that it is always persisted, "false" means that it is not guaranteed, and the default is "false". This property only works on the root activity of a task, and other activity is ignored.

By default, if an app is in the background for too long, for example 30 minutes, when the user selects the app from the main menu again, the system cleans up the application's task, except the root activity, the other activity will be cleared out of the stack. However, if you set this property in root activity, you can still see the interface of the previous operation when the user launches the app again.

This property is useful for some applications, such as browser applications, where there are many states, such as opening a lot of tabs, and users do not want to lose these states, and using this property is extremely appropriate.

3.android:cleartaskonlaunch

This property is used to mark whether all activity except the root activity is purged from the task, "true" means clear, "false" means no cleanup, and the default is "false". Similarly, this property only works on root activity, and other activity is ignored.

If this property is set to "true", each time the user restarts the app, it will only see that the other activity in the root activity,task is cleared out of the stack. If the activity of other apps is referenced in our app, these activity sets the Allowtaskreparenting property to "true", then they are re-hosted into a task with common affinity.

No picture, no truth, we'll come to illustrate this process with an example, we first modify the <activity> element of the root activity of APPB, as follows:

1. <activity android:name=". Firstactivity "
2. android:cleartaskonlaunch="true">
3. ...
4. </activity>

The Fristactivity interface is as follows:

Then we let firstactivity jump to secondactivity, the result is as follows:

Then we press the home button back to the main interface and start APPB again, we see the following results:

We see that when we start appb again, we can only see the Firstactivity interface, when all the activity on the firstactivity has been cleared out of the stack. As follows:

4.android:finishontasklaunch

This property is similar to the Android:allowreparenting property, except that the Allowreparenting property is re-hosted into a task with a common affinity, and the Finishontasklaunch property is destroying the instance. If both this property and the android:allowreparenting are set to "true", this property wins.

The above is the summary of today's content, these are commonly used knowledge, in addition to a lot of waiting for us to explore, and continue to work hard.

Task Stack for Android