Sunrise and sunsets are magical and fascinating to watch. What about that sensation you get when driving a supercar? Well, just like sunrise to sunset, from zero to 200 km/hr android activities go through some stages but I can promise you things happen so much faster.
During sunrise the street lights spontaneously go off and birds come off the nest; after sunset, it is all dark and quiet. At 0 km/hr everything is still but at 200 you feel energy and adrenaline pumping through your veins as the tarred road gets eaten off underneath you.
There is a similar analogy with android activities; the activity goes through certain changes during its lifetime. Behind the scenes the android system is spontaneously creating, stopping, or resuming an activity depending on whether a user is entering or leaving the activity. Each of these states corresponds to a method callback as discussed below.
We never code these callbacks by ourselves we just override them.
onCreate() Called when the activity is first created. This is where you should do all of your normal set up: e.g. create views, bind data to lists, instantiate some class-scope variables.
By default we have override onCreate and then setContentView() to define the layout for the activity.
onCreate() also provides you with a bundled instance of the activity ’s previously frozen state. This instance can be passed back to onCreate() if the activity needs to be recreated e.g. during orientation change after rotating the device or when the activity is accidentally terminated by the system.
You can think of onCreate() as that moment when you turn the key or press your car’s starter button and magic happens as the engine roars to life. The fuel pump starts to build up pressure and components like lights, fan start-off.
oncreate() is always followed by onStart().
onRestart() – android system invokes this callback when an activity in the stopped state is about to restart. onRestart() restores the state of the activity from the time that it was stopped. This callback is always followed by onStart().
Using my car example, onRestart() corresponds to engaging the Drive Gear and releasing the handbrake. The car hasn’t moved yet and your foot is on the brake pedal.
onStart() – it is called when the activity is becoming visible to the user. This callback is followed by onResume() if the activity comes into focus, or onStop() if it becomes hidden.
It’s a strategic place to put a broadcastReceiver or initialize some state about the UI that should display consistently anytime the user comes back to this activity.
Back to the car this when you’re gently releasing the brake pedal your other foot on the accelerator ready to move.
onResume() – this fires up when the activity start interacting with the user. At this point your activity is at the top of the activity stack, with user input going to it. You can initialize components you need released during onPause() e.g. restart animations. onResume() is always followed by onPause().
Our car (let’s call it an Audi) is finally on the move maybe at 200km/hr if you have the guts.
onResume is called every time the activity comes to focus including when it is first created and is always followed by onPause().
onPause() – it is called when an activity has lost focus and is going into the background but has not yet been killed. This state occurs when, for example, the user taps the Back or Home button.
onPause() is used to commit unsaved changes( data held by content providers), stop animations and other things that consume CPU/battery e.g. broadcast receivers, camera or animations.
In situations where the system needs more memory it may kill paused processes to reclaim resources. Because of this, you should be sure that all of your state is saved by the time you return from this function.
You should not do anything lengthy here – whatever it is that you are doing has to be very quick because the next activity will not be resumed until this method returns.
Once onPause() finishes executing, the next callback is either onStop() or onResume(), depending on what happens after the activity enters the Paused state.
That’s not all yet. If you put away a device for a while it would go to sleep and onPause() method will be triggered. When you touch a screen the device wakes up onResume()is called.
There is a bump ahead and the Audi has to slow down but won’t stop completely lest we take a hit from behind.
onStop() – The system calls onStop() when the activity is no longer visible and is completely hidden to the user. The next callback that the system calls is either onRestart(), if the activity is coming back to interact with the user, or by onDestroy() if this activity is completely terminating.
OnStop() may not be called if the system does not have enough memory to keep your activity’s process running and instead onDestroy() is called to terminate the process.
The activity at this point is still holding resources e.g. the declared member variable and they won’t need to initialized again. Text on Edittext is also still intact.
Here our Audi has stopped at the red traffic light, the engine is still roaring though ready for the green light.
onDestroy() – this callback is activated before an activity is destroyed.This callback is the final one that the activity receives. onDestroy is called when
− when finish() is called
− when the user presses the back button
− the system has run out of space
− Orientation change occurs to recreate the process in the new orientation.
The onDestroy() callback releases all resources that have not yet been released by earlier callbacks such as onStop(). It is called to allow your activity to do any shut-down operations it may wish to do e.g. to ensure that all of an activity’s resources are released.
Processes are killed to free up memory when a fore activity needs more resources or if the activity is in the Stopped state and hasn’t been used in a long time. The system never kills an activity directly – it kills the process in which the activity runs, destroying the activity alongside everything else running in the process.
Activity is destroyed due to normal app behavior when;
− the user presses the Back button
− Activity signals its own destruction by calling the finish() method.
When your activity is destroyed due to normal app’s behavior the Activity instance is gone forever because the behavior indicates the activity is no longer needed.
If the system destroys the activity due to system constraints (rather than normal app behavior), then although the actual Activity instance is gone, the system remembers that it existed such that if the user navigates back to it, the system creates a new instance of the 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 a Bundle object.
We have reached our destination, Audi is nicely parked and the engine is off so that no petrol will be guzzled.
The below table gives few examples of situations and callbacks invoked
|When open the app||onCreate() –> onStart() –> onResume()|
|When home button pressed||onPaused() –> onStop()|
|When any dialog open on screen||onPause()|
|After dismiss the dialog||onResume()|
|When phone screen off||onPaused() –> onStop()|
|When screen is turned back on||onRestart() –> onStart() –> onResume()|
|When back button pressed to exit the app||onPaused() — > onStop() –> onDestory()|
|Open a recent app from Activity Stack||onRestart() –> onStart() –> onResume()|
|After call end||onResume()|
Keep the comments coming.