Tasks and Your App

If you have used an Android device for a reasonable length of time, most likely you will have seen the “overview screen, sometimes called the ”recent-tasks list". The look has varied widely over the years and across the range of devices and manufacturers. They all give you a way to “get back to where you once belonged” — you can rapidly return to some app that you had been in recently.

So, on Android 9.0 you might see:

Overview Screen on Google Pixel Running Android 9.0
Overview Screen on Google Pixel Running Android 9.0

…while on Android 5.0, you might see:

Overview Screen on Samsung Galaxy Note 3 Running Android 5.0
Overview Screen on Samsung Galaxy Note 3 Running Android 5.0

Tasks are the sort of thing that developers often ignore early on. However, many apps eventually do need to address task management.

What is a Task?

Tasks are a bit like tabs in a Web browser.

In a tabbed Web browser, each tab operates fairly independently from other tabs. In particular, each tab has its own “back stack”: pressing the BACK button affects your current tab, not other tabs that happen to be open.

Similarly, a task in Android represents a stack of activities. One activity can open other activities, in the same app or even in different apps, as we will explore in an upcoming chapter. By default, those activities will all belong to the same task. Each time the user presses the BACK button, it destroys the current foreground activity and returns control to whatever activity preceded it. If the user presses BACK from the first (“root”) activity of the task, the task itself is destroyed and the user returns to the home screen.

OK, So Why Do I Care?

The point of tasks is to allow users to rapidly move between apps that have been used recently. In principle, this is the same as a desktop operating system allowing the user to move between opened apps.

However, there is one practical difference: mobile devices usually have a lot less RAM. While newer high-end Android devices might have a lot of RAM, older or less-expensive Android devices might not have very much. As a result, we cannot have lots of running processes — the out-of-memory killer will eventually have to start killing off those processes to free up memory for yet other processes.

However, once an app’s process is terminated, everything it held onto in memory is now gone. It has to reload data from disk or from the network. Moreover, it loses all “context” by default: the app does not necessarily remember where the user had been in the app. Instead, by default, if the user goes back to the app, the app will start over from scratch.

To help deal with this, Android keeps track of some amount of state associated with your app. If:

…then Android will try to restore your app and its task to the state it had been in when the user left. In particular, for the purposes of this chapter, Android will hand some “instance state” back to your activity, and you can try to use that to pretend to the user that your activity had been around all along, even though in reality this is a brand-new activity instance in a brand-new process.


Prev Table of Contents Next

This book is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license.