Detailed explanation of four loading methods of Android

[[125130]]

In multi-Activity development, there may be activity jumps between your own applications, or reusable activities from other applications. You may want to jump to an original Activity instance instead of generating a large number of duplicate Activities.

This requires configuring a specific loading mode for the Activity instead of using the default loading mode.

Loading mode classification and where to configure

Activity has four loading modes:

• standard
• singleTop
• singleTask
• singleInstance

The setting location is in the android:launchMode attribute of the activity element in the AndroidManifest.xml file:

 <activity android:name= "ActB" android:launchMode= "singleTask" ></activity>

It can also be edited in the Eclipse ADT graphical interface:

The examples are very clear to distinguish the loading modes of Activity. Here is an example of looping between Activity A (ActA) and Activity B (ActB). By modifying the loading mode and making slight changes to the code, the differences between the four modes can be explained.

standard

First, let's talk about the standard mode, which is the default mode. You don't need to configure launchMode. Let's just write an Activity called ActA:

 package com.easymorse.activities;
 import android.app.Activity;
 import android.content.Intent;
 import android.os.Bundle;
 import android.view.View;
 import android.view.View.OnClickListener;
 import android.widget.Button;
 import android.widget.LinearLayout;
 import android.widget.TextView; 
 
 public   class ActA extends Activity {
 /** Called when the activity is first created. */  
 @Override  
 public   void onCreate(Bundle savedInstanceState) {
 super .onCreate(savedInstanceState);
        TextView textView = new TextView( this );
        textView.setText( this + "" );
        Button button = new Button( this );
        button.setText( "go actA" );
        button.setOnClickListener( new OnClickListener() {
 @Override  
 public   void onClick(View v) {
                Intent intent = new Intent();
                intent.setClass(ActA. this , ActA. class );
                startActivity(intent);
 }
 });
        LinearLayout layout = new LinearLayout( this );
        layout.setOrientation(LinearLayout.VERTICAL);
        layout.addView(textView);
        layout.addView(button);
 this .setContentView(layout);
 }
 }

In the example, layout is not used to avoid being too wordy. It can be seen that this is an example of ActA -> ActA. In the interface, the toString value of the object is printed out to identify whether a new ActA instance is created based on the hash code.

***Interface:

After clicking the button:

You can click it several times. You will find that a new instance of the Activity is created each time. The standard loading mode is like this, and the intent will be sent to the new instance.

Now click the back button on the Android device, and you can see that the Activity instances are displayed in reverse order of the ones you just created, which is similar to the operation of unloading the stack, while the process of operating the jump button just now is the operation of pushing the stack. As shown in the following figure:

singleTop

Both singleTop and standard modes will send the intent to a new instance (the latter two modes will not send it to a new instance if one already exists). However, singleTop requires that if there is already an instance of the Activity to be created at the top of the stack when the intent is created, the intent will be sent to that instance instead of to a new instance.

Still using the previous example, just change the launchMode to singleTop and you can see the difference.

When running, you will find that no matter how many times you press the button, the same ActiA instance is always used because the instance is at the top of the stack, so no new instance will be created. If you roll back, the application will exit.

The singleTop mode can be used to solve the problem of multiple duplicate Activities at the top of the stack.

If A Activity jumps to B Activity and then jumps to A Activity, the behavior is the same as standard. A new instance of A Activity will be created when B Activity jumps to A Activity, because the top of the stack at that time is not the A Activity instance.

The ActA class is slightly modified:

 package com.easymorse.activities;
 import android.app.Activity;
 import android.content.Intent;
 import android.os.Bundle;
 import android.view.View;
 import android.view.View.OnClickListener;
 import android.widget.Button;
 import android.widget.LinearLayout;
 import android.widget.TextView; 
 
 public   class ActA extends Activity {
 /** Called when the activity is first created. */  
 @Override  
 public   void onCreate(Bundle savedInstanceState) {
 super .onCreate(savedInstanceState);
        TextView textView = new TextView( this );
        textView.setText( this + "" );
        Button button = new Button( this );
        button.setText( "go actB" );
        button.setOnClickListener( new OnClickListener() {
 @Override  
 public   void onClick(View v) {
                Intent intent = new Intent();
                intent.setClass(ActA. this , ActB. class );
                startActivity(intent);
 }
 });
        LinearLayout layout = new LinearLayout( this );
        layout.setOrientation(LinearLayout.VERTICAL);
        layout.addView(textView);
        layout.addView(button);
 this .setContentView(layout);
 }
 }

ActB Class:

 package com.easymorse.activities;
 import android.app.Activity;
 import android.content.Intent;
 import android.os.Bundle;
 import android.view.View;
 import android.view.View.OnClickListener;
 import android.widget.Button;
 import android.widget.LinearLayout; 
 
 public   class ActB extends Activity {
 @Override  
 protected   void onCreate(Bundle savedInstanceState) {
 super .onCreate(savedInstanceState);
         Button button= new Button( this );
            button.setText( "go actA" );
            button.setOnClickListener( new OnClickListener() {
 @Override  
 public   void onClick(View v) {
                    Intent intent= new Intent();
                    intent.setClass(ActB. this , ActA. class );
                    startActivity(intent);
 }
 });
            LinearLayout layout= new LinearLayout( this );
            layout.addView(button);
 this .setContentView(layout);
 }
 }

The ActB class is loaded using the default (standard) method, and ActA is loaded using singleTop. The result is similar to the following figure:

If you change the loading mode of ActA to standard, the situation is the same.

singleTask

The singleTask mode and the subsequent singleInstance mode only create one instance.

When an intent arrives and a singleTask mode Activity needs to be created, the system checks whether there is already an instance of the Activity in the stack. If so, the intent is sent directly to it.

In the singleTop example above, change the launchMode of ActA to singleTask and ActB to standard. Then you will find that when you press a button in the ActA interface:

Then press the button in the ActB1 interface. Because ActA is a singleTask, the original ActA1 instance will be used. The situation in the stack at this time is:

If you press the button multiple times to jump, you will find that there is always only one instance of the ActA class, ActA1.

singleInstance

Explaining the singleInstance mode is more complicated.

First of all, let's talk about the concept of Task.

If it is a Swing or Windows program, there may be multiple windows that can be switched, but you cannot reuse other people's windows in your own program. Note that you should directly reuse other people's binary code, not the source code level call after you get other people's API.

Android can allow other programs to directly reuse your Activity (similar to the window of a desktop program).

To provide this mechanism, Android introduced the concept of Task. Task can be considered as a stack that can hold multiple Activities. For example, when launching an application, Android creates a Task and then launches the entry Activity of this application, which is the one configured as main and launch in the intent-filter (see the effect of deploying multiple applications with one APK file). This Activity is the root Activity and may call other Activities in its interface. If these Activities follow the three modes above, they will also be in this stack (Task), but the instantiation strategies are different.

The way to verify is to call and print the taskId of the Activity:

 TextView textView2 = new TextView( this );
 textView2.setText( "task id: " + this .getTaskId());

You will find that no matter you switch Activities, the taskId is the same.

Of course, you can also put other activities in this single Task stack, such as Google Maps, so that when the user presses the back key after viewing the map, the stack will be returned to the Activity that called the map. For the user, it does not feel like operating multiple applications. This is the role of Task.

However, there is a demand that multiple Tasks share one Activity (singleTask shares one Activity in one task).

A ready-made example is Google Maps. For example, I have an application for tour guides, which calls the Google Maps Activity. Now, if I press the home button and open Google Maps in the application list, you will find that the map displayed is the same as before, which is actually the same Activity.

If the above three modes are used, this requirement cannot be met. The Google Maps application has multiple context activities, such as route query, etc. The Tour Guide application also has some context activities. To roll back in each application, you need to roll back to the respective context activity.

The singleInstance mode solves this problem (I've been going around in circles for so long before I get to the point). The activity in this mode is placed in a separate task stack. This stack has only one activity. The intents sent by the tour guide app and the Google Maps app are received and displayed by this activity.

There are two more problems here:

• If this is the case, multiple task stacks can also be considered as one application. For example, when the tour guide application starts the map activity, a new stack is actually created in singleInstance mode on the tour guide application task stack (if it does not exist, if it does, it is directly displayed). When the first activity in this stack, the map activity, rolls back, it just moves this stack away, so that the activity of the tour guide application can be seen.
• Sharing an Activity with multiple applications (Tasks) requires that these applications are not exited. For example, we just emphasized that you should use the home button to switch from the tour guide application to the map application. Because if you exit the tour guide application and the map application is not running at this time, the separate map Activity (task) will also exit.

If we still take the example of ActA and ActB, we can change the mode of ActB to singleInstance and ActA to standard. If we press the button once to switch to ActB, the phenomenon shown in the diagram is similar to this:

If the first button switches to Act B, and then presses the button in Act B to switch to Act A, and then back, the schematic diagram is:

In addition, you can see that the taskIds of the two Activities are different.

**********************************This is the dividing line*********************************

Notice:

(I) When the latter two methods are selected, if you press the Home button to exit, and then long press the Home button to enter, onNewIntent will not be accessed at this time, because no Intent is initiated when entering again. onNewIntent will only be activated when startActivity(Intent i); is called. (This feature can be used to monitor the Home button, haha)

(ii) If the loading mode is selected as singleInstance, then if TTS is used, the result returned in onActivityResult during TTS detection will be TextToSpeech.Engine.CHECK_VOICE_DATA_FAIL; this will not happen in other modes. The specific reason remains to be studied.