This simple and expected behavior is induced and monitored by Android activities, which are the building blocks of any Android application.

Being the main building block of Android apps does not ensure simplicity. Indeed, activities are a very unusual programming block. Let's compare Android activities with the C# traditional application. Every C# program in the world has the following lines of code:

class Program {
  static void Main(string[] args) {
  }
}

These lines will be—more or less—the same in every program. Moreover, these lines represent the starting point of your program. C# is not the only language that builds around a static() method for launching programs. Actually, most of the languages used, such as Java, C, C++, and so on work this way. On the contrary, in an Android app, the starting point of the application can be any registered activity. In our Hello World example from Chapter 1, Getting Started, our unique activity is named "Hello World" and is represented by the MainActivity class:

[Activity (Label = "Hello_World", MainLauncher = true)]
public class MainActivity : Activity

The Activity() method does have a label and a MainLauncher attribute that informs the Android systems about the main starting point. If we remember the code from the MainActivity class, there was no static void Main method but only one method named OnCreate:

protected override void  onCreate (Bundle bundle) 

Even if the Android architecture allows programmers to create many activities, in practice, a large majority of Android applications have only one activity. Despite the official definition proposed by the Android team, which we discussed earlier, activities often drift from a single, focused thing to a bunch of functionalities that handle the whole application. Therefore, most of the Android applications have only one activity, and this activity is therefore the starting point of the applications. So you might ask why Android creators have implemented this functionality that allows us to create many entry points in the same program. If an application is forced to abort for any reason, such as a crash, the OS may try to restart the latest activities as they were before the crash. In other words, you can build applications that provide many functionalities divided into several activities so that if one of the activities crashes, it can be restored by the OS without affecting the rest of the application. Moreover, the activities fragmentation serves another purpose, that is, an OS can pause activities if they become inactive and awake them (unpause) at the user's demand.

Since the beginning of this section, we defined activities as the main building blocks of Android applications and as starting points that can be created, paused, and even restored or restarted. Therefore, activities have states. Activities also have lifecycles that we must master.

Activities can have four different states throughout their lives, and the OS, as we have seen earlier, will use these states to orchestrate the allocations of physical resources between the different applications running on the phone or Android device. These four states are officially named running, paused, stopped, and killed.

The Running state qualifies the application that is in the forefront, that is, the application that is currently being used by the user.

When a Running activity loses the focus but is still visible, the application is paused. The Paused state can be tricky to see, but it typically occurs when a translucent menu shows up with "How to Use" instructions. Because a picture is worth a thousand words, the following image shows the Welcome Semitransparent tutorial of the Pulse application, which is one of the best news reader apps out there:

This is a perfect example of a paused application. The main activity that is handling the Pulse application is paused because it was being used in the forefront but lost the focus while remaining visible and completely alive.

The next state is known as stopped and occurs when an application is not visible anymore. In this particular state, the application holds its inner data (filled in fields and so on) but a stopped application will often be killed by the OS in order to free some memory. Finally, when an activity is in the paused or stopped state, the OS can terminate it by gently asking it to close or, in a more brutal and instable way, by killing their underlying processes. If the user wants them in the forefront again, they have to be completely restarted from scratch. The following figure shows the actions that lead to the different states:

We can see that when a user starts an activity, some instantiation processes have to be done (we will get back to that in the next recipes), and then the activity is entered in the running state. When the activity is no longer focused but still visible, it's paused; however, it will be stopped if the activity is not visible at all.

If the activity is paused and comes back to the forefront or the user navigates back to a stopped Activity, the activity will be in the running state. Note that the change in state from paused to running requires less instantiation work than from stopped to running. Also, it is possible that the paused and stopped activities may have been killed by the OS to free some resources. In that case, the whole instantiation process has to be executed again, just as we did for the first launch.

As always, when programming, there are exceptions to simple statement sequences. Android programming comes with its bunch of exceptions too. The configuration changes occur, for example, when the phone is rotated. In such cases, the application must adapt itself to the new screen orientation and might want to display additional functionalities, for example, the virtual keyboard. If we have to follow the state sequence we just discussed, adapting an activity will cause it to pass by all states: onPause, onStop and onDestroy followed by the onStart. Because activities are the main mechanism for interacting with the user, we must keep them responsive. In order to achieve this, Android exposes a special API, which bypasses classical states and operates a quick deconstruction/reconstruction cycle of the activity.

The next recipe Practicing the activities' lifecycles for a hands-on tutorial on Android activities' life cycles.