Have you been familiar enough with Pixel Density? If you are a mobile apps developer, this term is your everyday stuff. However, if you are a web developer and want to know more about how it works, Pixel density may be a new challenge for you. Let’s take a look on a brief explanation of pixel density.
Pixel density (resolution) of an electronic image device uses pixels per inch (PPI) or pixels per centimeter (PPCM) as its measurement, such as a computer monitor or television display, or image digitizing device such as a camera or image scanner. Moreover, the density of horizontal and vertical may differ on devices that have non-square pixels but may be the same with devices which have square pixels.
Besides, PPI can also be used to describe the resolution, in pixels, of an image file. The unit is not square centimeters-a 100×100 pixel image printed in a 1 cm square has a resolution of 100 pixel per centimeter (ppcm). In fact, the measurement is meaningful when printing an object. Even though PPI refer to input resolution, it has become commonplace to refer to PPI as DPI. Industry standard, good quality photographs usually require 300 pixels per inch, at 100% size, when onto coated paper stock, using a printing screen of 150 lines per inch (lpi).
Screen frequency is determined by the type of paper the image is printed on. An absorbent paper surface, uncoated recycled paper for instance, lets ink droplets spread (dot gain)-so requires a more open printing screen. Input resolution can therefore be reduced to minimize file size without loss in quality, as long as the quality factor of 2 is maintained.
Although the system performs scaling and resizing to make your application work on different screens, you should make the effort to optimize your application for different screen sizes and densities. In doing so, you maximize the user experience for all devices and your users believe that your application was actually designed for their devices-rather than simply stretched to fit the screen on their devices.
By following the practices described in this document, you can create an application that displays properly and provides an optimized user experience on all supported screen configurations, using single .apk file.
Note: The information in this document assumes that your application is designed for Android 1.6 (API Level 4) or higher. If your application supports Android 1.5 or lower, please first read strategies for Android 1.5.
Also, be aware that Android 3.2 has introduced new APIs that allow you to more precisely control the layout resources your application uses for different screen sizes. These new features are especially important if you’re developing an application uses for different screen sizes.
Overview of Screens Support on How to Support Multiple Screens
In this section, we are going to discuss about an overview of Android’s support for multiple screens, including: an introduction to the terms and concepts used in this document and in the API, a summary of the screen configurations that the system supports, and an overview of the API and underlying screen-compatibility features.
- Explicitly Proclaim which Screen Sizes Your Application Can Support
In order to ensure that only devices with the screens you support can download your application, you need to state which screen sizes your application supports. Declaring support for different screen sizes can also affect how the system draws your application on larger screens-specifically, whether your application runs in screen compatibility mode.
Moreover, you should include the <supports-screens> element in your manifest file.
- Provide Different Layouts for Different Screen Sizes
By default, Android resizes your application layout to fit the current device screen in most cases which is fine; however your UI might not look as good and might need adjustments for different screen sizes. The configuration qualifiers you can use to provide size specific resources are small, normal, large and xlarge. For example, layouts for an extra-large screen should go in layout-xlarge/.
Beginning with Android 3.2 (API level 13), the above size groups are deprecated and you should instead use the sw<N>dp configuration qualifier to define the smallest available width required by your layout resources.
- Provide Different Bitmap Drawables for Different Screen Densities
In order to render at the appropriate physical size on each device, Android scales your bitmap drawables (.png, .jpg, and .gif files) and Nine-Patch drawables (.9.png files). For examples, the system scales them up when on a high-density screen, and scales them down when on a low-density screen, if your application provides bitmap drawables only for the baseline. This scaling can cause artifacts in the bitmaps. You should include alternative versions at different resolutions for different screen densities, to ensure your bitmaps look their best.