Androids good Intentions

The power of Android's application framework lies in the way in which it brings a web mindset to mobile applications. This doesn't mean the platform has a powerful browser and is limited to clever JavaScript and server-side resources, but rather it goes to the core of how the Android platform itself works and how the user of the platform interacts with the mobile device. The power of the internet, should one be so bold to reduce it to a single statement, is that everything is just a click away. Those clicks are known to the user as Uniform Resource Locators (URLs), or alternatively, Uniform Resource Identifiers (URIs). The use of effective URIs permits easy and quick access to the information users need and want every day. "Send me the link" says it all.

Beyond being an effective way to get access to data, why is this URI topic important, and what does it have to do with Intents? The answer is a nontechnical but crucial response: the way in which a -mobile user navigates on the platform is crucial to its commercial success. Platforms that replicate the desktop experience on a mobile device are acceptable to only a small percentage of hard-core power users. Deep menus, multiple taps, and clicks are generally not well received in the mobile market. The mobile application, more than in any other market, demands intuitive ease of use. While a consumer may purchase a device based on cool features enumerated in the marketing materials, instruction manuals are almost never touched. The ease of use of the UI of a computing environment is highly correlated with its market penetration. UIs are also a reflection of the platform's data access model, so if the navigation and data models are clean and intuitive, the UI will follow suit. This section introduces the concept of Intents and IntentFilters, Android's innovative navigation and triggering mechanism. Intents and IntentFilters bring the "click on it" paradigm to the core of mobile application use (and development!) for the Android platform.

■ An Intent is a declaration of need.

■ An IntentFilter is a declaration of capability and interest in offering assistance to those in need.

■ An Intent is made up of a number of pieces of information describing the desired action or service. This section examines the requested action and, generically, the data that accompanies the requested action.

■ An IntentFilter may be generic or specific with respect to which Intents it offers to service.

The action attribute of an Intent is typically a verb, for example: VIEW, PICK, or EDIT. A number of built-in Intent actions are defined as members of the Intent class. Application developers can create new actions as well. To view a piece of information, an application would employ the following Intent action:


The data component of an Intent is expressed in the form of a URI and can be virtually any piece of information, such as a contact record, a website location, or a reference to a media clip. Table 1.1 lists some URI examples.

Table 1.1 Intents employ URIs, and some of the commonly employed URIs in Android are listed here.

Type of Information

URI Data

Contact lookup

Map lookup/search

Browser launch to a specific website



The IntentFilter defines the relationship between the Intent and the application. IntentFilters can be specific to the data portion of the Intent, the action portion, or both. IntentFilters also contain a field known as a category. A category helps classify the action. For example, the category named CATEGORY_LAUNCHER instructs Android that the Activity containing this IntentFilter should be visible in the main application launcher or home screen.

When an Intent is dispatched, the system evaluates the available Activitys, Services, and registered BroadcastReceivers (more on these in the next section) and dispatches the Intent to the most appropriate recipient. Figure 1.5 depicts this relationship among Intents, IntentFilters, and BroadcastReceivers.

IntentFilters are often defined in an application's AndroidManifest.xml with the <intent-filter> tag. The AndroidManfest.xml file is essentially an application descriptor file, discussed later in this chapter.

A common task on a mobile device is the lookup of a specific contact record for the purpose of initiating a call, sending an SMS (Short Message Service), or looking up a snail-mail address when you are standing in line at the neighborhood pack-and-ship store. A user may desire to view a specific piece of information, say a contact record for user 1234. In this case, the action is ACTION_VIEW and the data is a specific contact record identifier. This is accomplished by creating an Intent with the action set to ACTION_VIEW and a URI that represents the specific person of interest.

Here is an example of the URI for use with the android.content.Intent. ACTION_VIEW action:

content://contacts/people/12 34

Here is an example of the URI for obtaining a list of all contacts, the more generalized URI of content://contacts/people

Here is a snippet of code demonstrating the PICKing of a contact record:

Intent myIntent = new Intent(Intent.ACTION_PICK,Uri.parse("content://contacts/ people"));


This Intent is evaluated and passed to the most appropriate handler. In this case, the recipient would likely be a built-in Activity named Dialer. However, the best recipient of this Intent may be an Activity contained in the same custom Android application (the one you build), a built-in application as in this case, or a third-party application on the device. Applications can leverage existing functionality in other applications by creating and dispatching an Intent requesting existing code to handle the Intent rather than writing code from scratch. One of the great benefits of employing Intents in this manner is that it leads to the same Uls being used frequently, creating familiarity for the user. This is particularly important for mobile platforms where the user is often neither tech-savvy nor interested in learning multiple ways to accomplish the same task, such as looking up a contact on the phone.

The Intents we have discussed thus far are known as implicit Intents, which rely on the IntentFilter and the Android environment to dispatch the Intent to the appropriate recipient. There are also explicit Intents, where we can specify the exact class we desire to handle the Intent. This is helpful when we know exactly which Activity we want to handle the Intent and do not want to leave anything up to chance in terms of what code is executed. To create an explicit Intent, use the overloaded Intent constructor, which takes a class as an argument, as shown here:

public void onClick(View v) { try {

startActivityForResult(new Intent(v.getContext(),RefreshJobs.class),0);

These examples show how an Android application creates an Intent and asks for it to be handled. Similarly, an Android application can be deployed with an IntentFilter, indicating that it responds to Intents already created on the system, thereby publishing new functionality for the platform. This facet alone should bring joy to independent software vendors (ISVs) who have made a living by offering better contact manager and to-do list management software titles for other mobile platforms.

Intent resolution, or dispatching, takes place at runtime, as opposed to when the application is compiled, so specific Intent-handling features can be added to a device, which may provide an upgraded or more desirable set of functionality than the original shipping software. This runtime dispatching is also referred to as late binding.

Mobile Apps Made Easy

Mobile Apps Made Easy

Quick start guide to skyrocket your offline and online business success with mobile apps. If you know anything about mobile devices, you’ve probably heard that famous phrase coined by one of the mobile device’s most prolific creators proclaiming that there’s an app for pretty much everything.

Get My Free Training Guide

Post a comment