![](https://csdnimg.cn/release/download_crawler_static/6806831/bg10.jpg)
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, which is 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, or perhaps 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 a the action set to ACTION_VIEW and a URI which 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/1234
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”));
startActivity(myintent);
This Intent is evaluated and passed to the most appropriate handler. In this case, the recipient would likely be
a built-in Activity named com.google.android.phone.Dialer. However, the best recipient of this Intent may be an
Activity contained in the same custom Android Application (ie, the one you build!), a built-in application as in this
case, or it may be a 3
rd
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 user
interfaces being used frequently, creating familiarity for the user. This is particularly important for mobile
platforms where the user is often non tech-savvy, nor interested in learning multiple ways to accomplish the same
task such as looking up a contact on their 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);
}
catch (Exception e)
{
…
}
}
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.
Please post comments or corrections to the Author Online forum at
http://www.manning-sandbox.com/forum.jspa?forumID=411
Licensed to Thow Way Chiam <ken.ctw@gmail.com>