34,333
edits
Changes
→Creating a Layout for each Display Size
<pre>
layout-<smallest-width>
</ptrpre>
For example, layout resource folders for the a range of devices might be configured as follows:
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 large tablet screen, for example, might not appear correctly scaled on a smaller phone based 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 – The default image folder
* res/drawable-sw200dp
* res/drawable-sw600dp
* res/drawable-sw800dp
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 based on the pixel density of the display:
* res/drawable-ldpi - Images for low density screens (approx. 120 dpi)
* res/drawable-mdpi – Images for medium-density screens (approx. 160 dpi)
* res/drawable-hdpi – Images for high-density screens (approx. 240 dpi)
* res/drawable-xhdpi – Images for extra high-density screens (approx. 320 dpi)
* res/drawable-tvdpi – Images for displays between medium and high density (approx. 213 dpi)
* res/drawable-nodpi – Images that must not be scaled by the system
== Checking for Hardware Support ==
By now, it should be apparent that not all Android devices were created equal. An application that makes use of specific hardware features (such as a microphone or camera) should include code to gracefully handle the absence of that hardware. 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>
== Providing Different Images ==
