Android Skill

Activity and Task Design
This document describes core principles of the Android application framework, from a high-level, user-centric perspective useful to interaction and application designers as well as application developers.
It illustrates activities and tasks with examples, and describes some of their underlying principles and mechanisms, such as navigation, multitasking, activity re-use, intents, and the activity stack. The document also highlights design decisions that are available to you and what control they give you over the UI of your application.
This document draws examples from several Android applications, including default applications (such as Dialer) and Google applications (such as Maps). You can try out the examples yourself in the Android emulator or on an Android-powered device. If you are using a device, note that your device may not offer all of the example applications used in this document.
Applications, Activities, Activity Stack and Tasks
Four fundamental concepts in the Android system that are helpful for you to understand are: Applications ， Activities ，Activity Stack ，Tasks
Applications
An Android application typically consists of one or more related, loosely bound activities for the user to interact with, typically bundled up in a single file (with an .apk suffix). Android ships with a rich set of applications that may include email, calendar, browser, maps, text messaging, contacts, camera, dialer, music player, settings and others.
Android has an application launcher available at the Home screen, typically in a sliding drawer which displays applications as icons, which the user can pick to start an application.
Activities
Activities are the main building blocks of Android applications. When you create an application, you can assemble it from activities that you create and from activities you re-use from other applications. These activities are bound at runtime, so that newly installed applications can take advantage of already installed activities. Once assembled, activities work together to form a cohesive user interface. An activity has a distinct visual user interface designed around a single, well-bounded purpose, such as viewing, editing, dialing the phone, taking a photo, searching, sending data, starting a voice command, or performing some other type of user action. Any application that presents anything on the display must have at least one activity responsible for that display.
When using an Android device, as the user moves through the user interface they start activities one after the other, totally oblivious to the underlying behavior — to them the experience should be seamless, activity after activity, task after task.
An activity handles a particular type of content (data) and accepts a set of related user actions. Each activity has a lifecycle that is independent of the other activities in its application or task — each activity is launched (started) independently, and the user or system can start, run, pause, resume, stop and restart it as needed. Because of this independence, activities can be re-used and replaced by other activities in a variety of ways.
An activity is the most prominent of four components of an application. The other components are service, content provider and broadcast receiver.
Activity Stack
As the user moves from activity to activity, across applications, the Android system keeps a linear navigation history of activities the user has visited. This is the activity stack, also known as the back stack. In general, when a user starts a new activity, it is added to the activity stack, so that pressing BACK displays the previous activity on the stack. However, the user cannot use the BACK key to go back further than the last visit to Home. The adding of an activity to the current stack happens whether or not that activity begins a new task (as long as that task was started without going Home), so going back can let the user go back to activities in previous tasks. The user can get to tasks earlier than the most recent Home by selecting its root activity from the application launcher, a shortcut, or the “Recent tasks” screen.
Activities are the only things that can be added to the activity stack — views, windows, menus, and dialogs cannot. That is, when designing the navigation, if you have screen A and you want the user to be able go to a subsequent screen B and then use the BACK key to go back to screen A, then the screen A needs to be implemented as an activity. The one exception to this rule is if your application takes control of the BACK key and manages the navigation itself.
Tasks
A task is the sequence of activities the user follows to accomplish an objective, regardless of which applications the activities belong to. Until a new task is explicitly specified (see “Interrupting the Task”), all activities the user starts are considered to be part of the current task. It’s notable that these activities can be in any application — that is, all in the same application or in different ones. That is, a task that starts out in contacts can continue, by choosing an email address, to an email activity and then, by attaching a file, to a picture gallery to pick from. Contacts, email and picture gallery are all separate applications.
The activity that starts a task is called the root activity. It is often, but not necessarily, started from the application launcher, Home screen shortcut or “Recent tasks” switcher (a long press on Home on some devices). The user can return to a task by choosing the icon for its root activity the same way they started the task. Once inside a task, the BACK key goes to previous activities in that task. The activity stack is made up of one or more tasks.
Here are some examples of tasks:
• Send a text message with an attachment
• View a YouTube video and share it by email with someone else

Interrupting the Task - An important property of a task is that the user can interrupt what they’re doing (their task) to perform a different task, then are able to return to where they left off to complete the original task. The idea is that users can run multiple tasks simultaneously and switch between them. There are two primary ways to jump off to that other task — in both cases the user should be able to return to where they were before the interruption:
• User is interrupted by a notification – a notification appears and the user wants to act on it
• User deciding to perform another task – user just presses Home and starts an application

Of course, there are exceptions to the rules. Beyond the two ways just mentioned, there is a third way to start a task, and that is by starting an activity that defines itself as a new task. Maps and Browser are two applications that do this. For example, choosing an address in an email starts the Maps activity as a new task, and choosing a link in an email starts the Browser activity as a new task. In these cases, the BACK key will return to the previous activity in a different task (Email), because it was not started from Home.
A Tour of Activities and Tasks
The following examples illustrate basic principles for applications, activities, the activity stack, the BACK key, tasks and intents. It shows how the system responds to user actions such as starting activities and switching between tasks. With most of these examples you can follow along, launching activities on your device as indicated.
Starting an Activity from Home
Home is the starting place for most applications. (Some applications can be launched only from other applications.) When the user touches an icon in the application launcher (or a shortcut on the Home screen), the main activity for that application is launched into the foreground where it has user focus.
Navigating Away from an Activity with BACK and HOME keys
An activity can keep or lose its state depending on how the user leaves the activity — by the HOME or BACK key.
By default, pressing the BACK key finishes (destroys) the current activity and displays the previous activity to the user.
In addition, not all activities have the behavior that they are destroyed when BACK is pressed. When the user starts playing music in the Music application and then presses BACK, the application overrides the normal back behavior, preventing the player activity from being destroyed, and continues playing music, even though its activity is no longer visible — as a visual substitute, the Music application places a notification in the status bar so the user still has an easy way to get to the application to stop or control the music. Note that you can write an activity to stop when its screen is no longer visible, or to continue running in the background — the latter was chosen for the music player.
Re-using an Activity
When activity A starts activity B in a different application, activity B is said to be re-used. This use case normally takes place because activity A is lacking a capability and can find it in activity B.
Contacts Re-Uses Gallery to Get a Picture - The Contacts activity has a field for a picture of a contact, but the Gallery is normally where pictures are kept. So Contacts can re-use the Gallery activity to get a picture. This is a good example of re-use of the Gallery activity.
Replacing an Activity
This is the use case where activity A replaces activity B in a different application. This situation normally happens because activity A is better at doing the job than activity B. In other words, A and B are equivalent enough that A can replace B. This case stands in contrast with re-using an activity, where A and B are quite different activities and supplement each other.
Multitasking
As previously noted, when an activity has been launched, the user can go to Home and launch a second activity without destroying the first activity. This scenario demonstrates launching the Maps application.
• State 1 - The user launches the View Map activity and searches for a map location. Let’s say the network is slow, so the map is taking an unusually long taking time to draw.
• State 2 - The user wants to do something else while they’re waiting, so they press HOME, which does not interrupt the map’s network connection and allows the map to continue loading in the background.
• State 3 - The map activity is now running in the background, with Home in the foreground. The user then launches the Calendar activity, which launches into the foreground, taking user focus, where they view today’s calendar (as indicated by the heavy outline).
• State 4 - The user presses Home, then Maps to return to the map, which by now has fully loaded.

The application launcher at Home has launched “View Map” and “Day View” activities into separate tasks, hence the system is multitasking — running multiple tasks.
Switching Between Tasks
This scenario shows how the user can switch between two tasks. In this example, the user writes a text message, attaches a picture, but before they are done they glance at their calendar. They then return to where they left off, attaching the picture and sending the message.
1. Start first task. You want to send a text message and attach a photo. You would choose:

Home > Messaging > New message > MENU > Attach > Pictures. This last step launches the picture gallery for picking a photo. Notice that picture gallery is an activity in a separate application.
At this point, before you have picked a picture, you decide to stop and glance at your calendar, which is a separate task. Because the current activity has no button to go directly to the Calendar, you need to start from Home.

1. Start second task. You choose Home > Calendar to look at a calendar event. Calendar launches from Home as a new task because the application launcher creates a new task for each application it launches.

2. Switch to first task and complete it. When done looking at the Calendar, you can return to attaching the picture by starting the root activity again for that task: choose Home > Messaging, which takes you not to Messaging, but directly to the Picture gallery, where you left off. You can then pick a photo, which is added to the message, you send the message and you’re done with the first task.

Design Tips
The following are tips and guidelines for application designers and developers.
When writing an activity that won’t be re-used, don’t specify intent filters — use explicit intents
If you’re writing an activity that you don’t want other activities to use, be sure not to add any intent filters to that activity. This applies to an activity that will be launched only from the application launcher or from other activities inside your application. Instead, just create intents specifying the explicit component to launch — that is, explicit intents. In this case, there’s just no need for intent filters. Intent filters are published to all other applications, so if you make an intent filter, what you’re doing is publishing access to your activity, which means you can cause unintentional security holes.
Consider how you want your activities to be launched or used by other applications
As a designer or developer, it’s up to you to determine how users start your application and the activities in it. As an application is a set of activities, the user can start these activities from Home or from another application.
• Launch your main activity from an icon at Home - If your application can run standalone, it should probably be started by the user touching an icon in application launcher (typically implemented as a sliding drawer on the Home screen), or from a shortcut icon on the Home screen, or from the task
switcher. (The mechanism for this is for the activity to have an intent filter with action MAIN and category LAUNCHER.)