Android Onactivityresult () receive a solution with a null return data

For app multiple interface management, if you typically use the activity default load mode, pressing the back key will return the last action, which is a new activity instance. A long time will become a lag, the average person will choose to manually block the return key in the code, using the app's development of the return key, this can also solve the problem.

But the essence of the problem is still unresolved, it is impossible to develop in the future with such a method, with more irritability. So the key to solving this problem is to understand the loading patterns of the activity.

The first load mode is: Standard mode, system default load mode

Android:launchmode= "Standard"

This mode is the default mode of the system, the general development app does not need to change. As soon as the physical keys on the phone are disturbed return the key back key.

The principle of this loading mode is to open the first interface of the app, create a task for the app to manage the app's open activity, each operation will create a new instance activty, and also include the return. So if you press the physical button on your phone back, you will return to your previous action, knowing that the first instance of the app is activty. If you're doing too much in your app, you'll get a lot of activity instances, and if you do a lot of things, it's a bit of a lag, and there's a possibility that a memory overflow will cause the phone app to hang up.

The second mode of loading is: Singletop mode

This pattern is similar to standard mode, but the difference is that if the activty is on top of the stack, it will not re-instantiate the activty, no matter how many times it will not change the program experience on the interface.

If there is no activty to open at the top of the task stack, a new actvity is created to load to the top of the stack-exactly the same as standard mode.

The third mode of loading is: Singletask mode

This loading mode has only one activty in a task stack task, and does not repeatedly create Activty instances in the task stack. There are three types of this pattern

(1) If the target activity to be started is not in the task stack and is not at the top of the stack, it will be re-instantiated activty loaded to the top of the stack.

(2) If the target activity that will be started is at the top of the stack, it is the same as the Singletop mode load mode

(3) If there is a task stack for the target activity to be started, but not the top of the stack, the system will place all activty in the task stack above the target until the target activty is exposed to the top of the stack.

Fourth loading mode; SingleInstance mode:

In this load mode, only one instance activity is created, regardless of which task stack the target activity is on. This pattern is divided into two situations:

(1) If the target activty to be started does not exist, a new task stack is created activty the target activty instance and adds it to the top of the stack.

(2) If the instance to be started activity exists, regardless of which application it is in, which task stack task is located, the system will move the target instance activity to the foreground, which is the top of the stack, so that the target activity is displayed

Note: Loading activity in singleinstance mode is always at the top of the stack, and the task where the activity is loaded with SingleInstance mode will contain only that activity

Back to the previous question, shielding physical keys is obviously not a good way to go. So the tradeoff is to change the activity's loading mode a little bit. Change the standard mode of the load mode to Singletask mode, at which point the previous problem is solved. Both the physical keys and the app return operation are valid, and there is no significant lag in the operation. Seems to solve the problem, but there is a problem, that is, the title of the problem, the use of the return value of the intent operation regardless of how the returned data is empty, and the app will appear a typical problem application is unresponsive.

Through the activity loading mode of Android, we can see that the Singletask mode loads the activity instance, when the target activity instance of the task stack is not at the top of the stack, the system removes all activity instances above the target, thus the target becomes the foreground. However, before the top of the stack to return the activity and does not exist, return to the first interface can not find the second interface returned data, so the return data is empty, and Onactivityresult () in the data capture exception, causing the program to hang up, this problem found, So you can set the load mode of the second interface to Singletop mode. At this point, the problem is solved. However, think about it, if you press the return key again, the second interface should also be repeatedly instantiated multiple times, but pressing the return key does not appear in the standard mode of Operation return mode. But the second interface will still create a second interface repeatedly without the application exiting, but it will not affect the return key operation. So this little flaw can still be allowed. So far the problem has been solved.

Android Onactivityresult () receive a solution with a null return data