The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

Intents, Intent Filters

We have seen Intent objects briefly, in our discussion of having multiple activities in our application. However, we really did not dive into too much of the details about those Intent objects, and they can be used in other ways besides starting up an activity. In this chapter, we will examine Intent and their filters.

What’s Your Intent?

When Sir Tim Berners-Lee cooked up the Hypertext Transfer Protocol — HTTP – he set up a system of verbs plus addresses in the form of URLs. The address indicated a resource, such as a Web page, graphic, or server-side program. The verb indicated what should be done: GET to retrieve it, POST to send form data to it for processing, etc.

An Intent is similar, in that it represents an action plus context. There are more actions and more components to the context with Intent than there are with HTTP verbs and resources, but the concept is still the same.

Just as a Web browser knows how to process a verb+URL pair, Android knows how to find activities or other application logic that will handle a given Intent.

Pieces of Intents

The two most important pieces of an Intent are the action and what Android refers to as the “data”. These are almost exactly analogous to HTTP verbs and URLs — the action is the verb, and the “data” is a Uri, such as representing an HTTP URL to some balding guy’s Web site. Actions are constants, such as ACTION_VIEW (to bring up a viewer for the resource) or ACTION_EDIT (to edit the resource).

If you were to create an Intent combining ACTION_VIEW with a content Uri of, and pass that Intent to Android via startActivity(), Android would know to find and open an activity capable of viewing that resource.

There are other criteria you can place inside an Intent, besides the action and “data” Uri, such as:

  1. Categories. Your “main” activity will be in the LAUNCHER category, indicating it should show up on the launcher menu. Other activities will probably be in the DEFAULT category, though other categories exist and are used on occasion.
  2. A MIME type, indicating the type of resource you want to operate on.
  3. A component, which is to say, the class of the activity that is supposed to receive this Intent.
  4. “Extras”, which is a Bundle of other information you want to pass along to the receiver with the Intent, that the recipient might want to take advantage of. What pieces of information a given recipient can use is up to the recipient and (hopefully) is well-documented.

You will find rosters of the standard actions, categories, and extras in the Android SDK documentation for the Intent class.

Intent Routing

As noted above, if you specify the target component in your Intent, Android has no doubt where the Intent is supposed to be routed to — it will launch the named activity. This might be OK if the target recipient (e.g., the activity to be started) is in your application. It definitely is not recommended for invoking functionality in other applications. Component names, by and large, are considered private to the application and are subject to change. Actions, Uri templates, and MIME types are the preferred ways of identifying capabilities you wish third-party code to supply.

If you do not specify the target component, then Android has to figure out what recipients are eligible to receive the Intent. For example, Android will take the Intent you supply to startActivity() and find the activities that might support it. Note the use of the plural “activities”, as a broadly-written intent might well resolve to several activities. That is the… ummm… intent (pardon the pun), as you will see later in this chapter. This routing approach is referred to as implicit routing.

Basically, there are three rules, all of which must be true for a given activity to be eligible for a given Intent:

The upshot is that you want to make your Intent specific enough to find the right recipient, and no more specific than that.

This will become clearer as we work through some examples throughout this chapter.

Stating Your Intent(ions)

All Android components that wish to be started via an Intent must declare Intent filters, so Android knows which intents should go to that component. A common approach for this is to add one or more <intent-filter> elements to your AndroidManifest.xml file, inside the element for the component that should respond to the Intent.

For example, all of the sample projects in this book have an <intent-filter> on an <activity> that looks like this:

  <action android:name="android.intent.action.MAIN"/>
  <category android:name="android.intent.category.LAUNCHER"/>

Here, we declare that this activity:

  1. Is the main activity for this application
  2. It is in the LAUNCHER category, meaning it gets an icon in anything that thinks of itself as a “launcher”, such as the home screen

You are welcome to have more than one action or more than one category in your Intent filters. That indicates that the associated component (e.g., activity) handles multiple different sorts of Intent patterns.

Responding to Implicit Intents

The preview of this section was fed to a gremlin, after midnight.

Requesting Implicit Intents

The preview of this section was lost in the sofa cushions.


The preview of this section will not appear here for a while, due to a time machine mishap.

Practice Safe Content Resolution

The preview of this section was fed to a gremlin, after midnight.