Every Android app goes through a series of steps in order to get where it's going in a user friendly fashion. Normally, you get a splash screen, followed by a home page, then maybe you take a trip to the settings page before you hit start and begin your awesome gaming journey. Because each page you see on an Android app is an Activity of some type, in the diagram above we see the steps that each Activity takes from its creation to its inevitable destruction.
Android, unlike many other programming frameworks which being an application by calling a start method, instead uses a series of callback methods in order to instantiate each Activity. The methods are run in a pyramid like fashion, like you see up above. Once it reaches the top of the pyramid, we would consider the Activity running in the foreground.
It's important to know just what is going in the background with your Activities so that you can take care of data and state at the appropriate times. If we were playing a game on our phones and after going to the menu, the game continued to play in the background, then we're going to have a bad time.
Before we begin we'll need to set our initial Launcher Activity. This is the Activity that gets run when we click on the icon to begin our application. We can set this value in our AndroidManifest.xml file by making sure the following is present in the file.
<activity android:name=".MainActivity" android:label="@string/app_name">
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
For every new Activity created in an application, the onCreate method is called. You can use the onCreate to declare class scope variables or define user interface elements.
Right after onCreate is called the system will call onStart() and onResume() in succession. Your activity will remain in the Resumed state, until some other action is called.
A vital part of any application. If you're playing a game for example. you hit the pause button, and normally you will get a transparent pause dialog in the middle of the screen. At this stage, your current Activity will have it's onPause method called. This is a good time to pause videos, or stop any animations that may waste those precious CPU cycles.
When the user resumes your activity from the Paused state, the system calls the onResume() method. You do not need to recreate any controls or restore state values for this. Pausing an Activity still keeps it alive and well in memory. If we took any actions in the onPause()
If we were to have a new Activity take over for the current one, by taking up 100% of the screen, then the onStop() method would be called. For example, if we jump to a recently open application or if we receive a phone call then the current Activity would be in the stop state. At this point, your Activity should release all of it's resources that aren't needed.
While we did use onPause() to pause resources,such as video playback or animations, we can use onStop() to use more cpu intensive shut down procedures.
When we bring back our Activity to the foreground, the system calls onRestart(). Keep in mind that the system keeps the Activity in memory, so it is probably unlikely that you will need to recreate any Views or other elements.
Once we are done with our Activity, the system comes back down the pyramid and calls onDestroy(). You probably won't be implementing this method too often, but if you have background threads to kill or other jobs that may cause memory leaks, this would be the place to do it.
For now, this should be enough info to move forward in app development. At least for me it is. I'm sure after some more hands on work, I might need to revisit the life cycle, but for now, I think it's time to get to coding.
Thumbs up if you enjoyed this post!
Walter G. is a software engineer with over 10 years of professional experience. When he isn't blogging or being a CTO he enjoys coding randomly complex things that he hopes many people will get a chance to use one day.