Real-time display of iOS UI code writing effect

[[144355]]

There are two ways to write iOS application UI, one is Storyboard/Xib, and the other is hand-written code. Storyboard/Xib organizes UI. Because it provides visualization features, you can display the results by dragging UI controls from the UI library, which greatly improves the development speed. But there is a problem with multi-person collaborative development. Since all UIs are placed in the same Storyboard file, conflicts will occur when merging codes using Git/SVN. Multi-person collaborative development is not the main problem. Some people have proposed to create multiple Storyboards to separate UI writing. The main problem of Storyboard/Xib is that the code reusability is relatively poor. So some people choose to hand-write UI code, which not only solves the problem of multi-person collaborative development, but also uses custom controls in multiple Views. But every time you write UI code by hand, you have to compile, build and run it, and finally display it in the simulator, which will slow down the development speed. If you save the changes every time you modify the UI control, the modified results will be displayed in the simulator in real time, which can greatly improve the speed of writing UI.

Auto Layout

What is Auto Layout

Auto Layout is a constraint-based layout system that adjusts the position and size of UI elements according to the constraint relationship between UI elements.

What problems does Auto Layout solve?

• Easier to adapt to screens of devices with different resolutions (iPhone 6 Plus, iPhone 6, iPhone 5s/5, iPhone 4s/4)
• No additional processing is required when the device is rotated
• Using constraints to describe layout logic is easier to understand and clear

How to use Auto Layout

The constraint class in Auto Layout corresponds to NSLayoutConstraint, and there are two main ways to create NSLayoutConstraint objects. The first is

 + (id)constraintWithItem:(id)view1
               attribute:(NSLayoutAttribute)attribute1
               relatedBy:(NSLayoutRelation)relation
                  toItem:(id)view2
               attribute:(NSLayoutAttribute)attribute2
              multiplier:(CGFloat)multiplier
                constant:(CGFloat)constant;

The main meaning of the above method is that the attribute1 of a view1 is equal to (less than or equal to/greater than or equal to) the multiplier of the attribute2 of a view2 plus the constant. The attribute mainly consists of the following values ​​representing the position (up/down/left/right) and size (width/height):

 typedef enum : NSInteger {
   NSLayoutAttributeLeft = 1 ,
 NSLayoutAttributeRight,
 NSLayoutAttributeTop,
 NSLayoutAttributeBottom,
 NSLayoutAttributeLeading,
 NSLayoutAttributeTrailing,
 NSLayoutAttributeWidth,
 NSLayoutAttributeHeight,
 NSLayoutAttributeCenterX,
 NSLayoutAttributeCenterY,
 NSLayoutAttributeBaseline,
   NSLayoutAttributeNotAnAttribute = 0  
 }NSLayoutAttribute;

Simplified, the formula can be expressed as:

 view1.attribute1 = view2.attribute2 * multiplier + constant

The second way is:

 + (NSArray *)constraintsWithVisualFormat:(NSString *)format
                                 options:(NSLayoutFormatOptions)opts
                                 metrics:(NSDictionary *)metrics
                                   views:(NSDictionary *)views;

This method mainly uses Visual Format Language to describe constraint layout. Although the syntax is relatively concise, it is less readable and prone to errors.

Problems with Auto Layout

Although Auto Layout is very powerful and flexible in laying out views, the syntax for creating constraints is too complicated. Here is an example from Masonry:

 UIView *superview = self; 
 
 UIView *view1 = [[UIView alloc] init];
 view1.translatesAutoresizingMaskIntoConstraints = NO;
 view1.backgroundColor = [UIColor greenColor];
 [superview addSubview:view1]; 
 
 UIEdgeInsets padding = UIEdgeInsetsMake( 10 , 10 , 10 , 10 ); 
 
 [superview addConstraints:@[ 
 
 //view1 constraints  
    [NSLayoutConstraint constraintWithItem:view1
                                 attribute:NSLayoutAttributeTop
                                 relatedBy:NSLayoutRelationEqual
                                    toItem:superview
                                 attribute:NSLayoutAttributeTop
                                multiplier: 1.0  
                                  constant:padding.top], 
 
    [NSLayoutConstraint constraintWithItem:view1
                                 attribute:NSLayoutAttributeLeft
                                 relatedBy:NSLayoutRelationEqual
                                    toItem:superview
                                 attribute:NSLayoutAttributeLeft
                                multiplier: 1.0  
                                  constant:padding.left], 
 
    [NSLayoutConstraint constraintWithItem:view1
                                 attribute:NSLayoutAttributeBottom
                                 relatedBy:NSLayoutRelationEqual
                                    toItem:superview
                                 attribute:NSLayoutAttributeBottom
                                multiplier: 1.0  
                                  constant:-padding.bottom], 
 
    [NSLayoutConstraint constraintWithItem:view1
                                 attribute:NSLayoutAttributeRight
                                 relatedBy:NSLayoutRelationEqual
                                    toItem:superview
                                 attribute:NSLayoutAttributeRight
                                multiplier: 1  
                                  constant:-padding.right], 
 
 ]];

If you need to write so many lines of code for such a simple example, imagine how painful it would be to create constraints for multiple views. Another way is to use Visual Format Language (VFL), which has a simpler syntax but poor readability and is prone to errors.

Masonry

Why use Masonry

Masonry uses a chained DSL (Domain-specific language) to encapsulate NSLayoutConstraint. This makes Auto Layout layout code easier to read and concise.
Use Masonry's MASConstraintMaker to express the same constraint

 UIEdgeInsets padding = UIEdgeInsetsMake( 10 , 10 , 10 , 10 ); 
 
 [view1 mas_makeConstraints:^(MASConstraintMaker *make) {
    make.top.equalTo(superview.mas_top).with.offset(padding.top); //with is an optional semantic filler  
    make.left.equalTo(superview.mas_left).with.offset(padding.left);
    make.bottom.equalTo(superview.mas_bottom).with.offset(-padding.bottom);
    make.right.equalTo(superview.mas_right).with.offset(-padding.right);
 }];

Even shorter

 [view1 mas_makeConstraints:^(MASConstraintMaker *make) {
    make.edges.equalTo(superview).with.insets(padding);
 }];

#p#

How to use

There are three ways to use Masonry to create constraints to define layouts: mas_makeConstraints, mas_updateConstraints, and mas_remakeConstraints.

1. mas_makeConstraints

After creating a constraint using mas_makeConstraints, you can use a local variable or attribute to save it for next reference; if you create multiple constraints, you can use an array to save them.

 // in public/private interface  
 @property (nonatomic, strong) MASConstraint *topConstraint; 
 
 ... 
 
 // when making constraints  
 [view1 mas_makeConstraints:^(MASConstraintMaker *make) {
    self.topConstraint = make.top.equalTo(superview.mas_top).with.offset(padding.top);
    make.left.equalTo(superview.mas_left).with.offset(padding.left);
 }]; 
 
 ...
 // then later you can call  
 [self.topConstraint uninstall];

2. mas_updateConstraints

Sometimes you need to update constraints (for example, animation and debugging) instead of creating fixed constraints. You can use the mas_updateConstraints method.

 // this is Apple's recommended place for adding/updating constraints  
 // this method can get called multiple times in response to setNeedsUpdateConstraints  
 // which can be called by UIKit internally or in your code if you need to trigger an update to your constraints  
 - ( void )updateConstraints {
    [self.growingButton mas_updateConstraints:^(MASConstraintMaker *make) {
        make.center.equalTo(self);
        make.width.equalTo(@(self.buttonSize.width)).priorityLow();
        make.height.equalTo(@(self.buttonSize.height)).priorityLow();
        make.width.lessThanOrEqualTo(self);
        make.height.lessThanOrEqualTo(self);
 }]; 
 
 //according to apple super should be called at end of method  
    [ super updateConstraints];
 }

3. mas_remakeConstraints

mas_remakeConstraints is similar to mas_updateConstraints, both of which update constraints. However, mas_remakeConstraints deletes the previous constraint and then adds a new constraint (suitable for moving animations); while mas_updateConstraints only updates the value of the constraint.

 - ( void )changeButtonPosition {
    [self.button mas_remakeConstraints:^(MASConstraintMaker *make) {
        make.size.equalTo(self.buttonSize); 
 
 if (topLeft) {
            make.top.and.left.offset( 10 );
 } else {
            make.bottom.and.right.offset(- 10 );
 }
 }];
 }

To learn more about the above three code snippets, you can download the Masonry iOS Examples project for reference.

Classy

Classy Introduction and Features

Classy is a stylesheet system that can be seamlessly integrated with UIKit. It borrows the ideas of CSS, but introduces new syntax and naming rules.

Flexible built-in syntax

{ } : ; These syntax symbols are optional, you can choose to express your stylesheet in a way that suits you.

You can use { } : ; to limit the stylesheet

 $main-color = #e1e1e1; 
 
 MYCustomView {
  background-color: $main-color;
  title-insets: 5 , 10 , 5 , 10 ;
 > UIProgressView.tinted {
    progress-tint-color: black;
 track-tint-color: yellow;
 }
 } 
 
 ^UIButton.warning, UIView.warning ^UIButton {
  title-color[state:highlighted]: #e3e3e3;
 }

Or you can use spaces to delimit the stylesheet

 $main-color = #e1e1e1 
 
 MYCustomView
  background-color $main-color
  title-insets 5 , 10 , 5 , 10  
 > UIProgressView.tinted
 progress-tint-color black
 track-tint-color yellow 
 
 ^UIButton.warning, UIView.warning ^UIButton
  title-color[state:highlighted] #e3e3e3

Default Style

Classy looks for a stylesheet file named stylesheet.cas in the application bundle by default. If you use this file name, you can load the stylesheet file without doing anything.
But if you want to specify another file path (style file name), you can create [CASStyler defaultStyler]

 [CASStyler defaultStyler].filePath = [[NSBundle mainBundle] pathForResource:@ "myStyles.cas" ofType:nil];

If you also want to get error information for debugging when an error occurs, you can use -(void)setFilePath:error:

 NSError *error = nil;
 NSString filePath = [[NSBundle mainBundle] pathForResource:@ "myStyles.cas" ofType:nil];
 [[CASStyler defaultStyler] setFilePath:filePath error:&error];

If you use Storyboard/Xib to organize the UI interface, you need to set the filePath in the int main(int argc, char * argv[]) method of main.m to ensure that the stylesheet is loaded before the UIWindow is created. Otherwise (using handwritten UI code), you set the filePath in the - (BOOL)application:didFinishLaunchingWithOptions: method of AppDelegate.m

Live Reload

Live Reload is a key feature that displays the effects of writing UI code in real time. It can check stylesheet file changes in real time without recompiling, building, and running the simulator, thus greatly improving development speed.
To enable Live Reload, you need to specify the stylesheet path and only run on the simulator.

 # if TARGET_IPHONE_SIMULATOR
    NSString *absoluteFilePath = CASAbsoluteFilePath(@ "../Styles/stylesheet.cas" );
    [CASStyler defaultStyler].watchFilePath = absoluteFilePath;
 #endif

Selectors

Style Selectors are a way to specify which view uses which style. There are three main ways to specify the target view:

1. Object Class
2. View Hierarchy
3. Style Class

You can mix and match the three methods, as shown below:

 /* match views
 * where class is UIButton or UIButton subclass
 * and styleClass is "large"
 * and superview class is UITabBar
 */   
 
 UITabBar > ^UIButton.large { }

For detailed usage, please refer to the Selectors section of the official website.

To avoid confusion with Objective-C message selectors, the term style selectors refers to selectors for classy stylesheets.

Properties

Classy supports all UIAppearance properties and methods, as well as many properties that are not related to UIAppearance. Classy uses the same property naming as UIKit, so you don't have to think about how to map style properties to Objective-C properties.
The properties of the UIPageControl class are as follows:

 @property (nonatomic,retain) UIColor *pageIndicatorTintColor;
 @property (nonatomic,retain) UIColor *currentPageIndicatorTintColor;

The name of the style property uses the same name as Objective-C

 UIPageControl {
  pageIndicatorTintColor black
  currentPageIndicatorTintColor purple
 }

The naming convention for style properties is kebab case.

 UIPageControl {
  page-indicator-tint-color black
  current-page-indicator-tint-color purple
 }

For detailed usage, please refer to the Properties section of the official website.

Keep it DRY(Don't Repeat Yourself)

A very important principle in programming is to avoid duplication, which can not only greatly reduce duplicate code, but also make the code easier to reuse and maintain. Classy provides three ways to avoid code duplication: grouping, nesting, variables

Grouping

If there are two or more style selectors sharing the same attribute

 UISlider.info {
  minimum-track-tint-color black
  maximum-track-tint-color purple
 } 
 
 UISlider.error {
  minimum-track-tint-color black
  maximum-track-tint-color purple
 thumb-tint-color red
 }

We can extract the same attributes into grouped style selectors

 UISlider.info, UISlider.error {
  minimum-track-tint-color black
  maximum-track-tint-color purple
 } 
 
 UISlider.error {
 thumb-tint-color red
 }

#p#

Nesting

If two or more style selectors share the same view hierarchy

 UICollectionView {
 background-color #a2a2a2
 } 
 
 UICollectionView > UICollectionViewCell {
 clips-to-bounds NO
 } 
 
 UICollectionView > UICollectionViewCell UILabel {
 text-color purple
 } 
 
 UICollectionView > UICollectionViewCell UILabel.title {
 font 20  
 }

We express the view hierarchies in this way through nesting

 UICollectionView {
 background-color #a2a2a2 
 
 > UICollectionViewCell {
 clips-to-bounds NO 
 
 UILabel {
 text-color purple 
 
 &.title {
 font 20  
 }
 }
 }
 }

Variables

Classy allows you to store multiple identical style property values ​​for sharing by defining variables. The variable naming rules are as follows:

• Must start with an uppercase or lowercase letter or a $ sign

• Can contain _, - or any alphanumeric characters

   // prefix with ' $ ' to help distinguish variables  
   $brand-color = #e1e1e1 
   
   // OR not  
   insets = 5 , 10 , 5 , 10   
   
   UIButton {
    background-color $brand-color
   contentEdgeInsets insets
    background-image[state:selected] bg_button insets
   }

  *** The official also provides an example to explain how to use it: Custom Views Example

ClassyLiveLayout

ClassyLiveLayout combines Classy stylesheets with Masonry to create a tool that allows you to fine-tune Auto Layout constraints in real time in a running simulator.

ClassyLiveLayout has a core category: UIView+ClassyLayoutProperties, which defines the following properties in UIView:

 @property (nonatomic, assign) UIEdgeInsets cas_margin;
 @property (nonatomic, assign) CGSize cas_size; 
 
 // shorthand properties for setting only a single constant value  
 @property (nonatomic, assign) CGFloat cas_sizeWidth;
 @property (nonatomic, assign) CGFloat cas_sizeHeight; 
 
 @property (nonatomic, assign) CGFloat cas_marginTop;
 @property (nonatomic, assign) CGFloat cas_marginLeft;
 @property (nonatomic, assign) CGFloat cas_marginBottom;
 @property (nonatomic, assign) CGFloat cas_marginRight;

cas_margin and cas_size represent the position and size of UI elements respectively, while the rest of the properties are further subdivisions of the two properties. We can access style properties from stylesheets to define constraint layouts, separating data from code, which is conducive to modifying and reusing code.

 UIView.blue-box {
 cas_size: 80   100  
 cas_margin-top: 60  
 cas_margin-left: 50  
 } 
 
 UIView.red-box {
 cas_size-width: 120  
 cas_margin-left: 20  
 }

We can reference style properties when defining layouts in updateConstraints or updateViewConstrains

 - ( void )updateViewConstraints {
  [ super updateViewConstraints]; 
 
  [_blueBoxView mas_updateConstraints:^(MASConstraintMaker *make) {
      make.width.equalTo(@(_blueBoxView.cas_size.width));
      make.height.equalTo(@(_blueBoxView.cas_size.height));
      make.top.equalTo(@(_blueBoxView.cas_margin.top));
      make.left.equalTo(@(_blueBoxView.cas_margin.left));
 }]; 
 
  [_redBoxView mas_updateConstraints:^(MASConstraintMaker *make) {
      make.width.equalTo(@(_redBoxView.cas_size.width));
      make.height.equalTo(_blueBoxView);
      make.top.equalTo(_blueBoxView);
      make.left.equalTo(_blueBoxView.mas_right).with.offset(_redBoxView.cas_margin.left);
 }];
 }

When defining view layouts, Auto Layout constraints are placed in stylesheets and live reloaded. If you modify constraints, you can see the effect of the changes in real time without having to recompile, build, and run the simulator.

Sample Project

Configuration Project

Since Masonry, Classy and ClassyLiveLayout need to be referenced, the Podfile is configured as follows:

 pod 'Masonry' , '~> 0.6.1'  
 pod 'Classy' , '~> 0.2.4'  
 pod 'ClassyLiveLayout' , '~> 0.6.0'  

Writing Code

1. Add stylesheet.cas file to the project

After installing Masonry, Classy and ClassyLiveLayout, the first time you run the project, you will see an error message saying there is no stylesheet.cas file:

No stylesheet.cas file error.png

Just add an empty stylesheet.cas file to your project.

Create stylesheet.cas file.png

2. Create a LiveView class that inherits SHPAbstractView.

Create LiveView inherit SHPAbstractView.png

Create a LiveView object in ViewController and then reference it by self.view.

Setup root view in ViewController.png

When compiling and running, a compilation error occurs in SHPAbstractView.h because UIView cannot be found.

SHPAbstractView Compile error.png

#p#

The problem can be solved by simply introducing UIKit, but when running the application, the following error occurs:

Must override methods.png

The main reason is that any custom UIView that inherits SHPAbstractView needs to override two methods: - (void)addSubviews and - (void)defineLayout. We can see from the source code of SHPAbstractView:

SHPAbstractView Source Code .png

So just override two methods in the LiveView.m file

 #pragma mark - Add subviews and define layout
 - ( void )addSubviews
 {
 } 
 
 - ( void )defineLayout
 {
 }

3. LiveView class design

LiveView mainly consists of two properties: redBoxView and blueBoxView. redBoxView represents the red square, and blueBoxView represents the blue square.

 # import   "SHPAbstractView.h"   
 
 @interface LiveView : SHPAbstractView 
 
 @property (strong, nonatomic) UIView *redBoxView;
 @property (strong, nonatomic) UIView *blueBoxView; 
 
 @end  

4. LiveView class implementation

Since the SHPAbstractView class has already handled how to initialize the View, it exposes two interfaces - (void)addSubviews and -(void)defineLayout to handle building the view hierarchy and defining the layout respectively. The subclass only needs to override these two methods of SHPAbstractView to create a LiveView.
However, we put all Auto Layout constraints in stylesheets for real-time loading (Live reload), that is, in the stylesheet.cas file of this project, to separate layout data from layout code.

 UIView.redBox {
 cas_marginTop 50  
 cas_marginLeft 20   
 
 cas_size 100   100  
 } 
 
 UIView.blueBox {
 cas_marginTop 50  
 cas_marginRight - 20   
 
 cas_size 100   100  
 }

Once you have the constraint data, you can lay it out in code:

 @implementation LiveView 
 
 #pragma mark - Add subviews and define layout
 - ( void )addSubviews
 {
    self.backgroundColor = [UIColor whiteColor];
    [self addSubview:self.redBoxView];
    [self addSubview:self.blueBoxView];
 } 
 
 - ( void )defineLayout
 {
    [self.redBoxView mas_updateConstraints:^(MASConstraintMaker* make){
        make.top.equalTo(@(self.redBoxView.cas_marginTop));
        make.left.equalTo(@(self.redBoxView.cas_marginLeft));
        make.width.equalTo(@(self.redBoxView.cas_sizeWidth));
        make.height.equalTo(@(self.redBoxView.cas_sizeHeight));
 }]; 
 
    [self.blueBoxView mas_updateConstraints:^(MASConstraintMaker *make){
        make.top.equalTo(@(self.blueBoxView.cas_marginTop));
        make.right.equalTo(@(self.blueBoxView.cas_marginRight));
        make.width.equalTo(@(self.blueBoxView.cas_sizeWidth));
        make.height.equalTo(@(self.blueBoxView.cas_sizeHeight));
 }];
 } 
 
 #pragma mark - Lazy initialization
 - (UIView*)redBoxView
 {
 if (!_redBoxView) {
        _redBoxView = [UIView new ];
        _redBoxView.cas_styleClass = @ "redBox" ;
        _redBoxView.backgroundColor = [UIColor redColor];
 } 
 
 return _redBoxView;
 } 
 
 - (UIView*)blueBoxView
 {
 if (!_blueBoxView) {
        _blueBoxView = [UIView new ];
        _blueBoxView.cas_styleClass = @ "blueBox" ;
        _blueBoxView.backgroundColor = [UIColor blueColor];
 } 
 
 return _blueBoxView;
 }

5. The simulator supports Live Reload

To enable Live Reload, you need to specify the stylesheet path and only run on the simulator.

Support Live Reload.png

The effect at this time:

#p#

6. Separate style files

Because some netizens have raised the following question: If the styles of all views are placed in the same stylesheet.cas file, the stylesheet.cas file will be complicated, and it will not be easy to merge the code when multiple people collaborate on development. Therefore, it is necessary to separate the style files into multiple files.

1. Create a variable.cas file and put the style of redBox corresponding to UIView in the variable.cas file.

   variable.cas file.png

2. Use the @import directive in the stylesheet.cas style file to reference the variable.cas file

stylesheet.cas file.png

***Effect

Sample code storage address: LiveAutoLayout

Summarize

Before, every time you change the handwritten UI code, you usually have to recompile, build, and run the simulator to see the effect. But after using Masonry, Classy, ​​and ClassLiveLayout together, you can say goodbye to this time-consuming process and greatly improve the development speed. In addition, we put all Auto Layout constraints in stylesheets for real-time loading (Live reload), separate layout data from layout code, and make the code more reusable and maintainable. Classy also provides three ways to avoid duplication: Grouping, Nesting, and Variable, so that style data can be reused as much as possible.
This is my first time writing a technical blog. There may be many errors and loopholes. I hope you can give me more advice and I hope this article can help you.