Android screen adaptation - just read this article

The reason why Android screen adaptation appears

Before we learn how to perform screen adaptation, we need to understand why Android needs screen adaptation.

Due to the openness of the Android system, any user, developer, OEM manufacturer, and operator can customize Android and modify it to what they want.

But to what extent does this “fragmentation” reach?

In 2012, OpenSignalMaps (hereinafter referred to as OSM) released the first Android fragmentation report, and the statistics showed that

• In 2012, there were 3,997 devices supporting Android.

• In 2013, there were 11,868 devices supporting Android.

• In 2014, there were 18,796 devices supporting Android.

The picture below is enough to fully illustrate the severity of the fragmentation problem in the current Android system, because each rectangle in the picture represents an Android device.

[[154400]]

As the number of devices supporting the Android system (mobile phones, tablets, TVs, watches) increases, the degree of device fragmentation, brand fragmentation, system fragmentation, sensor fragmentation, and screen fragmentation is also increasing. What we are going to discuss today is the screen fragmentation that has the greatest impact on our development.

The picture below is a schematic diagram of the Android screen size. In this picture, the size of the blue rectangle represents different sizes, and the depth of the color represents the percentage.

Corresponding to this is the picture below, which shows the screen size and proportion that iOS devices need to adapt to.

Of course, this picture only shows the sizes of 4, 4s, 5, 5c, 5s and tablets. Now the newly launched iPhone 6 and plus should also be included. However, compared with the degree of screen fragmentation of Android, it is still far behind.

Please click here for detailed statistics.

Now you should know why we need to adapt the Android screen, right? There are so many screen sizes. In order for the programs we develop to be displayed beautifully on devices of different sizes, resolutions, and pixel densities (I will explain these concepts in detail below), we need to handle them during the development process. As for how to handle them, this is our topic today.

But before we get into the topic, let's discuss one more thing, that is the screen size of Android devices. From smartphones of a few inches, to 10-inch tablets, to digital TVs of dozens of inches, which devices should we adapt?

In fact, this problem should not be considered in this way, because for devices with the same pixel density, the higher the pixel, the larger the size, so we can change our thinking and convert the problem from the perspective of pure size to pixel size and pixel density.

The following figure shows the six mainstream resolutions that accounted for more than 5% of the total in early 2014. It can be seen that 480*800 accounts for the largest proportion, and 320*480 devices also account for a large proportion. However, compared with the data six months ago, the proportion of medium and low resolutions (320*480, 480*800) is decreasing, while the proportion of medium and high resolutions is increasing. Although the proportion of each resolution is changing, the overall trend has not changed. It is still the same six types, but the resolution is constantly increasing.

Therefore, as long as we try to adapt to these resolutions, it can run normally on most mobile phones.

Of course, this is only an adaptation for mobile phones. For tablet devices (TV can also be regarded as a tablet), we still need some other processing.

Well, so far, we have figured out why Android development needs to be adapted and which objects we should adapt. Next, let’s finally get to the point!

First, we need to learn a few important concepts.

Key Concepts

• What are screen size, screen resolution, and screen pixel density?

• What are dp, dip, dpi, sp, px? What is the relationship between them?

• What are mdpi, hdpi, xdpi, xxdpi? How to calculate and distinguish?

We will introduce these concepts in the following content.

Screen size

Screen size refers to the length of the diagonal of the screen, measured in inches, 1 inch = 2.54 cm

For example, common screen sizes include 2.4, 2.8, 3.5, 3.7, 4.2, 5.0, 5.5, 6.0, etc.

Screen resolution

Screen resolution refers to the number of pixels in the horizontal and vertical directions, and the unit is px, 1px = 1 pixel. It is usually vertical pixels * horizontal pixels, such as 1960*1080.

Screen pixel density

Screen pixel density refers to the number of pixels per inch, and the unit is dpi, which is the abbreviation of "dot per inch". Screen pixel density is related to screen size and screen resolution. Under a single change condition, the smaller the screen size and the higher the resolution, the greater the pixel density, and vice versa.

dp, dip, dpi, sp, px

We should be more familiar with px. The previous resolution is in pixels. In most cases, such as UI design and Android native API, px is used as a unified unit of measurement, such as obtaining the screen width and height.

dip and dp mean the same thing, both are abbreviations of Density Independent Pixels, that is, density-independent pixels. As we said above, dpi is the screen pixel density. If there are 160 pixels in one inch, the pixel density of this screen is 160dpi. In this case, how to convert dp and px? In Android, it is stipulated that 160dpi is the benchmark, 1dip=1px. If the density is 320dpi, then 1dip=2px, and so on.

If we draw a 320px line, it will be displayed as 2/3 of the screen width on a 480*800 resolution phone, and will occupy the entire screen on a 320*480 resolution phone. If we use dp as the unit, 160dp will be displayed as half the screen length in both resolutions. This is why we should try to use dp instead of px when writing layouts in Android development.

sp, or scale-independent pixels, is similar to dp, but can be scaled according to the text size option. It is the royal unit for setting font size.

mdpi, hdpi, xdpi, xxdpi

In fact, there was also a ldpi before, but with the continuous upgrading of mobile device configurations, devices with this pixel density have become very rare, so it does not need to be considered when adapting now.

mdpi, hdpi, xdpi, and xxdpi are used to modify the drawable folder and values ​​folder in Android to distinguish images and dimen values ​​at different pixel densities.

So how do we distinguish them? Google officially specifies the following criteria for distinction:

When developing, we need to put pictures of appropriate sizes in appropriate folders. The following is an introduction using icon design as an example.

When designing icons, the five mainstream pixel densities (MDPI, HDPI, XHDPI, XXHDPI, and XXXHDPI) should be scaled in a ratio of 2:3:4:6:8. For example, a launch icon with a size of 48x48 dp means that its actual size on an MDPI screen should be 48x48 px, its actual size on an HDPI screen is 1.5 times that of MDPI (72x72 px), its actual size on an XDPI screen is 2 times that of MDPI (96x96 px), and so on.

Although Android also supports low pixel density (LDPI) screens, you don't need to worry about it. The system will automatically reduce the HDPI size icon to 1/2 to match.

The following figure shows the corresponding sizes of icons for various screen densities:

Solution

Supports various screen sizes

Use wrap_content, match_parent, weight

To ensure that your layout is flexible and adapts to screen sizes of various sizes, you should use "wrap_content" and "match_parent" to control the width and height of certain view components.

With "wrap_content", the system sets the view's width or height to the minimum size required to fit the content in the view, while "match_parent" (called "fill_parent" in API levels lower than 8) expands the component to match the size of its parent view.

If you use "wrap_content" and "match_parent" size values ​​instead of hard-coded sizes, the view will use only the space it needs or expand to fill the available space accordingly. This approach allows the layout to adapt correctly to a variety of screen sizes and screen orientations.

Here is a sample code

The picture below shows the display effect when switching between horizontal and vertical screens. We can see that this can adapt well to changes in screen size.

Weight is a unique property of linear layout. We can use this property to distribute the interface in proportion to meet some special requirements.

But how should we understand the calculation of this property?

First, look at the example below. We set our interface like this in the layout.

We set the layout to linear, arrange it horizontally, and then place two buttons with a width of 0dp, setting the weight to 1 and 2 respectively. In the rendering, we can see that the two buttons are arranged normally in a width ratio of 1:2. This is also a scenario we often use. It is easy to understand at this time. The width of Button1 is 1/(1+2) = 1/3, and the width of Button2 is 2/(1+2) = 2/3. We can clearly understand how to calculate the proportion in this scenario.

But if our width is not 0dp (wrap_content and 0dp have the same effect), what about match_parent?

Here is the effect of setting it to match_parent

We can see that in this case, the proportion is exactly the opposite of the above. What's going on? At this point, we have to mention the calculation method of weight.

The real meaning of android:layout_weight is: if the View has this attribute set and it is valid, the width of the View is equal to the original width (android:layout_width) plus the proportion of the remaining space.

Let's explain the above phenomenon from this perspective. In the above code, we set the width of each Button to match_parent. Assuming the screen width is L, the width of each Button should also be L, and the remaining width is equal to L-(L+L) = -L.

Button1's weight = 1, and the remaining width accounts for 1/(1+2) = 1/3, so the final width is L+1/3*(-L)=2/3L. The calculation of Button2 is similar, and the final width is L+2/3(-L)=1/3L.

This is true horizontally, is it true vertically as well?

The following is the test code and effect

If it is vertical, then we should change the layout_height property. Here is the display effect of 0dp

Below is the display effect of match_parent. The conclusion and level are exactly the same.

Although we have demonstrated the display effect of match_parent and explained the reason, when we actually use it, we always set a certain attribute to 0dp and then calculate the percentage according to the weight.

Use relative layout and disable absolute layout

In development, we mostly use linear layout, relative layout and frame layout. Absolute layout is rarely used due to its poor adaptability.

Since each layout has different characteristics, it is impossible to say which layout is the best. The layout that should be used can only be determined based on actual needs. We can use nested instances of LinearLayout in combination with "wrap_content" and "match_parent" to build quite complex layouts. However, we cannot precisely control the special relationship of child views through LinearLayout; the system will directly lay out the views in LinearLayout side by side.

If we need to arrange the subviews in various effects rather than in a straight line, it is usually more appropriate to use RelativeLayout, which allows you to specify the layout based on the special relationship between the components. For example, we can align a subview to the left side of the screen and another view to the right side of the screen.

The following code uses the official Demo as an example.

In the above code, we use relative layout and use alignXXX and other attributes to specify the position of child controls. Here is how this layout works in response to screen changes:

Display on small screen

Display effect on the large size of the tablet

Although the size of the control has changed due to the increase in screen size, we can see that due to the use of relative layout, the previous position relationship of the controls has not changed, which shows that our adaptation is successful.

Using Qualifiers

Using Size Qualifiers

The flexible layout or relative layout mentioned above can only bring us so many advantages. Although these layouts can stretch the space inside and outside the component to adapt to various screens, they may not provide the best user experience for each screen. Therefore, our application should not only implement flexible layouts, but also provide some alternative layouts for various screen configurations.

How do we do this? We can use configuration qualifiers to automatically select appropriate resources based on the current device configuration at runtime, such as selecting different layouts based on various screen sizes.

Many apps implement a "dual panel" pattern on larger screens, showing a list of items on one panel and the corresponding content on another panel. Tablet and TV screens are large enough to accommodate both panels at the same time, but mobile screens need to display them separately. Therefore, we can use the following files to implement these layouts:

res/layout/main.xml, single panel (default) layout:

res/layout-large/main.xml, dual-panel layout:

Note the large qualifier in the second layout name directory. The system selects this layout on devices with larger screens, such as 7-inch or larger tablets. The system selects the other layouts (the *** qualifier) ​​on smaller screens.

Using the minimum width qualifier

One of the issues developers ran into on Android devices prior to 3.2 was the range of "larger" screen sizes, which affected the Dell Streak, early Galaxy Tabs, and most 7" tablets. Even though these devices had "larger" screens, many apps might display different layouts for various devices in this category (e.g., 5" vs. 7"). This is why Android version 3.2 introduced the "smallest-width" qualifier along with the other qualifiers.

The minimum width qualifier allows you to target screens by specifying a minimum width in dp. For example, the minimum width of a standard 7" tablet is 600 dp, so if you want to use a two-panel UI on such a screen (but only display a list on smaller screens), you can use both the single-panel and two-panel layouts described above, but instead of using the large size qualifier, you should use sw600dp to indicate that the two-panel layout only applies to screens with a minimum width of 600 dp.

res/layout/main.xml, single panel (default) layout:

res/layout-sw600dp/main.xml, dual-panel layout:

That is, for devices with a minimum width greater than or equal to 600 dp, the system will choose the layout-sw600dp/main.xml (dual-panel) layout, otherwise the system will choose the layout/main.xml (single-panel) layout.

However, this technique is not supported on devices with Android versions lower than 3.2 because they do not recognize sw600dp as a size qualifier, so we still need to use the large qualifier. This will result in a file named res/layout-large/main.xml (same as res/layout-sw600dp/main.xml). But it doesn't matter much, we will soon learn how to avoid duplication of such layout files.

Using layout aliases

The smallest width qualifier is only available for Android 3.2 and higher. Therefore, if we still need to use the generalized size ranges (small, normal, large, and extra large) that are compatible with lower versions. For example, if the user interface is designed to display a single panel on phones, but multiple panels on 7-inch tablets, TVs, and other larger devices, then we need to provide the following files:

• res/layout/main.xml: single panel layout

• res/layout-large: multi-panel layout

• res/layout-sw600dp: multi-panel layout

The latter two files are identical because one is designed to work with Android 3.2 devices, while the other is for tablets and TVs using earlier versions of Android.

To avoid duplication of files for tablets and TVs (and the maintenance headaches that this creates), you can use alias files. For example, you could define the following layout:

• res/layout/main.xml, single panel layout

• res/layout/main_twopanes.xml, two-panel layout

Then add these two files:

res/values-large/layout.xml:

res/values-sw600dp/layout.xml:

The latter two files have the same content, but they don't actually define a layout. They simply set main to be an alias for main_twopanes. Because these files contain the large and sw600dp selectors, they are applied to tablets and TVs regardless of the Android version (tablets and TVs below 3.2 will match large, and tablets and TVs above 3.2 will match sw600dp).

Using screen orientation qualifiers

Some layouts support both landscape and portrait modes, but most of them can be tuned to perform better. In the News Reader sample app, the layout behaves like this for each screen size and orientation:

• Small screen, portrait: single panel with logo

• Small screen, landscape: single panel with logo

• 7" tablet, portrait: single panel with action bar

• 7" tablet, landscape: dual panel, wide, with action bar

• 10" tablet, portrait: dual panel, narrow, with action bar

• 10" tablet, landscape: dual panel, wide, with action bar

• TV, landscape: dual panels, wide, with action bar

Therefore, each of these layouts is defined in an XML file in the res/layout/ directory. To continue assigning each layout to various screen configurations, the app uses layout aliases to match the two:

res/layout/onepane.xml: (single panel)

res/layout/onepane_with_bar.xml: (single panel with action bar)

res/layout/twopanes.xml: (two-panel, wide layout)

res/layout/twopanes_narrow.xml: (two-panel, narrow layout)

Now that we have defined all possible layouts, we just need to use configuration qualifiers to map the correct layout to each configuration.

Now you can do this simply by using the layout aliasing technique:

res/values/layouts.xml:

res/values-sw600dp-land/layouts.xml:

res/values-sw600dp-port/layouts.xml:

res/values-large-land/layouts.xml:

res/values-large-port/layouts.xml:

Use automatic bitmap stretching

Supporting a variety of screen sizes often means that your graphic assets must also adapt to a variety of sizes. For example, a button background must adapt to whatever shape it's applied to.

If you use a simple image on a component that changes size, you'll quickly notice that the display is somewhat suboptimal, as the system stretches or shrinks your image evenly at runtime. The solution is to use an auto-stretch bitmap, which is a specially formatted PNG file that indicates areas that can and cannot stretch.

The production of .9 is actually to add a 1px border to the original image, and then set the corresponding position to a black line according to our needs, and the system will stretch it according to our actual needs.

The following figure explains the meaning of the four sides of Figure 9. The upper left side represents the stretching area, and the lower right side represents the padding box, which is the spacing area. Below, we give an example to facilitate your understanding.

Let’s first look at the two pictures below to understand the meaning of these four lines.

The difference between the above and the following pictures is the black line on the lower right. For the specific effect difference, see the effect picture on the right. The dark blue area in the above effect picture represents the content area. We can see that it is in the center. This is because we have two points on the lower right. The distance between these two points in the four directions of up, down, left, and right is the padding distance. Therefore, the dark blue content area is in the center of the picture. Let's look at the picture below. Since the black line on the lower right is the length of the picture, there is no padding. From the effect picture, the dark blue area is the same size as the picture. Therefore, we can use the lower right edge to control the padding of the content and the background edge.

If you still don’t understand, let’s look at the following renderings. We use Picture 1 and Picture 2 as the background images respectively. The following is the rendering.

We can see that using the wrap_content attribute to set the length and width, the effect of Figure 1 is larger than that of Figure 2. Why is this? Remember what I said about padding above?

This is the effect of padding. How to prove it? Let's look at the picture below. Add padding=0 to picture 1. Then the padding effect of the background image is gone. Are the two images the same size?

Ok, I think you should understand the meaning of the black line on the lower right. Now let’s take a look at the effect on the upper left.

Below we only set the upper left edge, the effect is as follows

The upper line does not cover the icon, but the lower line does. You can see the difference from the effect picture on the right. The area where the black line is located is the stretching area. The area where the black line is located in the upper picture is all solid color, so the icon is not deformed. The stretching area below covers the icon, so the icon will be stretched when stretched, but this will cause the icon to deform. Did you notice the red line area below? This is the system prompt. Because this stretching does not meet the requirements, it will prompt us.

Support for various screen densities

Use density-independent pixels

Defining layout dimensions using pixels can be problematic because the same number of pixels can appear different sizes on different devices, since screens have different pixel densities. Therefore, always specify dimensions using dp or sp units. dp is a density-independent pixel that has the same dimensions as a 160 dpi pixel. sp is also a base unit, but it adjusts based on the user's preferred text size (i.e., scale-independent pixels), so you should use that measurement for text sizes.

For example, use dp instead of px to specify the spacing between two views:

Be sure to use sp to specify the text size:

In addition to introducing these most basic knowledge, let's discuss another issue below.

After the above introduction, we all know that in order to avoid the trap of different pixel densities, Google recommends using dp instead of px as the unit of measurement for control length, but let's look at the following scenario.

If we use Nexus 5 as the test model to check the effect when writing code, the total width of Nexus 5 is 360dp. Now we need to place two buttons horizontally, one is 150dp left-aligned, and the other is 200dp right-aligned, with a 10dp gap in between. Then the display effect on Nexus 5 will be as follows:

<

But what if I run it on Nexus S or Nexus One? Here are the results:

As you can see, the two buttons overlap.

We have all used dp, why does this happen?

Please listen to me and I will tell you slowly.

Although dp can eliminate the problem of different pixel densities and make 1dp display the same on different pixel densities, due to the diversity of Android screen devices, if dp is used as a unit of measurement, not all screen widths have the same dp length. For example, Nexus S and Nexus One belong to hdpi, with a screen width of 320dp, while Nexus 5 belongs to xxhdpi, with a screen width of 360dp, Galaxy Nexus belongs to xhdpi, with a screen width of 384dp, and Nexus 6 belongs to xxxhdpi, with a screen width of 410dp. Therefore, Google's own products have so many standards, and there is no correlation between screen width and pixel density. Even if we use dp, there will still be a 90dp difference between a 320dp width device and a 410dp device. Of course, we try to use match_parent and wrap_content as much as possible, and use dp as little as possible to specify the specific length and width of the control. Combined with weight, we can adapt in most cases.

But apart from this method, do we have any other more thorough solutions?

Let’s think about this problem from another perspective.

The following solution comes from [blue-深圳] from the Android Day Day Up group. Thank you for his sharing spirit.

Because the resolutions are different, px cannot be used; because the screen widths are different, dp must be used carefully. So can we use another method to unify the units, and use a fixed value unit to count the screen width no matter how large the resolution is?

The answer is: Of course.

We assume that the width of the mobile phone screen is 320 units, then we divide the total number of pixels of the screen width into 320 equal parts, and each part corresponds to a specific pixel.

How to implement it specifically? Let's look at the following code:

 import java.io.File;
 import java.io.FileNotFoundException;
 import java.io.FileOutputStream;
 import java.io.PrintWriter; 
  
 public class MakeXml { 
  
    private final static String rootPath = "C:\\Users\\Administrator\\Desktop\\layoutroot\\values-{0}x{1}\\" ; 
  
    private final static float dw = 320f ;
    private final static float dh = 480f ; 
  
    private final static String WTemplate = "[dimen name=\" x {0}\"]{1}px[/dimen]\n";
    private final static String HTemplate = "[dimen name=\" y {0}\"]{1}px[/dimen]\n"; 
  
    public static void main(String[] args) {
 makeString(320, 480);
 makeString(480,800);
 makeString(480, 854);
 makeString(540, 960);
        makeString(600, 1024);
        makeString(720, 1184);
        makeString(720, 1196);
        makeString(720, 1280);
        makeString(768, 1024);
        makeString(800, 1280);
        makeString(1080, 1812);
        makeString(1080, 1920);
        makeString(1440, 2560);
 } 
  
    public static void makeString(int w, int h) { 
  
        StringBuffer sb = new StringBuffer();
        sb.append("[?xml version =\"1.0\" encoding =\"utf-8\"?]\n");
        sb.append("[resources]");
 float cellw = w / dw;
 for (int i = 1 ; i <   320 ; i++) {
            sb.append(WTemplate.replace("{0}", i + "").replace("{1}",
                    change(cellw * i) + ""));
 }
        sb.append(WTemplate.replace("{0}", "320").replace("{1}", w + ""));
        sb.append("[/resources]"); 
  
        StringBuffer sb2 = new StringBuffer();
        sb2.append("[?xml version =\"1.0\" encoding =\"utf-8\"?]\n");
        sb2.append("[resources]");
 float cellh = h / dh;
 for (int i = 1 ; i <   480 ; i++) {
            sb2.append(HTemplate.replace("{0}", i + "").replace("{1}",
                    change(cellh * i) + ""));
 }
        sb2.append(HTemplate.replace("{0}", "480").replace("{1}", h + ""));
        sb2.append("[/resources]"); 
  
        String path = rootPath .replace("{0}", h + "").replace("{1}", w + "");
        File rootFile = new File(path);
        if (!rootFile.exists()) {
            rootFile.mkdirs();
 }
        File layxFile = new File(path + "lay_x.xml");
        File layyFile = new File(path + "lay_y.xml");
 try {
            PrintWriter pw = new PrintWriter(new FileOutputStream(layxFile));
            pw.print(sb.toString());
 pw.close();
 pw = new PrintWriter(new FileOutputStream(layyFile));
            pw.print(sb2.toString());
 pw.close();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
 } 
  
 } 
  
    public static float change(float a) {
        int temp = (int) (a * 100);
 return temp / 100f;
 }
 }

The code should be easy to understand. We divide the screen width into 320 parts and the height into 480 parts, and then copy each unit according to the actual pixels and put them in the lax.xml and lay.xml under the corresponding values-widthxheight folder. In this way, you can unify all the units of the resolution you want. The following is a file with a resolution of 320*480 generated. Because the total score and the number of pixels are the same after the width and height are divided, x1 is 1px, and so on.

So what does it look like at a resolution of 1080*1960? We can see that since 1080 and 320 are 3.37 times, x1=3.37px

Regardless of the resolution, x320 represents the screen width and y480 represents the screen height.

So, how should we use it?

First, we need to put all the generated values ​​folders into the res directory. When the designer gives you the UI HD design drawing, you can find the corresponding pixel unit based on the size on the design drawing and a certain resolution model, and then set it to the control.

The following figure still has two buttons. The difference is that we have changed the unit to the value of dimen in the values ​​folder. In this way, at the resolution you specify, no matter the width is 320dp, 360dp, or 410dp, it can be fully adapted.

However, there is still a question, why are the following three not adapted?

This is because there is no corresponding resolution in the generated values ​​folder. In fact, an error was reported at the beginning because the default values ​​have no corresponding dimen, so I can only create a corresponding file in the default values, but the data in it is difficult to process. Because I don’t know the resolution, I have to default to x1=1dp to ensure compatibility as much as possible. This is also one of the disadvantages of this solution. For mobile phones that do not generate corresponding resolution files, the default values ​​folder will be used. If the default folder does not have it, there will be problems.

So, although this solution is a one-time solution, it is actually still using px as the unit of measurement for length, so it is somewhat different from Google's requirements. It is hard to say whether there will be any unpredictable problems in the future. Secondly, if you want to use this solution, you must include as many resolutions as possible, because this is the basis for using this solution. If there is a lack of resolution, it will cause poor display effects and even the risk of errors, which will inevitably increase the size of the software package and the difficulty of maintenance, so everyone should use it at their own discretion.

For more information, please refer to Hong Yang's new article: Android screen adaptation solution.

Providing an alternate bitmap

Since Android runs on devices with a wide range of screen densities, the bitmap assets we provide should always cater to a wide range of common densities: low density, medium density, high density, and ultra-high density. This will help our images look great and perform well on all screen densities.

To generate these images, we first extract the original resource in vector format and then generate the corresponding images for each density according to the size ranges below.

• xhdpi:2.0

• - hdpi: 1.5

• mdpi: 1.0 (***required)

• - ldpi: 0.75

That is, if we generate a 200x200 px image for xhdpi devices, we should use the same resource to generate 150x150, 100x100, and 75x75 sized images for hdpi, mdpi, and ldpi devices respectively.

Then, place the generated image files in the corresponding subdirectories under res/ (mdpi, hdpi, xhdpi, xxhdpi), and the system will automatically select the appropriate image based on the screen density of the device running your application.

In this way, as long as we reference @drawable/id, the system can select the appropriate bitmap according to the dpi of the corresponding screen.

Remember the icon design size we mentioned above? It’s the same as this.

However, there is another issue that needs attention. If it is a .9 image or an image that does not require multiple resolutions, just put it in the drawable folder. The images of the corresponding resolutions must be correctly placed in the appropriate folder, otherwise it will cause problems such as image stretching.

Implementing an Adaptive UI Process

We have previously introduced how to display the appropriate layout based on the device characteristics, but doing so may result in different user interface flows. For example, if the application is in dual-panel mode, clicking on an item on the left panel will directly display the relevant content on the right panel; while if the application is in single-panel mode, clicking on the relevant content should jump to another Activity for subsequent processing. Therefore, we should follow the following process to complete the implementation of the adaptive interface step by step.

Determine the current layout

Since each layout implementation is slightly different, we need to first determine which layout is currently being displayed to the user. For example, we can first know whether the user is in "single panel" mode or "dual panel" mode. This can be done by querying whether a specified view exists and is displayed.

 ublic class NewsReaderActivity extends FragmentActivity {
 boolean mIsDualPane; 
  
 @Override  
 public   void onCreate(Bundle savedInstanceState) {
 super .onCreate(savedInstanceState);
        setContentView(R.layout.main_layout); 
  
        View articleView = findViewById(R.id.article);
        mIsDualPane = articleView != null &&
                        articleView.getVisibility() == View.VISIBLE;
 }
 }

Note that this code queries whether the Story panel is available, which allows for much more flexibility than hard-coding a query for a specific layout.

Another example of a way to adapt to the presence of various components is to check whether they are available before performing an action on them. For example, the News Reader sample app has a button that opens a menu, but this button only exists when you run the app on versions of Android earlier than 3.0 because the ActionBar in API level 11 or higher has replaced the button's functionality. Therefore, you can add an event listener for this button using the following code:

 Button catButton = (Button) findViewById(R.id.categorybutton);
 OnClickListener listener = /* create your listener here */ ;
 if (catButton != null ) {
    catButton.setOnClickListener(listener);
 }

Respond based on current layout

Some actions may have different results depending on the current layout. For example, in the news reader example, if the UI is in two-panel mode, clicking a headline in the headline list will open the corresponding article in the right panel; but if the UI is in single-panel mode, the above action will start a separate activity:

 @Override  
 public   void onHeadlineSelected( int index) {
 mArtIndex = index;
 if (mIsDualPane) {
 /* display article on the right pane */  
        mArticleFragment.displayArticle(mCurrentCat.getArticle(index));
 } else {
 /* start a separate activity */  
        Intent intent = new Intent( this , ArticleActivity. class );
        intent.putExtra( "catIndex" , mCatIndex);
        intent.putExtra( "artIndex" , index);
        startActivity(intent);
 }
 }

Likewise, if the app is in dual-panel mode, an action bar with navigation labels should be set, but if the app is in single-panel mode, a navigation bar should be set with a drop-down menu. So our code should also determine which case is appropriate:

 final String CATEGORIES[] = { "Hot News" , "Politics" , "Economy" , "Technology" }; 
  
 public   void onCreate(Bundle savedInstanceState) {
 ....
 if (mIsDualPane) {
 /* use tabs for navigation */  
        actionBar.setNavigationMode(android.app.ActionBar.NAVIGATION_MODE_TABS);
 int i;
 for (i = 0 ; i < CATEGORIES.length; i++) {
            actionBar.addTab(actionBar.newTab().setText(
                CATEGORIES[i]).setTabListener(handler));
 }
        actionBar.setSelectedNavigationItem(selTab);
 }
 else {
 /* use list navigation (spinner) */  
        actionBar.setNavigationMode(android.app.ActionBar.NAVIGATION_MODE_LIST);
        SpinnerAdapter adap = new ArrayAdapter( this ,
                R.layout.headline_item, CATEGORIES);
        actionBar.setListNavigationCallbacks(adap, handler);
 }
 }

Reuse fragments from other activities

Repeat mode in a multi-screen design means that for some screen configurations, part of the implemented interface will be used as a panel; for others, this part will exist as a standalone activity. For example, in the News Reader example, for larger screens, the news story text will be displayed in the right panel; for smaller screens, the text will exist as a standalone activity.

In similar cases, it is often possible to reuse the same Fragment subclass in multiple activities to avoid code duplication. For example, ArticleFragment is used in a double-panel layout:

Then I reused it in the Activity layout of the small screen:

 ArticleFragment frag = new ArticleFragment();
 getSupportFragmentManager().beginTransaction().add(android.R.id.content, frag).commit();

Of course, this is the same as declaring fragments in XML layouts, but in this case there is no need to use XML layouts because the report fragments are the only component in this activity.

Be sure to be careful when designing clips, do not create strong couplings for specific activities. To do this, you can usually define an interface that outlines all the ways the relevant clip needs to interact with its main activity, and then let the main activity implement the interface:

For example, the HeadlinesFragment of a News Reader application executes the following code exactly:

 public   class HeadlinesFragment extends ListFragment {
 ...
    OnHeadlineSelectedListener mHeadlineSelectedListener = null ; 
  
 /* Must be implemented by host activity */  
 public   interface OnHeadlineSelectedListener {
 public   void onHeadlineSelected( int index);
 }
 ... 
  
 public   void setOnHeadlineSelectedListener(OnHeadlineSelectedListener listener) {
        mHeadlineSelectedListener = listener;
 }
 }

Then, if the user selects a title, the relevant fragment will notify the listener specified by the main activity (rather than not notifying a hard-coded specific activity):

 public   class HeadlinesFragment extends ListFragment {
 ...
 @Override  
 public   void onItemClick(AdapterView parent,
                            View view, int position, long id) {
 if ( null != mHeadlineSelectedListener) {
            mHeadlineSelectedListener.onHeadlineSelected(position);
 }
 }
 ...
 }

In addition, we can also use third-party frameworks, such as EventBus in the "subscribe-release" mode to optimize communication between components and reduce coupling.

Handle screen configuration changes

If we implement separate parts of the interface using a standalone Activity, then note that we may need to respond to specific configuration changes (such as changes in screen orientation) in order to maintain consistency of the interface.

For example, on a standard 7-inch tablet running Android 3.0 or later, if the News Reader Sample app is running in portrait mode, it will display news stories using standalone activity; but if the app is running in landscape mode, it will use a dual-panel layout.

That is, if the user is in portrait mode and the screen displays an activity for reading the report, then it is necessary to perform the corresponding operation after detecting a change in the screen direction (which becomes landscape mode), that is, stop the above activity and return to the main activity, so as to display the relevant content in the dual-panel layout:

 public   class ArticleActivity extends FragmentActivity {
 int mCatIndex, mArtIndex; 
  
 @Override  
 protected   void onCreate(Bundle savedInstanceState) {
 super .onCreate(savedInstanceState);
        mCatIndex = getIntent().getExtras().getInt( "catIndex" , 0 );
        mArtIndex = getIntent().getExtras().getInt( "artIndex" , 0 ); 
  
 // If should be in two-pane mode, finish to return to main activity  
 if (getResources().getBoolean(R.bool.has_two_panes)) {
 finish();
 return ;
 }
 ...
 }

Through the above steps, we can completely build an App that can adapt to the user interface configuration.

***practice

About HD design drawing size

There are two solutions to the size of high-definition design drawings given by Google. One is to design with mdpi and then enlarge the corresponding image to obtain higher resolution, and the other is to use high resolution as the design size, and then shrink to a small resolution according to the multiples.

Based on experience, I recommend the second method, because small resolution will cause pixel loss when generating high-resolution pictures. I don’t know if there is a way to prevent this from happening.

The resolution can be designed with 1280*720 or 1960*1080 as the main resolution.

ImageView's ScaleType property

Setting different ScaleTypes will get different display effects. Generally speaking, setting it to centerCrop can get better adaptation effects.

Dynamic settings

In some cases, we need to dynamically set the control size or position, such as the display position and offset of popwindow. At this time, we can dynamically obtain the current screen attributes and then set the appropriate value.

 public   class ScreenSizeUtil { 
  
 public   static   int getScreenWidth(Activity activity) {
 return activity.getWindowManager().getDefaultDisplay().getWidth();
 } 
  
 public   static   int getScreenHeight(Activity activity) {
 return activity.getWindowManager().getDefaultDisplay().getHeight();
 } 
  
 }