Appstore Blogs

Appstore Blogs

Want the latest?

appstore topics

Recent Posts

Archive

Showing posts tagged with Best Practices

February 21, 2013

lisamar

When uploading multimedia or binary files to your Amazon Mobile App Distribution Portal account, files larger than 100 MB must be uploaded using FTP. To upload your larger assets using FTP, simply follow the below instructions:

On the Images & Multimedia or Binary File(s) tab in your app details, click on the FTP instructions and naming convention link to obtain the app-specific naming conventions you will need to upload via FTP.

 

FTP Upload Steps

 1.  Select the app whose file(s) you will be uploading using the dropdown

2.  Use the generated name list to rename any assets over 100 MB to the specific file name provided—this file name is how Amazon will know what app and asset field to apply the file

3.  Using the FTP client of your choice, login and upload your renamed files using the specified FTP server and username—if needed, reset your password to have a new one sent to you


4.  You’re almost done! Simply review and submit your app once your files appear uploaded

Allow up to 20 minutes for an e-mail confirmation that your assets are processed and available. You will also receive an e-mail if the uploaded asset is invalid or misnamed. E-mails will be sent to the e-mail address you have provided us in your Distribution Portal profile. Once the asset has been uploaded, finish any remaining steps and review your content one last time. After you have satisfied all the asset requirements, you will be able to submit your app to have it reviewed for inclusion in the store.

More about the FTP Naming Convention

Every app has a unique application ID (appId below) that is a required part of the filename when you upload via FTP. Including the package name after the application ID is optional—add the package name only if it helps you organize your files.

Small icon (114 x 114 pixels):  appId-AD-ICON.png  or  appId-package.name-AD-ICON.png

EXAMPLE:  M0A2KAXJX4CATH-AD-ICON.png or M0A2KAXJX4CATH-com.example.mobile.app-AD-ICON.png

Large icon (512 x 512 pixels):  appId-AD-THUMB.png  or  appId-package.name-AD-THUMB.png

EXAMPLE: M0A2KAXJX4CATH-AD-THUMB.png OR M0A2KAXJX4CATH-com.example.mobile.app-AD-THUMB.png

Screenshots (1024 x 600px or 800 x 480 pixels): appId-AD-SHOTXX.png orappId-package.name-AD-SHOTXX.png where XX is an optional numerical index of the image

EXAMPLE: M0A2KAXJX4CATH-AD-SHOT.png, M0A2KAXJX4CATH-com.example.mobile.app-AD-SHOT.png, M0A2KAXJX4CATH-com.example.mobile.app-AD-SHOT1.png, M0A2KAXJX4CATH-com.example.mobile.app-AD-SHOT05.png

Promotional image (1024 x 500 pixels, landscape only): appId-AD-PROMO.png or appId-package.name-AD-PROMO.png

EXAMPLE: M0A2KAXJX4CATH-AD-PROMO.png or M0A2KAXJX4CATH-com.example.mobile.app-AD-PROMO.png

Video(s): appId-AD-VIDEOXX.png or appId-package.name-AD-VIDEOXX.avi where XX is an optional numerical index of the video

EXAMPLE: M0A2KAXJX4CATH-com.example.mobile.app-AD-VIDEO.avi,M0A2KAXJX4CATH-com.example.mobile.app-AD-VIDEO1.avi,M0A2KAXJX4CATH-com.example.mobile.app-AD-VIDEO05.avi

Binary file/APK:

Signed by Amazon (recommended)

With DRM: appId-<binary alias>.apk  or  appId-package.name-<binary alias>.apk

EXAMPLE: M0A2KAXJX4CATH-my_alias.apk orM0A2KAXJX4CATH-com.example.mobile.app-my_alias.apk

Without DRM: appId-<binary alias>-nodrm.apk or appId-package.name-<binary alias>-nodrm.apk appId-<binary alias>-nodrm.apk or appId-package.name-<binary alias>-nodrm.apk

EXAMPLE: M0A2KAXJX4CATH-my_alias-nodrm.apkor M0A2KAXJX4CATH-com.example.mobile.app-my_alias-nodrm.apk

Signed by you

Unsigned binary with DRM: appId-<binary alias>-precert.apk or appId-package.name-<binary alias>-precert.apk

EXAMPLE: M0A2KAXJX4CATH-my_alias-precert.apk orM0A2KAXJX4CATH-com.example.mobile.app-my_alias-precert.apk

Unsigned binary without DRM: appId-<binary alias>-precert-nodrm.apk or appId-package.name-<binary alias>-precert-nodrm.apk

EXAMPLE: M0A2KAXJX4CATH-my_alias-precert-nodrm.apk  or  M0A2KAXJX4CATH-com.example.mobile.app-my_alias-precert-nodrm.apk

Signed binary: appId-<binary alias>-mycert.apk or appId-package.name-<binary alias>-mycert.apk

EXAMPLE: M0A2KAXJX4CATH-my_alias-signed.apk

 

January 23, 2013

Amazon Mobile App Distribution Program

Mike Hines, Technical Evangelist for Amazon Kindle, is our guest blogger for this post.

So writing your app was the hard part. Okay, true enough;but it’s not the last part. You still need to sell your app, and a great product description will help you do that. Here's how to make sure your description puts your app in the best light.

Start with the Basics

Make sure your description is clear, honest, and straightforward. If you have a personal finance app that tracks income and expenses and helps you budget, explain why and how this is helpful and how the app works. Don’t make grandiose promises about how your app will make users wealthy; customers see through inflated claims, and your description will lose credibility.

Use the following checklist to get the basics right:

Do:

  • Always use proper punctuation and grammar.
  • Introduce your app clearly and succinctly.
  • Describe your app's most notable features.
  • Use a conversational tone.
  • Explain why and how your app will benefit users.
  • Show off, but don’t inflate claims. Include the attributes that make your app stand out.
  • Finish with a call to action.

Don't:

  • Write your product description in the web form on the Mobile App Distribution Portal. Instead, write your product description in a word processor and paste the finished result back to the Distribution Portal.
  • Refer to your app only as "this app" or "an app"—use your app's full name at least once in your product description.
  • Make false, hyperbolic claims—this type of marketing rarely works and may hurt your app in the long run.
  • Simply list your app's features. Instead, explain why these features are awesome and worth adding to a customer’s app collection.
  • Use atypical or inappropriate language that could mislead or confuse customers.

But wait, there's more! Remember—this is the Basics checklist. If you just do the things in the list above, you’ll only get an okay product description. We can do better. 

Learn from the Masters

Consider the following description:

This is a clever, addictive game that’s a lot like a word search game. It also makes you think instead of just looking for words. Create words by linking letters that disappear when you link them. When they disappear, they are replaced with letters from the grid above.

If you’re clever, you can set yourself up to create long words and get lots of points and you’ll never run out of games to play. In addition to Standard mode, there is a 'Timed' mode too. Tracked stats include 'Longest Word', 'Highest Scoring Word', 'Total Score' and more! Play MyGame in Portrait, as well as Landscape view. MyGame is the best game ever for everyone who likes puzzles and games.

This example is not “a bad example.” This product description would do alright as is, because it does several things right:

  • It describes the game in terms of a reference most users will understand (“…like a word search game.”)
  • It takes a shot at describing what the app actually does. (“Create words by linking letters…”)
  • It describes why it is unique and may be a lot of fun. (“…you can set yourself up to create long words…and you’ll never run out of games to play.”)
  • It even makes an attempt to appeal to a market. (“MyGame is…for everyone who likes puzzles and games.”)

Still, this product description isn’t brilliant. This writing probably won’t generate the enthusiasm, curiosity, or the confidence required to convert a marginally interested shopper into a buyer. It reads poorly, uses choppy structure, and is imprecise or confusing on a number of items.

Now consider a much better description of the same game:

MyGame is a word search game with a tactical twist.

Create words by linking letters within a grid of scrambled letters. Each word created is then removed from the grid and the letters above fall into the gaps left behind, creating new word possibilities. With careful play, letters can be brought into play strategically and used to create longer, higher scoring words. The starting grid is randomly generated, so no two games should ever be the same.

MyGame offers two modes of play: 'Relaxed' - for those who like to take their time and try to create the longest words, and 'Timed' - where players can test themselves against the clock to see how they score under pressure. Your 'Longest Word', 'Highest Scoring Word', 'Words Made' and 'Total Score' stats are all recorded so you can track your achievements. If you like word search puzzles, you’ll love this game. Download MyGame and start finding words with a twist today!

This description does a number of things differently than the previous description. It completes the checklist, but more importantly, it provides the following subtle improvements.

The improved description:

  • Is more fluid and reads more easily.
  • Includes the name of the title, and avoids unnecessary superlatives or exaggeration.
  • Uses more precise and descriptive language to describe how the game works.
  • Describes the uniquely fun component of the game in more detail (“With careful play, the letters can be brought into play strategically and used to create longer, higher-scoring words.”) This type of precision is missing from the first description.
  • Includes context and benefits for its features.
    • It describes why long words are desirable (“…create longer, higher scoring words.”) so users have context to the benefit of ‘Relaxed’ mode (“…take their time and create the longest words,…”).
    • The score-tracking features are given a benefit statement (“…are recorded so you can track you achievements.”).
    • The claim in the first description (“…never run out of games...”) is substantiated in the second (“The starting grid is randomly generated, so no two games should ever be the same.”)
  • Includes a call to action in the last sentence.

While these two product descriptions are similar, one of the big differences lies in the implementation of the required checklist elements (and, honestly, a bit of proofreading).

Refine the Nuances 

So how do you refine the nuances of your description? Use these three simple checks to see if you've met the bar.

  1. Don’t ignore spell and grammar check results.
  2. Read your product description out loud. This is a great test for continuity and flow.
  3. Ask someone who has never used the app to read the product description and describe what the app is, how it works, and why they might want it. If they struggle to get any of those points right, or fail to see why they should buy it, you need a rewrite.

Start Today 

Trust us: It gets better from here. Even if your first few product descriptions are closer to good than great, it is okay to rewrite your description. With practice, you’ll find it easy to develop a solid, recognizable style in your product descriptions that can help establish consistency, brand recognition, and consumer trust.

So, go ahead—why wait? Get started today by using these guidelines to make a small edit or two to an existing product description.

January 14, 2013

Amazon Mobile App Distribution Program

Derek Gebhard, Solutions Architect for Amazon, is our guest blogger for this post.

One of the things you will spend time on when building a Kindle Fire app is testing and debugging. Using a Kindle Fire emulator is the recommended way to test and debug your mobile apps if you do not have the device available. This post will cover tips on increasing the performance of the KindleFire emulators, including the newly released KindleFire HD 8.9” emulator, but will also apply to most other Android emulators.

For Ice Cream Sandwich-based Kindle Fire emulators(Android SDK 4.0.3, API level 15) you can enableGPU emulation to significantly improve the performance. One thing to be aware of: GPU emulation is currently an experimental feature in the Android tools suite, and may not work on all host hardware configurations or operating systems. If you experience issues, you may need to disable this functionality.

To enable GPU emulation, launch the Android Virtual Device Manager. This can be done by running “android avd” or clicking the Android Virtual Device Manager icon in Eclipse.

For existing emulators:

  1. Select the emulator for which to enable GPU emulation
  2. Click “Edit…”
  3. Check “Use Host GPU” under the Emulation Options section.
  4. Click “OK” to save your configuration changes.

When creating a newemulator:

  1. Click the “New…”button
  2. Add the Kindle Fire details according to our configurationguide.
  3. Check “Use Host GPU” under the Emulation Optionssection.
  4. Click “OK” to create your emulator.

Image1
Image 1:Changing the GPU emulation property

To showcase the effect of GPU emulation property, there are two screenshots below. These GPU measurements were taken on a Windows desktop,using the Kindle Fire HD 7” emulator. This test included starting the emulator,running SDK Tester, and accessing the Kindle Fire settings. As you can see, GPU emulation must be enabled in order for the emulator to leverage the GPU’s dedicated memory. 

Image2

Image 2:GPU emulation set to “no”

 

Image3
Image 3:GPU emulation set to “yes”

There are also a few other things that can help when running apps on the Kindle Fire emulators. Below is a list of the other ways we can increase performance and save time:

  • Close any non-essential processes and programs as the emulator uses a large amount of CPU time and memory when emulating the device.
  • Make the SD card as small as possible, as large card sizes increase the start-up time
  • Enable snapshots to save and restore state to a‘Snapshot’ file in each AVD, so you can avoid booting when you start the emulator.  Note: This feature is alpha-quality feature so the emulator window will freeze while its saving the state after you close the emulator. Also, GPU emulation and Snapshot cannot be used together.
  • Lower the screen size if your app does not depend upon screen size.
  • Restart the adb server if you experience ani ncrease in the time it takes to install applications on the emulator. This can occur over time and is solved by running adb kill-server followed by adb start-server.

January 02, 2013

Amazon Mobile App Distribution Program

E-dan Bloch, Solutions Architect for Amazon, is our guest blogger for this post.

The new Kindle Fire HD 7” and 8.9” tablets introduce high definition screens that provide a great opportunity for mobile app developers to deliver an improved user interface, high resolution images,and apps that take advantage of more “screen real estate”. While native layouts make use of these higher resolutions by default, layouts within WebViews may require some HTML adjustments to be made.

WebView control may display pages that are logically longer and wider than the physical screen size, allowing users to pinch to zoom and scroll through a web page. To accommodate the difference in size, the WebView control takes two properties into consideration: the native view size (the size of the control itself) and the logical view port size (the size of the content currently visible within the control).

The viewport, with respect to the WebView control, is the area of the page currently visible to the user. The native Android layout engine controls the view size, and the HTML page determines the logical viewport size. For example, when the WebView displays a page that is zoomed in, the logical viewport size is smaller than the actual size of the control (hence the zooming). This can lead to seemingly unexpected behavior of web apps, especially when JavaScript is used to create the page’s layout.

There are two key properties that mobile app developers leveraging WebViews should be familiar with: the viewport metadata property and the android:theme property.

The “viewport” metadata property is represented as <meta name="viewport" content="…" />. Adding this entry to the <head> section of your HTML pages will allow you to better control how your pages are displayed on users’ devices. Control this property by setting its content attribute with the following descriptors:


height = [pixel_value | device-height],

width = [pixel_value | device-width ],

initial-scale = float_value,

maximum-scale = float_value,

minimum-scale = float_value,

user-scalable = [yes | no],

target-densitydpi =

[dpi_value | device-dpi | high-dpi | medium-dpi | low-dpi]

 

By default, the target-densitydpi descriptor assumes the medium-dpi value. For Kindle Fire HD devices, you should change this setting to high-dpi so that your content will display properly. Alternatively, you can use the device-dpivalue and have the WebView control determine the density dynamically according to the device being used. This automatic setting will cause the viewport to scale differently for each device’s pixel density.


 

To use this automatic setting, add the following line to the <head> section of the HTML page being viewed:

<meta name="viewport" content="target-densitydpi = device-dpi" />

 

In instances where a web page uses a fixed-size layout, or a purely relative (fluid) layout, we may also want to have the width and/or height descriptors set to device-width or device-height (respectively). Setting these values will set the logical size of the WebView to match that of the device being used. So the viewport property would look like this:


<meta name="viewport" content="target-densitydpi = device-dpi, width = device-width" />

 

Combined with the auto-density selection we get:

<meta name="viewport" content=" target-densitydpi = device-dpi, target-densitydpi = device-dpi, width = device-width" />

 

To demonstrate the effect of the latter tag, here is a side-by-side comparison of a simple web page displaying different size values with and without it:

Webviews-2n

Notice how, in the example on the right, the ViewPort size matches the WebView size. The difference, in both examples, between the screen size and the WebView size are due to the status (above) and menu (below) bars.

The second property is the android:theme property. Although it relates to the Android activity itself, and not just the WebView control, it can impact the screen real estate that your apps use. A good example is full-screen browsing. The Kindle Fire’s soft-key menu provides developers with power over the amount of screen their app can use by allowing them to hide both the title bar and the menu buttons. To use this feature, you can add the android:theme attribute to the <application> or <activity> elements in your AndroidManifest.xml manifest file and set the appropriate theme. For example, you can use@android:style/Theme.NoTitleBar to hide the top title bar, or

@android:style/Theme.NoTitleBar.Fullscreen to hide both the title bar and the soft-key menu bar. For example, if you want your entire app to operate in full-screen, your AndroidManifest.xml file might look like this:


<application

  android:icon="@drawable/icon"

  android:label="@string/app_name"

  android:theme="@android:style/Theme.NoTitleBar.Fullscreen">…</application>

 

This last value gives you the most screen area to work with. However, this option should be used with care as it affects the user experience by minimizing standard controls such as the clock and battery indicator, as well as the “back”, “search”, and “home” buttons.

 

To demonstrate, here is a side-by-side comparison of the default theme versus the Fullscreen theme:

 

Notice how, in the example on the right, all buttons are hidden until the user taps on the pull-up button seen on the bottom.

 

For more information, please also see the  User Experience Guidelines.

 

December 26, 2012

Amazon Mobile App Distribution Program

One of the great new features that the Kindle Fire HD offers is a set of dual-driver stereo speakers on both sides of the display. This sound setup opens new possibilities to game and app developers by allowing for a more comprehensive and immersive sound experience.With minor adjustments, any app can leverage the stereo speakers and enhance the user experience. By default, Kindle Fire HD uses both speakers to output balanced sound (left speaker = right speaker). By changing the volume on either side, we can achieve an effect of localized sound. As a simple example, we can consider a conga drum app. The app will have two conga drums displayed, one on the left and one on the right. Tapping on the left conga produces sound only in the left speaker and similarly, tapping on the right drum produces sound only in the right speaker.

The way to control the volume on the speakers depends on the method being used to actually play sound. For the purpose of this post, we will assume that the MediaPlayer class is used, but most other methods should be similar if not identical in nature. The following code will create a MediaPlayer instance that will play audio only through the left speaker:

import android.media.MediaPlayer;

float leftVolume = 1.0f;

float rightVolume = 0.0f;

 

MediaPlayer mPlayer = MediaPlayer.create(…);

if (nPlayer == null) {

            mPlayer.setVolume(leftVolume,rightVolume);

}

The leftVolume and rightVolume parameters can be set toany value between 0.0 (“off”) and 1.0 (“full volume”). The volume level is relative to the master volume of the device so changing these values is basically just changing the balance between the stereo channels or, in this case, the two speakers.

Using the SoundPool class is not all that different:

 

import android.media.SoundPool;

float leftVolume = 1.0f;

float rightVolume = 0.0f;

 

SoundPool sPool = new SoundPool(…);

// Load an asset into the pool

int streamId = sPool.load(…);

 

sPool.play(streamId,leftVolume, rightVolume ,0, 0, 1.0);

Want the latest?

appstore topics

Recent Posts

Archive