A few years ago, screen adaptation has been a major problem that troubled Android development engineers. However, with the birth of various screen adaptation solutions in recent years and the launch of various Google adaptation controls, screen adaptation has become increasingly easier. Below, we will summarize the skills about screen adaptation.
ConstraintLayout
Many Android engineers don’t like to use ConstraintLayout. They feel that the use of ConstraintLayout is cumbersome and requires setting various up, down, left and right constraints. But please believe that the more you put into the code in the early stage, the fewer bugs will need to be solved later.
The predecessor of ConstraintLayout is PercentLayout (percent layout). PercentLayout was also very popular when it was launched, but it only lasted for a short period of time before being replaced by ConstraintLayout. Common properties of ConstraintLayout include the following
The attributes in red box 1 are equivalent to the layout_align related attributes of RelativeLayot, which can determine the edge alignment characteristics between each View. The attributes in red box 2 are equivalent to the layout_to related attributes of RelativeLayout, which can determine the relative position between each View. Through these attributes, the relative position of the View can be basically determined, and effects that are difficult to achieve with other View containers can also be achieved.
For example, there are two Buttons, namely Button1 and Button2. The requirement is to place Button1 in the middle of the screen and always cover the upper left half of Button2. The UI effect is as follows
The above effect can be achieved through the following code
ConstraintLayout also has several other properties, through which we can better help us make adaptations.
bias
ConstraintLayout provides horizontal and vertical bias properties. The value range of this attribute is 0~1, and its main function is to establish the position percentage of the View in the horizontal or vertical direction. For example, the following example code
In the figure, Horizontal_bias and Vertical_bias respectively specify that the TextView is displayed at 30% of the position in the horizontal direction and 50% of the position in the vertical direction. The final display effect is as follows
weight
LinearLayout can easily arrange multiple UI controls in a certain direction and set certain weight rules. ConstraintLayout can also achieve similar effects. The following code can arrange three TextViews in the same direction and with equal weights.
The display effect is as follows
ContraintLayout also provides the chain attribute to set different equalization strategies. The specific attribute values are as follows:
spread
spread will divide the remaining space equally, allowing the Views inside the ConstraintLayout to occupy the remaining space equally. spread is also the default attribute, and the display effect is as shown above.
spread_inside
spread_inside will pull the two edgemost Views on both sides toward the edge of the parent component, and then let the remaining Views divide the gap layout equally in the remaining space. The code and display effect are as follows
app:layout_constraintHorizontal_chainStyle="spread_ inside"
packed
Group all Views together without allocating extra space (except margin), then display the entire component in the remaining available space and center it. The code and effect are as follows
app:layout_constraintHorizontal_chainStyle="packed"
On the basis of chain, you can also add the bias attribute to arrange it according to weight at a certain percentage position. For example, under the above packed chain attribute, add the following attributes to TextView1. The final display effect is as follows
app:layout_constraintHorizontal_bias=".75"
Note: When using ConstraintLayout, you need to pay special attention to the visible properties of UI controls. Because the visibility of the internal control of ConstraintLayout is set to GONE and INVISIBLE, the constraints on other controls are different.
Multi-dimens dp-based adaptation solution
Based on ConstraintLayout, we can also create multiple sets of values folders in the res folder. As follows
In the figure, the sw after “values-” refers to the smallest width, which is the minimum width. The Android system will automatically identify the minimum available screen width at runtime, and then search the resource file for the attribute value in the corresponding resource file based on the identification result. For example, if there is a 360dpi mobile phone device, when running the App, it will automatically search for the corresponding value in the values-sw360dp folder.
It is troublesome to write each values folder by hand. You can use tools to generate values files with one click. For details, please refer to this article: Android screen adaptation, automatic generation of different dimens.xml details
This method has a good integration mechanism. For example, if the minimum width of a mobile phone is 350dp, if the Android system does not find the values-sw350dp folder in res, it will not directly use the values in the default values file. Instead, it looks down to the closest minimum-width folder. For example, in the picture above, the value closest to 350dp is the value in values-sw320dp. Although this value is not accurate as a percentage, the effect will not be too far off.
By adding multiple dimens adaptation solutions to ConstraintLayout introduced above, the UI layout can basically be adapted to all models. On this basis, it is basically perfect to adapt individual UI controls.
UI control adaptation
In an Android App, text + image content occupies the vast majority of an App’s display UI. Although it will be mixed with nested views such as RecyclerView, ViewPager, and ScrollView, the nested views ultimately contain text. Content + image content. Therefore, the adaptation of the two is our focus.
Text TextView
For the width and height of TextView, it is recommended to use wrap_content adaptive as much as possible. Because once a specific finger is used to limit it, we cannot guarantee that it will not be cut off on some mobile phones.
A gory example: There is a “Clear” button in the search interface with the width set to 24dp and the font size set to 16sp. There is no problem with the display on almost all mobile phones, but when the Nokia Android phone came out, suddenly the “Clear” button was cut in half, and only “Clear” was displayed. The reason is that the calculated width of 24sp on the Nokia mobile phone is not enough to display two 16sp sized text.
There is another situation to note about TextView. We have to get used to using an extremely long string to test the display of TextView in some extreme cases. Because most of what is given in the requirements document is a relatively conventional text content, but the text string we obtain from the backend is sometimes user-defined and may be a relatively long text string. You can use the tools:text attribute to debug during debugging. The tools attribute is only valid in the preview interface. For example, the following configuration
The TextView in the picture above will show that it is a very long text content in the preview interface of AS, but when installed on the mobile phone, it will display text content.
Image ImageView
It is not recommended to use wrap_content uniformly for ImageView. Because sometimes our pictures are downloaded from the server and displayed locally, the width and height of the pictures are not necessarily exactly the same, which will cause the display size of the pictures to be inconsistent. In this case, generally
The requirement is that the size of each item in the RecyclerView is 1/3 of the screen. You can consider dynamically setting the size of the item view in the code. As follows
In fact, this approach to ImageView also applies to the display of other controls.
Summary
This article mainly introduces several Android screen adaptation techniques, mainly including: