Archive

As an app developer, you know the importance of using external services and APIs offered by other developers. Leveraging third-party software eliminates unnecessary coding on your part and allows you to quickly bring higher-quality, feature-rich apps to market. An app can leverage the features of other apps to handle various types of requests. One common example is using a browser to handle user requests to hyperlinked text displayed in your app. Another example is launching a third-party social networking app to authenticate your user. Although on the surface these integration points appear similar-- the reality is that they can be very different. The difference lies in the mechanism used to invoke the external app.

In the first scenario, when a user clicks on a hyperlink, the action will automatically invoke an intent, which is sent to the Android system to process. The intent, which encapsulates an operation to be performed and contains the necessary data to send to the operation, acts as the glue between two or more loosely coupled Android apps. The Android system matches the intent to one or more activities, services, or receivers that have registered with the system. In the case of a hyperlink, typically the default browser activity will handle the intent. However, if more than one intent handler is able to process the operation (such as when a user clicks on an e-mail address), the system offers the user the option to select the intent handler they are interested in using. In the example below, an e-mail handler and the copy-paste handler are invoked after a user clicks on an e-mail address within a browser.

The important thing about the first scenario is that your app does not concern itself with who handles the intent, and no data is shared between the two. Your app will defer to the user to make the appropriate selection.

In the second scenario, you will have a more tightly coupled dependency on the authentication service provided by the third-party social networking app. This means that you do not want just any social networking app to authenticate your user. Instead, you are looking for a particular app, and if that app does not exist, you will respond accordingly.

However, before this dependency can be created, your app will need to be able to share data with the service provider. This is done by signing your app and obtaining the appropriate security key(s) from the third party to access its API. Depending on the requirements of the service provider, you can then either bundle its library with your app or require that the third party’s app be installed on the device.

At runtime, if you cannot resolve the dependency to the third-party app (i.e. it’s not installed), then you will want to provide the user an opportunity to install the app. This can be done by launching an intent from your app to an Amazon Appstore URL:

The above example links the intent to the Amazon MP3 app. To link to a different app, you can simply take the package name (“com.amazon.mp3”) and replace it with the one for the app you are depending on. The Amazon Appstore mobile client will be configured to handle URL intents of the following pattern:

http://www.amazon.com/gp/mas/dl/android?p=<packagename>

The invocation of the intent will then provide the user the option to view the app page through the Amazon Appstore mobile client.

From there, the user can take advantage of Amazon’s 1-Click purchase feature to download the app (paid or free). After the user installs the third-party app, they can go back to your app’s activity and continue from there.

The following list includes some other helpful links you can use to make requests to the Amazon Appstore:

To search the Appstore:

http://www.amazon.com/gp/mas/dl/android?s=<searchtext>

To show all apps by the developer of the app corresponding to the specified package name: