Understanding of Android Activity Lifecycle – Step by Step – As we mentioned earlier, every Android App is actually based on a framework similar to the Java Applet.
which consists of certain methods related to different conditions of each activity of the Android App, called Base Class named Activity Define in and in our Android App we have to write Program Logics for each state of each activity overriding the same methods.
In other words, every Android App has a lifecycle and various important points of this lifecycle are represented by certain methods. As a result, in which state of a particular activity we have to perform what operation, the program logics related to that operation have to override the method related to that particular state and specify it in the same overridden method.
The lifecycle of an Android App is fully managed by the Android Operating System i.e. Android Platform based on the user’s needs and available resources.
For example, although the user wants to launch Web Browser on his Android Device, the Android system of the device determines whether the Web Browser App will be launched or not. Therefore, the Android platform of the Android Device is the Ultimate Manager and decides whether a Specific Task will be completed or not and if it is how.
The Android platform itself determines when an Android App will be Load, Pause, Resume or Stop.
If the user is currently using an activity, then the Android Platform gives the highest running priority to the currently running activity whereas if an activity is not currently visible on the screen, then the Android platform gives it the lowest priority, deciding that Whether the currently running activity needs more resources, whether to free its resources by shutting down the Inactive Activity so that the Current Running Activity can keep running smoothly without interruption.
That is, the activity that receives the lower priority, the Android system also shutdown that activity without our knowledge when needed, so that the resources released by it can be allocated to other currently active resource hungry activity.
In this case the lifecycle of an Android App is an easy Logical Concept but basically it is very Complicated because in a full Android App a lot of things work directly in Foreground, then a lot of things also work indirectly in the background. And Android App is working properly, all other things also work properly.
Android Application Architecture, in particular, is basically a Component and Integration Oriented Architecture that gives us the convenience of Rich User Experience, Code Reuse and Easy Application Integration but at the same time creates a lot of complexities for our Application Lifecycle Manager, Which has to do a lot of complex work in Invisibly Background to run an Android App properly.
For example, suppose a User A is talking to someone from User B on a phone call. User B asks for any information from User A, which is in the webpage whose URL is in an email Saved in User A’s Mail Box. To provide that information, the user A has to open his email app during the phone call and click on the hyperlink of the webpage on which the information is exist.
We can understand that during this entire process User A has to switch between four Android Apps in total: Home Application, Talk Application, Email Application and Web Browser Application and when User A navigates from one application to another application. , Then in this Navigation, he does not face any kind of problem, that is, the user’s experience is quite Seamless. However, while switching from each application to another, the Android system in the background keeps saving and restoring the state of the current application.
That is, while navigating from Application A to Application B, before loading the activity of Application B, saving the state of the activity of Application A and restoring Activity A from previous Values when returning to Activity A again from Activity B, all these The work is continuously and automatically handled in the background by the Android system.
For example, when User A goes from Phone Call App to Email App, then the Email App is launched only after the Phone Call App’s metadata is saved. Simply put, the Android system saves the metadata of the current activity before launching any new activity, so that when the other activity is finished and backtracked again to the current activity, the current by the Android system The state of the activity can be restored again.
Whereas if there is a memory problem during this Navigation i.e. it is not possible to run all Android Apps in parallel, then in that case Shutdown the Android App with Lowest Priority to release its Memory and Released Memory again All of these things are decided by the Android system at their own level Automatically to Allocate Current Android App Activity or when to Pause, Resume or Restart which Activity.
The Android system is quite sensitive in terms of the lifecycle of any of its applications and components. Therefore, to develop a Stable Android App, we need to have a good understanding of the entire lifecycle of Android App and the various events that happen during the lifecycle of the Trigger so that we can execute the Appropriate Event in response to a Specific Event that is being triggered. Create a handler.
The processes that run our Android App and its components, pass through a lot of Lifecycle Events, and the Android System invokes some Callback Methods in Response to each Lifecycle Event, which we change with each state change of our Android App. Implement can do for. That is, you can get your Implemented Methods Executed for the State Change occurring in Response of a Particular Event:
protected void onCreate (Bundle savedInstanceState);
protected void onStart ();
protected void onRestart ();
protected void onResume ();
protected void onPause ();
protected void onStop ();
protected void onDestroy ();
All these methods represent the lifecycle of an activity that represents a specific state change event, so it is very important to understand when and what method is called by the Android system in response to which state change event So that we can implement a Stable Android App.
If we display all these Callback Methods as a picture to represent the Lifecycle of Android Application, then we can do as follows:
It is also important to note here that we do not have to implement all the methods, rather we should be able to perform a task in the lifecycle of an activity in our Android App, at which point a task related to the event triggered at that point Handler or Callback Method only has to be implemented.
The Android system can start or stop the activities of our application depending on what is happening in other parts of the Android system. For example, if our Android Device does not have as much free memory as is necessary to launch a new Android App, then no matter how many times we try to launch that new Android App, the Android system will Won’t Start, unless we Shutdown an already running Android App and release its memory, so that the Released Memory can be used by the Android System to launch our new Android App.
When we launch an Android App on an Android Device, the Android system calls the onCreate () method to create the first screen that is being displayed for that Android App and just after the onCreate () method. We always have onStart () method call but just before onStart () call is always called onCreate () method call, it is not necessary because onStart () method can be called even in that case when our Android App Stopped.
When the onStart () method is called, then our activity is not visible in front of the user, but is going to be visible. That is, the onStart () method represents the position just before the activity becomes visible.
The onResume () method is called just after onStart () and this method is Exactly the call when the first activity of our Android App is visible in front of the user with whom the user can interact.
When the user moves to another activity while the current activity is visible, then in that case the Android system calls the onPause () method for the current activity and when the onPause () method calls for an Android App Then for that App can be either onResume () Method Call or it can be onStop () Method.
If the user returns backtracking to his previous activity, then there is an onResume () method call for it, but if that activity becomes completely invisible to the user, then in that case onStop for that activity () Is the Method Call.
Understanding of Android Activity Lifecycle – Step by Step
Whereas if once the onStop () method call for an activity is visible again in front of the user, then the onRestart () method call is for that activity.
But if our activity is not visible in front of the user, but is waiting to be activated in Stack, and at the same time the Android system wants to kill that activity for some reason, then that Inactive Android App should be completely Shutdown Calls the onDestroy () method to do.
If we try to understand this process a little bit better, then we can represent the activity lifecycle of Android App to their states and the associated callback methods from those states as follows:
As we discussed in the previous section, in the lifecycle of an activity, it goes through several states and the Android system calls a callback method associated with it across all states, but during the lifecycle of the activity there are basically only three states (Resumed , Paused, Stopped) remain static until the end:
When the activity is in the Resumed State, it remains Visible in the Foreground for the user and the user can interact with this activity. This state is also sometimes known as Running State and whenever a new Android App is launched, it goes directly through Android App Created and Started States to the Resumed State and Android System for each state. OnCreate (), onStart () and onResume () methods call respectively.
In this state of activity, he gets partially covered by some other activity.
For example, suppose you are playing a game, then suddenly a message arrives. As soon as the message arrives, some part of the screen of the game activity is covered by a Semi-Transparent Notification Activity being newly displayed and onPause () method call for the game and the game goes into Paused State and till then User Input cannot accept unless you close the Notification Activity Manually.
It is to be noted here that this type of Semi-Transparent Notification Activity does not completely cover the current activity, but only covers some part of the current activity and as soon as that Partial Activity is terminated, the previous game The app again goes into the Resumed State i.e. it becomes completely Visible and the user can accept Input.
In this state of activity, he is completely covered by any other activity. As a result, the current activity is completely hidden from any other activity and goes into the background and the onStop () method is called by the Android system to stop the current activity.
In this state, Current Activity Instance and all its state information such as Member Variables can be accessed but its codes are not Execute in any case.
When the activity hits the Stopped state, then if the user returns to the previous activity after closing the later launched activity, then the onPause () and onResume () method calls for that activity and the activity respectively. It becomes Visible again, if for some reason the Android system needs more resources, it also destroys this Stopped Activity by calling the onDestroy () method.
Thus although many Callback Methods for different states of the Activity Lifecycle of an Android Application are executed periodically, in most circumstances we basically have to implement the onCreate (), onResume () and onPause () methods. is.
We implement the onCreate () method to create a User Interface of our Activity and bind various components, Widgets etc. related to the User Interface with triggering events.
In the onPause () method, we can write Codes related to saving the Critical Data of our application in the Data Store as it is the last Safe Method that is called by the Android System before our application is killed.
OnStop () and onDestroy () Method, both of them have no guarantee of being called. So we cannot rely on them for Critical Codes related to our Android App.