A simplified explanation of the Android lifecycle
If you have ever used an Android device, you have probably noticed that it works quite differently to many other operating systems. For example, you can be using an app on your device, perhaps checking what people are doing on Facebook.
Then, you get an email notification and you tap the notification to read it. Halfway through reading the email, you might get a Twitter notification and, because you are waiting on important news from someone you follow, you interrupt your email reading and change apps to Twitter with a touch.
After reading the tweet, you fancy a game of Angry Birds; however, halfway through the first fling, you suddenly remember the Facebook post. So, you quit Angry Birds and tap on the Facebook icon.
You will likely resume Facebook at the exact same point that you left it. Afterward, you could then go back to reading the email, decide to reply to the tweet, or start an entirely new app.
All this toing and froing takes quite a lot of management on the part of the operating system, and is independent from the individual apps themselves.
The difference between, for example, a Windows PC and Android in the context of what we have just discussed is notable. With Android, although the user decides which app they are using, the OS decides when to close down (or destroy) an application and our user's data (such as the hypothetical note) along with it. We need to consider this when coding our apps; just because we might write code to do something interesting with our user's input doesn't mean that Android will let the code execute.
The lifecycle phases demystified
The Android system has a number of distinct phases that any given app can be in. Depending upon the phase, the Android system decides how the app is viewed by the user, or whether it is viewed at all.
Android has these phases so that it can decide which app is in current use, and can then allocate the correct amount of resources, such as memory and processing power, to the app.
In addition, as the user interacts with the device (for example, touches the screen), Android must give the details of that interaction to the correct app. For instance, a drag-and-release movement in Angry Birds means take a shot, but in a messaging app, it might mean delete a text message.
We have already raised the issue of when the user quits our app to answer a phone call; will they lose their progress, data, or important note?
Android has a system that, when simplified a little for the purposes of explanation, means that every app on an Android device is in one of the following phases:
- Being created
- Starting
- Resuming
- Running
- Pausing
- Stopping
- Being destroyed
This list of phases will hopefully appear logical. As an example, the user presses the Facebook app icon and the app is being created; then, it is started. This is all straightforward so far, but the next phase in the list is resuming.
This is not as illogical as it might first appear. If, for a moment, we can just accept that the app resumes after it starts, then all will become clear as we continue.
After resuming, the app is running. This is when the Facebook app has control of the screen and has the greater share of system memory and processing power, and is receiving the details of the user's input.
Now, what about our example where we switch from the Facebook app to the email app?
As we tap to go to read our email, the Facebook app will have entered the paused phase, followed by the stopping phase, and the email app will enter the being created phase, followed by resuming, and then running.
If we decide to revisit Facebook, as in the previous scenario, the Facebook app will probably skip being created and go straight to resume and then be running again (most likely at the exact same place that we left it).
Note that at any time, Android can decide to stop and then destroy an app, in which case, when we run the app again, it will need to be created at the first phase all over again.
So, had the Facebook app been inactive long enough, or perhaps Angry Birds had needed so many system resources that Android had destroyed the Facebook app, then our experience of finding the exact post that we were previously reading might have been different. The point is that it is within the control of the app and how it interacts with the lifecycle to determine the user's experience.
If all this is starting to get confusing, then you will be pleased to know that the only reason to mention these phases is due to the following:
- You know they exist
- We will occasionally need to interact with them
- We will take things step by step when we do