Android Foundation Summary Chapter III: Activity task-related introduction _android

This article mainly introduces the Android basic summary of the three: Activity task-related, has a certain reference value, there is a need to understand.

Today we're going to talk about the task-related content of the activity.

The last time we talked about the four startup modes of activity, we've learned a few things about task, and I'm going to introduce you today. A task is a container with a stack structure in which you can place multiple activity instances. When an application is started, the system creates a task for it to place the root activity; By default, when one activity initiates another, two of the activity is placed in the same task, and the latter is pressed into the task stack where the former is located. When the user presses the back key, which is ejected from the task, and the former appears in front of the screen, especially when the activity is started in other applications, the two activity appears to the user as belonging to the same application;

System tasks and tasks are independent of each other, when we run an application, we press the home key to go back to the main screen and start another application, in which the previous task is moved to the background, the new task is moved to the foreground, and the root activity is displayed before the curtain, after a while, Click Home to return to the main screen, then select the previous application, before the task will be transferred to the foreground, the system still retains all the activity instances within the task, and the new task will be moved to the background, if the user do back up and so on, is to operate within the task.

Let's talk about task-related knowledge today, and divide the main points:

1.Activity of Affinity (affinity)

2.Intent of several common flags

3.<activity> and task-related properties

Affinity

Affinity for an activity as if it were an identity card, it can tell the task in which it belongs, a member of the task, and multiple activity theories with the same affinity belong to a task, The affinity of the task itself is determined by the affinity value of the root activity. Affinity on what occasions to apply it? 1. Select the host task for the activity (working with the allowtaskreparenting attribute) according to the affinity; 2. The intent used flag_activity_new_ in the process of initiating an activity A task tag that finds or creates a new task with a corresponding affinity based on affinity. We will explain it in detail later.

By default, all activity within an application has the same affinity, inherited from the application (reference <application> taskaffinity attribute). and application default affinity is the package name in <manifest>, we can set the Taskaffinity property value for <application>, which can be applied to <application All <activity> under >, or you can set taskaffinity for an activity alone. For example, in the browser of the system itself, package is com. Android.browser, but <application> customizes a taskaffinity property value:

<application android:name= "Browser" 
    android:label= "@string/application_name" android:icon= " 
    @drawable /ic_launcher_browser " 
    android:backupagent=". Browserbackupagent " 
    

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 looks for or creates 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 this 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 it is meaningless for a jump between activity within an application to use this tag if the taskaffinity of the activity in the same application uses the default value or both to set the same value, because the current application task is the best host for the target activity. Here we will demonstrate this feature through an example:

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

<activity android:name= ". Secondactivity "> 
   <intent-filter> 
    <action android:name=" android.intent.action.APP_A_SECOND_ Activity "/> 
    <category android:name=" Android.intent.category.DEFAULT "/> 
   </intent-filter> 
  </activity> 

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

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

We want to demonstrate a few steps: 1. firstactivity Click button in APPB to jump to secondactivity;2 in Appa. Press home to return to the main screen and start the appb;3 again in the main menu. Press home to return to the main screen and start the Appa in the main menu. The demo process is as shown in the figure:

Start APPB application again:

Start 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 illustration:

Then we modify the jump code:

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

We've added the flag_new_task tag to look at the demo results:

Start APPB again:

Start Appa:

We see the difference, and when we start APPB again, we can't see the secondactivity in the Appa we just started, and when we start the Appa, we see it directly, which means the secondactivity instance is not in the APPB task, Instead, a task is created, the affinity of which is the default affinity of the secondactivity, because Appa secondactivity is inherited from Affinity, So when the 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 an activity instance is found on the stack, the activity above the instance is emptied and placed on top of the stack. For example: Our firstactivity jumps to secondactivity,secondactivity jumps to thirdactivity, and thirdactivity jumps to secondactivity, Then thirdactivity instance will be pop-up stack, so that secondactivity is on the top of the stack, display to the screen, the stack is left only firstactivity and secondactivity. This secondactivity can receive the intent either in Onnewintent (), or it can be destroyed and then restarted to accept the intent. In the default "standard" boot mode, if the flag_activity_single_top tag is not used in intent, it will be closed and rebuilt, if the flag_activity_single_top tag is used, The existing instance is used, and for other boot modes, no flag_activity_single_top is used, it will use an existing instance, and intent will be passed to the onnewintent () of the instance.

Now let's verify this process:

First, the activity startup mode is "standard" according to the default value. From the firstactivity jump to the Secondactivity,secondactivity instance as follows:
When you jump from thirdactivity to secondactivity, the jump code is as follows:

Intent Intent = new Intent (this, secondactivity.class); 
Intent.setflags (Intent.flag_activity_clear_top); 

Then jump after the Secondactivity instance as follows:

From the serial number you can see that these two instances are different, proving that it is a process of destruction and re.

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

Intent Intent = new Intent (this, secondactivity.class); 
Intent.setflags (Intent.flag_activity_clear_top | Intent.flag_activity_single_top); 

The two instances are shown in the following illustration:

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

3.flag_activity_single_top: When there is a target activity instance in the task and at the top of the stack, no longer creates a new one and uses the instance directly. We have also mentioned in the example above.

4.flag_activity_clear_when_task_reset: If this property is included in a intent, Then the activity that it turns to and all the activity on that activity will be cleared out of the task when the task is reset. When we return a background task back to the foreground, the system comes with a flag_activity_reset_task_if_needed tag for the action in a particular case, meaning to reset the task when necessary, when flag_activity_clear _when_task_reset will come into force. 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 button, and then click the recent record, this action does not contain flag_activity _reset_task_if_needed tag, so the former will be cleared, the latter will not. About this tag, you can figure it out:

This tag is useful for situations where a split point is applied. For example, we have to select a picture in the application main interface, and then we start the image browsing interface, but to restore the application from the background to the foreground, in order to avoid confusing users, we hope that users still see the main interface, rather than the image browsing interface, This time we will add this tag to the intent when we go to the image browsing interface.

5.flag_activity_reset_task_if_needed: This mark will take effect in the following cases: 1. Create a new task to place the activity instance when the activity is started; 2. Existing tasks are placed in the foreground. The system resets the specified task according to the affinity, and the task presses into some activity instances or removes some of the instance. We can deepen our understanding by combining the above clear_when_task_reset.

<activity> task-related properties

Several common task-related attributes are defined in <activity>, which represent different behavioral characteristics within a task, and we'll introduce each one individually:

1.android:allowtaskreparenting

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

First, in the firstactivity of APPB, we make the following changes to the jump action:

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

The interface when entering APPB:

After starting the Web interface:

Then we press the Home button, is the current application to retire 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:

This behavior is also proof of our previous assertion, in order to more clearly explain the problem, and for everyone to be able to verify, we will again demonstrate the APPB and Appa Start process:

For Appa, on top of that, without modifying other places, simply add an attribute for the <activity> element of Secondactivity, as follows:

<activity android:name= ". Secondactivity "android:allowtaskreparenting= true" > ... 
 

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

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

We started APPB and saw the interface:

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

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

And then we start Appa, which is that we don't see it firstactivity, but see its secondactivity:
Usually two applications have their own task, their taskid must be different, but here's secondactivity show TaskID and appb the same, we think about it may be understood, it is the APPB migrated over, Any new activity instances are not generated when the Appa is restarted. This time, if we press the Back button, Appa will exit immediately, proving that there is only one activity instance in Appa's task at this point, the secondactivity instance.

It should be noted that if the APPB back to the background, did not start the APPB again, but directly start Appa, will not appear above phenomenon. The APPB action occurs during the restart process.

The android:allowreparenting effect is shown below:

2.android:alwaysretaintaskstate

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

By default, if an application stays in the background for too long, such as 30 minutes, and the user chooses the application from the main menu again, the system will clean up the task for that application, and other activity will be cleared out of the stack, except for the root activity. However, if this property is set in the root activity, the user will still be able to see the interface of the previous operation when it starts the application 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, using this attribute is extremely appropriate.

3.android:cleartaskonlaunch

This property is used to mark whether any activity other than the root activity is purged from the task, "true" means clear, and "false" means no purge, and default is "false". Again, this property works only for root activity, and other activity is ignored.

If this property is set to "true", each time the user restarts the application, they will only see that other activity in the root activity,task will be cleared out of the stack. If the activity of other applications is referenced in our application, these activity sets the Allowtaskreparenting property to "true", they are then hosted in a task that has a common affinity.

Without a picture without the truth, let's take an example to illustrate the process, and we'll first modify the <activity> elements of APPB's root activity, as follows:

<activity android:name= ". Firstactivity " 
android:cleartaskonlaunch= true" > ... 
 

The Fristactivity interface is as follows:

Then we let firstactivity jump to secondactivity, and the results are as follows:

Then we press home to go back to the main screen and start appb again, and we see the following results:
We see that when we start APPB again, we see only the Firstactivity interface, at which point all the activity on firstactivity has been cleared out of the stack. The schematic diagram is as follows:

4.android:finishontasklaunch

This property is similar to the Android:allowreparenting property, except that the Allowreparenting property is hosted in a task that has a common affinity, and the Finishontasklaunch property is the destroy instance. This property wins if this property and Android:allowreparenting are both set to "true".

This is the summary of today's content, these are commonly used knowledge, in addition there are many waiting for us to explore, continue to work hard.

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

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.