34,333
edits
Changes
New page: <table border="0" cellspacing="0" width="100%"> <tr> <td width="20%">Previous<td align="center">[[Kindle Fire Development Essent...
<table border="0" cellspacing="0" width="100%">
<tr>
<td width="20%">[[A Kindle Fire Amazon Mobile Ads API Example Application|Previous]]<td align="center">[[Kindle Fire Development Essentials|Table of Contents]]<td width="20%" align="right">[[Submitting an Application to the Amazon Mobile App Distribution Portal|Next]]</td>
<tr>
<td width="20%">A Kindle Fire Amazon Mobile Ads API Example Application<td align="center"><td width="20%" align="right">Submitting an Application to the Amazon Mobile App Distribution Portal</td>
</table>
<hr>
<google>BUY_KINDLE_FIRE</google>
Before being made available for purchase on the Amazon App Store, an application must first be submitted to the Amazon Mobile App Distribution portal for review and approval. One of the most important steps to take before submitting an application is to decide which Kindle Fire models the application is intended to support and, more importantly, that the application runs without issue on those devices.
This chapter will cover some of the areas to consider when making sure that an application runs on the widest possible range of Kindle Fire models and what to do when support for all Kindle Fire models is not possible.
== Handling Different Kindle Fire Displays ==
The Kindle Fire comes in a variety of different screen sizes and resolutions. The ideal solution is to design the user interface of your application so that it appears correctly on all members of the Kindle Fire device family. The best way to achieve this is to design the user interface using layout managers that do not rely on absolute positioning (in other words specific X and Y coordinates) such as the RelativeLayout so that views are positioned relative to both the size of the display and each other.
Similarly, avoid using specific width and height properties wherever possible. When such properties are unavoidable, always use density-independent (dp) values as these are automatically scaled to match the device display at application runtime.
Having designed the user interface, be sure to test it on each device on which it is intended to be supported. In the absence of the physical device hardware, use the emulator templates provided by Amazon.
In the event that it is not possible to design the user interface such that a single design will work on all Kindle Fire devices, another option is to provide a different layout for each display.
== Creating a Layout for each Kindle Fire Display ==
The ideal solution to the multiple display problem is to design user interface layouts that adapt to the display size of the device on which the application is running. This, for example, has the advantage of having only one layout to manage when modifying the application. Inevitably, however, there will be situations where this ideal is unachievable. Another option is to provide different layouts, each tailored for a specific Kindle Fire display. This involves identifying the smallest width qualifier value of each display and creating an XML layout file for each one. The smallest width value of a display indicates the minimum width of that display measured in dp units. The smallest width values for the Kindle Fire family of devices are as follows:
* Kindle Fire (2nd Generation) – sw600dp
* Kindle Fire HD 7” – sw533dp
* Kindle Fire HD 8.9” – sw800dp
Notable by its absence from the above list is the first generation Kindle Fire. This is because the concept of smallest width was not introduced into Android until version 3.2. As such, this value is not available for the first generation Kindle Fire. This, however, can be resolved by allocating the default layout to the first generation Kindle Fire and setting specific layouts for those devices that support the smallest width qualifier.
Display-specific layouts are implemented by creating additional sub-directories under the res directory of a project. The naming convention for these folders is:
<pre>
layout-<smallest-width>
</pre>
For example, layout resource folders for the entire family of Kindle Fire devices would be required as follows:
* ''res/layout'' - Kindle Fire (first generation)
* ''res/layout-sw600dp'' – Kindle Fire (second generation)
* ''res/layout-sw533dp'' – Kindle Fire HD 7”
* ''res/layout-sw800dp'' – Kindle Fire HD 8.9”
Each folder must, in turn, contain a copy of the layout XML file adapted for the corresponding display, all of which must have matching file names. Once implemented, the Android runtime system will automatically select the correct layout file to display to the user to match the device display.
== Providing Different Images ==
User interface layouts are not the only area of concern when adapting an application for different screen densities, dimensions and aspect ratios. Another area to pay attention to is that of images. An image that appears correctly scaled on an HD 8.9” screen, for example, might not appear correctly scaled on a first generation Kindle Fire device. As with layouts, however, multiple sets of images can be bundled with the application, each tailored for a specific display. This can once again be achieved by referencing the smallest width value. In this case, drawable folders need to be created in the res directory. For example:
* ''res/drawable'' - Kindle Fire (first generation)
* ''res/drawable-sw600dp'' – Kindle Fire (second generation)
* ''res/drawable-sw533dp'' – Kindle Fire HD 7”
* ''res/drawable-sw800dp'' – Kindle Fire HD 8.9”
Having created the folders, simply place the display specific versions of the images into the corresponding folder, using the same name for each of the images.
Alternatively, the images may be categorized into broader display densities using the following directories:
* ''res/drawable-mdpi'' – First and second generation Kindle Fire devices
* ''res/drawable-hdpi'' – Kindle Fire HD 7” and Kindle Fire HD 8.9”
== Checking for Hardware Support ==
By now, it should be apparent that not all Kindle Fire models were created equal. By far the weakest links in the chain are the first and second generation Kindle Fires (no camera or microphone). An application that makes use of these hardware features should include code to gracefully handle the absence of specific hardware on older models of device. This typically involves performing a check to find out if the hardware feature is missing, and subsequently reporting to the user that the corresponding application functionality will not be available.
The following method can be used to check for the presence of a microphone:
<pre>
protected boolean hasMicrophone() {
PackageManager pmanager = this.getPackageManager();
return pmanager.hasSystemFeature(
PackageManager.FEATURE_MICROPHONE);
}
</pre>
Similarly, the following method is useful for checking for the presence of a front facing camera:
<pre>
private boolean hasCamera() {
if (getPackageManager().hasSystemFeature(
PackageManager.FEATURE_CAMERA_FRONT)){
return true;
} else {
return false;
}
}
</pre>
Map support, on the other hand, can be verified as follows:
<pre>
public boolean hasMapSupport()
{
boolean result = false;
try {
Class.forName( "com.amazon.geo.maps.MapView" );
result = true ;
}
catch (Exception e) {}
return result;
}
</pre>
== Providing Device Specific Application Binaries ==
Even with the best of intentions, there will inevitably be situations where it is not possible to target all of the Kindle Fire models within a single application. In this situation, the application submission process allows multiple application binaries to be uploaded for a single application. Each binary is then configured to indicate to Amazon the Kindle Fire devices with which the binary is configured to work. When a user subsequently purchases the application, Amazon ensures that the correct binary is downloaded for the user’s device.
It is also important to be aware that it may not always make sense to try to provide support for every Kindle Fire model. There is little point, for example, in making a video chat application available on Kindle Fire models that have neither a microphone nor a camera. In this case, a single binary could be uploaded to the distribution portal and configured for availability only on the Kindle Fire HD models.
== Summary ==
There is more to completing an Android application than making sure it works on a single Kindle Fire model. Before an application is submitted to the Amazon App Store, it should first be tested on each Kindle Fire on which it is intended to be made available. This includes making sure that the user interface layouts and images scale correctly for each display variation and taking steps to ensure that the application gracefully handles the absence of certain hardware features on earlier Kindle Fire models. It is also possible to submit to the distribution portal a different application binary for specific Kindle Fire models, or to state that a particular application simply does not support certain devices.
<google>BUY_KINDLE_FIRE</google>
<hr>
<table border="0" cellspacing="0" width="100%">
<tr>
<td width="20%">[[A Kindle Fire Amazon Mobile Ads API Example Application|Previous]]<td align="center">[[Kindle Fire Development Essentials|Table of Contents]]<td width="20%" align="right">[[Submitting an Application to the Amazon Mobile App Distribution Portal|Next]]</td>
<tr>
<td width="20%">A Kindle Fire Amazon Mobile Ads API Example Application<td align="center"><td width="20%" align="right">Submitting an Application to the Amazon Mobile App Distribution Portal</td>
</table>
<tr>
<td width="20%">[[A Kindle Fire Amazon Mobile Ads API Example Application|Previous]]<td align="center">[[Kindle Fire Development Essentials|Table of Contents]]<td width="20%" align="right">[[Submitting an Application to the Amazon Mobile App Distribution Portal|Next]]</td>
<tr>
<td width="20%">A Kindle Fire Amazon Mobile Ads API Example Application<td align="center"><td width="20%" align="right">Submitting an Application to the Amazon Mobile App Distribution Portal</td>
</table>
<hr>
<google>BUY_KINDLE_FIRE</google>
Before being made available for purchase on the Amazon App Store, an application must first be submitted to the Amazon Mobile App Distribution portal for review and approval. One of the most important steps to take before submitting an application is to decide which Kindle Fire models the application is intended to support and, more importantly, that the application runs without issue on those devices.
This chapter will cover some of the areas to consider when making sure that an application runs on the widest possible range of Kindle Fire models and what to do when support for all Kindle Fire models is not possible.
== Handling Different Kindle Fire Displays ==
The Kindle Fire comes in a variety of different screen sizes and resolutions. The ideal solution is to design the user interface of your application so that it appears correctly on all members of the Kindle Fire device family. The best way to achieve this is to design the user interface using layout managers that do not rely on absolute positioning (in other words specific X and Y coordinates) such as the RelativeLayout so that views are positioned relative to both the size of the display and each other.
Similarly, avoid using specific width and height properties wherever possible. When such properties are unavoidable, always use density-independent (dp) values as these are automatically scaled to match the device display at application runtime.
Having designed the user interface, be sure to test it on each device on which it is intended to be supported. In the absence of the physical device hardware, use the emulator templates provided by Amazon.
In the event that it is not possible to design the user interface such that a single design will work on all Kindle Fire devices, another option is to provide a different layout for each display.
== Creating a Layout for each Kindle Fire Display ==
The ideal solution to the multiple display problem is to design user interface layouts that adapt to the display size of the device on which the application is running. This, for example, has the advantage of having only one layout to manage when modifying the application. Inevitably, however, there will be situations where this ideal is unachievable. Another option is to provide different layouts, each tailored for a specific Kindle Fire display. This involves identifying the smallest width qualifier value of each display and creating an XML layout file for each one. The smallest width value of a display indicates the minimum width of that display measured in dp units. The smallest width values for the Kindle Fire family of devices are as follows:
* Kindle Fire (2nd Generation) – sw600dp
* Kindle Fire HD 7” – sw533dp
* Kindle Fire HD 8.9” – sw800dp
Notable by its absence from the above list is the first generation Kindle Fire. This is because the concept of smallest width was not introduced into Android until version 3.2. As such, this value is not available for the first generation Kindle Fire. This, however, can be resolved by allocating the default layout to the first generation Kindle Fire and setting specific layouts for those devices that support the smallest width qualifier.
Display-specific layouts are implemented by creating additional sub-directories under the res directory of a project. The naming convention for these folders is:
<pre>
layout-<smallest-width>
</pre>
For example, layout resource folders for the entire family of Kindle Fire devices would be required as follows:
* ''res/layout'' - Kindle Fire (first generation)
* ''res/layout-sw600dp'' – Kindle Fire (second generation)
* ''res/layout-sw533dp'' – Kindle Fire HD 7”
* ''res/layout-sw800dp'' – Kindle Fire HD 8.9”
Each folder must, in turn, contain a copy of the layout XML file adapted for the corresponding display, all of which must have matching file names. Once implemented, the Android runtime system will automatically select the correct layout file to display to the user to match the device display.
== Providing Different Images ==
User interface layouts are not the only area of concern when adapting an application for different screen densities, dimensions and aspect ratios. Another area to pay attention to is that of images. An image that appears correctly scaled on an HD 8.9” screen, for example, might not appear correctly scaled on a first generation Kindle Fire device. As with layouts, however, multiple sets of images can be bundled with the application, each tailored for a specific display. This can once again be achieved by referencing the smallest width value. In this case, drawable folders need to be created in the res directory. For example:
* ''res/drawable'' - Kindle Fire (first generation)
* ''res/drawable-sw600dp'' – Kindle Fire (second generation)
* ''res/drawable-sw533dp'' – Kindle Fire HD 7”
* ''res/drawable-sw800dp'' – Kindle Fire HD 8.9”
Having created the folders, simply place the display specific versions of the images into the corresponding folder, using the same name for each of the images.
Alternatively, the images may be categorized into broader display densities using the following directories:
* ''res/drawable-mdpi'' – First and second generation Kindle Fire devices
* ''res/drawable-hdpi'' – Kindle Fire HD 7” and Kindle Fire HD 8.9”
== Checking for Hardware Support ==
By now, it should be apparent that not all Kindle Fire models were created equal. By far the weakest links in the chain are the first and second generation Kindle Fires (no camera or microphone). An application that makes use of these hardware features should include code to gracefully handle the absence of specific hardware on older models of device. This typically involves performing a check to find out if the hardware feature is missing, and subsequently reporting to the user that the corresponding application functionality will not be available.
The following method can be used to check for the presence of a microphone:
<pre>
protected boolean hasMicrophone() {
PackageManager pmanager = this.getPackageManager();
return pmanager.hasSystemFeature(
PackageManager.FEATURE_MICROPHONE);
}
</pre>
Similarly, the following method is useful for checking for the presence of a front facing camera:
<pre>
private boolean hasCamera() {
if (getPackageManager().hasSystemFeature(
PackageManager.FEATURE_CAMERA_FRONT)){
return true;
} else {
return false;
}
}
</pre>
Map support, on the other hand, can be verified as follows:
<pre>
public boolean hasMapSupport()
{
boolean result = false;
try {
Class.forName( "com.amazon.geo.maps.MapView" );
result = true ;
}
catch (Exception e) {}
return result;
}
</pre>
== Providing Device Specific Application Binaries ==
Even with the best of intentions, there will inevitably be situations where it is not possible to target all of the Kindle Fire models within a single application. In this situation, the application submission process allows multiple application binaries to be uploaded for a single application. Each binary is then configured to indicate to Amazon the Kindle Fire devices with which the binary is configured to work. When a user subsequently purchases the application, Amazon ensures that the correct binary is downloaded for the user’s device.
It is also important to be aware that it may not always make sense to try to provide support for every Kindle Fire model. There is little point, for example, in making a video chat application available on Kindle Fire models that have neither a microphone nor a camera. In this case, a single binary could be uploaded to the distribution portal and configured for availability only on the Kindle Fire HD models.
== Summary ==
There is more to completing an Android application than making sure it works on a single Kindle Fire model. Before an application is submitted to the Amazon App Store, it should first be tested on each Kindle Fire on which it is intended to be made available. This includes making sure that the user interface layouts and images scale correctly for each display variation and taking steps to ensure that the application gracefully handles the absence of certain hardware features on earlier Kindle Fire models. It is also possible to submit to the distribution portal a different application binary for specific Kindle Fire models, or to state that a particular application simply does not support certain devices.
<google>BUY_KINDLE_FIRE</google>
<hr>
<table border="0" cellspacing="0" width="100%">
<tr>
<td width="20%">[[A Kindle Fire Amazon Mobile Ads API Example Application|Previous]]<td align="center">[[Kindle Fire Development Essentials|Table of Contents]]<td width="20%" align="right">[[Submitting an Application to the Amazon Mobile App Distribution Portal|Next]]</td>
<tr>
<td width="20%">A Kindle Fire Amazon Mobile Ads API Example Application<td align="center"><td width="20%" align="right">Submitting an Application to the Amazon Mobile App Distribution Portal</td>
</table>
