Android’s Good Intentions: Employ Intents to Reuse Code and Improve User Experiences
This article explains how Android intents work by building the application shown in Figure 1. We target the 2.1 Level 7 API, but you should be able to get things working on 2.2 with minor adjustments.
Figure 1 The sample application places a picture taken with the camera in a callout bubble over a map.
Function-wise, the application embeds a camera picture in a callout bubble (drawn with 2D graphics) over a map. If this is your first time with Android, you should read the Application Fundamentals document before continuing.
Tasks, Activities, and Intents
Before discussing intents, a tasks and activities refresher is a good idea. A task is something useful an Android device does such as make a phone call, navigate directions, or take a picture. They’re carried out by activities one screen at a time. For example, reading an e-mail is two activities. One screen displays an inbox and the other a message from it. Figure 2 shows how the e-mail application fits together. The activities live under the same umbrella in the same application but don’t have to, and that’s where intents come into play.
Figure 2 A conceptual view of the e-mail application. While Application and Activity classes exist, a task is a concept (i.e., there’s no Task class).
Activities launch each other with explicit and implicit intents. When a message is tapped, the “Inbox” activity explicitly launches the “Display Message” activity through an Intent constructed with the Class of the latter. A dependency results, but that’s standard fare for activities in the same application.
Now consider doing an e-mail attachment. Most e-mail clients explicitly summon a file chooser, but Android’s presents choices based on the capabilities of applications installed alongside it. It might pick from the camera, a file explorer, or the gallery. All advertise their capability to yield files system-wide through intent filters, which are discussed in the next section. Compare Figure 2 with Figure 3 to see how implicit intents cross application boundaries.
Figure 3 Applications borrow functionality from each other with implicit intents.
Implicit intents completely decouple activities at compile time and bind them at runtime. The best part is this: New applications improve the way old ones work automatically. It’s like teaching an old dog new tricks!