Android intents are simply an easy way to safely expose certain application functionality for other applications to use. Many very popular applications like the suite of Google Android applications document their intents for other developers to use, which helps establish those applications as with users. It also makes for seamless application switching, which keeps those users happy.
Here’s the good news: There’s nothing stopping you, the Android developer, from doing the same with your applications. In this article, we explore third-party intents: what they are, why you should use them, and why you may benefit from creating your own for others to use.
A Little Background on Android Intents
The Intent mechanism of the Android platform allows applications to invoke other applications (technically, a specific Activity) for a variety of purposes. For example, Android app developers often want to invoke Google Maps and display a certain location, or the built-in Browser application to a given website, or the Dialer application to easily make a phone call.
So how does this work? You may already be familiar with how to package up Android intents to transition between activities within your own Android app. The process of invoking third-party Android intents is pretty similar. Your application creates an intent, packages up any related data associated with the request (such as a phone number or Web URL extras in a Bundle) and sends that request out to the Android operating system. The Android OS knows about all the applications installed on the device and can determine which of those applications have intent filters matching the request. If another application installed on the device has the ability to handle that intent, the request is dispatched to that application and handled. Control is then returned to your application.
Using Third-Party Android Intents
Many applications expose their functionality using well documented and supported intents that your application can use. There are three very common intent usage patterns for applications to expose certain functionality through an intent:
- Invoking Google applications usually pre-installed on many Android devices. You can find a list of some of the Google application intents at the Android developer documentation site.
- Invoking stock intent action types (such as
ACTION_SEND) with specific URI content types. For example, many Android applications, like the Facebook and Twitter apps, will happily respond to
ACTION_SENDintents for text and picture content.
- Invoking third-party applications that may or may not be installed on the device. The documentation for these is usually provided by the individual developer. Websites like OpenIntents.org provide a registry for developers to list their application intents for others to use.
The best practices for using third-party intents is much like using third-party content providers. It’s best to use only those that are well documented and supported. Using undocumented intents–or misusing them–is highly discouraged for similar reasons. The Android Developer Blog has a great write-up on why you should stick to supported, documented content providers. The gist of the issue is: when you use undocumented or non-public APIs, whether through the content provider mechanism (Android app data sharing) or through intents (Android app functionality sharing), you risk publishing an unstable application that will not be easy to maintain or support over time, or across different devices.
Tips for Invoking Third-Party Android Intents
When invoking an intent, here are a couple of tips to keep in mind.
- There may be many applications installed on the device that can accommodate your intent request. Therefore, you should allow the user to choose which application they want to handle the request at that particular time.
- There may not be an application installed on the device that can accommodate your request. Therefore, you should conditionally offer third-party functionality to your users.
Let’s talk about each of these cases in a bit more depth.
Say your application has a picture, and you want to allow the user to share it with their friends. Who knows if they want to share it via email, instant messaging, Facebook, Twitter or Google+. Some users might have all of these applications installed. How does your application know which to use? Well, your application doesn’t care; it just wants to offer the ability to send that picture to another application and that application takes care of the details.
Basically, when you package up your intent, you should use a chooser to show all the user’s options. The user can pick one at runtime. This way, as new applications are added and removed from the device, your application will pick them up and include them as options from within your applications with no code changes for you!
Another common case for multiple application installations that can handle a given request: users often install alternative Web browsers on their devices.
Now let’s look at the other case. You want to allow the user to do something, but there are no applications installed on the device that can do it. You can use the PackageManager to programmatically query to see if anything currently installed on the device can handle your request. If not, you should either hide the functionality within your application or suggest they install a specific application.
Develop Your Own Android Intents
Android app developers can, in theory, promote their applications more easily at the OS level by implementing and exposing their own intents for other Android apps to use. The user will still need to install your Android app first, but they’re more likely to use it if it’s well-integrated into their OS. Clever, eh?
The simplest way to do this is to provide functionality associated with that first group of intent types, again like
ACTION_SEND, with the content types in which your specific application excels. These are the types of intent requests most frequently used on the system, for features like “Share.” By using these stock intent types, your application will automatically become one of the applications that is listed in any picker when more than one application is capable of handling an intent request. The originating application doesn’t even need to know of your existence to integrate with you.
Less common but still sometimes effective is the idea of making custom intent types for other applications to use. Here the task of documenting and supporting your intent types is more burdensome. You need other applications to request your intents explicitly and somehow ensure that the user installs your application in the first place. This technique often works for very popular applications that provide some sort of popular service. For example, a popular auctioneer or bank might create an application with a set of well-understood intents for use–it helps if they already have APIs and third-party developer relationships to draw from. This technique also works well if you develop a suite of applications and want them to be well-integrated with one another.
Regardless of which avenue you take, it’s your responsibility to provide adequate documentation of the intents your application uses and the extra data it supports.
Android intents are the foundation of the powerful application integration system that helps set Android apart from competing platforms. Your applications can integrate with other applications by using those intents that are properly exposed and documented, and expose your own application functionality to other applications by handling intents of specific actions and types within your own applications.
About the Authors
|Shane Conder and Lauren Darcey — Contributing Editors, Mobile Development — have coauthored two books on Android development: an in-depth programming book entitled Android Wireless Application Development (ISBN-13: 978-0-321-62709-4) and Sams Teach Yourself Android Application Development in 24 Hours (ISBN-13: 978-0-321-67335-0). When not writing, they spend their time developing mobile software at their company and providing consulting services.