Handling different display devices in android

Handling Different Device Displays

Android devices come 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 the widest possible range of devices. 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 wherever possible to test on the widest possible range of devices.
In the event that it is not possible to design the user interface such that a single design will work on all Android devices, another option is to provide a different layout for each display.

Creating a Layout for each Display Size

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 given the vast difference in screen size between a phone and a tablet. Another option is to provide different layouts, each tailored for a specific display category. 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.
Display-specific layouts are implemented by creating additional sub-directories under the res directory of a project. The naming convention for these folders is:
layout-<smallest-width>
For example, layout resource folders for a range of devices might be configured as follows:
  • res/layout – The default layout file
  • res/layout-sw200dp
  • res/layout-sw600dp
  • res/layout-sw800dp
Alternatively, more general categories can be created by targeting small, normal, large and xlarge displays:
  • res/layout – The default layout file
  • res/layout-small
  • res/layout-normal
  • res/layout-large
  • res/layout-xlarge
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

Alternatively, the images may be categorized into broader display densities using the following directories based on the pixel density of the display:
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.
  • 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:
protected boolean hasMicrophone() {
 PackageManager pmanager = this.getPackageManager();
 return pmanager.hasSystemFeature(
              PackageManager.FEATURE_MICROPHONE);
}
Similarly, the following method is useful for checking for the presence of a front facing camera:
private boolean hasCamera() {
 if (getPackageManager().hasSystemFeature(
           PackageManager.FEATURE_CAMERA_FRONT)){
         return true;
      } else {
              return false;
      }
}

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:
protected boolean hasMicrophone() {
 PackageManager pmanager = this.getPackageManager();
 return pmanager.hasSystemFeature(
              PackageManager.FEATURE_MICROPHONE);
}
Similarly, the following method is useful for checking for the presence of a front facing camera:
private boolean hasCamera() {
 if (getPackageManager().hasSystemFeature(
           PackageManager.FEATURE_CAMERA_FRONT)){
         return true;
      } else {
              return false;
      }
}

Comments

Post a Comment

Please post comments here:-)

Popular posts from this blog

Android Objective type Question and Answers

Android Objective type Question and Answers 1) Once installed on a device, each Android application lives in_______?  a)device memory  b)external memory  c) security sandbox  d)None of the above Ans) c 2)Parent class of Activity?  a)Object  b)Context  c)ActivityGroup  d)ContextThemeWrapper Ans) d 3)What are the Direct subclasses of Activity?  a)AccountAuthenticatorActivity  b) ActivityGroup  c) ExpandableListActivity  d) FragmentActivity  e) ListActivity  f) all the aove Ans) f 4)What are the indirect Direct subclasses of Activity?  a)LauncherActivity  b)PreferenceActivity  c) TabActivity  d)All the above Ans) d 5)Parent class of Service?  a)Object  b)Context  c) ContextWrapper  d)ContextThemeWrapper Ans) c 6)What are the indirect Direct subclasses of Services?  a) RecognitionService  b) RemoteViewsService  c)SpellCheckerS...
Read more

Android Questions and Answers for written exams

1. bmgr tool is used to a)take backup of the applications b)to restore operations c)wipe archived data for a specific application d)all of the above ans: d 2. foreground service a)starts when you call start foreground() b)may or may not provide a notification for the status bar c)notification can't be dismissed unless the service is either stopped or removed from the foreground d)both a & c ans:d 3. A1,A2,A3 and A4 are activities called using intents.Then A1-A4-A2--A3.A4 calls A2 with intent flag FLAG_ACTIVITY_NO_HISTORY.When finish method is called on A3, What will be the currtent running activity? a)A1 b)A4 c)A3 d)A2 ans: b 4. A1,A2,A3 and A4 are activities called using intents.Then A1-A2-A4--A3.A2 calls A4 with intent flag FLAG_ACTIVITY_CLEAR_TOP.When finish() method is called on A3, what will be the current running activity? a)A4 b)A3 c)A2 d)A1 Ans:  a 5. A1,A2,A3 and A4 are activities called using intents.Then A1-A2-A3-A4. A3 call...
Read more

SCJP1.6 Question and Answers

Question – 1 What is the output for the below code ? 1.         public class A { 2.         int add(int i, int j){ 3.                     return i+j; 4.                     } 5.         } 6.         public class B extends A{ 7.         public static void main(String argv[]){ 8.         short s = 9; 9.         System.out.println(add(s,6)); 10.        } 11.        } Options are A. Compile fail due to error on line no 2 B. Compile fail due to error on lin...
Read more