A brief discussion on iOS screen adaptation practice

Screen adaptation in front-end development is actually a basic skill, and every programmer has his own summary through long-term practice.

On the iOS platform, I personally feel that Apple's support for adaptation is not very user-friendly. It provides technologies such as AutoLayout and sizeClass, which are not as flexible as front-end technologies such as flexBox. It seems that Apple has chosen the wrong skill tree, and it pays too much attention to using xib to configure the UI, but many programmers are still used to pure code programming. Cocoa does not have pure layout files such as css, which often leads to us writing layout, UI and logic together, which is very confusing and lengthy.

The following is a brief introduction to the direction and ideas of screen adaptation in practice, just to stimulate further discussion.

From Design to Code: Communication and Standards

The UI interface of the App is drawn by designers (product, UI) and then implemented by developers. Both parties must have good communication and standardize and document the design content.

For designers, the rules of adaptation are always in their minds. Whether it is proportional scaling, fixed spacing, a common set of rules, or a special layout for large screens, all need to be conveyed to the honest coders in a clear way.

The most common layout methods are:

• Fixed spacing: The spacing is always fixed at different sizes.
• Flow layout: text, pictures, etc. are arranged in a flow-like manner on different screens. For example, four pictures are displayed in a row on a large screen and three pictures are displayed in a row on a small screen. The picture size is fixed.
• Proportional enlargement: Proportional enlargement of spacing, text size, image size, etc.
• Maintain ratio: The length and width of two UI elements or images should maintain a certain ratio.
• Alignment: Elements are aligned in a certain direction.

Designers need to clearly mark these layout rules to facilitate communication and future tracing.

For some common UI components, standardization is necessary, which is conducive to the unification of App style in design and convenient for development and encapsulation in implementation.

UI construction: xib VS pure code

Apple has always used xib to promote their app development as being easy to use: just drag and drop everything you need onto the screen, and a UI interface is ready. Isn't that cool?

The advantages of Xib are obvious:

• Easy to use, visual, what you see is what you get
• Reduce the amount of code
• Fast, suitable for rapid development of small apps

However, in our actual project, it is not recommended to use xib.

First of all, xib itself is too clumsy and can only build some simple UIs. It has poor dynamics and cannot meet the complex UI interaction requirements of App.

Secondly, those who have done performance optimization know that the performance of xib (or StoryBoard) is very poor. Compared with components allocating with pure code, xib loads slowly and takes up the size of the App package. It's not just the performance of the App. When you use an old Mac to open a large xib file, it can sometimes make you question your life and seriously affect your development efficiency (mood).

In addition, xib is not a good option for team collaboration: it is difficult to read, historical changes cannot be viewed on git, conflicts are prone to occur and are difficult to resolve, the links between elements and code through outlets are difficult to maintain, and errors are prone to occur in changes, etc.

In addition, for an engineer like me who switched to the front-end midway, I have a mysterious distrust of everything configured on the IDE interface, and I feel that it is not as reliable as lines of black-and-white code.

Of course, we don't completely disable xib. The disadvantages of coding UI are also obvious: cumbersome and large amount of code. Therefore, for some UI components with many elements and relatively fixed, we can use xib to reduce the amount of code:

In the case of cumbersome UI code and a lot of repeated coding, we can clarify the logic through appropriate encapsulation (UI factory class) and organizational structure (MVC, separation of UI code).

 // label factory method
 + (UILabel *)labelWithFont:(UIFont *)font
                     color:(UIColor *)
                      text:(NSString *)text
             attributeText:(NSAttributeString *)attributeText
                 alignment:(NSTextAlignment)alignment;

Layout: Back to Basics

Apple introduced AutoLayout in Cocoa platform for basic UI layout since iOS 7. However, AutoLayout is very anti-human, not only the code is cumbersome, but also the usage is inflexible and has many restrictions.

For example, if I want to display three elements on the screen with equal spacing, it would be a complete failure if I used AutoLayout, not to mention the advanced requirement of dynamically switching between two layouts.

Later, Apple launched sizeClass in an attempt to solve the problem of multiple layouts, but it still did not address the pain points of programmers, and its reliance on xib made it less versatile.

A typical AutoLayout code is as follows:

 _topViewTopPositionConstraint = [NSLayoutConstraint
                                    constraintWithItem:_topInfoView
                                    attribute:NSLayoutAttributeTop
                                    relatedBy:NSLayoutRelationEqual
                                    toItem:self. view  
                                    attribute:NSLayoutAttributeTop
                                    multiplier:1.0
                                    constant:self.navigationController.navigationBar.frame. size .height + self.navigationController.navigationBar.frame.origin.y]; 
    
   [self. view addConstraint:topViewLeftPositionConstraint]; 
    
 (The similar structure above is omitted here*4)

A lot of code is omitted above, and in fact it can't fit on one page. What does it do? It just places an element close to the edge of the screen. In the project, we will use the third-party AutoLayout encapsulation: PureLayout, which simplifies the code and has other practical functions.

AutoLayout is suitable for:

• Basic alignment (up, down, left, right, center, etc.)
• Fixed layout, fixed spacing, and low dynamics
• Simple and few UI elements

Not good at:

• Proportional layout
• A more dynamic part of the page
• Adaptation to different screen size ratios
• Complex UI

Another point is that AutoLayout has a lossy effect on performance, so in scenarios that require performance, such as cells in a list, we will use code to calculate the frame and increase the sliding frame rate.

Therefore, in actual projects, it is necessary to choose a layout method.

Here is the layout code snippet of the homepage news feeds in the App:

 - (void)layoutSubviews { 
     
 [super layoutSubviews]; 
     
    CGFloat cellWidth = CGRectGetWidth(self.bounds);
 CGFloat currentY = 0.f; 
     
 // 0.content
    CGFloat cellHeight = CGRectGetHeight(self.bounds);
    CGFloat contentHeigth = cellHeight - kCellPaddingHeight;
    _mainContentView.frame = CGRectMake(0, 0, cellWidth, contentHeigth); 
     
 // 1. topic
    CGFloat topicLabelWidth = [_topicLabel.text boundingRectWithSize:CGSizeMake(CGFLOAT_MAX, CGFLOAT_MAX) options:NSStringDrawingUsesLineFragmentOrigin attributes:@{NSFontAttributeName:_topicLabel.font} context:nil]. size .width; 
     
    CGFloat topicLabelHeight = [@ "Height measurement" boundingRectWithSize:CGSizeMake(CGFLOAT_MAX, CGFLOAT_MAX) options:NSStringDrawingUsesLineFragmentOrigin attributes:@{NSFontAttributeName:_topicLabel.font} context:nil]. size .height; 
     
    CGFloat topicLogoLeftPadding = 3.f;
    CGFloat topicLogoWidth = 10.f;
    CGFloat topicLeftPadding = 13.f; 
     
    _topicView.frame = CGRectMake(topicLeftPadding, currentY + kTopicUpPadding, topicLogoWidth + topicLogoLeftPadding + topicLabelWidth, topicLabelHeight);
    _topicLogo.frame = CGRectMake(topicLabelWidth + topicLogoLeftPadding, CGRectGetHeight(_topicView.frame) / 2.0 - topicLogoWidth / 2.0, topicLogoWidth, topicLogoWidth);
    _topicLabel.frame = CGRectMake(0, 0, topicLabelWidth, topicLabelHeight); 
     
 (Omitted a lot of code...) 
     
 // 10._sourceLabel
    CGSize sourceSize = [_sourceLabel.text boundingRectWithSize:CGSizeMake(CGFLOAT_MAX, CGFLOAT_MAX) options:NSStringDrawingUsesLineFragmentOrigin attributes:@{NSFontAttributeName:_sourceLabel.font} context:nil]. size ; 
     
    _sourceLabel.frame = CGRectMake(kEdgeHorizontalPadding, currentY + kLeadingUpPading, sourceSize.width, sourceSize.height);
 }

As you can see, in order to determine the position of each element, we need to perform a lot of calculations, and the code is not easy to read and is cumbersome. If dynamicity is introduced, such as changing the font size of different screens and scaling the element size proportionally, the amount of calculation will increase by another order of magnitude.

Dynamic layout: clear and independent

The UI interface is dynamic. In different states, different sizes, or horizontal and vertical screen situations of mobile phones, we often need to switch between multiple layout solutions or fine-tune the layout. If you use xib layout, you can use the SizeClass + AutoLayout solution; if it is a page implemented by code, there is no official tool provided, and you can only use logic to judge.

Generally speaking, when we write complex UI pages, we need to follow two principles:

1. The UI layout code should be clear: This is the most important thing. You should know at a glance what to adjust and how to adjust it. If you can't, split it appropriately and optimize the naming.
2. Layout code should be independent of business logic: In some common design patterns, we will decouple the UI and data model. Within the UI, we should also decouple the interaction and configuration logic from the layout, and separate pure layout files such as front-end css.

Extract the layout code and call different implementations at different sizes:

 if (IS_IPHONE_6){
    self.layout = [MyLayout iPhone6Layout];
 } else if (IS_IPHONE_6_PLUS){
    self.layout = [MyLayout iPhone6PlusLayout];
 } 
 
 // Implement small screen layout
 + (MyLayout *)iPhone6Layout {...}
 // Implement large screen layout
 + (MyLayout *)iPhone6PlusLayout {...}

Font adaptation: font set

In development, we often encounter situations where we need to set fonts dynamically:

• Different screen sizes, or horizontal and vertical screens, need to display different font sizes.
• Provides users with the option to adjust the font size of articles.
• Different language versions of the app require different display fonts.

A simpler approach is to use macros or enumerations to define font parameters. We get different values ​​for screens of different sizes:

 #ifdef IPHONE6
 #define kChatFontSize 16.f
 # else IPHONE6Plus
 #define kChatFontSize 18.f
 #endif

When adapting and expanding the fonts of some old codes, directly modifying the source code will cause too many changes and may cause confusion. You can use the runTime method to hack the display of controls such as Label and replace the original setFont method:

 + (void) load { 
     
    Method newMethod = class_getClassMethod([self class], @selector(mySystemFontOfSize:));
    Method method = class_getClassMethod([self class], @selector(systemFontOfSize:));
    method_exchangeImplementations(newMethod, method);
 } 
   
 + (UIFont *)mySystemFontOfSize:(CGFloat)fontSize{
 UIFont *newFont = nil;
 if (IS_IPHONE_6){
        newFont = [UIFont adjustFont:fontSize * IPHONE6_INCREMENT];
    } else if (IS_IPHONE_6_PLUS){
        newFont = [UIFont adjustFont:fontSize * IPHONE6PLUS_INCREMENT];
 } else {
        newFont = [UIFont adjustFont:fontSize];
 }
 return newFont;
 }

The above routines have obvious shortcomings: they are not flexible enough, the logic is dispersed, they are not easy to maintain, and their scalability is not good.

A better practice is to introduce the concept of font collection. What is a font collection? When we use Keynote or Office, the software will provide some paragraph styles, which define the fonts of paragraphs, titles, descriptions and other texts. We can switch between different paragraph styles to directly change the font style of the entire article.

Does it sound similar to our needs? We also do similar things in the code, defining fonts for different scenarios into a Font Collection:

 @protocol XRFontCollectionProtocol <NSObject> 
 
 - (UIFont *)bodyFont; // article
 - (UIFont *)chatFont; // Chat
 - (UIFont *)titleFont; // title
 - (UIFont *)noteFont; // description
 ......
 @ end  

Different scenarios, flexibly choose different font sets:

 + (id<XRFontCollectionProtocol>)currentFontCollection {  
 #ifdef IS_IPhone6
 return [self collectionForIPhone6];
 #elif IS_IPhone6p
 return [self collectionForIPhone6Plus];
 #endif
 return nil;
 } 
 
 // set font
 titleLabel.font = [[XRFontManager currentFontCollection] titleFont];

To adapt to new screens or scenes, we only need to simply add a set of fonts. It is very convenient to manage the font styles in the App, and it is also easy to switch dynamically.

In summary, it is relatively simple to implement a design draft in one size with code, but to faithfully reflect the design idea at various sizes requires reasonable code design and a certain amount of code.

UI restoration is actually a very important part of front-end development. As programmers, we often focus on the stability of the code and the normal use of the business, but ignore the equally important user experience factor of the software interface. If a designer sees that the proportions, fonts, and colors he has carefully adjusted are displayed crookedly on mobile phones of different sizes, he will definitely be very angry.

The author is a mobile development engineer at Xingren, a former embedded engineer, and focuses on new trends in big front-end technology.