With Android, Google implemented its very own UI component model, introducing various new terms and concepts probably unfamiliar to most developers. Although well designed and powerful, it is unconventional, has a high learning curve and, in some respects, lacks sufficient documentation. Basic use cases may be quick to implement, but in order to develop more complex applications, a thorough understanding of Android’s UI component model is essential.
This series aims at providing this understanding while focusing on the UI related concepts of activities and tasks.
This series is composed out of four posts:
- This first post gives an introduction to Android’s UI component model and briefly explains the concepts behind activities and tasks.
- The second post details the various intent flags used to customize the start of activies and influence corresponding behavior (caller).
- The third post deals with the different activity properties specifyable for the called activity (callee).
- The fourth post concludes the series with an exploration of the different combinations of intent flags and activity properties.
Introduction to Android’s component model
In Android, the visible UI of an application is composed out of so-called activities. An activity usually corresponds to one screen the user interacts with, responsible for doing one particular job within an application, like showing a list of files or rendering a web page. Activities display UI controls (so-called views) to the user and react to events. They are each implemented within a single class that extends Android’s Activity base class.
Most applications consist of multiple activities, allowing the user to navigate from one activity to another. Technically, this usually implies creating a new activity instance and starting it. From a developer’s perspective, this is achieved by using so-called intents (that either specify the to-be-called activity explicitely or describe the “intention” accurately enough for Android to choose a suitable one).
A distinct characteristic of Android is the possibility to start activities provided by other applications, enabling the user to seamlessly navigate between applications without necessarily being aware of this fact, forming a cohesive user experience. At any point, the user may press the “back” button of his device to return to the previously viewed activity.
To provide this functionality, Android keeps stacks of activities the user has opened. Such stacks are referred to as tasks. In many cases, a new task is started by launching an application from the application menu or home screen. The called “bootstrap” activity instance of the launched application becomes the first one in the task’s stack. When navigating from this activity to another one, the new one is pushed on the stack, which is then holding two activity instances.
Thus, a task is what the user experiences as “application”, while activities contained in a task may actually come from different applications. For example, an activity might display a list of locations that each, when clicked, open a Google Maps activity to show the location on a map. This map activity is not part of the original application but is experienced by the user as such. Android pushes it on top of stack of the current task. Pressing the “back” button of the device at any time will remove the (currently visible) top activity instance from the task’s stack, close it and return to the underlying activity, thus providing an activity history not unlike the one known from web browsers.
It is possible to have multiple tasks present in the system at the same time. The user can bring a particular task to the foreground, work with it, then switch back to a task started earlier, or create a new task by launching another application. The stack of activities for each task is retained.
From the user’s perspective, such a task switch is performed by leaving the current task via pressing the “home” button and launching another application, which will either create a new task or bring an existing one to the foreground, depending on if the application was already started before. In addition, pressing and holding the “home” button will display a list of recent tasks to switch to directly, similar to ALT+TAB known from Desktop operating systems.
When speaking of activities in a task’s stack, we always mean activity instances. It is possible to have multiple instances of the same activity within the same task, e.g. an activity that shows the content of a certain folder within a file explorer application. Clicking on a folder opens the same activity with a different folder. Also, two instances of the same activity may run in two different tasks, e.g. an activity to view a location on a map.
The described behavior for activities and tasks can be customized by specifying certain intent flags when starting an activity. For example, we may want to bring an activity already existing in the task’s stack to the top instead of creating a new instance of that activity. These possibilities are explored in detail in the next post of this series.