Understanding Density Independence in Android

Https://www.captechconsulting.com/blogs/understanding-density-independence-in-android

Background

Android is a mobile operating system with very few limitations on its devices ' hardware. Manufacturers can create devices of almost any screen shape, size, and density. Devices can has physical keyboards and buttons, or only virtual keyboards and buttons. While this flexibility are great for allowing device customization, it creates a few hurdles for application developers. First, how can apps support all of the these various devices configurations with a consistent experience? Also, how can apps take advantage of devices that has higher end hardware or more features than others? Android is built with this in mind, and gives developers tools-to-support all device configurations, and optimize the EXP Erience for other device configurations, which'll be covered later.

In order a application to being flexible and compatible with any device configuration, careful thought are required to Make sure the user experience is appropriate across configurations. When creating a Android application, designers and developers must create user interfaces that work well with the small s Pace of a phone, and the large space of a tablet. They also must take to account have image resources optimized for high and low density screens. While there is many ways to create optimized user interfaces for different screen sizes and orientations, the focus of th Is blogging is what Android supports different screen densities.

The basic design concept of Android is to has the user interfaces that has elements that was about the same physical size, R Egardless of the screen density. Why? Simple, a user's finger is the same physical size no matter what's the screen density is. A button or clickable item should render about the same physical size (larger than a fingertip) on any device. This also goes for text, words should render about the same (readable) font size across devices.

Screen Density, not Resolution

Screen density are a ratio of resolution and display size, which can be quantified as dots per inch, or dpi. The higher dpi, the smaller each individual pixel are, and the greater clarity. Simply put, a higher dpi means more detail are displayed per inch, but does not necessarily correlate with a higher screen Resolution. For example, the Galaxy nexus (4.65 "diagonal) have a 720x1280 px resolution, while the Nexus 7 (7" diagonal) have an 800x12 Resolution PX. It's a common misconception to assume that they has about the same screens density, since their resolutions is almost ID Entical. However, the Galaxy Nexus have a screen density of about dpi and the Nexus 7 have a screen density of 216 dpi, not even Close. This was because while they was displaying the same resolution, they was also displaying it in different amounts of space. Again, screen density are a ratio of resolution and display size, and both factors contribute to the density.

Density Buckets

There is a myriad of Android devices with varying screens densities, which can range from the DPI to over 480 dpi. In order to optimize images for all these screens densities, images need to is created at different resolutions. However, trying to optimize every image resource for every possible density would be incredibly tedious, cause app sizes T o be enormous, and simply are not a feasible solution. As a compromise, Android uses density "buckets" that is used to group devices together within certain screen density rang Es. This, apps is only required to optimize images for each density bucket, instead of every possible density. This keeps the workload reasonable for designers and developer, and also prevents the application size from ballooning. Of course, there is a tradeoff, leading to variance in the physical rendered size of images depending on device density, W Hich'll be shown later.

So, how does designers and developers optimize image resources for these density buckets? First, the rendered size of the image needs to be decided. For example, say an icon was intended to being 0.5x0.5 in while rendered on a screen. Next, the image must is created at the largest density supported, or as a scalable vector graphic. Best practice are to support the maximum density, which currently are xxhdpi at 480 dpi. At 480 dpi, a 0.5x0.5 with image converts to 240x240 px. Once The maximum density version of the graphic resource is created @ 240x240 px, it can then be scaled down proportional Ly to create each subsequent density bucket version, each using the same file name. Google recommends creating a tvdpi version at 213 dpi, since it was only needed for certain applications and used by a Small set of devices. Once All versions has been created, they can be added to ' drawable ' folders, using resource identifiers to tell Android W Hat density bucket They is intended for. Last, simply RefeRence the graphic resource in XML layouts and code using its name generated in the ' R ' file, which holds references to all The resources in the app. Android would then load the resources at runtime, doing it best to match the actual device ' s config Uration to the resource identifiers applied. If any density version of a image resource is not included, Android would use another density version and scale it to the Proportional size required. It is not a recommended to let Android does this, as it was not as efficient nor as precise at manipulating resources as image Editing software.

Dimension Units

In Android, user interfaces can is created in XML, and programmatically in code. In order to express a form of distance or length, there is several units for dimensions. These can used on elements to set widths, heights, margins, padding, and more.

px -an actual pixel in the screen. This was a density dependent unit, and the physical size of a single "px" varies depending in screen density.

in-A physical inch on the screen. This was a density independent unit, and the physical size of a single "in" are the same on every screen density. The number of pixels a single ' in ' translates to varies depending on screen density.

mm -A physical millimeter on the screen. This was a density independent unit, and the physical size of a single "MM" are the same on every screen density.  There is 25.4 "mm" in an inch. The number of pixels a single "mm" translates to varies depending in screen density.

PT -A point, a common font size unit, in the screen. This was a density independent unit, and the physical size of a single "PT" are the same on every screen density. There is "PT" in an inch. The number of pixels a single "pt" translates to varies depending in screen density.

dp  -A density independent pixel. This was a density independent unit, however the physical size of a single "DP" are only approximately the same on every SCR Een density. There is approximately "DP" in an inch. A scaling factor, depending on the density bucket of the device, was applied to convert "DP" to the number of pixels at 160 Dpi. The number of pixels a single "DP" translates to varies depending on the pixel in screen density and the density bucket th e device falls into.

SP -A scale independent pixel, specially designated for text sizes. This was a density independent unit, however the physical size of a single "SP" are only approximately the same on every SCR Een density. Scaling factors, depending on the density buckets of the device, as well as the user's text size preference, is applied to Convert "SP" to the number of pixels at p DPI. The number of pixels this translates to varies depending in screen density and the density bucket, the device falls into.

The Magic of "DP"

As discussed, "px" is not density independent, and was not a same size on every device, while ' in ', "MM", and "PT" are de Nsity Independent and the same size on every device. However, "DP" and "SP" is a little bit different from the rest, since they is density independent, but they is not the Same size on every device. Why was that? The answer is in how "DP" and "SP" were computed into pixels. Android uses MDPI, DPI, as its baseline density, where 1DP is 1px. Essentially, "DP" Can is thought of as "px" at the DPI. This is why the converts DP is on 1 in. So depending on the ratio between a devices density buckets and the baseline density, mdpi, a scaling factor is applied to Convert "DP" to "PX".

The reason "DP" tends to vary in physical size are due to the same scaling factor being applied for the entire density buck Et. The scaling factor is computed with the density bucket's dpi, and not the device ' s actual dpi. When the device's DPI is not exactly the same as its density bucket's dpi, the same amount of "DP" converts to the same AM Ount "px". This leads to the same amount of "PX" being displayed on different density screens, which render at different sizes.

The table above shows how-DP converts to "PX" on different density devices. DP should roughly translate to 0.625 in, and does so perfectly at the bucket sizes. However, when the DPI of the device was less than the density bucket ' s dpi, its pixels was physically larger, and the same Amount of "DP" would render larger, and vice versa.

So this begs the question, what does "DP" allow this variation in its physical size? Basically, Android sacrifices some precision in physical size, in order to maintain performance and display quality. Since "DP" scales to "px" using Android ' s density buckets ratios (0.75:1.0:1.5:2.0:3.0), this allows for minimal "px" round ing and simpler computations. Also, since the scaling factors is proportional to the density bucket ratios, "DP" would render proportionally to image re Sources provided for each density. Lastly, when scaling graphics, it's best to stay as close to whole numbers and simple fractions, as complex fractions can Create artifacts and aliasing.

Defining UI Element Bounds

When defining width and height attributes on a user interface element, there is special options available, as well as the Dimension units.

Wrap_content -this would "wrap" the bounds of the element to being just large enough to contain its content (images, text, etc), children elements contained within it, plus padding. Essentially, this set the element is the size of its largest content, and would not adjust the size of the element.

match_parent (Fill_parent deprecated in API 8)-This would "match" the bounds of the element to its parent element, using the maximum a llowed space, minus padding. Essentially, this lets the element is the max size its parent allows, and would adjust the size of the element if needed.

Dimension Unit -this would set the bounds of the element to precisely the size of the dimension unit, each discus Sed earlier. Essentially, this sets the element is the exact size of the dimension unit, and would adjust the size of the element if nee Ded.

Demo

To demonstrate the comes together, creating and testing an example application are necessary. For the example, take a-design that uses a 200x200 px-image at xhdpi, or-dpi. For simplicity, the image resource can is named "Android_logo". Using the 200x200 PX resolution at $ dpi as the desired physical size, the alternate image sizes can be computed.

200x200px Image at xhdpi (320dpi)

After computing the required density specific image dimensions, they can is created by scaling down from the maximum Densi Ty version, as explained earlier. Next, each density version of the image can is put to its respective "drawable" folder using Resource identifiers. Android would then choose the best resource at runtime, depending on the configuration of the device.

Now, to exhibit the possible ways of keeping density independence, the image should is set to the same physical size, usin G Each of the density independent dimension units. Since "px" is not density independent, and "SP" are designed for text, they can omitted.

Device example:xhdpi Bucket

By using a layout with the same image using each dimension unit set to the same physical size, it's possible to compare H ow each dimension unit works. When running on a emulator at the images display at the exact same size, for every dimension unit. This is expected since the DPI of the emulator exactly matches the xhdpi density bucket, at. However, when running on a Galaxy Nexus, which also falls into the xhdpi density bucket, there is some variations in the Size of the image.

320DPI Emulator screenshot

Galaxy Nexus screenshot

Upon inspection, it is apparent, the images set with "Wrap_content" and "DP" match in size, while the images set with "In", "MM", and "PT" also the match in size. However, the groups or images don ' t match each of the other. So, what's happening here? As discussed earlier, "Wrap_content" and "DP" use the density buckets ratios to properly convert their dimensions. So, the image computes to 200x200 px on the device. However, the Galaxy Nexus ' s actual screen density are not exactly at the-DPI, it has a 315.3 xdpi and a 318.7 ydpi. Since The actual density is less than the xhdpi bucket density of the. dpi, the pixels on the actual device would be larger than the intended physical size of 0.625 in.

When analyzing the images is set with "in", "MM", and "PT", notice that each image converts to 197.1x199.2 px. As discussed earlier, "in", "MM", and "PT" all with the actual device ' s density to convert their dimensions to pixels. Since The actual density of the Galaxy Nexus is less than the xhdpi buckets density at-Z, fewer pixels is needed to Cover 0.625x0.625 in, and the image gets scaled down.

When comparing the rendered images, it's apparent, the images set with "Wrap_content" and "DP" has less precise phys ical sizes, but their image quality are better than the images set with "in", "MM", and "PT".

No scaling with ' wrap_content ' and ' DP ' (left). Scaling with ' in ', ' pt ', and ' mm ' (right).

Device example:hdpi Bucket

Next, when running on a emulator at + dpi, the images display at the exact same size, for every dimension unit.  Again, this is expected since the DPI of the emulator exactly matches the hdpi density buckets at + dpi. But as before, when running on a hdpi device, this time a Droid incredible, there is some variations in the size of the Image.

240DPI Emulator screenshot

Droid Incredible screenshot

Similar to before, the Droid incredible displays the "Wrap_content" and "DP" images at 150x150 px. Since the Droid incredible ' s actual density is 254x254 dpi, greater than the hdpi buckets at + dpi, this means the pixels On it screen is smaller than the bucket size. This causes the 150x150 px image to appear smaller than the baseline size of 0.625 in. The images set with ' in ', ' mm ', and ' pt ' display at 158.8x158.8 px Since more pixels is needed to cover 0.625x0.625 in, a nd the image gets scaled up.

Just like on the Galaxy Nexus, the ' wrap_content ' and ' DP ' images render with less precise sizing, but better image qualit Y.

No scaling with ' wrap_content ' and ' DP ' (left). Scaling with ' in ', ' pt ', and ' mm ' (right).

Dimension Unit Best Practices

px -Does not keep density independence. Should never be needed.

in/mm/pt -keeps density independence, but computes to exact amounts of pixels which can hurt performance, and CA Use image artifacts and aliasing. Necessary if precise sizing is required, and any deviation are unacceptable. Also useful to set distances between elements when exact distances is needed.

DP -keeps density independence and best image quality, but at the cost of small deviations in physical size. Since it computes using density bucket scaling, it provides proportionally accurate sizing with image resources. This was the recommended dimension unit to use for setting bounds on elements or distances in between them.

SP -keeps density independence, and font quality, but at the cost of small deviations in physical size. The recommended dimension unit to use for font sizing only, as it takes density and the user ' s text size Preferenc e into account.

Summary

To recap, the keys to keeping density independence:

• Decide the required physical rendered size needed for each image asset.
• Design Vector graphic image assets, or raw image assets larger than the size needed for the maximum density bucket.
• Create density specific versions of every image asset for each density buckets, and place them into the proper "drawable" R Esource folder using identifiers.
• When setting bounds for images, use ' wrap_content ' for best display, ' match_parent ' to fill the display, or ' DP ' for a fix Ed size.
• When the setting distances in layouts, use the "DP" for the best display. Only use ' in ', ' mm ', or ' pt ' If a precise size is required. There should never is a use for "px".

With a understanding of how Android handles displaying user interfaces on different density screens, it becomes much easi Er to design and develop applications optimized for any density display.

Understanding Density Independence in Android