Comparison with Xib when using masonry to build special layouts

Previously only relatively shallow contact with masonry. Most of the layout in the project is also a combination of the AutoLayout in Xib and the frame calculation of the hand code, I believe there will be many projects as well as I am the combination of these two layouts. In fact, xib all aspects of the feeling are very good, the former is a performance problem, the conflict has been criticized by people, but with the upgrading of Apple these problems have gradually tended to minimize. The main reason for our team's rectification is for finer-grained components. Because reusing a piece of code to another page is much faster than dragging several controls from Xib to other pages, and code written with masonry is very clear and understandable on the relationship between controls.

The general layout will be omitted, here to build some more special layout.

If you are not in the Dong Platinum Blog Park See this article please click to view the original text.

1. There are three UIView or UIButton below, at any time as the screen width changes (horizontal screen vertical screen) always maintain equal width and so on.

The top right is the code for the Xib, which uses the regular masonry syntax to complete the layout.

 [Redview mas_makeconstraints:^ (Masconstraintmaker *make) {make.left.equal        to (Self.view.mas_left). With.offset (0);        Make.bottom.equalTo (Self.view.mas_bottom). With.offset (0);    Make.height.equalTo (@100);        }]; [Blueview mas_makeconstraints:^ (Masconstraintmaker *make)        {Make.left.equalTo (redview.mas_right). With.offset (0);        Make.bottom.equalTo (Self.view.mas_bottom). With.offset (0);        Make.width.equalTo (redview.mas_width). With.offset (0);    Make.height.equalTo (redview.mas_height). With.offset (0);        }]; [Greenview mas_makeconstraints:^ (Masconstraintmaker *make)        {Make.left.equalTo (blueview.mas_right). With.offset (0);        Make.bottom.equalTo (Self.view.mas_bottom). With.offset (0);        Make.right.equalTo (self.view.mas_right). With.offset (0);        Make.width.equalTo (blueview.mas_width). With.offset (0);    Make.height.equalTo (blueview.mas_height). With.offset (0); }];

You can see the specific logic in the code or it is particularly clear. You can clearly understand the relationships between controls, and basically each row represents a constraint in Xib.

and masonry supports some ellipsis and shorthand:

If there is a connection between the same position (constraint) of the two controls, the control constraints can be omitted from the parentheses;

If the constraint relies on the same control, you can use and to connect two constraints to a single line of writing;

If offset is 0, the trailing with.offset (0) can be omitted;

The simplest of the above code can be written as follows

    [Redview mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.bottom.equalTo (self.view);        Make.height.equalTo (@100);    }];        [Blueview mas_makeconstraints:^ (Masconstraintmaker *make) {        make.bottom.and.width.and.height.equalTo (redview);        Make.left.equalTo (redview.mas_right);    }];        [Greenview mas_makeconstraints:^ (Masconstraintmaker *make) {        make.bottom.and.width.and.height.equalTo (blueview);        Make.right.equalTo (Self.view);        Make.left.equalTo (blueview.mas_right);    }];

Note: For this kind of several modules function similar location, it is recommended that the multi-layer parent control, convenient for the entire component operation and extraction, and from a macro point of view the project structure is clearer.

2. Achieve interdependent automatic layout, the height of the background view is determined by how long the label of its own child control can pull.

The simple description is that the left and top of the label is dependent on the parent control Grayview. However, the bottom of the parent control Grayview is dependent on the child control label.

The above right is the AutoLayout of the IB page, but the code written according to Xib's ideas is problematic.

    [Grayview mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (self.view). With.offset ();        Make.width.equalTo (@200);        Make.bottom.equalTo (CONTENTLBL). With.offset (Ten);    }];        [Contentlbl mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (grayview). With.offset ();        Make.right.equalTo (Grayview). With.offset ( -10);    }];

The above code causes a crash because the CONTENTLBL constraint on line 4th above is not yet built, causing a crash. The case of a red arrow in Xib is a constraint error, and the Red arrow turns into a yellow arrow when the constraint is adjusted correctly, or the constraint is correct. But with masonry and xib different, xib error can tolerate you to correct, masonry as long as there is an error will immediately collapse. So for this kind of interdependence constraint, the following is not built to constrain him seemingly unable to complete, the actual solution is to use the child control in turn rely on him is also possible. That is, you want the parent control to rely on child controls more than 10 pixels, and to set child controls dependent on the parent control less than he 10 pixels is an equivalent concept that can be converted to each other. If you are a careful netizen, you will find that in Xib you set the parent control to rely on child controls, but the actual constraints are placed in the child controls.

The modified code is as follows:

    [Grayview mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (self.view). With.offset ();        Make.width.equalTo (@200);    }];        [Contentlbl mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (grayview). With.offset ();        Make.right.equalTo (Grayview). With.offset ( -10);        Make.bottom.equalTo (Grayview). With.offset ( -10);    }];

3. Set the Percent constraint, that is, one constraint is the number of another constraint.

This constraint generally applies to width and height. For screen adaptation is useful, equal to the former frame of thought added to the AutoLayout.

    [Grayview mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (self.view). With.offset ();//        Make.width.equalTo (@200);        Make.width.equalTo (Self.view). Multipliedby (0.5). Offset (0);    }];        [Contentlbl mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (grayview). With.offset ();        Make.right.equalTo (Grayview). With.offset ( -10);        Make.bottom.equalTo (Grayview). With.offset ( -10);    }];

As with native constraints, you can set the vector coefficients (proportions) after setting an offset.

4. Setting up a constraint update

There are many third-party libraries for the current auto-layout, and masonry is also a heavyweight compared to the other. The biggest advantage of masonry compared to other auto-layout libraries is that the constraint updates are doing well.

Assuming that the constraint is now the 2nd constraint above, now set the button to click on the update constraint code as follows

-(Ibaction) Btnclick: (ID) Sender {    [Self.grayview mas_updateconstraints:^ (Masconstraintmaker *make) {        Make.width.equalTo (@300);    }];    [UIView animatewithduration:3.0 animations:^{        [Self.grayview layoutifneeded];    }];}

If you set constraints on constraint changes, you need to wrap the layoutifneed in a block with UIView animation. Instead of wrapping the constraint update directly.

There are essential differences between mas_updateconstraints and mas_remakeconstraints in updating constraints. The former update is to retain the previous constraint and add the new constraint you added this time.  If the same method of setting constraints occurs, only the values are different, the original constraint is replaced directly. The latter remake is to directly take the original all out and then add the constraints of this setting.

So the update should be careful not to add a constraint with a new method that would conflict with the previous constraint. What remake needs to be aware of is that the constraints you write in remake must be a complete constraint, because the previous constraints are completely emptied.

If you do not fully understand the difference between the two methods, you may write the following code, which is wrong

-(Ibaction) Btnclick: (ID) Sender {    [Self.grayview mas_updateconstraints:^ (Masconstraintmaker *make) {        Make.left.and.top.equalTo (Self.view). With.offset ();        Make.width.equalTo (Self.view). Multipliedby (0.5);    }];        [UIView animatewithduration:3.0 animations:^{        [Self.grayview layoutifneeded];    }];}

Because the original make.width.equalTo (@200); And this time Make.width.equalTo (Self.view). Multipliedby (0.5); Although the settings are set to width but the method is different, the new old capital will keep the conflict error.

If you are not in the Dong Platinum Blog Park See this article please click to view the original text.

5. Set priority and label anti-compression

Sometimes the width of the label or the internal font changes, there may be xx ... In this case, this is because the label is compressed. The masonry has anti-compression settings, and this setting is closely related to the priority priorities of the masonry . IOS9 font changes cause a lot of labels to appear ..., if you used masonry to set up the layout and set up anti-compression, you should be able to completely avoid this problem.

Sets a view that has a child control label.

    [Blackview mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.equalTo (self.view). With.offset ();        Make.top.equalTo (Self.view). With.offset (+);        Make.size.mas_equalTo (Cgsizemake (+));    }];        [ContentLbl2 mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (blackview). With.offset ();        Make.right.equalTo (Blackview). With.offset ( -50);        Make.height.equalTo (@30);    }];

The first piece of code above is to build a normal parent control that can be ignored. The next piece is the label's constraint

If this is set, the right side is 50 less than the parent control, so the label's text will not show up.

However, if you add a constraint that says "width is at least 200" and the precedence is higher than "right is 50 less than the parent control", the code is as follows

    [ContentLbl2 mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (blackview). With.offset ();        Make.width.greaterThanOrEqualTo (@200). Priority (n);        Make.right.equalTo (Blackview). With.offset ( -50). Priority (+);        Make.height.equalTo (@30);    }];

The priority of line 3rd is greater than the priority of line 4th so that line 3rd is executed, and the label is not squeezed.

Anti-compression There's another way to set it up

    [ContentLbl2 mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (blackview). With.offset ();        Make.right.equalTo (Blackview). With.offset ( -50). Priority (990);        Make.height.equalTo (@30);    }];        [ContentLbl2 setcontentcompressionresistancepriority:uilayoutpriorityrequired Foraxis: Uilayoutconstraintaxishorizontal];

Set the "right to 50 less than the parent control" to a priority of 1000, and then write a line of code that is compressed horizontally in the following direction. Note here that the above "right is less than the parent control 50" priority can not be written, because masonry this type of code default priority is 1000, and the following uilayoutpriorityrequired priority is 1000, then the following code is not effective.

In fact, there is a simpler way to set up, do not write the horizontal direction of anti-compression, only need to change the precedence of the above constraint to 750 or less

    [ContentLbl2 mas_makeconstraints:^ (Masconstraintmaker *make) {        make.left.and.top.equalTo (blackview). With.offset ();        Make.right.equalTo (Blackview). With.offset ( -50). Priority (749);        Make.height.equalTo (@30);    }];

Because priority 750 corresponds to the priority enumeration is Uilayoutprioritydefaulthigh, can be understood as masonry itself has an anti-compression protection, priority is 750.

    [ContentLbl2 Setcontentcompressionresistancepriority:uilayoutprioritydefaulthigh Foraxis: Uilayoutconstraintaxishorizontal];

This line of code should be any label that exists by default.

So if you want to make the label anti-compression, set the priority to 750 or less is OK.

　

Summarize:

The 1.Masonry method is not many, the chain method, each point syntax is to return a constraint object, a specific constraint is the property of this object.

2.Masonry different from the xib construction constraints appear red can also be adjusted, the former a problem directly crashes, the problem stuck in the development phase.

3.Masonry you must set up a parent-child relationship before you can establish a constraint, and you cannot add dependencies to controls that do not have constraints set.

4. Update constraints to understand the difference between remake and update.

No Unauthorized reproduction

Comparison with Xib when using masonry to build special layouts