the attribution of activity, which is the task in which the activity should be, the adsorption relationship between activity and task. We know that, in general, in the same application, the activity that is initiated is in the same task, and they spend their life cycle in that task, which is a good example of mindedness.
So why did the activity that we created go into this task? Will they be transferred to other tasks? If you go to other tasks, what kind of task will they go to?
The key to solving these problems is the Taskaffinity property of each activity.
each activity has a taskaffinity attribute, which indicates the task it wants to enter. If an activity does not explicitly indicate the activity's taskaffinity, then its attribute is equal to the taskaffinity specified by application, and if application is not specified, Then the value of the taskaffinity is equal to the package name. The task also has its own affinity property, whose value equals the value of the taskaffinity of its root activity.
In the beginning, the activity created will be in the task that created it, and most of it will spend its entire life here. However, in some cases, the activity created will be assigned to other tasks, and some may even be in a task, and then a transfer occurs. Let's start by analyzing the two scenarios that are presented to us in the Android documentation.
The first case . If the activity's allowtaskreparenting is set to true, it enters the background and when a task with the same affinity as it enters the foreground, it is re-hosted and enters into the foreground's task.
Let's verify the situation.
application Activity taskaffinity allowtaskreparenting
Application1 Activity1 com.winuxxan.affinity true
Application2 Activity2 com.winuxxan.affinity false
we created two projects, Application1 and Application2, each containing Activity1 and Activity2, with the same taskaffinity, The allowtaskreparenting of Activity1 is true.
First, we start Application1, load Activity1, and then press the home key to get the task (assuming Task1) into the background. The Application2 is then started and the Activity2 is loaded by default.
What have we seen? Yes, it was supposed to show Activity2, but we saw Activity1. Actually Activity2 was also loaded, just Activity1 re-hosted, so I saw Activity1.
The second case . If the intent,flag that loads an ACTIVITY is set to Flag_activity_new_task, it first checks to see if there is a task that is identical to its own taskaffinity, and if so, it is directly hosted into the task. Re-create the task if it does not exist.
Let's do a test.
we first write an application that has two activity (Activity1 and Activity2), Androidmanifest.xml as follows:
<application android:icon= "@drawable/icon" android:label= "@string/app_name" >
<activity android:name= ". Activity1 "
android:taskaffinity= "Com.winuxxan.task"
android:label= "@string/app_name" >
</activity>
<activity android:name= ". Activity2 ">
<intent-filter>
<action android:name= "Android.intent.action.MAIN"/>
<category android:name= "Android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
</application>
the code for Activity2 is as follows:
Public class Activity2 extends Activity {
private static final String TAG = "Activity2";
@Override
protected void OnCreate (Bundle savedinstancestate) {
super.oncreate (savedinstancestate);
Setcontentview (r.layout.main2);
}
@Override
Public Boolean ontouchevent (Motionevent event) {
Intent Intent = new Intent (this, activity1.class);
intent.setflags (intent.flag_activity_new_task);
startactivity (Intent);
return Super.ontouchevent (event);
}
}
then we write an application myactivity, which contains an activity (myactivity), androidmanifest.xml as follows:
<application android:icon= "@drawable/icon" android:label= "@string/app_name" >
<activity android:name= ". MyActivity "
android:taskaffinity= "Com.winuxxan.task"
android:label= "@string/app_name" >
<intent-filter>
<action android:name= "Android.intent.action.MAIN"/>
<category android:name= "Android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>
We start myactivity First, then press the Home button, return to the desktop, then open Activity2, click Activity2, enter Activity1. Then press the back key.
we found that the order in which we entered activity was activity2->activity1, and the order of return was activity1->myactivity. This illustrates a problem where Activity1 isre-homed to the task in which myactivity resides when it starts . ( because android:taskaffinity= "Com.winuxxan.task" )
The above is a validation of the use of the two taskaffinity presented in the document.
here is the time to witness miracles, Comrades, don't blink!
We will now combine the Launchmode in the article with the taskaffinity in this article for some time.
The first is the combination of Singletask loading mode and taskaffinity.
we still use the Singletask code of the article for a period of time, here is not listed, please read the last article. The only difference is that we set the same taskaffinity for MyActivity and Activity1 and re-execute the tests above.
we found that the test results surprised us: launching Singletask from the same application and launching the different applications was completely the opposite of what was said above!
when we think about it, we can get a conclusion from executing from the same application and executing another way from different applications:
when an application loads an activity in a singletask mode, the activity first checks for the existence of the same task as its taskaffinity.
1, if present, then check whether the instantiation, if already instantiated, then destroy the activity above the activity and call onnewintent. If there is no instantiation, then the activity instantiation is merged into the stack.
2. If it does not exist, recreate the task and merge it into the stack.
use a process to represent:
then we examine the situation when the SingleInstance mode is integrated into the taskaffinity, and we also use the example above to test the singleinstance, which is not listed here, the reader read the previous article. The only difference is that we set myactivity and Activity2 to the same taskaffinity.
we find that the test results also have a certain discrepancy, that is, when the activity is started from the singleinstance, it is not necessary to recreate a task, but to enter the task that is in the myactivity with the same affinity.
Therefore, we can also get the following conclusions :
1. When an application loads an activity in a singleinstance mode, if the activity is not instantiated, recreate a task, merge it into the stack, if it has been instantiated, Then the onnewintent of the activity is invoked ;
2. The task where singleinstance activity is not allowed to have other activity, any other activity loaded from the activity (assuming Activity2) will be put into other tasks. If there is a task with the same affinity as Activity2, a Activity2 is created within that task. If it does not exist, regenerate the new task merge stack.
Android--taskaffinity Property
