Android's UI Adaptive Solution

Source: Internet
Author: User

1. Overview

as an Android developer, the biggest headache is getting the programs you've developed to appear as consistent as possible on different terminals (of course, if you want to take advantage of the big screen). On a global scale, Android has hundreds of millions of devices, many of which have a wide range of device resolutions and a variety of physical dimensions of the device's screen.

In general, we need to do three points, one lets the app each UI in each view width and height more flexible to adapt to different resolutions, the second for large-screen devices (PAD) need to have different design, there may be more display content, access to your entire app all the UI can be a layout, Its three icon resources need to provide different sizes (MDPI, HDPI, XHDPI, xxhdpi, xxxhdpi), you can also map convenient to provide only a set of high-size API, no problem, this may only make those low-profile devices (or low resolution, actually the two are generally proportional) More memory is spent on loading the resource picture.

2. Official support1. Icon Resources

The official recommended icon resource used in the app is to provide drawable-ldpi (not currently necessary), DRAWABLE-MDPI, drawable-hdpi, drawable-xhdpi.

When it comes to dpi (Dots per Inch) is actually the unit size of how many pixels, the calculation is the cell phone resolution width squared + high squared, and then open the square root to get diagonal diagonal resolution. Then use this divided by the actual size of the screen (that is, we often say 4-inch, 5-inch, 7-inch, 10-inch), this size is actually the diagonal diagonal size of the screen. The result of this calculation is pixel density, the larger the pixel density, the more detailed the display of the mobile phone. For example, HTC One resolution is 1920*1080, the screen size is 4.7 inches, take the formula above to calculate 2202/4.7=468 then which area does it belong to? Android gives a range, as follows:


It is obvious that HTC One is subsumed within the xhdpi category. So if your app provides the drawable-xhdpi icon below, HTC One will choose to load it when it runs your app.


2. Layout

The five major layouts for Android are linearlayout (linear layout), Framelayout (frame layout), relativelayout (relative layout), Absolutelayout (absolute layout), and tablelayout (tabular layout). The most used is the number of linearlayout and relativelayout,framelayout and tablelayout can be used in the special needs of the page, here is not introduced, The absolutelayout has been tagged bit deprecated since API level 3and is not recommended for reuse.

The linear layout is characterized by that each view inside is placed in order, either vertically or horizontally, and who is declared in front of the person who displayed it. The relative layout position is not limited by the emission sequence, and you can specify in the XML which view is above, below, to the left, or to the right.

The most important place to do self-adaptation in the layout above, first to get the demand after the analysis of the page layout structure to better self-adaptation, or the design of the app design is relatively simple, and mobile phone software design rules are more simple and easy to use! Use Match_parent wrap_content as much as possible on the layout, never use PX (unless, of course, if your apk only needs to support a certain resolution), do not want to set the size of the use of DP units, so that the different DPI but the size of the physical size of the phone on the same general. But all with DP and can not meet at the same time to adapt to mobile phones and tablets (physical size there is a large difference), because the physical size of the tablet is usually more than 7 inches, for example, two buttons to set its size to width 50dp height 50dp, it 800*480 The size of the 4-inch mobile phone above shows the following effect:

The 1024*600 seven-inch flat panel above shows the following effects:

It is obvious that the effect on the tablet is too small, and why there is such a difference, we can calculate the answer. 800*400 4 inch dpi is 230,normal dpi is 160, so we can figure out that 50DP in this 800*480 4-inch device occupies the pixel is 230/160*50 = 72px, obviously this width only covers the entire width of the screen 72/480= 0.15, look at it, it should be about the same proportion. If the 1024*600 7-inch (DPI is 170) device above 50DP occupies the pixel is 170/160*50=53px, so that the entire button occupies the width of the screen is only 53/600=0.09, that is, as seen in a small lump.

Therefore, through DP as a unit does not solve the different size of the device's adaptive problem, as well as Android also provides a corresponding solution, in android3.2 (API 13) before the screen size has been categorized as follows:

To differentiate between different size devices in a layout file, you can pass Layout-small, Layout-normal, Layout-large, and Layout-xlarge, depending on the value we just calculated, Just specify the size of the button in Layout-large x the value of this x can be calculated by the formula x* (170/160)/600=0.15 x = 600*0.15/(170/160) =95DP, and then look at the following effect:

The effect is almost the same as they appear. At the same time, not only the size, display location can be based on the size of the screen to do different display. In general, you need to maintain layout layout-large and Layout-xlarge three sets of layouts, and after Android 3.2 The official provides a more accurate size-size-difference approach, SW<N>DP, where SW refers to the length and width of the smaller, such as 1024*600 7-inch, SW calculation method is 600/(170/160) =565DP, but the actual is wrong, referring to the page "official six" in the description:

Note:  the sizes that you specify using Thesequalifiers is   not the actual-screen sizes . Rather, the sizes arefor the width or height in DP units that are  available to youractivity ' s window . The Android system might use some of the screens Forsystem UI (such as the system bar at the bottom of the the St ATUs Barat the top), so some of the "screen might" is available for your layout. Thus, the sizes you declare should is specifically about the sizes needed Byyour activity-the system accounts for any SPAC E used by System UI whendeclaring What much space it provides for your layout. Also beware thatthe action Bar  isconsidered A part of your application ' s window space, although your layout doesnot declare it, so it reduces the space available for your layout and you Mustac count for it in your design.

So it is necessary to note that the calculation of the SW will have a certain range of floating, we need to define smaller, such as 565DP if you are defined as SW565DP, but the actual is SW564DP, then will not go to SW565DP inside, but use down to find the nearest principle, If none are found, use the default layout.

For the official why the introduction of the concept of SW, because large xlarge has been unable to adapt to a variety of manufacturers too much of the intermediate size, such as 5.5, 5.7, 6, 6.5 and so on, If it is below the android3.2, these will all be classified into the category of large, so that the 5.5 and 7-inch devices display the effect will be some discrepancy, of course, there will be no big difference. In order to meet people's design excellence, in android3.2 after the equipment can use the SW to do a finer division, such as SW480DP SW600DP SW720DW SW1024DP and so on.

Of course, in order to avoid maintaining so many layouts layout files, we can also use another version to complete the adaptive action. As the above example, each button is a screen width of 0.15, we can use the concept of layout_weight weight, set the button weight of 0.15, it will be on each device to achieve the same effect-the screen width of 0.15, high is also the same. A device that is consistent with a wide and high ratio this is a good choice, but for devices with different aspect ratios, it is obviously not possible to use Layout_weight to do adaptive adaptation, such as 800*480 and 854*480 devices, if the same weight are used for high- 854 of the high will certainly appear stretched. If the button has a background picture above it, the picture will deform. There is a small trick to solve this problem, is to use ImageView instead of button, while the background picture is set to Android:src, in the foreground mode, so that you can take advantage of the ImageView properties, so that the picture remains the original proportional fill.

3. Values

Various values are used in the layout file, such as the width and height of the view, the size padding size of the font, the size of the magin, and so on, which can be defined in the values folder, including Strings.xml Dimens.xml Styles.xmlcolor.xml and so on, of course, is related to self-adaptation is dimens.xml. This defines the size of the various view properties, such as the button's height of 50DP can be defined inside the Dimens <dimen name= "Btn_size" >50dp</dimen> then the button android: Layout_width= "@dimen/btn_size". In the Layout section we talk about using Layout-large LAYOUT-SW600DP and so on to distinguish different screen size devices, also in the values can add VALUES-LARGEVALUES-SW600DP, etc. to distinguish, For example, in the first example, we can just define a layout to set the button's width height to @dimen/btn_size, then define a values/dimen.xml and a values-large/dimen.xml, respectively. <dimen name= "Btn_size" >50dp</dimen> and <dimen name= "Btn_size" >95DP</DIMEN> This is the same as writing multiple layout effects. But I personally think that if the page is relatively simple, it is easier to work in values than to write multiple layout.

3. Expansion

Sometimes we need to support the older API version, but we want to use some of the more advanced API features, then we can add-v<xx> such as VALUES-V11, which 11 is the API version, Devices that are more than 11 API will use the contents of values-v11. For example, API 11 added the Action Bar function, so if you want to use this feature, you can define a style.xml in Values-v11, inherit from the action bar related style, The style that does not support the action bar is defined in the Style.xml in values, but the effect of the action Bar is simulated with a different view in the layout.

4. Summary

A summary of the UI adaptation is primarily two points, with the same screen size at different resolutions and different screen sizes at the same resolution. For the former, simply use the unit in the layout of the place all with DP can be resolved (if the drawable best can provide a different resolution of the icon, really not, to provide the largest possible range of resolution pictures). For the latter, it is necessary to write a different layout file or a values file according to the level of the size, which should be freely chosen according to the specific degree of responsibility of the project.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.