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.

If you own a Kindle, you’ve experienced the power of having a Digital Locker and the ability to download your purchased content to just about any device. The notion of “buy once, read anywhere” will now also apply to your Android apps purchased through the Amazon Appstore. 

Customers who purchase an app will retain an entitlement to their app even if they decide to replace their current Android device and/or purchase new devices, as long as the new devices meet the installation requirements of the app. This provides insurance to customers that their purchased apps will be available for use on all supported devices, even if the customer has uninstalled or otherwise removed those apps in the past.

The digital locker service combined with a robust Digital Rights Management (DRM) solution not only make managing apps easier for customers, they also address one of the biggest concerns developers have:  unauthorized copying and distribution. An authorized user can now install your app on any of their supported devices; however, if you chose to apply DRM on your app at submission time, your app will not run on unauthorized devices.

Any app that has Amazon DRM applied to it will require users to have installed and signed-in to the Amazon Appstore client to access the app. When an app is accessed by the user, it will verify with the Amazon Appstore device service as to whether the user has an entitlement to the app. If the user does not sign in or does not have an entitlement to that app, then the app will not be usable. However, any user can gain an entitlement by purchasing the app through Amazon.

We will be posting more updates on Amazon DRM over the next few weeks on the Amazon Appstore Developer Blog.  We will cover additional topics, such as sharing data between apps and signing your app after Amazon DRM has been applied.

Update:  In response to your questions, we’d like to take this opportunity to provide a few clarifications.

Do I have to use Amazon DRM if I sell my app through Amazon.com?

No, it is not required. When you submit your app you can choose to offer your app DRM free or you can apply Amazon DRM.

Do customers need to have internet access to use an Amazon DRM-enabled app?

No. Once an app is installed, a user can use the app without having internet access.

How can you verify that the user has an entitlement to the app without internet access?

During the installation process for an app, the Amazon Appstore client downloads a small token that grants the user the right to access the application. A valid token permits the user that purchased the app to access their app offline. The Amazon Appstore client will periodically communicate with Amazon servers to refresh the token.

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

Since the official launch of the Amazon Developer Portal, we have received tons of positive feedback regarding the developer registration and app submission process.  However, with the large volume of activity, it’s not surprising that developers have a few questions that are not directly answered in our FAQ.  We’ll take this opportunity to answer some of those questions:

Are you required to submit a video along with other multimedia content, such as icons and screenshots?

Although compelling videos can be helpful to customers when they are deciding on which app to buy, they are not required. 

The only multimedia files that are required are:

• Device icon (114x114px)
• Large icon (512x512px)
• A minimum of three screenshots (480x854px or 854x480px each)

The maximum size for each image is 3Mb.  More information about multimedia files can be found here. If you have submitted your app and see the status “Incomplete (Missing Multimedia)”, then it is likely that you did not submit one or more of the required images.  If you believe you have submitted all multimedia files and are still seeing this status, we encourage you to contact our support team.

What is the maximum video size that you can upload for an app? 

The maximum size for a video is 30Mb.  There is a 3Mb limit for video files submitted through the Developer Portal’s web console.  If you want to submit a video that is greater than 3Mb (but under 30Mb), please use your FTP account.  The process to create an FTP account and submit your app video is described here. 

What video formats do you support?  Your FAQ says MP4 H.264- so does this mean you don’t accept any other format?

We require your videos to be stored in an MP4 H.264 encoded format.  This is to ensure an optimal visual and performance experience for your customers.  Remember that these videos will not only be viewed on Amazon’s retail website, but also on mobile devices.  If you upload videos that do not meet the requirements outlined in our FAQ, there may be a delay in your submission review, or your video may not be included on your final detail page.

If you have any additional questions as you go through the Amazon Appstore submission process, please do not hesitate to contact our support team.

While designing and building your apps, you may encounter the question:  Should I create multiple versions of my apk for different devices?  In most instances, the answer should be an emphatic no!  Unnecessarily offering multiple copies of your apk to your customers will not only make your development process more complex and painful, it may also create confusion for your users.  A well-designed app that follows the best practices guidelines will be deployable and usable on almost all Android devices.

Some common scenarios when developers think they need to create multiple apks, but really don’t, include supporting:

• Different Android SDKs and OS versions
• Different  hardware features (GPS vs. non-GPS)
• Various screen resolutions and densities (high definition vs. standard definition)

If you are concerned about your app being installed on an unsupported environment, follow the best practices guide for Android development to avoid such issues.

After appropriately defining settings in your Android manifest file, you will want to design your app to make the necessary runtime decisions at the lowest levels in your code.  For instance, you may want to implement conditional user interface logic at the latest point possible, such as altering display and layouts based on device screen and density settings.  This is an ideal way to not only lower the total lines of code you write, but it may also reduce the number of bugs in your app and reduce the size of your apk.

There are, however, a handful of situations that justify creating multiple apks.  These include:

• Pricing differences for certain devices
• Large resources, such as images and videos, make your apk too big

If you are offering your app for a different price to customers on a smartphone versus a tablet, then submitting a separate apk for each form factor makes sense.  Furthermore, if the apk file size difference is significant and you want to avoid users of your SD version unnecessarily downloading MBs of HD images, then a separate apk may be appropriate. You should consider making this decision when your apk grows larger than 8 MBs.  Under these circumstances, and others that we did not cover, you will need to submit each apk individually to the Amazon Appstore as separate apps. 

In conclusion, unless your reason for creating multiple versions is well-justified, we recommend that you submit only one apk per app version. 

Since Android’s first release in September 2008, the number of Android users and supported devices has steadily increased.  A recent comScore report shows that there are now nearly 16 million users in the US owning Android smartphones, surpassing the total number of iPhone owners. Late last year, Canalys reported that Android claims a quarter of the smartphone market segment share.  Their recent report says that Android’s growth in 2011 will be twice the rate of their major competitors, including Apple’s iOS-based devices.  There is a growing market segment here that presents a great opportunity to developers including those in the Android space, and those who have only developed for iPhone and iPad.  For iOS developers, porting apps to Android presents a rare opportunity to tap into this market segment and a fast growing user base. 

If you are considering taking advantage of this opportunity, here are key topics to be aware of when porting your apps from iOS to Android.

Differences between iOS and Android programming

Apps for iOS are written in Objective-C, an object-oriented descendent of the C programming language.  Android apps are written in Java, a very popular programming language invented by Sun in 1994, traditionally used for building server-side applications over the past 15 years.

In addition to the differences in language, syntax and semantics, there is also a key runtime difference that affects how your code is written.  Java has automatic garbage collection, which means that you do not have to explicitly free objects after they are used.  Objective-C requires developers to manage memory explicitly.

Integrated Development Environment (IDE) options and SDK platform support

You have more options when it comes to selecting an IDE and platform when writing code for Android. While building Java-based apps, you can write and compile your code on all major operating systems, including Linux, Windows, and Mac OS X.  Furthermore, the Android SDK integrates with most major IDEs, such as Eclipse and Intellij, which means you can run an Android emulator and test your application on either of these IDEs and operating systems.  The iOS SDK, which includes XCode IDE, runs only on Apple-based operating systems.

Apple is the only provider of iOS devices, while many vendors offer devices supporting Android

As we discussed in a previous post, Android has many vendors, which means Android devices have varying capabilities and features.  iOS devices are only manufactured by Apple and are currently limited to iPhone, iPad and iPod touch.  For developers who are accustomed to building apps for a small set of devices, building apps for Android presents a completely new challenge.

Ultimately, iOS developers with a good understanding of these fundamental differences will be able to assimilate well in developing apps for Android.  In fact, the developer who was previously constrained by the platform limitations of iOS devices may now find the flexibility of having IDE options, SDK platform support and the nuances of the Java language to be refreshing and energizing.

Whether you have a bug fix, enhancement or performance optimization that you want to deliver to your customers, one of your Android apps will inevitably require an upgrade.  This can be either a seamless process or a painful one for your customers.  To ensure that it is the former and not the latter, the Android SDK provides some simple guidelines to help you manage this process.  Last week, we discussed some useful configuration settings offered through AndroidManifest.xml for designing apps to run on smartphones and tablets.  This same configuration file also provides settings to version your apk.

There are two attributes you can specify to manage the versioning process of your app:

• android:versionName
• android:versionCode

The versionName attribute is a user facing string that identifies the version of the application in use.  For example, if you are upgrading for the first time, your previous versionName may be “1.0” while a minor upgrade version would be indicated by “1.1” and a major upgrade by “2.0”.  The versionName attribute is primarily used for display purposes and helps users identify differences between app versions.  The following is a snippet of the manifest from the Amazon MP3 App for Android:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.amazon.mp3"
      android:versionCode="80029"
      android:versionName="1.8.29">

        ...
</manifest>

The versionCode is the attribute that is used by the Amazon Appstore for Android to compare versions of your app.  This is an integer, like 80029 in the sample manifest, not a string like the versionName.  If the versionCode of an apk is greater than the versionCode of another apk, then it is considered to be newer.  Of course, for this comparison to be valid, the apk package name and signature must also match.  To avoid unexpected behavior, it is extremely important to keep track of your versionCode and to always increase the value whenever you are releasing a new version. 

At last week’s CES, it was hard to ignore the fact that many technology pundits are considering 2011 as the year of the tablet.  And although Apple should be thanked for resurrecting interest in tablets in 2010, 2011 will see a record breaking surge in the number of vendors bringing new tablets to market.  Sean Dubravac, Chief Economist and Director of Research, Consumer Electronics Association,  predicted, “While many firms are touting product launches within the tablet sphere for the fourth quarter of 2010, the real action will occur a few weeks after the end of the quarter at CES.”  The next few weeks will be telling for the future of the tablet and so far it’s looking quite bright. 

The good news for you, the Android developer, is that many of these tablets will be sporting Android OS and, with the recent announcement of the Amazon Appstore Developer Portal, you have a convenient way of offering your apps to both tablet and smartphone users.  We’re not mandating that you optimize your apps for tablets as well as smartphones, but it’s definitely something you should consider. 

The expected surge in the number of tablets on the market and the number of Android devices a single user will own brings forth new opportunities and challenges.  The opportunities are clear—more devices mean more users, more hardware features and more APIs to take advantage of.   These new tablets will continue to feature larger screens and supported resolution levels, ample amounts of disk space and extremely fast processer speeds that are not far behind that of a typical laptop. An important thing to remember as a developer is that customers may be using your app across tablets and smartphones – no longer just one or the other. 

 A quick comparison of the best selling smartphones and tablets on Amazon.com shows that tablets boast 50-100% more screen real-estate and 50% more disk space.  Furthermore, many of the tablets demonstrated at CES also feature dual-core CPUs.  These differences make it more important than ever for developers to be aware of the device capabilities and limitations.  With Amazon.com’s convenient 1-Click purchase and digital locker features, customers will be able to buy your apps and run it on any of their Android devices.  Unfortunately, the growth in devices will present one of the biggest challenges for you—you want to continue to build and extend your killer apps and offer it to the tens of millions of Amazon.com customers, but you also want to keep your customers happy by setting expectations on how and where the apps can be run.   

The Android SDK requires that each application contain a file called AndroidManifest.xml within the apk.  This is where you can let the system know what your app needs at a minimum to run and what resources and services it will use.  For instance, if you are building a word processor app that is designed to only run on a tablet, you will want to set the android:largeScreens attribute to “true” on the <supports-screens> property, while explicitly setting the small and normal screen flags to false.  If you don’t declare this requirement for your app, then the Android system will assume it works on all screen sizes.   

On the other hand, if you are building a game that looks great on any phone or tablet, then you can declare this in the xml file by including the following settings:

<supports-screens
        android:smallScreens="true"
        android:normalScreens="true"
        android:largeScreens="true"
        android:xlargeScreens="true" />

One thing to be aware of, however, is that once you declare support for all screen sizes, you will want to check the DisplayMetrics settings at runtime to make important display decisions in your code.  This information can be used to make performance optimizations, such as displaying low to medium resolution images on small devices and high resolution images on large screens—a great way to avoid creating multiple versions of your app.

Apps that depend on hardware resources, such as GPS, Wi-Fi or Bluetooth capabilities, can define these requirements by appropriately setting the <uses-features> option. 

Furthermore, with last month’s announcement of the Gingerbread release, there are now 6 flavors of Android OS in use.  If the trend over the past two years continues, you can expect one more major release (3.0, Honeycomb) and another minor release to be announced before 2012. With major features being added in every new platform version, such as improved copy-and-paste and faster text input processing in Gingerbread, you will want to take advantage of these capabilities and also ensure your apps only run under their supported environment.  The manifest provides a way to enforce dependencies on specific SDK features by using the <uses-sdk> flag.

Customer satisfaction is a key driver behind Amazon.com’s success.  As you develop and offer your application to Amazon.com’s customers, following these Android development best practices guidelines is a great start towards achieving similar success.