Content hugging and content Compression resistance priority parsing in iOS development AutoLayout

The content of this blog is not too complicated, is a AutoLayout of some advanced usage. This blog we mainly use some examples to see the content hugging Priority and content Compression in AutoLayout Resistance priority these two priorities. Let's take a brief look at the implications of these two priorities:

• Content huggingpriority: literal translation into Chinese is the "contents of the embrace of priorities ", in the literal sense is two views, who "content hug priority" High, who will prioritize their content. We'll show you some examples later on.

• Content Compression Resistancepriority: This is a literal translation into Chinese, which is " compression resistance priority ". That is, the greater the content compression resistance priority of the view, the more difficult it is to compress the contents of the view. In the case of a view with a small priority, the content is first compressed. We will also look at the specific performance of this priority in a later example.

Let's take a look at these two priority usage scenarios and how they work.

I. GENERAL statement

First of all, let's take a look at the overall content hugging priority and content Compression resistance priority two the priority attribute of the AutoLayout. These two properties can be set directly in Storyboard , select the control you want to set, and in the right constraint column there is content hugging priority and content Compression resistance priority setting place. content hugging priority has a default value of 250 for both horizontal and vertical, while content Compression resistance priority The default value for horizontal and vertical is 750. We can set this value here.

　　

Of course, the precedence of these two codes can also be set in the code. Below is the way the code is used to set the appropriate priority for our control and we can get the value of the corresponding priority. The specific code looks like this:

　　

Ii. Content Hugging priority

Let's take a look at the usage scenarios for Content hugging priority and how to use them in conjunction with examples.

If we have a need, we need two labels to display, we call it Label1 and Label2. The display content in Label1 and Label2 is obtained from the network, and the content is variable in length. We require priority display of LABEL1. That is, the width of the Label1, but the Label1 will have a maximum width, when the Label1 display to the maximum width, Label1 content will be compressed, the rest of the show Label2. Of course, when Label1 is not displayed to the maximum value, the remainder still shows Label2. Label2 will also be compressed if the display is not complete.

Next we add the appropriate constraint as described above, first we add a constraint for Label1, as shown below. We have added Top, left, width, and height four constraints for Label1, and these four constraints are sufficient to determine the label's position. But note that the width of the label is less than or equal to a certain worth, here we specify the width <=. That is, the label's width has a maximum value of 200. The constraint is added as follows:

　　

Next we'll add a constraint for the second label. Since the previous label content is required to display the contents of the label on the right, the rest of the section shows the content of the Label2, so we have added a constraint for left , Top, straight, and height . The left is, of course, based on the label on the right, while the left is based on the parent view.

　　

As we can see from below, some constraints have been added to the red, which is the constraint conflict. That is, the currently added constraint cannot really position the current control. From the above constraints we are not difficult to find, horizontally, the width of two labels are indeterminate, so will error.

　　

We can click on the red error arrows below to see the corresponding error message. Clicking on the red arrow will show the interface below, which will prompt for the appropriate error message. From the dialog box below, we can see that the specific error message is "content priorityambiguity", meaning that the contents are ambiguous. Clicking on this red circle will give you the appropriate solution:

• Decrease horizontal hugging of "Second Label" from 251 to + make it grow before.

The general meaning is: need to reduce the level of second label priority, from the current 251 to 250. In other words, if you change the Content hugging priority of "Second Label" from 251 to 250, the problem below will be solved. "To makesit grow beforeother views", this sentence means that the priority is lowered to allow the view to grow before the other view.

The translation is somewhat obscure, let's talk about it with plain English. The reason for the error below is that the width of the two labels placed horizontally is not deterministic, and the priority of the content is consistent, so it is not possible to determine whether to determine the width of the first label or to determine the width of the second label before running. The solution is to lower the content hugging priority of the label on the right and, of course, the first label's content hugging priorities are relatively high. So the label on the left takes precedence over its contents, meaning that the label will prioritize its width. When the width of the label on the left is determined, then the width of the label on the right is determined, so the error below is resolved.

　　

Below is the result of changing the Content hugging priority of the label on the right to 250. You can see that the previous error has been resolved. Of course, you can also change the Content hugging priority of the label on the left to be higher than the right level. Here we only discuss the Content hugging in the horizontal direction of the priority, the vertical direction of the priority is the same, here do not do too much to repeat.

　　

Once the above constraints are added and the priority is added, we can look at the effect of the operation. To dynamically look at the effect of the constraint, we add a step control for each label , and it is not difficult to see that the control is primarily used to control the size of the corresponding label. The performance below is consistent with our previous expectations. The length of the label on the left is one of the most worthwhile, and when the label on the left is finished, the remaining space on the right shows the contents of the second label .

　　

Iii. contents Compression Resistance priority (content compression resistance precedence)

After chatting about "content hug priority", let's take a look at contents Compression resistance priorities. content Compression resistance priority , in the literal sense, the greater the priority, the greater the content compression resistance, which means that the content is more difficult to compress. When two labels are displayed side-by, and the screen is not sufficient to display all of the two labels, the smaller the content compression resistance priority is compressed first.

We still use the last part of the way, from the wrong start, in the process of error resolution to recognize this "Content Compression resistancepriority." First of all, we also let two label side-by, the left label we call Firstlabel, the right label we call Secondlabel. The constraints we added for Firstlabel were top, left, height, and width >=, and we added a constraint of Secondlabel to left (referring to first right),top, Right, height, and width>=102. Below is the effect of adding the above constraint:

　　

After adding the above constraints, we can see in the storyboard that there will be an error. The cause of the error is also very clear, "content priorityambiguity", is also a conflict of contents priorities. The plain English explanation is that the width of the two label cannot be determined horizontally. Of course, click on the red dots will also give the corresponding error solution:

• Decrease horizontal compression resistance of "Bottom Label2" from-to-749-make it get clipped before other views.

The general meaning is to reduce the horizontal compression resistance of the second label, changing the current 750 to 749 so that the Secondlabel is cropped before the other views. This error will be fixed at the moment if you click on the "Change priority" button in the prompt.

　　

To visually look at the effect of this priority, we added a switch switch to modify the precedence of the two labels above. When the switch is turned on, the compression resistance of the Firstlabel is greater than Secondlabel, and the switch is turned off instead. The specific code looks like this:
　　

After modifying the corresponding error and adding the appropriate code, let's look at the results of the operation. When the switch is turned on, the front compression resistance is greater than the label behind. When the switch is closed, the resistance priority is greater than the front, and the operating effect is as follows.

　　

Through the demo of the example above, you should have an intuitive feel for content hugging priority and content Compression resistance , this blog will come here first. Below is a shared link to the above example on GitHub, as shown below:

GitHub Share Link:https://github.com/lizelu/AutoLayoutContentHuggingAndCompressionResistance

Content hugging and content Compression resistance priority parsing in iOS development AutoLayout