With the rise in popularity of bar code-reader apps, QR Codes have become a convenient way of transferring text from media to mobile devices. A report published recently by MGH indicates that a growing number smartphone owners use the two-dimensional images to gain access to products and promotions.

A QR Code is a square, black and white image that contains standardized patterns to store text, in the same way that bar codes contain patterns for alphanumeric characters. The amount of encoded text can vary depending on the size of the QR Code image, but typically the text encoded is relatively short and takes the form of a URL. You may have seen the following options on our Get Started page to quickly give you access to the Amazon Appstore on your Android device:

As mentioned in a previous post, you can link directly to apps in the Amazon Appstore with a mobile-friendly URL. The URL can be represented as a QR Code, which can then direct potential customers on your website or blog to your app on the Amazon Appstore mobile client. For instance, the following link and corresponding QR Code will send users to the detail page for the Amazon MP3 App for Android:

http://www.amazon.com/gp/mas/dl/android?p=com.amazon.mp3 

The following URL will invoke a search to find MP3 related apps on the Appstore:

http://www.amazon.com/gp/mas/dl/android?s=mp3

Any QR Code generator that meets the ISO requirements will suffice. Some websites that can do this for you include Delivr, bit.ly, the URL shortening site, and Google.

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:

String url = "http://www.amazon.com/gp/mas/dl/android?p=com.amazon.mp3";
Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse(url));
startActivity(intent);

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: 
  
  http://www.amazon.com/gp/mas/dl/android?p=<packagename>&showAll=1