In this chapter, we will get familiar with the lifecycle of an Android app. At first, this might sound a bit strange, that a computer program has a lifecycle, but it will make sense soon.
The lifecycle is the way that all Android apps interact with the Android OS. Just like the lifecycle of humans interacts with the world around them, we have no choice but to interact with it, and we must be prepared to handle different events without notice if we want our apps to survive.
We will see the phases of the lifecycle that an app goes through, from creation to destruction, and how this helps us know where to put out Java code, depending on what we are trying to achieve.
In brief, in this chapter, we will look at the following:
- The life and times of an Android app
- What is method overriding? And the
@Overridekeyword - The phases of the Android lifecycle
- What exactly we need to know and do to code our apps
- A lifecycle demonstration mini app
- Code structure, ready to get Java coding in the next chapter
Let's start learning about the Android lifecycle.
We have talked a bit about the structure of our code: we know that we can write classes, and within those classes we have methods, and these methods contain our code that gets things done. We also know that when we want the code within a method to run (be executed), we call that method by using its name.
Also, in Chapter 2, First Contact: Java, XML and the UI Designer, we learned that Android itself calls the onCreate method just before the app is ready to start. We saw this when we output to the logcat and used the Toast class to send a pop up message to the user.
What we will look at in this chapter is what happens throughout the lifecycle of every app we write; when it starts and ends, as well as a few stages in-between as well. And what we will see is that Android interacts with our app on numerous occasions each time it is run.
It does so by calling methods that are contained within the Activity class. Even if the method is not visible within our Java code, it is still being called by Android at the appropriate time. If this doesn't seem to make any sense, then read on.
Did you ever wonder why the onCreate method had the strange-looking line of code just before it?
@Override
What is going on here is that we are saying to Android, when you call onCreate, please use our overridden version because we have some things to do at that time.
Furthermore, you might remember the odd-looking first line of code in the onCreate method:
super.onCreate(savedInstanceState)
This is telling Android to call the original/official version of onCreate before proceeding with our overridden version. This is not just a quirk of Android; method overriding is built in to Java.
There are also many other methods that we can optionally override, and they allow us to add our code at appropriate times within the lifecycle of our Android app. Just as onCreate is called right before the app is shown to the user, so there are more methods that are called at other times. We haven't seen them yet, we haven't overridden them yet, but they are there, they are called, and their code executes.
The reason we need to care about the methods of our app that Android calls whenever it wants is because they control the very life and death of our code. For instance, what if our app allows the user to type an important reminder. Then, halfway through typing the reminder, their phone rings, our app disappears, and the data (the reminder) is gone.
It is vital, and thankfully quite straightforward, that we learn when, why, and which methods Android will call as part of the lifecycle of our app. We can then know where we need to override methods to add our own code and where to add the real functionality (code) that defines our app.
Let's examine the Android lifecycle. We can then move on to the ins and outs of Java and will know exactly where to put the code that we write.