Appstore Blogs

Appstore Blogs

Want the latest?

appstore topics

Recent Posts

Archive

Showing posts tagged with How To

March 11, 2014

Mike Hines

If you are a developer who has had an app in our store for a while, or someone new to our platform, we encourage you to use Amazon Appstore and Kindle Fire badges and branding to help promote your app.  In this article we’ll review badges, other images, links and guidelines for their use with your app and marketing.

Badges:

There are two badges with three color-treatments each that you can use. Here are the badges that you can use to promote the availability of your app in our U.S. store:


The Amazon and Kindle Fire badges above are available in English, Spanish, German, French, Italian and Japanese. The Amazon badges are also available in Portuguese.

You can get full-size downloads of these badges on this page, along with some usage guidance.

Other Images

If you’d like to use a plain icon:

Or if you would like to use a Kindle device image:

You can find links to those resources about half way down this page.

Links to the Amazon Appstore

For web-browser based linking, please:

Use this link structure: http://www.amazon.com/gp/product/ASINnumber/ref=mas_pm_app_name

Replace the bold “.com” with your country marketplace suffix. (.com for US, .de for Germany, etc)

Replace the bold “ASINnumber” with your mobile app’s ASIN (Amazon Standard Item Number) and app name. Please use an underscore (_) to separate the words in the “app_name” portion, if your title is more than one word. You can find the ASIN on the Product Details section of your mobile app on www.amazon.com/apps.

For example, this is the Air Patriots link in the German marketplace:

http://www.amazon.de/gp/product/B008KE3960/ref=mas_pm_air_patriots

For in-app advertising or mobile app-based linking:

In the US:

Use this link structure: http://www.amazon.com/gp/mas/dl/android?p=com.example.package&ref=mas_pm_app_name

Replace the bold portions with the package name of your APK, and app name respectively.

For our international stores:

Use this link structure:

amzn://android?p=com.example.package

Replace the bold portion with the package name of your APK.

NOTE: With any of these link structures, please test the links before using them to make sure that they direct to the correct page or search results.

The link instructions above are pretty much identical to the guidance near the bottom of this page.

Other Useful Guidelines

There is still more good stuff on the handy page I keep linking to. This includes guidelines for correct use of the Amazon Appstore trademark when blogging or using social media to promote your app. I would, of course, be remiss if I failed to mention the legal requirements listed at the bottom of the page. Our attorneys have done a good job of breaking the important points down into easily readable bullet points. Please do look at them, it won’t take long.

Just in case you missed the link earlier, you can read all of this information here, on our developer portal.

 

February 14, 2014

David Isbitski

When displaying ads in your apps and games, you may want to know how often you are actually displaying ads to your users, what types of ads are being displayed, and how your users are interacting with an ad. 

Thankfully, the Amazon Mobile Ads API includes events that can aid you in understanding performance of ads displayed on your apps.  You have the ability to track when an ad is successfully displayed from the Amazon Ad Network, how long a user views an ad, and when your user opens or closes a rich media expandable banner ad.  These events should help you track and better understand user behavior in your apps when ads are being shown.

With a guaranteed CPM of $1.50 for banner ads displayed on qualified apps during March and April (up to 2 million impressions per app per month), there has never been a better time to get started using the Amazon Mobile Ads API.

Handling Ad Events

All of the events associated with an ad provided by the Amazon Mobile Ads API will be returned by the AdListener interface.  Once you have declared an instance of an Amazon AdLayout, setting an event listener to the layout will let you track the entire life cycle of an ad. 

Keep in mind all of the listener's events are part of the main UI thread.  So if you are planning on executing any long running tasks you should do so in an AsyncTask.

Capturing Metrics When Ads are Loaded

You can capture metrics in your app each time an ad is loaded using the AdLoaded event.  AdLoaded is called each time an ad is successfully served by the Amazon Mobile Ad Network, and available for display.  You can use this event to adjust your app’s user interface when a new ad is loaded or to keep track of the type of ads you are being served. 

For example, if you have a game, you should choose to delay displaying the AdView until the player is at a point where an ad will not interrupt gameplay.  In the below example I am updating a TextView each time an ad is successfully loaded and then adding the AdView to the root container for display.

You can get additional properties about the ad being served at runtime through AdProperties.  These properties can help determine if your ad is a static banner or a rich media expandable banner.  Static banners are HTML web views that typically open an in-app browser, native browser, or Android Intent.  Rich Media Expandable Banners are HTML web views that expand in-app with rich interactive content (including videos), but also typically include opening an in-app browser, native browser, or Android Intent.

 

In the above screenshot, I have set a breakpoint to get information from the AdProperties variable.  There are four types of information that are filled by AdProperties.  These include:

  • adType - possible values are 'Image Banner', 'MRAID 1.0' or 'MRAID 2.0'.  MRAID stands for Mobile Richmedia Ad Interface Definition and will determine the capability of the rich media expandable banner.
  • canExpand – determines if the ad can be expanded
  • canPlayAudio – determines if the ad plays audio when expanded
  • canPlayVideo – determines if the ad plays video when expanded

Trigger changes when an ad expands

The onAdExpanded and onAdCollapsed events are called when a rich media expandable banner ad has been clicked by a user and is either expanded or collapsed.  You can use this event to pause your game or suspend background audio music when an ad has expanded, among other options.

 

Handling Ad Load Errors

If an ad fails to load, the AdListener.onAdFailedToLoad event returns an AdError object that contains an error code and a descriptive response message.  For example, the onAdFailedToLoad event below is logging the ad error message, removing the Amazon view from the UI, and then loading a Google AdMob view to request an ad.

 

It is important to keep in mind that the there is no logic to retry loading an ad.  If you encounter an error, you should decide whether to call AdLayout.loadAd again based on the error code returned. 

The error codes are helpful in debugging where errors may be occurring; server side, network based, or within the app code itself.  In the below example we see an AdError occurring due to the developer setting an incorrect view size.  This can happen if an ad is requested before its parent view is available. 

 

The possible error codes that can be returned include the following.

  • NETWORK_ERROR The ad request failed due to problems with network connectivity. Try again when a connection becomes available.
  • NO_FILL The ad request succeeded but no ads were available. Don’t retry immediately.
  • INTERNAL_ERROR The ad request failed due to a server-side error. Try again but limit the number of retry attempts.
  • REQUEST_ERROR There is a problem with the ad request parameters. Do not retry. Review the error message and update your app accordingly.

For specific error message descriptions, please refer to the following chart on our developer portal here.

You can get more information on the Amazon Mobile Ads API including code samples and training videos here.

-Dave (@TheDaveDev)

 

February 13, 2014

Jesse Freeman

The Current HTML5 Landscape

In a world quickly moving toward mobile device adoption, there is a growing pressure for web developers to learn new languages in order to adapt to the ever-changing landscape of content delivery. For the past 16+ years, web has been the king of mass distribution. But now as app stores on mobile devices are driving huge monetization opportunities, how do web developers stay competitive in this new “post PC world”? The key is to understand how you can maximize your web app’s potential in the distribution vs. monetization model.

The Distribution Vs. Monetization Model

As developers look to create new content, be it a web app or native app, they should be thinking about the following model:

 

The distribution vs monetization model.

 

The concept is that the larger your distribution base, the better your chances of monetization are. Along the far side of the x-axis is the native mobile and tablet space, which is fragmented around several different platforms, and the individual platform distribution potential is much smaller. On the flip side, since all mobile devices and computers have web browsers, an online web app’s potential reach is staggering.

The reality of this however has been that even with the smaller distribution of mobile, developers are seeing much higher opportunities to monetize on those devices. On the web, we have seen more difficulty to monetize that content without the help of built-in systems like IAP (in app purchase) or integrated checkout, which are generally available on native devices through their app stores. The ideal solution would be to actually target both demographics, and the only platform we have seen that is capable of effectively doing that is HTML5.

Scaling Your Web App

When most developers hear “scaling a web app” they instinctually think about the backend or server side of things. But over the past year as responsive design has come into its own, we are finally seeing websites that can not only run on desktop browsers but elegantly reconfigure themselves to accommodate all the different viewports users are visiting with.

The most common responsive design resolution breakpoints.

The forethought that goes into building a truly responsive design that flows correctly from desktop to mobile phones is no small task but the opportunity for capturing the largest possible distribution is worth it. Gone are the days of splitting off your web traffic between a mobile only site and a desktop site because the cost of maintaining both grow exponentially. But what about still reaching native app stores?

But What About Still Reaching Native App Stores?

Some of the current solutions on the market for publishing HTML5 content next to native apps have revolved around the PhoneGap/Cordova model. These allow the developer to package the web app and submit it to a native app store. But there is one glaring downside to this kind of distribution; you lose the ability to maintain a single codebase. In an ideal world, you would want to simply redistribute your online app in a mobile store and keep the two in sync. This is some of the thinking behind our HTML5 web app resources for Amazon Appstore.

Own Your Content and Keep it Online

The last thing a developer would want to do is fork a project and end up maintaining multiple code bases to support each platform it is distributed on. So why not just keep your content online where it will get the largest potential for distribution and still submit it to an app store that offers you an entirely new way to monetize it? This is a fairly new publishing model that has been growing more and more popular over the past few years. It offers the best of both worlds since you maintain a single place were your web content can live and you gain the added benefit of being able to distribute your app in a native store. With that distribution comes the potential of increased monetization by simply charging for the app, using IAP or continuing with your current ad based model.

The best part is that you can experiment with this new type of distribution today in the Amazon Appstore with our HTML5 Web App Tester. Simply download the app, point it to your site’s URL and test out how your web app works. From there it’s easy to submit to the Amazon Appstore and begin reaching a whole new audience.

 

February 11, 2014

Mike Hines

There is still plenty of room for more great mobile apps. That is, if you’re thorough and obsessed with quality. Recently, I was reminded of the importance of doing a solid job of testing all aspects of an app when reviewing geography bee apps.  

For the last two years, my son has competed in his middle school geography bee, and rather than suggest that he spend his time buried in an atlas, I suggested a handful of apps designed to help students prepare for geography bees. Of the apps that we found, not one app was rated 5-star by customers.

The shortcomings of these apps generally fell into one of three categories:

  • The app was different than described
  • Poor UI/workflow impeded use
  • Deal-Breaker Bugs

Description should match the apps

Sometimes an app might be useful but just doesn’t deliver what a customer expected based on the description. Imagine an app that purports to be a Geography Bee study app, yet quizzes for dates of events and asks for definitions of sedimentary rocks. Some of the apps we tried were like this, being better suited to geology or history quizzes than to a geography bee.

What can you do?

Make sure the product title and app description accurately reflects what the app actually does. The apps that I was disappointed in were not bad apps, just a bad fit for my needs.

Streamlined User Experience

Sometimes an app had solid content, but the navigation was too confusing or it took too many steps. I’m in the business of apps, so I’ll give any app a thorough review. But many users won’t bother to enter their name and age every single time the app launches. And if a customer loses their user state in the middle of a series of questions, you can bet they’ll be frustrated. 

What can you do?

Think more like a user. For example, when a student uses a geography bee app, more than likely they’ll be interrupted. The app not only needs to go from start to finish cleanly, but it also needs to tolerate interruptions, be fast to re-enter, and avoid re-doing completed work. Have someone else try the app and see what he or she tries to do. If they seem frustrated, then it’s probably worth considering whether the experience needs to be re-designed in some way.

Squash the Bugs

Strangely enough, some bugs were easier to live with than problems with UX or failure to deliver on value. Bugs, like truncated buttons, pixelated graphics or having to tap twice on an answer, might cost a star in the rating, but they still leave the app usable. Other bugs, like text entry boxes hidden under keyboards, were considerably more problematic. The app whose UX I liked the best contained outstanding educational content, but it didn’t get much use because it kept crashing on both iOS and Android tablets.

What can you do?

Be maniacal about your QA. If your resources are constrained, there are solid testing services out there. The services have apps that they can refer you to, so you can get a sense of how well the testing works. Check out the referral apps, and if the quality seems top notch, consider using them to help with your QA. This attention to detail can go a long way to help you get the app rating you’re looking for.

 

February 10, 2014

David Isbitski

Setting up your Kindle Fire device for testing and debugging is a simplified process thanks to Android Debug Bridge (ADB) support.  Since questions around ADB driver support have come up on Stack Overflow and our developer forums I thought it would be beneficial to walk through the setup process. 

Certain development tools referenced in this post are provided by third parties, not by Amazon. Any links to these tools will take you to third-party sites to download and install them.

Getting Started

Note – this post was updated on April 16th, 2014 to reflect changes in the Amazon Android SDK addon.

First, ensure your development computer has at least one package of Kindle Fire system images installed. This is critical because the package includes the vendor identification needed for ADB to recognize any of the physical Kindle Fire tablets.  This is done through the following steps:

  • Ensure you have the Android SDK already installed
  • Launch the Android SDK Manager
  • Under Tools, select Manage Add-On Sites, and enter the following url: http://kindle-sdk.s3.amazonaws.com/addon.xml

  • Select Close and wait for the list of available packages to refresh
  • Select Kindle Fire USB Driver, Kindle Fire Device Definitions, and optionally the Amazon AVD Launcher.

  • Select at least one Kindle Fire image so that vendor information is available for ADB.  I’ve chosen to select the three Kindle Fire 3rd Generation images (API Level 17).

  • Accept the license agreements and install.

For complete information about setting up your development computer and installing the SDK packages, see Setting Up Your Development Environment.

Uninstalling existing Windows drivers

If you installed a previous version of the Kindle Fire USB driver then take the following steps to remove the previous USB device driver and force re-installation of the driver.

  • Connect your Kindle Fire tablet to the USB port on your development computer.
  • On the development computer, from the Start menu, right-click Computer, and then click Manage.
  • In the left pane, under Computer Management, expand System Tools, and then click Device Manager.
  • In the right pane, expand Portable Devices.

  • Next, Right-click Kindle and then click Properties.
  • In the Kindle Properties window, on the Driver tab, click Uninstall, and then Confirm.

  • Finally, unplug your Kindle Fire tablet from your computer.

Enabling ADB on the Kindle Fire

Next, we need to turn on ADB support on our actual Kindle Fire device.  Follow these steps:

  • On your Kindle Fire tablet, go to Settings.
  • On a third-generation Kindle Fire tablet, tap Device.  On a second-generation Kindle Fire tablet, tap Security.  First-generation Kindle Fires already have ADB enabled by default so no action is needed.
  • Set Enable ADB to On, and then accept the pop-up warning message.       

As a security precaution, you should set Enable ADB to Off when you are not trying to connect to the Kindle Fire tablet to your development computer.

Installing Windows ADB drivers

First, ensure you have enabled ADB on the Kindle first as described above.  For the USB driver to install correctly, Windows must recognize the device as Android Composite ADB Interface during installation. If ADB is not enabled, Windows instead recognizes the device as Portable Devices.

Do the following to install the Kindle Fire USB driver:

  1. In your Android SDK directory, at \extras\amazon\kindle_fire_usb_driver, run KindleDrivers.exe, and then follow the instructions on the screen.

  1. Connect your Kindle Fire tablet to a USB port on your development computer.
  2. From Start, click Control Panel, and then select Device Manager.
  3. In Device Manager, under Kindle Fire, verify that the device appears as Android Composite ADB Interface.

Next, do the following to detect your Kindle Fire tablet through ADB:

  1. Open a command prompt window.
  2. Change directory to your Android SDK platform-tools directory.
  3. Run the following commands and confirm that the serial number for your Kindle Fire tablet appears in the list of devices.

adb kill-server

adb start-server

adb devices

If the serial number does not appear after running adb devices, do the following:

  1. Change directory to your Android SDK tools directory.
  2. Run the following command:

android update adb

  1. Change directory back to your Android SDK platform-tools directory.
  2. Run the following commands:

adb kill-server

adb start-server

adb devices

If your Kindle Fire device still does not show up you may need to reboot your development machine and then try again.

Installing Mac OSX ADB drivers

Perform the following steps if your development computer runs OS X:

  1. Connect your Kindle Fire tablet to a USB port on your development computer.
  2. Open a terminal shell and navigate to your Android SDK tools directory.
  3. Run the following command to update ADB.

./android update adb

4. In the terminal shell, navigate to your Android SDK platform-tools directory.

5. Run the following commands and confirm that the serial number for your Kindle Fire tablet appears in the list of devices.

               

If your Kindle Fire device does not show up in the list of devices you may need to reboot your development machine and then try again.

You should now be able to fully test with your Kindle Fire device over the Android Debug Bridge.  For additional information on enabling ADB for Kindle Fire Devices, see Setting Up Your Kindle Fire Tablet for Testing.

-Dave (@TheDaveDev)

 

January 30, 2014

Russell Beattie

Creating an application using Amazon's Mobile App Distribution Program is a great way for developers who have hosted web apps to create downloadable apps available on the Amazon Appstore. Web app developers benefit from the increased discoverability that the store provides when users are searching for new apps, as well as being reminded to use the web app by the icon on their device's home screen afterwards. In addition, all of a user’s linked devices that use the Amazon Appstore will have the icon waiting in their Cloud list of apps as well.

And because web apps are hosted online, developers have increased flexibility to re-use existing assets and make changes or fixes to the app quickly and easily, without having to re-create a new app that has to be re-installed by the end user. But what happens if the user wants to use the app offline? Obviously, if the app relies on live server-side content - such as streaming videos or airline reservations - then obviously it's not going to work. But if the web app is self-contained and doesn't need to talk to a server for its core functionality - like most games - then being able to take the app offline is something that should be an option for users.

Happily, enabling your web app to be used offline can be done using HTML5's built-in Application Cache with only a few small changes to your code. Below I'll outline the steps you need to take to create a basic offline web app. It's surprisingly easy to set up, but beware! Application Cache has a well deserved reputation for being difficult for developers to get a handle on.

Offline Web App Walkthrough

1. Create Manifest File

The first thing you need to do is create an HTML5 manifest text file with a list of every asset file your web app requires - HTML, JavaScript, CSS, images, icons, fonts, etc. The manifest file can have any name you choose, but we'll use app.appcache to be clear and to avoid overlap with other types of manifest files.

Here's the content of a basic manifest file:

CACHE MANIFEST 
# Version 1.0 
CACHE: 
main.js 
main.css 
logo.png 
NETWORK: 
*

- The first line needs to be CACHE MANIFEST.

- The second line in this example is just a comment, but is useful to make changes to your web app by simply incrementing the version number. Note: Only changes to the manifest file will invalidate the cache.

- The third line begins the CACHE: section where you list out the asset files used by your web app, either relative to the location of the manifest file, an absolute path or complete URL. Note: DO NOT list app.appcache in your manifest.

- The NETWORK: section has a wildcard which permits the browser to download files that are not listed in the CACHE: section. Note: Without the NETWORK: section, the browser will ONLY re-request files listed in the CACHE: section after the initial page load.

2. Confirm Server Settings

You need to also make sure your web server serves the correct MIME type for the manifest file. For Apache, it looks like this:

AddType text/cache-manifest .appcache

You also need to makes sure the manifest file is not being cached on the server. If the HTTP Cache-Control header for the manifest file doesn't update, or a 304 Not Modified is return, then the web engine won't be able to see if the manifest file has been changed or not, which is the only way to invalidate the offline cache.

3. Add Manifest Attribute

You then need to add an attribute to the tag of every HTML page you serve pointing at the manifest file, like this:

<html manifest="app.appcache">

4. Add Update Script

Finally, you need to make sure your app updates itself if the manifest changes - the easiest way to do this is to add this bit of JavaScript to your main HTML:

<script>
window.applicationCache.addEventListener('updateready', function(e){
    window.location.reload();
});
</script>

5. Test

Your web app should now be offline enabled! If you have Python installed, you can test this by setting up a local server to see what's happening both on the server and in the browser.

beattier@amazon.com:~/html5demos/offline$ python -m SimpleHTTPServer

Serving HTTP on 0.0.0.0 port 8000 ...

1.0.0.127 - - [21/Jan/2014 13:42:52] "GET / HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /app.appcache HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /main.css HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /main.js HTTP/1.1" 200 -
1.0.0.127 - - [21/Jan/2014 13:42:52] "GET /logo.png HTTP/1.1" 200 -

... 

If you request the page again, you'll see that *only* the manifest is requested.

1.0.0.127 - - [21/Jan/2014 13:43:12] "GET /app.appcache HTTP/1.1" 304 -

By modifying the manifest file and reloading, you'll see that all the files listed will be re-downloaded again.

You can also connect the Amazon Web App Tester to see the client side of the process as well by using Remote Debugging. (See our previous overview of setting up the Tester here.) In the screenshot above, I've connected to a Kindle Fire HDX and loaded a demo offline web app stored on Github. By looking at the Resources tab and drilling down into the Application Cache folder, I can see the assets that are cached locally, and a log of the Application Cache events.

Application Cache Gotchas

This is just a basic way to setup an offline web app. There are more options that you can add to your manifest file, more events you can track in JavaScript and more functionality you can use to make your web app's offline experience much more seamless to the end user. Check out the links below for more information.

Conceptually, it's important to understand that once you've enabled a manifest, your web app is now offline first and forever. Let's repeat that for clarity: OFFLINE FIRST AND FOREVER.

OFFLINE FIRST means:

- Your web app's files will then always be loaded from the offline cache first, and then a request will be made to the server for the manifest file to see if there have been any updates.

- The browser will not automatically refresh if the manifest has changed. It will in fact download the files from the server, but it will wait until the next time the page is requested to use them. This is why the script in step 4 above to detect a manifest change and immediately refresh the page is important.

FOREVER means:

- The only thing that can invalidate the offline cache and trigger a re-download of files is a change in the contents of the manifest file - not just the timestamp.

- There is no programmatic way to invalidate the offline cache from the browser. Even changing or deleting the manifest attribute in the tag will not invalidate the cache.

- Until the browser requests a manifest and receives a 404 or 410 from the server, it will continue to consider the web app as being offline and use the last downloaded version, rather than updating from the server.

Summary and External Resources

The info above should be able to get you started with offline web apps. Once you've added in the manifest, your web app will be available offline the next time your users load up your app. Fair warning: This can be a tricky feature to implement - especially if you misconfigure or forget some of the steps above. Getting the browser to let go of the manifest and refresh your code can be incredibly frustrating. I think the upside is worth it though, as enabling your web app to be used anywhere a native app can be used is incredibly satisfying.

To get more information about Application Cache, I encourage you to check out these great articles which dive into the topic in even more detail.

·         http://diveintohtml5.info/offline.html

·         http://www.html5rocks.com/en/tutorials/appcache/beginner/

·         http://www.html5rocks.com/en/mobile/workingoffthegrid/

·         http://alistapart.com/article/application-cache-is-a-douchebag

In future posts, I'll expand on offline apps by looking at topics such as offline data storage and efficient caching strategies.

-Russ (@RussB)

 

January 28, 2014

Jesse Freeman

Note: Effective 08-26-2015 Free App of the Day (FAD) has been replaced with Amazon Underground.

In August of last year we enabled HTML5 developers to publish hosted web apps next to native Android apps in the Amazon Appstore, making HTML5 web apps discoverable to millions of Amazon customers. Starting today, developers can set a list price for their web apps, giving them another way to monetize web content to Amazon Appstore customers in nearly 200 countries across the globe.

Prior to this update, web apps published to the Amazon Appstore were automatically set to free.  In the latest update developers can now set a list price in specific currencies based on the local markets they’re publishing their web apps to. This is great news for developers looking to publish their first web app to the Amazon Appstore, and the feature is now retroactive to all web apps that have already been published. That means existing developers simply need to log into their Developer Account to see an updated “Availability & Pricing” tab with the option to charge for the app.

Now with the ability to set a price for web apps in the Amazon Appstore, HTML5 developers can take part in our Free App of the Day (FAD) promotion. For developers not familiar with this program, qualifying apps gain greater exposure that could drive significant traffic to their apps. Opting into the FAD promotion and being selected enables us to work directly with the publisher to be featured in some of our most visible marketing placements. This includes placements on mobile devices, Kindle Fire, and the Amazon Gold Box Best Deals page, which are complemented by social media exposure including Facebook and Twitter announcements. These placements and the exposure they provide can drive significant traffic to the featured apps and allow the developers to grow their install base quickly. 

To learn more about qualifying for the Free App of the Day program, check out this post on how to get approved, and make sure you opt to have your web app considered for the program during the app submission process.

To republish an existing app as paid, simply edit the ‘Availability & Pricing’ tab and enter a list price, which is already defaulted to free. The same list price changes can also be made to any submission set to “IN PROGRESS” that is waiting to be approved for release.

This is just one new feature we’ve added to help make publishing HTML5 Web Apps to the Kindle Fire best in class. For more information, check out the HTML5 Web Apps detail page

-Jesse Freeman (@JesseFreeman)

 

January 23, 2014

David Isbitski

Amazon allows you to distribute your web apps and mobile-optimized HTML5 websites to millions of Amazon Appstore customers in nearly 200 countries across the globe.  With Amazon’s In-App Purchasing API for JavaScript you can increase revenue by enabling compelling monetization strategies.  This includes a "freemium" model for your app where the app itself is free but you charge a premium for advanced services or functionality.  Your web app can offer customers in app currency, subscriptions and entitlements all through the secure Amazon checkout process.

Getting Started

The first step in implementing In-App Purchasing in your web apps is to download the Amazon Mobile App SDK, then you will submit a new web app to the portal and then finally add a reference to the Amazon Web API libraries in your html. 

The latest versions of the Amazon Web API libraries are hosted by Amazon for you.  The current urls can always be found in the LATEST_URLS.txt file located in the Amazon Mobile App SDK folder.

<!DOCTYPE html>

<html>

<head>

    <title>Button Tester</title>

    <!-- Use of this sample code involves calling jQuery from Google

                 Hosted Libraries and is subject to the terms located here:

                 https://developers.google.com/speed/libraries/terms

    -->

    <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js" type="text/javascript"></script>

    <script src="https://amazon-web-app-resources.s3.amazonaws.com/v0/latest/Amazon-Web-App-API.min.js" type="text/javascript"></script>

    <script src="https://amazon-web-app-resources.s3.amazonaws.com/v0/latest/Amazon-Web-App-API-tester.min.js" type="text/javascript"></script>

    <script src="js/buttonclicker.js" type="text/javascript"></script>

    <link rel="stylesheet" href="buttons.css"/>

</head>

Once you have referenced these JavaScript files you will have everything you need to access the Amazon In-App Purchasing API from your web app.

Setting Up Your Catalog

Before you can make any In-App Purchase calls you need to have a catalog of SKUs set for your web app to use.  You can add SKUs to your web app’s catalog by opening the Developer Console, selecting Apps & Services, choosing the web app submission you want to add SKUs to and then clicking on the In-App Items link, which will take you to the list of SKUs currently offered in your web app.

There are three types of SKUs you can offer to your customers.

·         Consumables – This type of purchase is available only on the device it was purchased on.  Some consumable examples include in-game currency or an extra power up in a game.

·         Entitlements – This is content that requires access rights such as unlocking additional game levels or offering specific magazine issues.  Entitlements do not expire, are tied to a customer’s Amazon account and are available on any device they access the content from.

·         Subscriptions – These are entitlements that are bound by a period of time which auto-renews at the end of the period and is tied to the customer’s Amazon account. Subscriptions are available on any device a customer accesses the content from. You are allowed to have multiple subscriptions for purchase within your app.

 

Simply click on the type of SKU you would like to add and you will be taken to a new screen where you can provide information about the SKU.  For example, if I wanted to offer an Entitlement purchase for my World of Warcraft Realm Status app to track a single realm I would click Add an Entitlement and then enter a Title and SKU.

 

Next you will need to enter pricing information for your new SKU.  In this case, I want to sell a Track Single Realm for $1.00.  Amazon gives you the option of setting your own list price for each marketplace or it can match the prices based on your entered base price.

 

You can also enter a detailed description, along with keywords for the Entitlement.  Descriptions can be provided in multiple languages and if no translations are given the default English description will be used.

 

You also need to provide images of the item for users along with the image you want displayed upon a successful purchase.

 

Once you  have completed this, click Save, and then Submit In-App Item.  You will be taken back to our In-App Items screen with the new SKU now listed.  In the upper right corner will be a button to download a JSON Data file. 

This JSON file will include a list of our SKUs that will be used by the SDK Tester Tool when we want to simulate a purchase in our development environment.

 

The SDK Tester Tool is included in the Amazon AVD Launcher emulators or it can be installed on a device via the APK included in the Amazon Mobile App SDK under the /Android/InAppPurchasing/tools.

The Button Clicker example includes a similar JSON file that covers all of the purchasable item types.

Purchase Process Flow

The JavaScript In-App Purchasing API is designed to encapsulate the complexity behind the purchase process while providing a fully featured API. While building your app, it is important to understand which parts of the purchase flow the app must implement, and which parts are handled by the Amazon Services library.

Note: In order to protect customers, we also require that you serve the page of your app that uses In-App Purchasing over  SSL/HTTPS. For more information, please refer to the Making Your Web App Safe documentation

Below is a simplified chart explaining responsibilities during the purchase flow.

 

In-App Purchasing API for JavaScript is comprised of three elements:

  • Amazon Services JavaScript - The class/API that manages the interaction between the application and Amazon's native APIs.
  • Purchase Handlers - The object your application provides to respond to callbacks from the Amazon Services JavaScript. They are registered as an observer to the Amazon Services In-App Purchasing API.
  • Receipt Verification Service - An HTTP service you should use to validate the customer's purchase receipt.

The process workflow between your JavaScript calls and the Amazon Services JavaScript library looks something like this:

 

You can deliver static content stored locally or dynamic content that is updated over time for customers.  For more details about the Purchase Process workflow and the types of deliverable content you refer to the Understanding In-App Purchasing for JavaScript API documentation here.

Implementing and Testing Purchase Calls

Now that you understand the process flow, have referenced the proper JavaScript libraries and have created a list of SKUs (or local JSON file) it’s time to call out to the Amazon Services in your own JavaScript.

Every call you initiate via the Amazon Services JavaScript Libraries results in a response received by the corresponding response handler specified in registerObserver(). Each of these responses makes use of a response object and includes the following:

  • GetUserIdResponse - Provides the app-specific UserID for the user currently logged into the Amazon Client
  • PurchaseUpdatesResponse - Provides a paginated list of receipts and revoked SKUs since the offset passed into the initiating request. Receipts are returned in a set and are unordered.
  • ItemDataResponse - Provides item data, keyed by SKU.
  • PurchaseResponse - Provides status on purchases initiated within your app. Any error for a purchase is automatically managed for you by In-App Purchasing API.

There are also purchase handlers, similar to the In-App Purchasing API for Android that have already been implemented for you inside the Amazon Services JavaScript files.  They include the following:

  • onSdkAvailable(onAvailableResponse) - This gets called when the In-App Purchasing services are ready to be called by your code. Production applications should not grant entitlements when they are run in sandbox mode.
  • onGetUserIdResponse(userIdResponse) - Called in response to GetUserId.
  • onItemDataResponse(itemDataResponse) - Called in response to GetItemData. data.itemData is a hash table of itemData objects keyed by SKU.
  • onPurchaseResponse(purchaseResponse) - Called to report the status of a purchase operation. purchaseResponse.purchaseRequestStatus contains the status of the response. If a prior session of the application shut down before a purchase response could be delivered, this function will be called when a new session of the application registers a purchase hander.
  • onPurchaseUpdateResponse(data) - Called with the list of entitlements that the user has been granted. data.receipts contains a hash table, keyed on SKU, that contains the receipts for the IAPs that have been granted to the user. data.revokedSkus has a list of SKUs that the user can no longer use.

Implementation of the Amazon Services JavaScript library is as follows:

  • Enable the API Tester
  • Register a Purchase Observer
  • Check to see if we are running in developer Sandbox Mode
  • Update any existing Purchases
  • Handle Purchase Responses
  • Store Receipts

For example, the Button-Clicker example starts off by calling an initialize() function which will set up an IAP observer using amzn_w.IAP.registerObserver() and then checks the response object to see if the web app is in debug mode.  If it is an alert box is generated telling the user the app is in development mode.  If not it will check for updated Purchases.

Finally, the function sets up handlers for Purchase Response and Purchase Updates Response objects.

// Setup

function initialize() {
    loadPageState();
    amzn_wa.enableApiTester(amzn_wa_tester);
    refreshPageState();

    // Setup button press handlers
    $("#theButton").click(function() { buttonPressed(); });
    $("#redButton").click(function() { redButtonPressed(); });
    $("#greenButton").click(function() { greenButtonPressed(); });
    $("#blueButton").click(function() { blueButtonPressed(); });

    // Ensure we can call the IAP API
    if (amzn_wa.IAP == null) {
        console.log("Amazon In-App-Purchasing only works with Apps from the Appstore");
    } else {
        // Registers the appropriate callback functions
        amzn_wa.IAP.registerObserver({
                 // Called the the IAP API is available
                'onSdkAvailable': function(resp) {
                    if (resp.isSandboxMode) {
                        // In a production application this should trigger either
                        // shutting down IAP functionality or redirecting to some
                        // page explaining that you should purchase this application
                        // from the Amazon Appstore.
                        //
                        // Not checking can leave your application in a state that
                        // is vulnerable to attacks. See the supplied documention
                        // for additional information.
                        alert("Running in test mode");
                    }

                    // You should call getPurchaseUpdates to get any purchases
                    // that could have been made in a previous run.
                    amzn_wa.IAP.getPurchaseUpdates(state.lastPurchaseCheckTime != null ?
                            state.lastPurchaseCheckTime : amzn_wa.IAP.Offset.BEGINNING);
                },

                // Called as response to getUserId
                'onGetUserIdResponse': function(resp) {},

                // Called as response to getItemData
                'onItemDataResponse': function(data) {},

                // Called as response to puchaseItem
                'onPurchaseResponse': function(data) { onPurchaseResponse(data); },

                // Called as response to getPurchaseUpdates
                'onPurchaseUpdatesResponse': function(resp) { onPurchaseUpdatesResponse(resp);
            }
        });
    }
}

$(function() {
    initialize();
});

Once initialization is done you can make purchase calls by passing in your SKU title.  The example code here is making a call to purchase the more “sample.clicks” SKU.

function buyClicks() {
    if (amzn_wa.IAP == null) {
        alert("You are out of clicks, however Amazon In-App-Purchasing works only with Apps from the Appstore.");
    } else if (confirm("Buy more clicks?")) {
        amzn_wa.IAP.purchaseItem("sample.clicks");
    }

The purchaseItem function will return a response object you need to handle and check for success or failure.

// purchaseItem will cause a purchase response with one receipt
function onPurchaseResponse(e) {
    if (e.purchaseRequestStatus == amzn_wa.IAP.PurchaseStatus.SUCCESSFUL) {
        handleReceipt(e.receipt);
    } else if (e.purchaseRequestStatus == amzn_wa.IAP.PurchaseStatus.ALREADY_ENTITLED) {
        // Somehow we are out of sync with the server, let's refresh from the
        // beginning of time.
        amzn_wa.IAP.getPurchaseUpdates(amzn_wa.IAP.Offset.BEGINNING)
    }
    refreshPageState();
}

If it gets back a status of PurchaseStatus.SUCCESSFUL it will handle the receipt returned in the response object like so: 

// purchaseItem will cause a purchase response with one receipt
function onPurchaseResponse(e) {
    if (e.purchaseRequestStatus == amzn_wa.IAP.PurchaseStatus.SUCCESSFUL) {
        handleReceipt(e.receipt);
    } else if (e.purchaseRequestStatus == amzn_wa.IAP.PurchaseStatus.ALREADY_ENTITLED) {
        // Somehow we are out of sync with the server, let's refresh from the
        // beginning of time.
        amzn_wa.IAP.getPurchaseUpdates(amzn_wa.IAP.Offset.BEGINNING)
    }
    refreshPageState();
}

In this Button-Clicker example we are setting a Boolean value to true based on a successful purchase.  In a real web app you would want to save the purchase receipt to local storage or back to your own cloud storage so you can verify purchase receipts in the future.

Using the SDK Tester App

If you are running in the development Sandbox Mode we mentioned above calls to the Amazon Services will go through the local SDK Tester App instead of to the Amazon Cloud. 

This allows you to simulate purchasing SKUs in your web app without having to spend any actual currency.  You have the option to test a purchase inside the browser itself using the included Amazon Service JavaScript Libraries.

In this scenario you need to ensure your JSON file holding the SKUs is located in the same folder as you web app.  If you want to test the In-App Purchase on a device you can do so using the SDK Tester tool and a JSON file that has been copied to the SD Storage.

For a complete video walkthrough of the purchase process and SDK Tester tool you can watch the following screencast on our Youtube Channel.

Conclusion

By utilizing the Amazon In-App Purchasing API for JavaScript you are able to quickly implement and test purchases through your existing web app.  Customers can take advantage of in app items, subscriptions and entitlements you might offer all through the secure Amazon checkout process.

Be sure to check out our HTML5 Web App materials on the developer portal to get started today!

-Dave (TheDaveDev)

 

 

January 21, 2014

Russell Beattie

The Amazon Mobile App Distribution Program enables developers to create Kindle Fire apps using existing HTML5 mobile web apps. It’s also a good way for web developers to start creating mobile apps using the skills and knowledge they already have.

Back in December we covered how to get your existing web apps onto actual devices with a Webinar on Submitting HTML5 Web Apps to the Amazon Appstore, and companion blog post focusing on setting up the Amazon Web App Tester to debug and test your apps.

We wanted to follow up with some more details to help you get the most out of the tester, which is a key part of the HTML5 web app creation process on Kindle Fire tablets. The Web App Tester has a variety of powerful features which can be used to make development faster and easier. Below are a few ways to best take advantage of all that great functionality. 

Amazon's Web App Tester

What exactly is Amazon's Web App Tester? It's a downloadable app which lets you test your web app in a production-like environment on your Kindle Fire or Android device, without first submitting it to our store. The tester contains the same web engine and libraries that will run your web app when it is wrapped into a downloadable app. The tester however, has an interface that lets you enter in your own custom URLs, and most importantly, enables remote debugging for development and testing using your desktop computer.

Because the Web App Tester is based on the same technologies as the final wrapped app, you should be able to better assess your app's performance and functionality - and more quickly work through any problems you might encounter - on the device itself, rather than via an emulator or simulator, which may not be as accurate.

Additionally, libraries that are pre-loaded into the final downloadable app, such as the In App Purchasing API for JavaScript, are also built into the Tester so you can debug your IAPs before you launch. (Look for a more detailed post about enabling IAP for your web apps coming soon).   

Managing Multiple URLs

The first thing you'll encounter when using the Web App Tester is a place to enter a URL for testing. This is great for easy ad-hoc testing, but if you have complicated URLs to enter, or have multiple URLs that you need to manage, you can create a JSON file of URLs and put it into the root folder of your Kindle Fire. The file has to be named amazon.testerurls.json and placed in the /mnt/sdcard/ folder on your device. Here's how the list of URLs should be formatted:

{ 
   "urls":[
      "http://m.imdb.com",         
      "http://m.amazon.com",         
      "https://read.amazon.com"]     
}
 

The easiest way to get it to the correct spot on your device is via the command line using the Android Debug Bridge (ADB), which comes as part of the Android SDK. Assuming you've set up the SDK correctly, you only need to connect your device using USB, open a command line, change to the directory where your JSON file is located and run this command:

$ adb push amazon.testerurls.json /mnt/sdcard/ 

Remote Debugging Options

If your device and your computer share the same network, you can enable Web Developer Tools for debugging over WiFi. If you're on a corporate network, or want to test aspects of your app including offline functionality or WLAN speeds, you can connect via USB using ADB.

Helpfully, the Web App Tester gives you all the details you need to enable Remote Debugging once you start the app. Simply click the full screen handle at the bottom or side of the screen, and swipe down. There you'll see options to enable remote debugging using ADB or via your network.

 

Once you choose, a dialog box pops up with instructions and the exact URL to enter into your Chromium based browser (for debugging). For example, here are the instructions for remote debugging via WiFi:

 

Close that dialog, enter the URLof your web app to test and you'll be all set to debug via a desktop computer.

Dev Tools Tips

Once the Dev Tools page is open in your desktop browser, remote testing and debugging of your mobile web app should become as familiar as doing development for desktop browsers. Here are some things to watch for.

On Device Tools. First, note that all the normal functionality you'd find in Dev Tools is live, but running on the device itself. In fact the entire UI is a static HTML app served from the device, which then communicates back via Web Sockets. Viewing the network speed, recording the timeline activity or profiling is all happening with the device's hardware.

Reload Shortcut. When doing development for a desktop browser, you may be in the habit of clicking the reload icon in the browser to refresh the page. Rather than exiting out of your app on the device, and then re-starting, you can simply type Command-R/Control-R inside the remote Dev Tools window to refresh the contents of the page on the device itself.

Live Inspection. Just like on a desktop browser, you can use the inspect icon to help pinpoint elements on the screen within the HTML5 markup of your app - rather than clicking the screen, just activate the inspect icon, and then touch the screen to find that element within the Dev Tools. It goes in reverse as well, notice that as you use your mouse to hover over the markup in Dev Tools, the corresponding elements light up on the device.

FPS Meter. In the Dev Tools, you can use the settings icon to turn on the FPS meter, which displays in the top corner of your device. This will let you get a live view of how fast your app is refreshing, without having to add in additional libraries.

On Device Debugging and Console. You can step through JavaScript code just as you would normally. Additionally, the console is also live, with the JavaScript engine running on the device. This allows you to use console tricks such as $0 to refer to the selected element, navigate using document.location.href, or even pop up an alert() window if needed.

Remote Debugging API

Because the Web App Tester's Dev Tools use the same remote debugging protocol as desktop Chromium browsers, they can be accessed not only from Dev Tools, but from text editors, IDEs or via scripting languages such as Python. Here's an example using the chrome-remote-interface Node.js module.

First, install the library using NPM:

npm install chrome-remote-interface 

Then create a test.js file with this boilerplate example (modifying the options variable as needed):

var Chrome = require('chrome-remote-interface');

var options = {

host:  'localhost',

port:  '9222'

};

Chrome(options, function (chrome) {

    with (chrome) {

        on('Network.responseReceived', function (message) {

            console.log(message);

        });

        on('Page.loadEventFired', function (message) {

            console.log("----------------------- page loaded ");

            console.log(message);

        });

        Network.enable();

        Page.enable();

        Page.reload();

    }

}).on('error', function (err) {

    console.log(err);

    console.error('Cannot connect to Chrome');

)};

Then run the script

node test.js 

As you use your app on the device, you'll see events logged in your console as they fire. The protocol and module will also let you send commands to the remote browser, letting you automate testing on the device and recording the results. For more info, check out the Remote Debugging Protocol pages here.

Hopefully some of these tips will come in handy as you're doing development for your web app, if you have any tips of your own or questions about using Dev Tools, definitely get in touch!

-Russ (@RussB)

 

January 08, 2014

David Isbitski

HTML5 Web Apps: Tips on Acquiring Customers in the Amazon Appstore

We want to start the year off by focusing on getting your Web Apps noticed in the Amazon Appstore, so you have the best chance of acquiring new customers.  There are a few easy steps you can take to so that your apps, whether web or non-web apps, are more appealing to first time downloaders.  This includes ensuring you have quality screenshots and promotional images, detailed product descriptions, an easy way for customers to review or share your app, as well as a way for customers to discover your apps outside of the Amazon Appstore.  Amazon also offers unique ways to help your Web Apps get noticed including weekly promotions for the top Web Apps in the Appstore as well as access to Appstore Developer Select.   

Appstore Developer Select

All Web Apps submitted to the Amazon Appstore will be automatically entered into for Appstore Developer Select, if they meet the program requirements.  This program helps get your Web Apps discovered and gives you more opportunities to boost your sales and revenue.  As a developer with one or more qualifying apps, you will receive the following benefits:

  • Enhanced Merchandising to Improve Discovery: Your qualifying apps will receive 500,000 free mobile ad impressions across the Amazon Mobile Ad Network. We’ll provide enhanced merchandising for your apps in a dedicated section on the Amazon Appstore home page and consider your apps for advertising on Kindle Fire.
  • Amazon Coins Rewards to Customers to Improve Conversion: Consumers purchasing your app or in-app items in your app will receive up to 30% of the purchase price back in Amazon Coins. We’ll boost customer acquisition by rewarding first-time purchasers of Select paid apps and in-app items with an extra 250 bonus Coins.
  • 25% off AWS Services to Help You Scale: You will earn 25% credit back on qualifying purchases of Amazon Web Services (AWS) products, up to a maximum $500 credit per year.

You can check the status of your eligibility by going to the My Apps section of the Apps and Services Tab in the Developer Console.
 

 

You can click on View Report to see which items your App has passed on and which items you need to update in order to become eligible.


 

Once your app has been enrolled in Appstore Developer Select you will also have the option to view the Ad Campaign that has been set up on your behalf.
 

 

Optimizing App Details

The title and description of your app is like the front door of a building.  Customers will never know what’s inside until they knock and walk inside.  By writing an effective description you can change your app from the spooky abandoned house on the corner to an enticing new shopping mall just waiting to be explored.

 

The keywords section will be how customers find your app when searching the Amazon Appstore so make sure you chose relevant discoverability terms. 

In addition to the App details you can also select a Content Rating for your app letting customers know what to expect.

Be sure to read our previous blog post with tips on effective title and description for your apps here.

High Res Screenshots and Multimedia

Your Web App submission will need to provide screenshots of your app running as well as an optional video.  You should create and upload both a 114x114 icon and a 512x512 icon, which will be used for the app list and carousel respectively.

 

In order to take the screenshots of your app running you will need to use the Web App Tester program on a Kindle device (emulators are not currently supported) and use the Kindle built in screenshot button combination.  The button sequence for each Kindle device can be found here.

You will need to next copy the screenshots off of the Kindle device and uploaded to the developer portal.  

On windows simply plug in your Kindle device and open File Explorer to Internal Storage > Pictures > Screenshots.

 

For Mac OSX you will need to use the Android File Transfer Tool and navigate to Pictures > Screenshots.

 

While you are only required to submit three screenshots, having additional screenshots as well as a promotional image is recommended and will help to increase the chance for downloads.  You can also include an optional Video showcasing your Web App.

 

You can get additional information on taking screenshots of your Web Apps via the official developer documentation  here.

App Badges

Amazon also offers App Badges you can include on your Website and customer communications such as email blasts.

  

These Badges are available in a variety of languages and will further increase potential download traffic to your app by referring customers who are already interested in your products or have come across your website. 

For full details on using App Badges be sure to check out the documentation here.

Conclusion

Building an audience for your apps and connecting with new customers is an important concern for most developers.  By following the steps listed here you can ensure a higher chance of getting noticed.  The more customers who see your app the greater the chance of increased downloads, more reviews and eventual promotion inside the Amazon Appstore.

Got a great HTML5 Web App in the Amazon Appstore?  Looking to get promoted?  Why not tell us about it!  You can Contact Us directly and let us know. 

 

-Dave (@TheDaveDev)

 

December 18, 2013

David Isbitski

We recently launched the Mobile Associates API (MAA) for Amazon Appstore (including Kindle) and general Android devices. Since the launch, the API has been successfully integrated in hundreds of Android apps and has helped generate incremental revenue for developers. Mostly, developers use MAA to complement revenue generated from mobile ads. Using MAA, you can sell real products from the millions of items at Amazon, whether physical (i.e. toys, clothing) or digital (i.e. eBooks), from inside your apps while earning up to 6% in advertising fees from those purchases.  With wide variety of the Amazon product catalog, there are probably many items that are relevant to your users. Plus, you have complete control over the products you want to promote and the in-app user experience. 

In this post, we will show how to build “Relevant products” experience using Mobile Associates API. In this experience, you can offer contextually relevant products in your app by specifying a search term and direct customers to mobile optimized Amazon search result page. Customers can browse through the search results page, select products, and complete the purchase after signing in to their Amazon account. You earn advertising fees equal for qualifying purchases made during that session. Most developers can build this experience in 30 minutes.

“Relevant Products” Experience

For developing other experiences, please visit Amazon Mobile Associates API

Steps to Integrate                                                                                                  

1.       Identifying relevant products to promote

2.       API code integration

3.       Testing the app

Identifying relevant products to promote

Mobile Associates API provides four parameter, searchTerm, product category, Brand, and SortOrder, to search and promote most relevant products to your app users on search landing page. Please see the available product categories and compatible sorting and filtering options here.

To identify relevant products, begin by identifying the most relevant product categories based on your app category and your app user’s demographics. You can also use different product categories in different sections of your app.

Once you have identified the relevant product categories, identify a relevant searchTerm to find relevant products within your chosen categories. Now go to Amazon.com and search for products using searchTerm within your chosen categories. App users will see this list of products when using your app. Refine your searchTerm to identify the list of products your users are most likely to purchase. These items may not be the highest value item available under the given category. For example, most app users are unlikely to buy the most expensive running shoes.

You can also sort these items in different orders. We recommend sorting them by “relevance”. You may consider other sortOrder such as “highest to lowest price” under special circumstances. You can also specify “brand” as a filter if you believe that your app users are more likely to buy a certain brand.

Once you have identified the products you want to promote, you can use the appropriate searchTerm, product category, Brand, and SortOrder in the APIs to promote the relevant products.

Example: If your app belongs to the fitness category, you can pick product categories such as “Health and Personal Care” to promote vitamins, “Shoes” to promote running shoes, or even “Books” to promote fitness related books. You should promote context appropriate products such as barbells or protein supplements to a person who does frequent weight training. Use “men’s running shoes” in shoes category if the app user is male. You should refine the searchTerm based on your conversion rates and the products your users are purchasing.  Promote brands which are popular in your app user’s geographic location. For example, Adidas is a very popular brand in Germany.

API code integration

Update the Android Manifest

Making requests to the Amazon Mobile Associates API requires the INTERNET permission. These permissions need to be declared outside of the <application> tags in yourAndroidManifest.xml file.

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />

Initialize the API

In your Activity.onCreate(), initialize the API by calling AssociatesAPI.initialize(config) using your Application Key.

protected void onCreate(final Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
   setContentView(R.layout.activity_main);
   AssociatesAPI.initialize(new AssociatesAPI.Config(APPLICATION_KEY, this));
}

To get the Application Key, log on to the developer portal, click on the "My Apps" tab and then select an existing app or click on the "Add a New App" button. When creating a new app, just fill in the "App Title" and "Form Factor" fields and click the "Save" button. The next screen will show the unique Application Key value, which is a 32-character globally unique alphanumeric string that is used to identify your app. The same Application Key can be used across platforms, but each distinct app must have a unique Application Key.

Direct to Amazon Search Result Page

To direct customers to an Amazon product search results page, construct an OpenSearchPageRequest by specifying the search keyword and pass the search request to the LinkService.openRetailPage method.

String searchTerm = "running";
String category = "Shoes";
openSearchPageButton = (Button)findViewById(R.id.open_search_page_by_term_button);
openSearchPageButton.setEnabled(true);
openSearchPageButton.setOnClickListener(new View.OnClickListener() {   

    public void onClick(View view) {
       OpenSearchPageRequest request = new OpenSearchPageRequest(searchTerm, category);
       try {
           LinkService linkService = AssociatesAPI.getLinkService();
           linkService.openRetailPage(request);
       } catch (NotInitializedException e) {
               e.printStackTrace();
       }
   }
});

For more details on building “Relevant products” experience, please visit the Amazon Developer Portal.

Testing the app

Once you have integrated the MAA APIs in your app, you should test your app by clicking through MAA links and validating that the users are presented with the relevant products. We also recommend that you validate application id and that the app has INTERNET permission enabled before publishing the app.

 

 

December 09, 2013

David Isbitski

The Amazon Mobile App Distribution program enables you to distribute your existing web apps on Kindle Fire and select Android devices in nearly 200 countries across the globe (including the US, Canada, UK, Germany, Spain, Italy, France, Brazil and Japan). 

Almost any mobile friendly website you are hosting today can be run as a Web App.  This means all of the HTML5, JavaScript, and CSS code you have built today can be made available as an App in the Amazon Appstore

In the recent Webinar on Submitting HTML5 Web Apps to the Amazon Appstore, we covered how to get your existing web apps onto actual devices and debug and test them.

You can debug your HTML5 Web App in two different ways.

•      You can use your favorite IDE or debugging tools for normal Web App development like you are already doing. 

•      Or, you can optionally use the Chrome DevTools to debug your web app using a Kindle Fire or an Android device running the Web App Tester Tool.

Note: The Chrome DevTools, the Chrome Browser installation tool, the Android SDK and certain other development tools are provided by third parties, not by Amazon.

Setting up your Debug Environment

The Chrome Developer Tools are freely available from Google and included in all the latest versions of the Chrome Browser.  Simply select the Chrome menu at the top-right of your browser window, then select Tools > Developer tools to begin debugging.  You can get additional information on installing the tools off the Chromium blog.  The Chrome DevTools use the Android Debug Bridge (adb), part of the Android SDK tools, to communicate with the web app from your computer.

Next, we will need to install the Web App Tester Tool from the Amazon Appstore.  This tool will allow us to create a bridge to our computer over USB or WiFi. 

Simply swipe from the top of the device (if on a Kindle Fire device make sure you tap the full screen handle on the bottom of the screen to open the status bar) and then swipe down from the top of the screen to display the Quick Settings Notification Area.  Once there you will have the option to connect over either USB or WiFI.

In this example I have selected WiFi and am given a url I can put into my browser to connect the Chrome Dev Tools to that running app.

Here is a screenshot of a Kindle Fire running my Web App with the Chrome Debug Tools showing the source for my app.  This enables me to now select actual <div> tags now in the html code via Chrome on my computer and see those <div> tags being highlighted on my actual device (as in the example below).

Conclusion

By utilizing the free Chrome Developer Tools and the free Web App Tester tool we are now able to debug our Web App on an actual device in real time.  This includes everything you would expect from the Chrome Developer Tools, like real time resource monitoring, the ability to view our html source and a JavaScript console.

For a complete walkthrough of the steps described here you can watch the short screencast below as well as checking out the web app debug documentation on our developer portal here.

 

-Dave (@TheDaveDev)

 

December 06, 2013

David Isbitski

The Amazon Mobile Ads API allows you to easily place high-quality display ads from the Amazon Mobile Ad Network into your Android and Kindle Fire apps. Successfully monetizing your apps with ads depends on several factors, one of the biggest being the ad fill rates you receive. A common practice is to use multiple ad networks so that if you are unable to fill an ad with one network you can request an ad from another one.

I thought it would be helpful to offer some guidance on how you can implement multiple ad networks into your own apps. This should help increase your fill rates as well as giving you the opportunity to show ads to customers were the Amazon Mobile Ad Network currently does not serve ads.

Let’s get started!

Setting up the App Manifest and Layout

The first thing you will need to do is follow the guidelines for including the correct Android network permissions and ad Activity as described here.  Since you are going to include AdMob ads as well you will need to define that activity after our Amazon Ad as seen below.

You will also need to make sure you have set up the Amazon AdLayout inside of your layout file like below.

Declaring Multiple Ad Networks

Verify that both ad networks have been added to your Android project and set for export as seen below. For purposes of this demo, I will be using version 6.4.1 of the AdMob SDK and version 5.1.153 of the Amazon Mobile Ads API.”

Depending on what ad network SDK you are working with, many of the classes may be named similarly to the ones used in Amazon Mobile Ads API . You will need to be extremely careful when referencing individual classes and I recommended using fully qualified namespaces as seen below.

Displaying an Amazon Ad

Displaying an ad with the Amazon Mobile Ads API is as simple as creating and adding an Amazon AdView to the layout, setting any optional targeting properties and then calling the loadAd method of the AdView.

In the example below I am setting the ad to target a twenty five year old male and using a simple fixed rate timer to refresh the ad over time using a fixed schedule timer.

I have also turned logging on by setting the AdRegistration logging flag to true. This will give us detailed information in LogCat about the ads being served.

Here are some screenshots of the Amazon ads being loaded on a Kindle Fire HDX device:

Here is an example of the Amazon ad information being written to LogCat:

Checking if an Amazon Ad was served

If an Amazon ad has not been served within the timeout period it will call the onAdFailedToLoad() method. The default timeout is 20 seconds but you can change this to a different value (defined in milliseconds) by setting a property on the AdView itself. I recommend doing this while testing so that you can force the ad mediation to happen.

In the code below you will see I have set the timeout to be 100 milliseconds, which will always cause the ad to fail while I am debugging my secondary ad network. Once I have seen ads being loaded from both networks I can set this back to a more reasonable value.

Inside the onAdFailedToLoad method I log the ad error message I received, remove the Amazon view from the UI, load the AdMob view and then I have it request an ad.

Here are some screenshots of the AdMob ad being loaded on a Kindle Fire HDX device:

Here is an example of the AdMob information being written to LogCat:

Setting an Ad Timeout

The Amazon Mobile Ad Network recommends loading a new ad on screen navigations and device orientation changes when the ad view changes size. You may also want to refresh the ad after a set time interval. In this case, the Amazon Mobile Ad Network recommends a refresh rate of 30 to 60 seconds. Faster ad refresh intervals could result in blocked ad requests.

Please note that the Amazon Mobile Ads API does not provide any built-in functionality for automatically refreshing ads. The timeout value of the Amazon AdView is the amount of time it will try to get a new ad for you before calling the onAdFailedToLoad method. This will not auto refresh the ad it will only change the amount of time it spends trying to load an ad.

You will need to create your own timer system to refresh the ad or some other way inside of your app. In the code example above I used a timer on a fixed rate schedule for demo purposes, but there is no limitation to the way you could handle this in your own apps. For example, every time a player reaches a new level in your game you briefly display an ad.

Conclusion

Hopefully you have seen how easy it is to set up ad mediation with the Amazon Mobile Ads API and third party ad SDKs in your own apps. You can read more details on working with other ad SDKs here on our developer portal. You can also get more detailed information about the Amazon Mobile Ads API itself and sign up here.

-Dave (@TheDaveDev)

 

November 26, 2013

Mike Hines

Ever wonder what’s involved in turning your web app into an app you can launch from a mobile device? On the Amazon Appstore, it’s pretty easy, and involves just a few steps you can learn about here. One of those steps is adding a JSON file called the web-app-manifest to your web app.

This manifest file contains information required to run your app on a mobile device, and the basic manifest file is created for you on the developer portal. Where you put that manifest file can make a difference though. You should know about that and how to edit your manifest file in order to give your app access to features like geolocation on the device.

Where can you put the Manifest, and what difference that makes.

While we recommend that you put the manifest file at the root of your web app, you can put the manifest file anywhere on your server. The location of your manifest file determines what pages will render in the context of your app, and which pages will render in the default browser. The pages in the sub-domains under your manifest will be accessible by your app and will render in the context of your app. Any pages outside of those domains or directories will open in the default browser instead of in the context of your app.

Take a look at what pages will and won’t be accessible from your mobile app depending on where you put the manifest. Note the special case of www. and m. addresses in yellow below.

If you put your manifest here…

These pages will open in your app

But these pages will open in a browser

http://foo.com/web-app-manifest.json

http://*.foo.com/*

http://*.notFoo.com/*

http://bar.foo.com/web-app-manifest.json

http://*.bar.foo.com/*

http://*.notBar.foo.com/*

http://m.foo.com/web-app-manifest.json

http://*.foo.com/*

http://*.notFoo.com/*

http://www.foo.com/web-app-manifest.json

http://*.foo.com/*

http://*.notFoo.com/*

http://foo.com/MyApp/web-app-manifest.json

http://foo.com/MyApp/*

http://foo.com/notMyApp/*

http://*.foo.com/MyApp/*

http://bar.foo.com/MyApp/web-app-manifest.json

http://bar.foo.com/MyApp/*

http://bar.foo.com/*

http://notBar.foo.com/*

http://notBar.foo.com/MyApp/*

http://bar.foo.com/notMyApp/*

SSL Note:

  • If the manifest is delivered with https://, then the entire app must be delivered over SSL as well.
  • If the manifest is delivered with http://, the app may be still be served over SSL.
  • If you use any permissions (IAP, Geo Location, Login), you must use SSL.

Now that you have a good idea where to put your manifest, what to put in it?

Contents of the web-app-manifest.json file

The manifest created automatically for you will look like this:

{
 "verification_key" : "c8efxxxx-xxxx-xxxx-xxxx-xxxxe5b239e9",
 "version" : "0.00(0)",
 "type" : "web",
 "last_update" : "2013-11-19 23:40:17+0000"
}

  • “verification key” connects your website to your app.
    *This is the only required field in the manifest.
  • “version” helps you track the version that you have submitted
  • “type” lets us know that in this case, the app is a web-app
  • “last_update” is when this manifest file was created (you can change it to match your updates)

In addition to the elements above, you may also wish to add one of these elements:

  • “permissions” specifies the permissions your app will request (these will require SSL use).  They consist of:
  • “Created_by” = you.
  • “launch_path” identifies the file you want your app to open
  1. iap = In App Purchasing
  2. geolocation = Get location information
  3. auth = if you request user credentials for login (facebook connect, google, your own.)

A finished web-app-manifest.JSON that uses all available fields might look like this:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

{

    "verification_key": " c8efxxxx-xxxx-xxxx-xxxx-xxxxe5b239e9",

    "launch_path": "index.html",

    "permissions": [

        "iap",

        "geolocation",

        "auth"

    ],

  

    "type": "web",

    "version": "0.1a",

    "last_update": "2013-04-08 13:30:00-0800",

    "created_by": "webappdev"

}

Updating your web-app-manifest.JSON file

If after your app launches, you decide you want to update you web-app-manifest.JSON file, the app on device will not automatically update with new JSON file data. You will need to publish an updated version of your app. You can create an updated version of your native app in the dev portal by using the ‘Add an upcoming version’ link at the top of the developer portal page for your app (see below).

Once your new version submission is underway, you can submit and verify a new manifest, and then submit the new app version for publication.

A Tip to Remember!

Please be sure to configure your server to accommodate .JSON MIME types! For example:

.json -> application/json
.webapp -> application/x-web-app-manifest+json

More Information

You can find detailed documentation on the web-app-manifest.JSON file and on HTML5 app submission on our Dev Portal here.

Should you have any additional questions about the web app manifest file and how it is used, please send us a quick note so we can get you the answer you need.

 

November 14, 2013

David Isbitski

We’re excited to announce a new tool for developers called the Developer Promotion Console (DPC). DPC gives you a self-service way to manage the pricing of all your apps with pricing campaigns. Want to run a 24-hour special holiday sale or discount all of your apps to celebrate the launch of a new game? It’s now much easier.

The Developer Promotion Console is available just in time for the holidays and it’s a great time run a special offer. In 2012, we saw a 50% increase in the number of app downloads during Thanksgiving week as compared to an average week. During ‘Digital Week’ 2012, the week after Christmas, customers purchased and downloaded 600% more apps than any other week during 2012.

What is it?

DPC allows you to create campaigns that run from 24 hours to any amount of time you choose, up to a maximum of 27 consecutive days. Pricing is worldwide so you can set discounts by Amazon marketplace. Best of all, you can run campaigns for the price of your mobile apps and any of your mobile in-app items.


 

What does it include?

Set temporary price drops: Create price drop promotions for your mobile apps and mobile in-app items to incentivize your customers to purchase your products. 

ReportingEasily view your ROI during your price drop promotion. Compare the performance of your promotion with your performance prior to the promotion.

Ease of use: Creating a price drop promotion is simple. Typically, it will take no more than five minutes and three steps to go from start to a scheduled promotion.

How do I get started?

Inside of the developer console, you will see a new tab called ‘Promotions.’ Clicking on the tab will display a new button to create a ‘Price Drop,’ as well as a list of your existing campaigns.

You will be able to set a discount for any of your apps and in-app items available for purchase.

For this example, we are going to create a new campaign for one app and set a price discount for the upcoming Thanksgiving holiday. We start off by giving the campaign a name, in this case the ‘Thanksgiving Holiday Promo’, and then selecting the app (currently blocked out in the image for privacy reasons) that we want to include in the promotion.

We then select the Amazon marketplaces we want the campaign to run in. Since Thanksgiving is a US holiday, we will only run it in the amazon.com marketplace.

Next, we can choose the dates for our campaign, with the minimum being one day and the maximum being 27 consecutive days. We are going to run this campaign for Thanksgiving Day only, on November 28, 2013.


We then click ‘Next’ and define the discount we want to apply to our app. We are going to do a 50% off sale with the price being rounded to the nearest 9. Selecting the amazon.com marketplace from the dropdown shows us that the list price for our app will go from 2.99 USD to 1.49 USD when the campaign is active.

Again, note that the app name in the above screenshot has been hidden in this example for privacy reasons.

Clicking ‘Next’ will give us a final confirmation of our campaign’s details. We have the ability to edit any of the sections before hitting ‘Submit’.

We’re finished. Our campaign is now ready to run on Thanksgiving Day in the amazon.com marketplace, where our app will be available for sale at 50% off.

How much did we increase sales?

Rather than guessing if we made more money with increased sales at a discount, the DPC reports will show us our net results of our campaign sales compared with our normal app pricing.

To view the results of the campaign, we just click on the ‘Promotions’ tab again (the same one we used to create our campaigns), and we will see a list of the campaigns that have run or are planned.

In the above example, we can see that we ran a campaign from October 29th through November 3rd (campaign name hidden for privacy reasons), and we have the option to click ‘View’ to see the results of that campaign.

We can see that during the campaign period, we sold 21 units of our app at 50% off.

The ‘Effect’ column takes the guesswork out of the ROI for our campaign and gives us the net results. Based on sales during the period of time before the campaign ran, we have increased our revenue for the period by 84%, resulting in a nice boost.

We can also click on the CSV icon, which will create a detailed view of daily sales during the campaign period and compare them with previous run rates.

Conclusion

The new Developer Promotion Console helps you manage discounted pricing which can lead to increased sales and customer engagement. Creating a new campaign is easy through the Developer Promotion Console, at no cost to you. With detailed reports that will show you the ROI of your campaign, you can feel more confident experimenting with discounts on your apps and in-app items.
 

-Dave (@TheDaveDev

 

Want the latest?

appstore topics

Recent Posts

Archive