Below diagram shows the Activity life cycle
The main life cycle states are
Resumed : In this state, activity is in foreground and user can interact with it. (Also referred to as running state)
Paused : In this state, activity is partially obscured by another activity. The other activity that is in the foreground is semi-transparent or does not cover the entire screen. The paused activity does not receive any user input nor execute any code.
Stopped : In this case, Actvity is completely hidden and not visible to the user; it is considered to be in the background. While stopped, activity information and all its state information such as member variables is retained, but cannot execute any code.
There are two other states Created and Started, these two are transient state and system moves quickly between these two states. i.e once the system calls onCreate, it quickly calls onStart and immediately onResume.
An activity should be specified as Launcher activity. The system will use this activity as the starting point of the application.
if any of the intent type MAIN Or LAUNCHER is not appearing in the manifest xml, application will not be listed in the HomeScreen's list of apps
when onCreate finishes the execution, the system calls onStart and onResume in quick succession. The application will never reside in created or started states. Technically the activity comes to the visible state when the onStart call happens, but onResume call comes immediately and it remains on the Resumed state.
The very last callback is onDestroy. The system calls this method as a final signal that the application's activity instance is being completely removed from the system memory. Most apps should do the cleanup operations in the onPause or onStop method of the activity.
In normal cases, onDestroy should come after the onPause and onStop methods. However, if the activity calls finish() from the onCreate methods with an intention to launch another activity, the onDestroy will be called without these two life cycle methods are called.
Pausing and Resuming Activity
During the life cycle of an activity, if there is a semi transparent style of ui is obstructing this activity, then system calls onPause method. However, if the activity is completely invisible, it calls the onStop method.
If the activity is resuming from the paused state, it will call onResume method.
It is recommended that the Activity does the below items on the onPause method
- Stop animations or other ongoing actions that may consume CPU
- Commit unsaved changes if required.
- RElease system resources such as broadcast receivers, handles to sensors (like GPS), or any resource that may affect battery life while the activity is paused and the user doesn't need them.
For e.g. if the application uses camera, this will be the right method to release it
Generally, onPause should not be used for any CPU intensive operations, instead, they should be done on onStop method.
When the activity is resumed from the paused state, it calls the onResume method.
Stopping and Restarting the Activity
Below are the few scenarios where the Activity is stopped and restarted.
- User opens the recent activity list and switches to the another application
- The user performs an action in your app that starts a new activity. The current activity will be stopped and when user performs the back, it will be restarted.
- User receives a device interruption such as a phone call.
When the Activity is getting restarted, onRestart method will be called and immediately the onStart method will be called.
Similar to paused state, framework keeps the data in memory. application not required to save it.
Even if the System destroys the activity while it is stopped, it still retains the state of the View objects in a Bundle (a blob of key value pairs)
When the app comes back from Background to foreground, Activities, onRestart get called and followed by that onStart get called.
Recreating An Activity
When the Activity is destroyed decease user pressed back or activity finishes itself, system's concept of that Activity is gone, However, if the system destroys an Activity due to system constraints, then although the actual Activity instance is gone, the system remembers that if user navigates back to it, the system creates a new instance of activity using a set of saved data that describes the state of the activity when it was destroyed. The saved data that the system uses to restore the previous state is called the "instance state" and is a collection of key-value pairs stored in Bundle object.
It is very important to note that the Activity get killed every time when rotate the screen!!! . This is because the screen configuration has changed and the system may need to load different layout files etc.
In this case also by default system will keep the state in Bundle object. But if the app has to keep track of other states, then it has to have its own mechanism.
Android uses the android:id attribute in the xml to keep track of the object for restoration purposes.
System will call onSaveInstanceState method and add key value pairs to the Bundle object. On onCreate method, application should check whether the bundleInstance is null. If not null application can read from it and assign to the instance variables.
Also application may choose onRestoreInstance method to restore the state of the instance. the onRestoreInstance may get called back only if there is any bundle exist. Also to note, always Application should call super.onREstoreInstancestate and super.onSaveBundleInstanceState methods so that System can do the store/restore operation on the instance state.
References:
No comments:
Post a Comment