android-support multi-screen-1

Original link: Supporting multiple Screens

Android runs on many different screen sizes (screens size) and density (density) devices. For applications, the Android system provides a consistent cross-device development environment that handles much of the work of the application adaptation screen. At the same time, in order to optimize the UI design for different screen configurations, the system also provides APIs that allow your application to control specific screen sizes and densities. For example, you might want the tablet's UI to be different from the phone.

While your application will work on a different screen by scaling and resizing, you should also try to optimize on different screens. By doing so, you can optimize the user experience for all devices, and your users will believe that your application is designed for their device, which is much better than simply stretching to fit their device.

Note: This document assumes that your app is designed for Android 1.6 (API level 4) or later, if your app supports Android 1.5 or lower, read the Android 1.5 screen adaptation policy first.
Also, note that Android 3.2 has a new API to give you more precise control over the layout resources of the application for different screen sizes. These new features will make your application especially important for tablet optimization. More details will be mentioned in the section "declaring Tablet Layouts for Android 3.2".

1: Screen Support overview

This section provides an overview of Android's support for different screens, including an introduction to the terminology and concepts that appear in the documentation and APIs, the system-supported screen configurations and related APIs, and screen-compatible underlying features.

1.1: Name and concept

Display size (screen size)
The actual physical size, measured according to the diagonal of the screen.
For the sake of simplicity, Android classifies all actual screen sizes into four generalization sizes: small, normal, Large,extra large.

Screen density (density)
The number of pixels contained in a physical area of the screen, usually relative to the dpi (dots per inch). For example, a "low" density screen has more pixels than a "normal" or "high" density screen.
For simplicity, Android categorizes the density of all actual screen densities at four kinds of generalization: low, Medium, High, extra.

Direction (Orientation)
The screen orientation viewed from the user's perspective. This refers to horizontal screen (landscape) or vertical screen (portrait), which means that the screen aspect ratio (aspect ratio) is wide or high respectively. Note that screens for different devices do not just have the default screen orientation, they may also change when the user flips the screen at run time.

Resolution (Resolution)
The total number of physical pixels on the screen, and when multi-screen support is performed, the program does not have to deal directly with the resolution; The program should only care about the size and density of the screen, such as several generalization dimensions and density collations specified above.

Density-independent pixels (density-independent pixel [DP])
Virtual pixel units are also a density-independent way that you should use when defining UI layouts, expressing dimensions and locations.
On the 160dpi screen (which is the baseline of the screen for "medium" density), a density independent pixel (DP) equals a physical pixel (px). At run time, the system transparently handles the scaling of the DP units based on the actual screen density. DP units and PX units are easy to replace:
PX = DP * (dpi/160).
For example: On a 240dpi screen, 1DP = 1.5px. You should always use DP to define the size of your app's UI so that your UI can be displayed on a different density screen.

1.2: Supported screen Range

Starting with Android 1.6 (API level 4), Android supports different screen sizes and densities, reflecting the many different screen configurations that the device may have. You can use the features of the Android system (feature) to optimize your application's UI for each screen configuration, and to ensure that your program UI is not only rendered reasonably, but also provides the best user experience possible for every user's screen.

To simplify the multi-screen UI design, Android divides the actual screen size and density into:

• Four generalization sizes: small, normal, large, xlarge Note: Starting with the Android3.2 (API level 13), this size division is obsolete, replacing a new technology for managing screen size and density. If you are developing Android 3.2 or higher, read the article for more information on declaring Tablet Layouts for Android 3.2.

• Density of four generalizations: ldpi (Low), MDPI (Medium), hdpi (High), xhdpi (extra high)

The Generalization screen size (generalized size) near the baseline configuration (baseline config) is normal, and the generalization screen density (generalized density) is mdpi. This baseline is built on the screen configuration of the first Android-powered phone (T-mobile G1), which has a HVGA screen (which is the only screen configuration supported by Android prior to version 1.6).

Each generalization size and density corresponds to a range of actual screen sizes and densities. For example, two devices that claim the same normal screen size may have a different actual screen size and aspect ratio (aspect ratio). Similarly, a device that also declares the same hdpi screen density, its actual pixel density may also be somewhat different. Android abstracts these minor inconsistencies in the application, so you just need to provide a UI design for the generalized dimensions so that the system can handle the necessary adjustments. Figure one explains how different sizes and densities are categorized.

Figure 1

When you design the UI for different screen sizes, you'll find that each design requires a minimum of space. Therefore, on top of each generalization screen size, the system-defined minimum resolution is associated. These minimum dimensions are in "DP" (you should use it when defining the layout to keep the system from worrying about screen density changes).

• XLarge minimum space is 960DP x 720DP

• Large minimum space is 640DP x 480DP

• Normal has a minimum space of 470DP x 320DP

• Small minimum space is 426DP x 320DP

Note: The minimum screen size definition before and after Android 3.0 is not the same. So you may encounter some of the wrong points in normal and large devices. These will also be built on the physical resolution of the screen, so it will make a difference across the screen, such as a 720 tablet with a system bar, which actually has a little less free space for the application because the space is already occupied by the system bar.

To optimize your application UI for different screen rulers, you can provide optional resources for different generalization sizes and densities (alternative resource). Typically, you should provide selectable layouts (layouts) to different screen sizes and selectable bitmap images to give different screen densities. At run time, the system chooses the right resource based on the generalization size and density of the current device screen.

You do not need to provide an optional resource for each combination of screen size and density. The system provides a very robust compatibility feature (compatibility feature) to handle most of the work that the application renders on different devices, implementing your UI by gracefully resizing (resize) The size of the technology. (described in the next section, "Best Practices")

Note: The features that define the generalization screen size and density of the device are independent of each other. For example: a WVGA high-density screen (high-density) is considered a normal size screen because its physical size is similar to that of T-mobile G1 (Android's first device and benchmark screen configuration). On the other hand, a WVGA medium density screen (medium-denity) will be considered a large size screen. Although they all have the same resolution (resolution, the same number of pixels), WVGA's medium-density screen has a lower screen density, meaning that the physical size of each pixel is larger, so the entire screen is larger than the benchmark (normal) screen.

1.3: Density-independent (Density independence)

When a UI element is rendered on a screen of different densities, the program maintains its physical size (from the user's perspective) through "pixel Independent (density independence)".

Maintaining density independence is important because, without it, UI elements (such as buttons) can be physically rendered on low-density screens at a higher density than high-density. Such density-dependent (density-related) dimensional changes can cause problems with the layout and usability of the application. Figures 2 and 3 show us each of these differences.

Figure 2: The case of different densities is not supported, from left to right is the screen of low, medium, and high density.

Figure 3: Support for different densities, from left to right are low, medium, and high density screens.

The Android system helps your application to achieve density independence in two ways:

• The system scales the DP units appropriately at the current screen density

• The system scales the drawing resources appropriately at the current screen density (drawable Resource)

In Figure 2, the dimensions (dimension) of the text view and bitmap drawable are set to pixels (px units), so these views are larger on low-density screens than high-density screens. This is because, despite their actual screen size, high-density screens have more pixels per inch (the same pixels occupy less space). In Figure 3, the dimensions of the layout are specified as density independent (density-independent) pixels (DP units). Because the density-independent baseline is a medium-density (medium-density) screen, a device with a medium-density screen has the same visual effect as Figure 2. However, for low-density and high-density screens, the system scales the density-independent pixels accordingly to fit the screen.

In most cases, you can ensure density independence by simply using DP units or "Wrap_content" in your program. The system scales appropriately bitmap drawable displayed on different dimensions, based on the appropriate scaling factor for the current screen density.

However, the scaling of bitmaps can lead to blurring or mosaic, which you might notice on the screen. To avoid these phenomena, you should provide an optional bitmap resource for different densities (alternative bitmap resource). For example, you should provide higher-resolution bitmaps for high-density (high-density) screens, instead of using them to adjust bitmaps designed for medium-density (medium-density) screens. The next sections will describe more about how to provide optional resources for different screen configurations.

2: How to support multi-screen

Android's support for multiple screens is based on its ability to manage the layout of the application and the rendering of the bitmap (bitmap drawables), making it a reasonable way to work in the current screen configuration. The system handles the rendering of the application on different screen configurations by scaling the layout to fit the screen size/density and scaling the bitmap to fit the screen density. However, to better handle different screen configurations, you should also:

(1) explicitly declare your application in the manifest file to support that screen size

By declaring the screen size supported by your application, you can guarantee that only the devices you support will be able to download your app. Declaring support for different screen sizes also affects the system drawing your application on a larger screen, specifically, whether your application is under Screen compatibility mode or not.
To declare the size of the application support, you should include the element into your manifest file.

(2) provide different layouts for different screen sizes

By default, Android will resize your app layout to fit the current device screen. In most cases, this can work well. In some cases, however, your UI may not look as good as it should, and you'll need to make adjustments to different screen sizes. For example, on a large screen, you might want to adjust the position and size of some elements to take advantage of additional screen space, or on a smaller screen, you might want to resize to make all the elements fit on the screen properly.
You can specify the configuration qualifier (config qualifiers) used by the resource for a specific size with small,normal,large and XLarge. For example, the layout of a large screen should be placed inside the layout-xlarge/.
Starting with Android 3.2 (API level 13), the above dimension classification is obsolete, instead of using the SWDP configuration qualifier to define the minimum effective width your layout resource requires. For example, if your multi-panel (Multi-pane) flat layout requires at least 600DP of screen width, you should put the appropriate resources into the layout-sw600dp/. More about using the new technology to declare layout resources in the declaring Tablet Layouts for Android 3.2 section.

(3) provide different bitmap resources for different screen densities

By default, Android scales your bitmap (. png,,jpg,and. gif file) and. 9 Picture (Nine-patch) in order to render the appropriate physical size on each device. For example, if your application provides pictures only for the benchmark medium-density screen (MDPI), the system zooms in on the high-density (high-density) screen accordingly, shrinking on a low-density (low-density) screen. These scales will affect the image. To make your pictures look more comfortable, you should provide alternative versions of different resolutions for different screen densities.
The configuration qualifiers that you can specify for a specific density resource are ldpi (low), MDPI (Medium), hdpi (High), and xhdpi (Extra high). For example, a picture on a high-density screen should be placed in the drawable-hdpi/folder.

The generalization size and density of the screen size and density configuration qualifier are discussed in the above range of screens supported section.
Note: If you are not familiar with configuring qualifiers and how the system applies them to optional resources, you can read providing alternative resources for more information.

At run time, the system uses the following steps to ensure that the resources are displayed as well as possible on the current screen:

1: The system uses the appropriate optional resources (alternative resource)
Based on the size and density of the current screen, the system will provide any size-or density-specified resources in your application. For example, if the device is a high-density screen, and the application requests a drawable resource, the system will have to follow a resource directory configured on the most matching screen. Depending on other valid optional resources, a resource directory with HDPI qualifiers (such as drawable-hdpi/) might be the best match, so the system will select Drawable resources from this directory.

2: If a valid matching resource does not exist, the system uses the default resource and then zooms in or out to meet the current screen size.
The "default" resource is those that do not have a qualifier flag configured. For example, under the drawable/directory is the default drawable resource. The system assumes that these resources are designed for the base screen size and density, which is the screen of normal size and medium density. Thus, the system will properly enlarge the default density of resources for the high-density screen, whereas the low-density screen will be scaled down. However, when the system is looking for a specific density (density-specified) resource and is not found in a specific density directory, it does not always use the default resource. The system might instead use other specific resources to scale to get better results. For example, when low-density resources are not found, the system prefers to shrink high-density resources. Because the system can easily high-density resources in accordance with the 0.5 factor to reduce it to adapt to the low-density version, which is better than the use of medium-density resources to 0.75 of the scaling factor.

For more information on how Android can select different configuration qualifier resources for screen configuration, read how Android Finds the best-matching Resource

2.1: Use config qualifier (configuration qualifier)

Android supports a variety of configuration qualifiers to allow you to control the system using optional resources. A configuration qualifier is a string that is followed by a resource directory in an Android project.
With configuration qualifiers, you need to:

1: Create a line directory under your project res/directory and use such a naming format.

• is a standard resource name (such as drawable or layout)
• is one of the configuration qualifiers in table 1 that specifies the resources to use for each screen configuration.

2: Save a resource that is appropriate for a specific configuration in this new directory. The name of the resource file must be the same as the original default.
For example: XLarge is a configuration qualifier for a large screen. When you add this string (such as Layout-xlarge) to the resource directory, the system will use those resources on the device with the extra-large screens.

Table 1. The configuration qualifier provided for different screen configurations.

Note: If you are developing Android 3.2 or later applications, follow this article declaring Tablet Layouts for Android 3.2 Gets the configuration qualifier that is used to declare the layout resource for a specific screen size.

More about how these qualifiers correspond roughly to the true screen size and density, you can see this article: Range of Screens supported, as mentioned earlier.

For example, the following list of resource catalogs in the program provides different layout designs for different screen sizes and offers different images for different screen densities.

Res/layout/my_layout.xml //layout for normal screen size ("Default")

Res/layout-small/my_layout.xml /layout for small screen size
Res/layout-large/my_layout.xml //layout for large screen size
Res/layout-xlarge/my_layout.xml //layout for extra large screen size
Res/layout-xlarge-land/my_layout.xml //layout for extra large in Landscape orientation

res/drawable-mdpi/my_icon.png //bitmap For medium density
res/drawable-hdpi/my_icon.png //bitmap for high Density
res/drawable-xhdpi/my_icon.png //bitmap for extra high Density

For more information on how to use optional resources and complete configuration qualification list characters (not just screen configuration), see providing alternative resources for this article.

It is important to note that when the Android system chooses a resource at run time, it will follow some logic to decide which is the "best matching" resource. That is, you do not need to have a resource for each screen configuration. In particular, when a resource is selected based on a size qualifier, the system uses a smaller resource if it does not have a more appropriate qualifier. (for example, if needed, a large-size screen would use Normal-size's resources). However, if the resource only exists in a qualifier larger than the current screen size, the system will not use it and your program will crash if there are no other resources that match the device configuration (for example, if all the resources are placed in the XLarge qualifier directory, but the device is Normal-size's screen). For more information on how the system chooses resources, please read how Android Finds the best-matching Resource.

Tip: If you have some picture resources that you don't want to be scaled (perhaps because you want to tweak them yourself at runtime), you should put them in the NODPI Configuration qualifier directory. Resources under this qualifier are considered to be density agnostic (density-agnostic) and the system does not scale them.

2.2: Design replaceable layouts and pictures (drawables)

The type of optional resource you want to create depends on the needs of your program. In general, you should use the dimension and orientation qualifiers to provide an optional layout resource, and use the density qualifier to provide an optional picture resource.
The following subsections summarize how you can use the size and density qualifiers to provide an optional layout or picture.

Optional layouts (alternative layouts)

In general, when you test your application in a different screen configuration, you know whether you should provide an optional layout for different screen sizes. Like what:

• When testing on a small screen, you may find that your layout is not appropriate. For example, a row of buttons on a small-screen device might not fit the width of the screen. In this case, you should provide an optional layout for the small screen to adjust the size or position of the button.

• When testing on a large screen, you may find that your layout is not using the big screen effectively and there is a noticeable stretching phenomenon. In this case, you should provide an optional resource layout for the oversized screen that is designed to redesign the optimized UI. Although your program may workplace well without providing an optional layout for a large screen, it is important for users to appear that the program is designed for their device. If the UI is visibly stretched, the user may not be satisfied with the experience of the program.

• Also, when comparing the test horizontal and vertical screens, you may notice that the UI elements at the bottom of the vertical screen should be placed on the right side of the screen.

To summarize, you should ensure that your program layout:

• Suitable for small screens (so that users can apply your program normally)

• Optimize for large screens to take advantage of additional screen space

• Optimized for both horizontal and vertical screens

If your UI uses pictures to fill the dimensions of the view after the system has scaled the layout (for example, the background of the button), you should use the. 9 picture file. A. 9 file is built on a PNG file that specifies a two-D stretch area. When the system needs to scale the bitmap that the view uses, the system stretches. 9 picture-specific areas. This way, you don't have to provide different images for different screen sizes, because. 9 pictures can be resized to any size. However, you should provide different versions of. 9 Images for different screen densities.

Optional picture (alternative drawables)

Almost all applications should have an optional picture resource with a different screen density, because most applications have an app launcher icon that looks pretty at full screen density. Similarly, if your program contains other images (such as menu icons or other graphics in the app), you should provide a selectable version for each of the different densities.

Note: You only need to provide files of different densities for picture files and. 9 files. If you are using XML to define graphics, colors, or other drawable resources, you should delegate a copy to the default drawable directory (drawable/).

To create an optional picture for different screen densities, you should follow the 3:4: 6:8 scale on four generalization densities. For example, if you provide a 48x48 image for the medium-density screen (the size of the app launch image), all the different sizes should be:

• 36x36 for low-density

• 48x48 for Medium-density

• 72x72 for high-density

• 96x96 for extra high-density

For more information on how to design icons, you can look at the icon design guidelines, which contains different picture size information, such as app launch icon (Launcher icons), menu icon (menus icons), status bar icon (bar icons), Switch card icon (tab icons) and more information.

Original Blog translation: http://www.darcye.com/article/46569744

android-support multi-screen-1