Android Activity Lifecycle - Like we said earlier, every Android App is actually based on a framework similar to the Java Applet, which has some methods related to different conditions of each Activity of 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, program logic 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 so in what way.
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 that 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 the 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 also 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 some 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 whole 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, ie 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 the previous values when returning to Activity A from Activity B again, 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 these things have to be 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 being Trigger. Handler can to Create.
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 in each state 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 some of the following ways:
The thing to note is that we do not need to Implement the Methods but we have to Perform a Task on the Point in Lifecycle of Activity of our Android App is that Trigger on the Point Event -related Event 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 calls, our activity is not visible in front of the user at that time, but is going to be visible. That is, the onStart () method represents the position just before the activity becomes visible.
Just the onStart () later onResume () is Method Call and Method Exactly at that time Call happens when our Android App of the First Activity, Can Interact User with the Visible to the User.
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 the App either onResume () might Method Call or onStop () might 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.
Whereas if once the onStop () method call for an activity is visible again in front of the user, then in that case 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 calls a callback method associated with the Android system 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. respectively: OnCreate (), OnStart () and onResume () does Methods Call.
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 that is 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.
The State of Activity She completely by another Activity Covered is taken. 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 Activity Stopped then Heata in the State, if the User that comes later on in the previous Activity again while Close the Activity went to Launch, so that respectively Activity OnPause () and onResume () is Method Call and Activity 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 periodically executed, 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 related to the User Interface, Widgets etc. with triggering Events.
In the onPause () method, we can write the Codes related to saving the Critical Data of our application in the Data Store because this is the last Safe Method that is called by the Android system before we kill our application.
OnStop () and onDestroy () Method, there is no guarantee of both of them being called. So we cannot rely on them for Critical Codes related to our Android App.