The life and times of an Android app
We have talked a bit about the structure of our code; we know that we can write classes, and within those classes we have functions, and these functions contain our code, which gets things done. We also know that when we want the code within a function to run (that is, be executed), we call that function by using its name.
Additionally, in Chapter 2, Kotlin, XML, and the UI Designer, we learned that Android itself calls the onCreate function just before the app is ready to start. We saw this when we output to the logcat window and used the Toast class to send a pop-up message to the user.
In this chapter, we will examine what happens throughout the lifecycle of every app that we write; that is, when it starts, ends, and the stages in between. What we will see is that Android interacts with our app on numerous occasions each time that it is run.
How Android interacts with our apps
Android interacts with our apps by calling functions that are contained within the Activity class. Even if the function is not visible within our Kotlin code, it is still being called by Android at the appropriate time. If this doesn't appear to make any sense, then read on.
Have you ever wondered why the onCreate function has the unusual override keyword just before it? Consider the following line of code:
override fun onCreate(…
When we override a function such as onCreate, we are saying to Android that when you call onCreate, please use our overridden version because we have some code in it that we want to execute.
Furthermore, you might remember the unusual-looking first line of code in the onCreate function:
super.onCreate(savedInstanceState)
This is telling Android to call the original version of onCreate before proceeding with our overridden version.
There are also many other functions that we can optionally override, and they allow us to add our code at appropriate times within the lifecycle of our Android app. In the same way that onCreate is called just before the app is shown to the user, there are also other functions that are called at other times. We haven't seen them or overridden them yet, but they are there, they are called, and their code executes.
The reason we need to know and understand the functions of our app that Android calls whenever it wants is because these functions 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 (that is, the user's important reminder) is gone?
It is vital and, thankfully, quite straightforward to learn when, why, and which functions Android will call as part of the lifecycle of our app. We can then understand where we need to override functions 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 Kotlin and gain an understanding of exactly where to put the code that we write.