iOS Auto Layout Framework – Masonry Detailed Explanation

Currently, most pages in iOS development have begun to use Interface Builder for UI development, but for some pages with more complex changes, UI development still needs to be done through code. In addition, many older projects are still developed using pure code.

Now the screen sizes of iPhone and iPad are getting bigger and bigger. Although developers only need to develop based on screen points instead of pixels, it is very difficult to develop if you make various judgments based on different screen sizes and write hard coordinates in the project.

Therefore, if you develop UI with pure code, you usually use some automatic layout frameworks to adapt to the screen. The adaptation frameworks provided by Apple include: VFL, UIViewAutoresizing, Auto Layout, Size Classes, etc.

Among them, Auto Layout is the most frequently used layout framework, but it also has its drawbacks. When using UILayoutConstraint, you will find that the amount of code is large, and most of the code is repetitive, so many people do not want to use this framework.

Later, a third-party layout framework Masonry based on UILayoutConstraint encapsulation appeared on Github. Masonry is very convenient to use. This article will explain the use of Masonry in detail.

[[182259]]

Introduction to Masonry

This article is just a brief introduction to Masonry and its usage, and some examples will be given. However, it does not involve the internal implementation of Masonry. I will write a special article to introduce its internal implementation principle, including the chain syntax.

What is Masonry

Masonry is a third-party automatic layout framework that encapsulates the system NSLayoutConstraint and provides developers with an API using chain programming. Masonry supports all operations supported by the system AutoLayout. Compared with the system API functions, Masonry is even better.

Masonry adopts a chain programming method, the code is very clear and easy to understand, and the amount of code looks very small after writing. The layout that used to be implemented by writing a lot of code with NSLayoutConstraint can be done with at least one line of code with Masonry. If you look at the Masonry code below, you will find that it is too simple and easy to understand.

Masonry supports both Mac and iOS platforms, and can be used for automatic layout on both platforms. We can see the following definition in the MASUtilities.h file, which is how Masonry distinguishes some keywords unique to the two platforms through macro definitions.

 #if TARGET_OS_IPHONE
 #import
 #define MAS_VIEW UIView
    #define MASEdgeInsets UIEdgeInsets
 #elif TARGET_OS_MAC
 #import
 #define MAS_VIEW NSView
    #define MASEdgeInsets NSEdgeInsets
 #endif

Github address:

https://github.com/SnapKit/Masonry

Integration

Masonry supports CocoaPods and can be integrated directly through the podfile file. You need to add the following code in CocoaPods:

 pod 'Masonry'  

Masonry Study Tips

I have used both pure code and Interface Builder in UI development, and I have accumulated some experience in the development process. For beginners learning pure code AutoLayout, I suggest that you first learn AutoLayout using Interface Builder, understand Apple's rules and ideas for automatic layout, and then embed this set of ideas in pure code. This way, it is easier to learn and you can avoid many pitfalls.

The AutoLayout constraints set in the project play a role in marking the view layout. After the constraints are set, when the view is created during program operation, the frame will be calculated according to the set constraints and rendered to the view.

Therefore, in the case of pure code, whether the constraints set by the view are correct should be based on the results displayed after running and the printed log.

Pitfalls of Masonry

There are some things to note when using Masonry for constraints.

1. Before adding constraints with Masonry, you need to use it after addSubview, otherwise it will cause a crash.
2. Beginners often make mistakes when adding constraints. There are two reasons for constraint problems: constraint conflict and lack of constraints. For these two problems, you can use debugging and log to check.
3. Previously, when adding constraints using Interface Builder, if there were errors in the constraints, they would be visible directly, and would be reflected as red or yellow warnings. However, Masonry does not reflect this intuitively, but instead reflects it by crashing during operation or printing an exception log, so this is also a disadvantage of hand-writing AutoLayout code.

The only way to solve this problem is to write more code and accumulate experience in using pure code for AutoLayout. Gradually, you will become more and more proficient in using it.

Basic use of Masonry

Masonry Basic API

 mas_makeConstraints() adds constraints
 mas_remakeConstraints() Remove the previous constraints and add new constraints
 mas_updateConstraints() Update constraints 
  
 The equalTo() parameter is an object type, usually a view object or a coordinate system object such as mas_width.
 mas_equalTo() has the same function as above. The parameters can pass basic data type objects, which can be understood as more powerful than the above API 
  
 width() is used to represent the width, for example, the width of the view
 mas_width() is used to get the width value. The difference from the above is that one represents a coordinate system object, and the other is used to get the value of the coordinate system object.

Auto Boxing

For example, equalTo or width above sometimes need to use the mas_ prefix, which needs to be distinguished during development.

If you declare the following two macro definitions before importing #import "Masonry.h" into the current class, you do not need to distinguish the mas_ prefix.

 // Define this constant so that you don't have to use the "mas_" prefix during development .
 #define MAS_SHORTHAND
 // By defining this constant, Masonry can help us automatically box the data of basic data types into object types.
 #define MAS_SHORTHAND_GLOBALS

Modified Statements

In order to make the code easier to use and read, Masonry can be called directly through dot syntax, and two methods, and and with, are added. These two methods actually do nothing inside, but just return self directly inside. The function is to make it easier to read, and has no actual effect on code execution.

For example, the following example:

 make. top . and .bottom.equalTo(self.containerView). with .offset(padding);

Its internal code implementation actually returns self directly.

 - (MASConstraint *) with {
 return self;
 }

Update constraints and layout

Regarding updating constraint layout related APIs, the following four APIs are mainly used:

 - (void)updateConstraintsIfNeeded Call this method. If there are constraints marked as needing to be re-layouted, the layout will be performed immediately, and the updateConstraints method will be called internally
 - (void)updateConstraints Override this method to implement a custom layout process internally
 - (BOOL)needsUpdateConstraints Whether the current layout needs to be re-laid out. The internal function will determine whether there are currently marked constraints.
 - (void)setNeedsUpdateConstraints marks the need for re-layout

Regarding the UIView re-layout related APIs, the following three APIs are mainly used:

 - (void)setNeedsLayout Mark as needing re-layout
 - (void)layoutIfNeeded Checks whether the current view is marked as needing to be re-laid out. If so, the layoutSubviews method is called internally to re-layout.
 - (void)layoutSubviews overrides the current method and completes the layout operation internally

Masonry Example Code

Masonry is essentially an encapsulation of the system AutoLayout, including many of the APIs in it, which are a secondary packaging of the system API.

 Masonry is essentially an encapsulation of the system AutoLayout, including many of the APIs in it, which are a secondary packaging of the system API.
 typedef NS_OPTIONS(NSInteger, MASAttribute) {
    MASAttributeLeft = 1 << NSLayoutAttributeLeft,
    MASAttributeRight = 1 << NSLayoutAttributeRight,
    MASAttributeTop = 1 << NSLayoutAttributeTop,
    MASAttributeBottom = 1 << NSLayoutAttributeBottom,
    MASAttributeLeading = 1 << NSLayoutAttributeLeading,
    MASAttributeTrailing = 1 << NSLayoutAttributeTrailing,
    MASAttributeWidth = 1 << NSLayoutAttributeWidth,
    MASAttributeHeight = 1 << NSLayoutAttributeHeight,
    MASAttributeCenterX = 1 << NSLayoutAttributeCenterX,
    MASAttributeCenterY = 1 << NSLayoutAttributeCenterY,
    MASAttributeBaseline = 1 << NSLayoutAttributeBaseline,
 };

Common methods

Set the padding

 /**
 Set the yellow view to be the same size as self.view and have a padding of 10.
 Note that according to the coordinate system of UIView, the right and bottom are inverted. So it cannot be written as follows, otherwise there will be problems in the right and bottom directions.
 make.edges.equalTo(self. view ). with .offset(10); 
  
 In addition to the offset() method in the example below, there are also methods such as centerOffset(), sizeOffset(), valueOffset() for different coordinate systems.
 */
 [self.yellowView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. left .equalTo(self. view ). with .offset(10);
    make. top .equalTo(self. view ). with .offset(10);
    make. right .equalTo(self. view ). with .offset(-10);
    make.bottom.equalTo(self. view ). with .offset(-10);
 }];

Simplify the way to set padding with insets

 // The following method is equivalent to the above example, except that it uses the insets() method.
 [self.blueView mas_makeConstraints:^(MASConstraintMaker *make) {
 // There is no need to write a minus sign for the bottom and right, the insets method has already done the inversion operation for us.
    make.edges.equalTo(self. view ). with .insets(UIEdgeInsetsMake(10, 10, 10, 10));
 }];

Update Constraints

 // Set the center and size of greenView so that you can achieve the purpose of simple constraints
 [self.greenView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.center.equalTo( self.view );
 // Here, mas_equalTo is used to set the basic data type parameter for size , which is a CGSize structure.
    make. size .mas_equalTo(CGSizeMake(300, 300));
 }]; 
  
 // To more clearly see the effect of constraint changes, update the constraints after displaying for two seconds.
 dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2.f * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
    [self.greenView mas_updateConstraints:^(MASConstraintMaker *make) {
        make.centerX.equalTo(self. view ).offset(100);
        make. size .mas_equalTo(CGSizeMake(100, 100));
 }];
 });

Greater than or equal to and less than or equal to a value

 [self.textLabel mas_makeConstraints:^(MASConstraintMaker *make) {
    make.center.equalTo( self.view );
 // Set the width to be less than or equal to 200
    make.width.lessThanOrEqualTo(@200);
 // Set the height to be greater than or equal to 10
    make.height.greaterThanOrEqualTo(@(10));
 }]; 
  
 self.textLabel.text = @ "This is a test string. You can see steps 1, 2, and 3. The first step is of course to upload a photo. You must upload a close-up photo of the front face. After uploading, the website will automatically recognize your face. If you think the recognition is inaccurate, you can modify it manually. On the left, you can see 16 modification parameters. The top one is the overall modification. You can also modify a single item according to your wishes. Put the mouse on the option, and the preview image on the right will show the corresponding position." ;

textLabel only needs to set one property

 self.textLabel.numberOfLines = 0;

Using basic data types as parameters

 /**
 If you want to use basic data types as parameters, Masonry provides us with macro definitions in the "mas_xx" format.
 These macro definitions convert the incoming basic data types into NSNumber types. This process is called Auto Boxing. 
  
 Macro definitions starting with "mas_xx" are internally implemented through the MASBoxValue() function.
 There are four main macro definitions of this type, namely mas_equalTo(), mas_offset(), greater than or equal to, and less than or equal to.
 */
 [self.redView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.center.equalTo( self.view );
    make.width.mas_equalTo(100);
    make.height.mas_equalTo(100);
 }];

Setting constraint priority

 /**
 Masonry provides us with three default methods, priorityLow(), priorityMedium(), and priorityHigh(), which correspond to different default priorities.
 In addition to these three methods, we can also set the priority value ourselves, which can be set through the priority() method.
 */
 [self.redView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.center.equalTo( self.view );
    make.width.equalTo(self. view ).priorityLow();
    make.width.mas_equalTo(20).priorityHigh();
    make.height.equalTo(self. view ).priority(200);
    make.height.mas_equalTo(100).priority(1000);
 }]; 
 
 Masonry also defines some default priority constants for us, corresponding to different values, and the maximum priority value is 1000.
 static const MASLayoutPriority MASLayoutPriorityRequired = UILayoutPriorityRequired;
 static const MASLayoutPriority MASLayoutPriorityDefaultHigh = UILayoutPriorityDefaultHigh;
 static const MASLayoutPriority MASLayoutPriorityDefaultMedium = 500;
 static const MASLayoutPriority MASLayoutPriorityDefaultLow = UILayoutPriorityDefaultLow;
 static const MASLayoutPriority MASLayoutPriorityFittingSizeLevel = UILayoutPriorityFittingSizeLevel;

Set constraint proportions

 // Set how much to multiply the current constraint value. For example, in this example, the width of redView is 0.2 times the width of self.view .
 [self.redView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.center.equalTo( self.view );
    make.height.mas_equalTo(30);
    make.width.equalTo(self. view ).multipliedBy(0.2);
 }];

Small Exercise

Subview equal height exercise

 /**
 The following example sets the height of the subviews in the array and the view corresponding to the current make to be equal by passing an array to the equalTo() method. 
  
 It should be noted that when setting margins in the following block, insets should be used instead of offset.
 Because when using offset to set the right and bottom margins, these two values ​​should be negative, so there will be problems if you use offset to set the values ​​uniformly.
 */
 CGFloat padding = LXZViewPadding;
 [self.redView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. left . right . top .equalTo(self. view ).insets(UIEdgeInsetsMake(padding, padding, 0, padding));
    make.bottom.equalTo(self.blueView.mas_top).offset(-padding);
 }]; 
  
 [self.blueView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. left . right .equalTo(self. view ).insets(UIEdgeInsetsMake(0, padding, 0, padding));
    make.bottom.equalTo(self.yellowView.mas_top).offset(-padding);
 }]; 
  
 /**
 The key is to set the make.height array below, which can be used to set the heights of the three views to be equal. Other things such as width can be done in a similar way.
 */
 [self.yellowView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. left . right .bottom.equalTo(self. view ).insets(UIEdgeInsetsMake(0, padding, padding, padding));
    make.height.equalTo(@[self.blueView, self.redView]);
 }];

Subview vertical centering exercise

 /**
 Requirements: (I saw this example in someone else's blog, and then I wrote the following code according to the requirements)
 Both views are centered vertically relative to the superview, and the margin between both views as well as the superview is 10, the height is 150, and both views are equal in width.
 */
 CGFloat padding = 10.f;
 [self.blueView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.centerY.equalTo( self.view );
    make. left .equalTo(self. view ).mas_offset(padding);
    make. right .equalTo(self.redView.mas_left).mas_offset(-padding);
    make.width.equalTo(self.redView);
    make.height.mas_equalTo(150);
 }]; 
  
 [self.redView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.centerY.equalTo( self.view );
    make. right .equalTo(self. view ).mas_offset(-padding);
    make.width.equalTo(self.blueView);
    make.height.mas_equalTo(150);
 }];

UITableView dynamic Cell height

In the process of iOS UI development, dynamic cell height of UITableView has always been a problem. There are many ways to achieve such a requirement, but the difference is the complexity and performance of the implementation.

Without considering performance, the dynamic height of tableView Cell can be estimated. If it is implemented by estimating the height, whether it is pure code or Interface Builder, only two lines of code are needed to complete the automatic height adaptation of Cell.

Implementation:

You need to set the rowHeight property of tableView. Here, set it to automatic height to tell the system that the height of the Cell is not fixed and the system needs to calculate it for you. Then set the estimatedRowHeight property of tableView to an estimated height. (The proxy method I use here is actually the same)

principle:

In this case, after the tableView is created, the system will set an estimated value for the tableView based on the value set in the estimatedRowHeight property. Then, when the Cell is displayed, the height of the Cell is obtained and the contentSize of the tableView is refreshed.

 - (void)tableViewConstraints {
    [self.tableView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.edges.equalTo( self.view );
 }];
 } 
  
 - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger) section {
 return self.dataList.count ;​
 } 
  
 - (MasonryTableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    MasonryTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:LXZTableViewCellIdentifier];
    [cell reloadViewWithText:self.dataList[indexPath.row]];
 return cell;
 } 
  
 // It should be noted that this proxy method is different from the proxy method that directly returns the current Cell height.
 // This proxy method estimates the height of all current cells instead of just calculating the displayed cells, so this method consumes a lot of performance.
 // Therefore, the final performance consumption is the same as that of the proxy method by setting the estimatedRowHeight property.
 - (CGFloat)tableView:(UITableView *)tableView estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
 return 50.f;
 } 
  
 - (UITableView *)tableView {
 if (!_tableView) {
        _tableView = [[UITableView alloc] initWithFrame:CGRectZero style:UITableViewStylePlain];
        _tableView.delegate = self;
        _tableView.dataSource = self;
 // Set tableView automatic height
        _tableView.rowHeight = UITableViewAutomaticDimension;
        [_tableView registerClass:[MasonryTableViewCell class] forCellReuseIdentifier:LXZTableViewCellIdentifier];
        [self. view addSubview:_tableView];
 }
 return _tableView;
 }

UIScrollView Auto Layout

I've heard many people say that UIScrollView is troublesome, but I don't think it's that troublesome (not pretending). I think those who say it's troublesome may not have tried it at all, they just think it's troublesome.

Here I will talk about two solutions for automatic layout of UIScrollView, and also talk about the techniques of automatic layout. As long as you master the techniques, the layout is actually very simple.

Layout tips:

Adding constraints to UIScrollView defines its frame, and setting contentSize defines its internal size. UIScrollView performs addSubview operations to add its subviews to contentView.

Therefore, the subviews added to UIScrollView and the constraints added to UIScrollView are all applied to contentView. You can master the skills of setting constraints by setting constraints for UIScrollView in this way.

Set contentSize in advance

 // Set the contentSize of UIScrollView in advance, and set the constraints of UIScrollView itself
 self.scrollView.contentSize = CGSizeMake(1000, 1000);
 [self.scrollView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.edges.equalTo( self.view );
 }]; 
  
 // Although the addSubview operation has been executed inside the get method of redView, UIView always takes the last added parent view as the basis, that is, redView is always on the last added parent view.
 [self.scrollView addSubview:self.redView];
 [self.redView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. left . top .equalTo(self.scrollView);
    make.width.height.mas_equalTo(200);
 }]; 
  
 [self.scrollView addSubview:self.blueView];
 [self.blueView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. left .equalTo(self.redView.mas_right);
    make.top .equalTo(self.scrollView);
    make.width.height.equalTo(self.redView);
 }]; 
  
 [self.scrollView addSubview:self.greenView];
 [self.greenView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. left .equalTo(self.scrollView);
    make.top .equalTo(self.redView.mas_bottom);
    make.width.height.equalTo(self.redView);
 }];

Automatic contentSize

The above example sets the internal size of UIScrollView's contentSize in advance, and then adds Subview directly to it. However, this requires that the size of contentSize must be known in advance, otherwise it cannot be set.

This example will show how to dynamically change the contentSize. The internal view will automatically expand to its own contentSize.

The implementation of this method mainly relies on creating a containerView content view and adding it to the UIScrollView as a subview. The original subviews of UIScrollView are added to the containerView and constraints are set with this view.

Because when you addSubview to UIScrollView, you are essentially adding it to its contentView. That is, the parent view of containerView is contentView, and the size of contentView is supported by containerView to achieve dynamic change of contentSize.

 // When constraining, add constraints to the top, bottom, left, and right of containerView and its subviews to confirm the boundary area of ​​containerView.
 [self.scrollView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.edges.equalTo( self.view );
 }]; 
  
 CGFloat padding = LXZViewPadding;
 [self.containerView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.edges.equalTo(self.scrollView).insets(UIEdgeInsetsMake(padding, padding, padding, padding));
 }]; 
  
 [self.containerView addSubview:self.greenView];
 [self.greenView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. top . left .equalTo(self.containerView).offset(padding);
    make. size .mas_equalTo(CGSizeMake(250, 250));
 }]; 
  
 [self.containerView addSubview:self.redView];
 [self.redView mas_makeConstraints:^(MASConstraintMaker *make) {
    make.top .equalTo(self.containerView).offset(padding);
    make. left .equalTo(self.greenView.mas_right).offset(padding);
    make. size .equalTo(self.greenView);
    make. right .equalTo(self.containerView).offset(-padding);
 }]; 
  
 [self.containerView addSubview:self.yellowView];
 [self.yellowView mas_makeConstraints:^(MASConstraintMaker *make) {
    make. left .equalTo(self.containerView).offset(padding);
    make.top .equalTo(self.greenView.mas_bottom).offset(padding);
    make. size .equalTo(self.greenView);
    make.bottom.equalTo(self.containerView).offset(-padding);
 }];