An Overview of Android Intents

An Overview of Android Intents

Android intents are structured mechanisms for passing messages between applications on the Android platform. Essentially, each application runs in its own sandbox and doesn’t have access to another application’s data—which is fair enough. To communicate with another application, an intent is sent to the Android OS itself, and, if one or more applications are configured to respond to that intent, then the OS provides them an opportunity to do so.

While intents are a native application concept, they make a lot of sense from a web developer’s perspective, primarily because they respect the web URI scheme ( http://en.wikipedia.org/wiki/URI_scheme) naming conventions. While we aren’t interested in how to use intents from the perspective of native application development, using intents can provide us with an almost seamless way to transition from a web page back into our native application. In our particular case, we are providing a transition from the Twitter authentication process, back into the PhoneGap application wrapper for Moundz.

If you own and use an Android device, then you have probably experienced this already—for example, if you were browsing a web page, and then after clicking a link were taken to one of the native Android apps, as if by magic. Both the Android Market and YouTube use intents in this way.

So, let’s see how complicated it is to have Moundz respond to some Android intents. The first thing we need to do is modify the AndroidManifest.xml file that resides in the root directory of our Moundz PhoneGap project. In this file, we will be adding an additional intent-filter to the application definition:

<application android:icon="@drawable/icon" android:label="@string/app_name"

CHAPTER 12: Polishing and Packaging an App for Release

android:debuggable="true"> <activity android:name=".Moundz"

android:label="@string/app_name" android:configChanges="orientation|keyboardHidden"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" />

</intent-filter>

<intent-filter> <action android:name="android.intent.action.VIEW"></action> <category android:name="android.intent.category.DEFAULT"></category> <category android:name="android.intent.category.BROWSABLE"></category> <data android:host="moundz" android:scheme="content"></data>

</intent-filter>

</activity> </application>

Our new intent-filter definition is setting up Moundz to receive intents with the VIEW action, and we are marking our filter with the categories of DEFAULT and BROWSABLE. Both of these category definitions are required to have the intent filter work properly from the native web browser.

Finally, the intent-filter definition contains a data tag that provides information on how the URI scheme will look when placed in an HTML anchor. For instance, our definition specifies a host of moundz and a scheme of content, which means that links in web pages that start with content://moundz are going to match this filter, and the Moundz native application would be opened in response to these links being clicked.

NOTE: The content URI scheme is an official registered URI scheme that maps to content providers for the Android platform. Note that it is also possible to use a custom scheme (e.g., we have URIs starting with moundz://); however, it is often discouraged, as URI schemes are meant to be unique, and this uniqueness is controlled through various Internet standards bodies.

Additionally, it is also possible to register the filter using the HTTP (or HTTPS) scheme should you want to allow users to either complete the action using the Android browser or via a native application. If we had actually deployed to a public URL, then this might be an excellent way to go, but at this stage we are focusing on a deployment through PhoneGap, so the content scheme is probably the best fit.

To test our new filter, we simply need to create a very simply web page with a link that matches the rule specified in the intent-filter:

<!DOCTYPE html> <html> <head> <title>Intent Test</title> <meta name="viewport" content="initial-scale=1.0, user-scalable=no" /> </head> <body> <a href="content://moundz/test">Moundz Local Test</a>

CHAPTER 12: Polishing and Packaging an App for Release

</body> </html>

All right, let’s give it a go. Save the preceding code and then browse to it using the native Android browser. You should see a simple link and, when you activate the link, the native Moundz application should be launched. Figure 12–16 displays an example of what you should see.

Figure 12–16. Clicking the test link takes us directly into the Moundz application. Excellent, it worked. With that functionality, we should be able to make some tweaks to

our Moundz application code and have it take appropriate action in response to the intents. We will, however, need a little help.