Android screen adaptation

   Android screen adaptation is a tricky thing to note in Android development:
Use linear layout (linearlayout) and relative layout (relativelayout) as much as possible,
Do not use absolute layout, use dip and SP as much as possible, do not use PX, provide different layout files and pictures for different resolutions, and set multi-resolution support in Androidmainfest.xml.

For Android application development friends should know that the current Android phone screen type is very diverse, size, length and width ratio are not the same, the same interface in different resolutions of the mobile phone may appear layout confusion, control movement phenomenon. It's not possible for the right spouse to do the screen to be exactly the same as the interface shown on each screen. Only by our usual programming habits and experience is the interface in different screen size will not appear excessive in the scope of the meeting to control the interface in different screen changes, and make corresponding adjustments. So how do we fit the screen? Let me say it in my development experience.

1, first from the layout considerations

The Android interface is done by the layout and components, and the layout is like a frame in the building, and the components are the bricks in the building. Components are arranged according to the layout requirements, which makes up the interface that the user sees. The five major layouts for Android are linearlayout (linear layout), Framelayout (single frame layout), relativelayout (relative layout), Absolutelayout (absolute layout) and tablelayout (table layout).

Each layout has its own characteristics, you may be depressed unable to master the use of each layout, in fact, no matter how complex an interface, we need only the above one or two layouts can be achieved, Android provides so many layouts for our choice just to facilitate our development.

I am accustomed to using linearlayout, may be due to personal habits, so I feel that the linear layout of a more coherent, linearlayout layout of the child control has a very important property, Android:layout_weight. This property will be described in the following, here is only recommended that you choose a more familiar layout, their own logical strengths, in the screen size changes, you can change the size and position of the control to a certain extent, in order to do a good screen adaptation.

2, PX, DP and Dip relations

Both layout and child controls have two important properties, Layout_height and Layout_width, that specify the size of the control. The system also provides several properties for our use,

1) fill_parent

Setting the layout of a component to fill_parent will force the component to expand to fill as much space as possible within the layout unit. This is roughly the same as the DockStyle property of Windows controls. Setting a top layout or control for Fill_parent will force it to fill the entire screen.

2) wrap_content

Setting the size of a view to Wrap_content will force the view to expand to show the entire content. Take the TextView and ImageView controls as an example, set to Wrap_content to fully display the text and images inside them. Layout elements will change size based on content. Setting the size of a view to Wrap_content is roughly equivalent to setting the AutoSize property of Windows controls to true.

3) Match_parent

Android2.2 in Match_parent and fill_parent is a meaning. Two parameters meaning, match_parent more appropriate, so starting from 2.2 two words can be used. Then if you consider the use of the lower version you will need to use fill_parent.

More cases, in order to interface can adapt to different screen resolution of the phone, we need to limit the size of the control, the use of PX, DP, dip, SP, and so on, here is only a brief introduction of the next PX and dip, the other here do not elaborate.

Px:pixels (pixels), different devices different display display effect is the same, is absolute pixels, is how much will never change. Obviously in order to fit the display of a different phone screen, using PX to specify the size of the control is not possible.

Dip:device independent pixels (device independent pixels). Different devices have different display effects, this is related to the device hardware, generally we support WVGA, HVGA and QVGA recommended use this does not rely on pixels.

It is important to note that dip is related to screen density and that the screen density is related to specific hardware and that the hardware settings are incorrect and may cause the dip to not display properly. On the screen density of 160 display, 1dip=1px, sometimes your screen resolution is very large, such as 720*1280, but the screen density is not set correctly for example or 160, then all the use of dip will show the anomaly, the basic display is too small.

Dip Conversion: dip (value) = (int) (PX (value)/1.5 + 0.5)

DP: Very simple, and the dip is the same.

Therefore, dip is recommended when you need to limit the size of the control.

3, the screen classification

1) The total number of pixels, the size of the text should be changed, as shown in:

Each category has its minimum resolution, such as the following, which can be divided into categories according to resolution:

2) with screen density, provide different pictures, as shown in:

Android looks for the best resource principle:

1. Exclude resources that are not compliant with device settings

2, according to the priority of the qualifier (qualifier), in order to find

3, under qualifier, whether there is a resource path

4. Exclude resource paths that are not included in the qualifier

5, continue to perform different qualifier lookups until the appropriate resource is found

As shown: (English and Chinese versions available)

4. Layout_weight Properties

This property is actually very useful, and is generally used in conjunction with android:layout_height= "Fill_parent" or android:layout_width= "Fill_parent", which is used to describe the proportion of the child element's size in the remaining space. Add a row only a text box, then its default value is 0, if there are two equal-length text boxes in a row, then their android:layout_weight value can be the same as 1. If there are two unequal text boxes in a row, their android:layout_weight values are 1 and 2, respectively, then the first text box will occupy two-thirds of the remaining space, and the second text box will occupy One-third of the remaining space. Android:layout_weight follows the principle that the smaller the value, the higher the importance. Android screen so many, can not be scaled, so the simple use of dip to set the control is not feasible, with the Layout_weight attribute flexible use, enhance the adaptability of the interface.

5. Drawable Resources

First: You need to add a child element as follows in the Androidmanifest.xml file

1. <supports-screens android:anydensity= "true"   android:largescreens= "true"   android:normalscreens= "true"   android:smallscreens= "true"   android: Xlargescreens= "true" &NBSP;/>&NBSP;&NBSP;&NBSP;

As the name implies, the above is a multi-resolution support for our screen (more accurately, the density of large, medium and small three). Android:anydensity= "true", this sentence is very important to the entire screen, the value is true, our application when installed on a different density of mobile phones, the program will load the resources in the HDPI,MDPI,LDPI folder separately. Conversely, if the value is set to False, even if we have the same resource under the Hdpi,mdpi,ldpi folder, then the application will not automatically go to the appropriate folder to find resources, this is in high-density, and low-density mobile phones, such as a 240x320 pixel cell phone, If you set android:anydensity= "false", the Android system will convert 320 (low density) to 320x480 (medium density), so the app will load the resources in the mdpi file on the small-density phone.
Careful people will find that since android2.0 started drawable files are replaced by three folders drawable-hdpi,drawable-mdpi,drawable-ldpi three folders, some programmers in order to let the application load some pictures by default , they will deliberately re-create the Drawable folder in the application after android2.0, in fact it is not necessary to do so, through the first paragraph of the analysis we learned that the android:anydensity= "false", then the application will be the size of density into medium density To load the resources in the MDPI. Here again, when android:anydensity= "false", the app will load the resources in the MDPI.

To summarize:

First: Android:anydensity= "true", the system will automatically find the corresponding folder according to the screen density

Second: android:anydensity= "false",

(1) If the drawable-hdpi,drawable-mdpi,drawable-ldpi three folders have different densities of the same picture resource, then the system will load

Resources in the DRAWABLE_MDPI folder

(2) If there is a high density image in the drawable-hpdi, the other two folders do not have the corresponding picture resources, then the system will load the resources in the drawable-hdpi.

(3) If there is a picture resource in the drawable-hdpi,drawable-mdpi, there is no corresponding picture resource in the drawable-ldpi, then the system will load the resources in the Drawable-mdpi folder.

Note the different representations of the various folders.

DRAWABLE-HDPI the picture is applied to the horizontal screen, also for the vertical screen

DRAWABLE-LAND-HDPI, when the screen is horizontal and high density, load the resources in this folder

DRAWABLE-PORT-HDPI, when the screen is vertical and high density, the resources in this folder are loaded

6. Draw9patch Tools

An image processing tool is provided in the tools directory of the Android SDK package. Sometimes we need image resources adaptive and not distorted, whether horizontal screen or vertical screen, high resolution or low resolution, can be filled automatically, and not distortion and so on background problems. Android in this case, a. 9.PNG format was specifically created to address this issue. Draw9patch is a gadget that helps we make a. 9.PNG format resource.
*.9.png in the standard PNG format, just the outermost circle of the extra 1px of the border, this 1px border is used to define the image of the extensible and static invariant area. In particular, the cross-section of the left and top (top) borders is an extruded part, and the unselected part is the static area section. The cross-section of right and bottom (bottom and right) borders is the content part.

In other words, in the phone. No matter how the above picture is enlarged, the rounded corners are not magnified! Only the left and top (top) borders will stretch!
Images with 9.PNG format in Android do not have backgrounds, so you can customize the stretch without distortion, such as the system button is a typical example. In fact, whether it is left and top, or right and bottom are to divide the picture into 9 pieces (corner Four is not scalable, the other four is allowed to scale), so called 9. Png.
About the use of draw9patch tools in this do not elaborate, you need to go to Baidu for a bit.

7. Layout Resources

Sometimes, because the screen layout is too complex, the same layout file can be difficult to adapt to all screen resolutions. You can create multiple corresponding layout folders under the Res folder of the project, like Drawable Resources, and write the appropriate layout file for the screen of the corresponding resolution.

The naming convention for folders is this: layout-resolution
For example: layout-320x240, layout-480x320 and so on.
The layout file under the appropriate folder will be loaded in the system based on the resolution of the operating environment.

8. Add code Dynamically

All used Swing know how to add controls dynamically, Android is the same, of course, the code dynamically added far from the XML layout file convenient, and not easy to manage. But his advantage is that we can get the screen size of the running environment in the code, and build the corresponding interface by calculation. Although the code-writing interface is cumbersome, his suitability is undeniable.
There are two ways to get the size of the screen:
//  method One:
windowmanager manager = getwindowmanager ();
int width = manager.getdefaultdisplay (). GetWidth ();
int height = manager.getdefaultdisplay (). GetHeight ();
//  Method II:
displaymetrics dmetrics =  new displaymetrics ();
getwindowmanager (). Getdefaultdisplay (). Getmetrics (Dmetrics);
int screenwidth = dmetrics.widthpixels;
INT&NBSP;SCREENHEIGHT&NBSP;=&NBSP;DMETRICS.HEIGHTPIXELS;&NBSP;

You can then set the inexpensive amount for each of these densities in your code, but it's best not to use it, but the best way is to set it separately in the XML file for different densities of phones.

The offset of the map here can be set in the Dimens.xml file in the values-hpdi,calues-mdpi,calues-ldpi three folder.

It is worth mentioning that:

<dimen name= "Bitmap_common_topoffset" >40dp</dimen>

<dimen name= "Bitmap_common_bottomoffset" >-14dp</dimen>

The negative number here is fully functional, and the system considers it to be a negative value.

9. The issue of national issues

Sometimes the appropriate language is set in XML, but why does the UI display still not work after we change the language? Don't suspect that the system is out of the question, which is related to how we refer to strings in Values/string.xml in code.

The wrong way:

1. Declare global variables private static String tempstr;

2. Assign a value TempStr =context.getstring (r.string.test) to the variable in the OnCreate method;

3. Reference the variable in a method that updates the UI (non-OnCreate method). ) Textview.settext (TEMPSTR);

The reason is that OnCreate will not be executed again when the local language is modified. The variable tempstr will still use the default English loaded when the page was first started.

The right way: go directly to the third step: Textview.settext (context.getstring (r.string.test));

10. Other

In addition to the XML file and code authoring interface, you can also use WebView to load the corresponding HTML file, the interface content is done by HTML. I have seen others using HTML5 writing interface is also very beautiful, screen adaptability is very strong. Because I am not very understanding of HTML5, this is not in detail, interested friends can go to understand the next.
Sometimes because the screen is too small, to display the content is too much, a screen really can not be pushed down. You can use the ScrollView control appropriately to make the interface more complete and secure the user experience.

How to adapt an application to a different phone, although this is not a technical problem, but for the developers just to do the screen is really not a very simple thing.
The above is just my study of Android development since a little humble opinion and summary, Welcome to love programming friends together to explore and learn!

Summary:

1, try to use linear layout (linearlayout) and relative layout (relativelayout), do not use absolute layout.

2, try to use dip and SP, do not use PX.

3. Provide different layout files and pictures for different resolutions.

4, set the multi-resolution support in Androidmainfest.xml.

Transferred from: http://mobile.51cto.com/aprogram-395071.htm

Android screen adaptation