Prerequisites: Activity lifecycle in android
As it is known that every Android app has at least one activity associated with it. When the application begins to execute and runs, there are various state changes that activity goes through. Different events some user-triggered and some system triggered can cause an activity to do the transition from one state to another. All the state changes associated with the activity are part of the activity lifecycle in android. When a certain event occurs, each activity has to go through different stages of the Android lifecycle. The state of activity is managed by maintaining the activity stacks, in which the new activity is on the top of the stack, and the rest of the activity is below in stack in the order of the time they have been put in the stack.
Imagine 3 activities, one is in a running state, the second activity is just minimized and is running in the background, and the 3rd activity is also running in the background but has gone from foreground to background earlier than the second activity. So here the 1st activity will be on the top of the stack, 3rd activity will be at the bottom of the stack and 2nd activity will be at the middle of the stack.
There are seven states of an Activity lifecycle, out of these seven states, it is sure that the activity will be in any of the seven states depending on the event that occurred.
To have detailed information on how this activity states works and what is the changes that activity undergoes in each state, refer to the article on activity lifecycle in android.
Events Leading to Configuration Change/State Change
There are many events that can lead to a configuration change of the application, which ultimately causes state change of the activities. Let’s see some events and cases where the activity state changes take place.
1. Changing the Orientation of the App
Let’s say the user is viewing the app in portrait mode and suddenly the user changes the orientation of the application to landscape mode. Since changing the orientation of the application will eventually change the view, which will lead to a configuration change in the app and the activity associated with the portrait mode is destroyed and new activity associated with the landscape mode is created. The running/active activity associated with the portrait mode will have onPause(), onStop(), and onDestroy() callbacks triggered. When the user changes the orientation, the new activity is created and new activity will have onCreate(), onStart(), and onResume() callbacks triggered.
Below is the sample video in which one can see the changes in states of activity which it undergoes when the orientation of the app changes. See the Toast messages to see the activity state changes.
2. Switching Between the Apps In MultiWindow Screen
As it is known that android has launched a multi-window feature for the Android 7 for the apps with API level 24 and higher, so when any configuration changes of the android app, the android system notify such events and change the lifecycle states of the activity according to the conditions in which configuration of the application have changed. The common example of changing the configuration of the app is when the user resizes one activity with respect to another activity. Your activity can handle the configuration to change itself, or it can allow the system to destroy the activity and recreate it with the new dimensions.
In multi-window mode, although there are two apps that are visible to the user, there is only the one app with which the user is interacting is in the foreground and has focus is in the onResume() state and another app that is in the background and visible to the user is in a Paused state. So it can be said that the activity with which the user is interacting is the only activity which is in the resumed state, while all the other activities are started but not resumed. When the user switches from one app to another app, the system calls onPause() lifecycle state on the running app, and onResume() lifecycle state on another app which is previously not in the active state. It switches between these two methods each time the user toggles between apps. See the Toast messages to see the activity state changes.
It can be seen that when there are multiple screens running at the same time, every time when the user resizes one screen relative to another screen, the original activity gets destroyed and new activity gets created corresponding to the new screen size
3. Activity or dialog appears in the foreground
Let’s suppose when an activity is running and is in progress, but at the same time, a new activity appears in the foreground, and partially covering the activity in progress, and take the focus and causing the running activity to enter into the Paused state by calling onPause() on the running activity and the new activity enter into the onResume() state. When the covered activity returns to the foreground and regains focus, it calls onResume(), whereas the running activity again enters into the onPause() state.
If a new activity or dialog appears in the foreground, taking focus and completely covering the activity in progress, the covered activity loses focus and enters the Stopped state. The android operating system then immediately calls onPause() and onStop() in succession. When the same instance of the covered activity comes back to the foreground, the system calls onRestart(), onStart(), and onResume() on the activity. If it is a new instance of the covered activity that comes to the background, the system does not call onRestart(), only calling onStart() and onResume(). See the Toast messages to see the activity state changes.
In the above video, the activity covers another activity completely and the state changes can be observed according to it.
4. The user taps the Back button
If an activity is in the foreground and is in running state, and the user taps the Back button, the activity transitions through the onPause(), onStop(), and onDestroy() callbacks. In addition to being destroyed, the activity has also removed the stack, which is used for storing the activities in order of the time put in the stack. It is important to note that, by default, the onSaveInstanceState() callback is not called in this case as it is assumed that the user tapped the Back button with no expectation of returning to the same instance of the activity and so there is no need to save the instance of the activity. If the user overrides the onBackPressed() method, it is still highly recommended that the user should invoke super.onBackPressed() from the overridden method, else if super.onBackPressed() is not invoked then it may lead to ambiguous behavior of the application and may lead to bad user experience. See the Toast messages to see the activity state changes.