Android Intents: Developer Best Practices for App Integration
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.