With auto layout, why are you still afraid of writing Uitabelview's adaptive layout?

Apple is the company that attaches the most importance to the app development experience. Every update, from Xib to storyboard, from auto layout to size Class, can be a great convenience for iOS app development. However, for an absolute majority of iOS Siege Lions, we are still afraid to write Uitabelview adaptive layouts. Of course, fear is not because we can't write, or what special technical points we have, but because it's too much trouble. Of course, the second part of the article will give the corresponding solution, after all, this article is not to spit groove and spit groove.

How troublesome is Uitabelview's adaptive layout?

uncertainty about data types: the more kinds, the more complex the page.

NetEase News

To NetEase News client as an example, the possible data include text news, picture News, Atlas, promotion, video and so on. Each type of data is subdivided into many different states, depending on the source or the number of clicks. Basically, each data type requires at least a single cell to render, and each cell's layout must be written separately. So, the type of data will directly determine the complexity of the page itself.

uncertainty of data length: the more uncertain fields, the higher the iteration cost.

Sina Weibo

Taken from Sina Weibo. A little bit of experience with the iOS siege Lion, all guessed what I'm going to vomit! Yes, it is the same data type, but the internal fields may be different in length, and they must be shown to them! In fact, I also hope that their own applications are like NetEase, fixed-length display news, The direct truncation--unfortunately, such applications are used by other companies. Perhaps you will say: The top of a non-microblogging text area to a fixed height, the text area dynamically calculated height, picture part, the picture height fixed, dynamically calculate the height according to the quantity, the forwarding part is the same, then according to the data in Tabelview proxy method TableView: Heightforrowatindexpath: The height can be returned dynamically. Yes, that's the way of thinking, but are you sure that the product manager has not changed the demand? Are you sure you don't need a 6plus font size? Are you sure your app doesn't want to show more pictures on the big screen? So you're sure the boss is not planning on the ipad version for your maintenance? For a design that is uncertain in length, but requires a full display, the most complex is not the implementation, but the late iteration. The more mutable fields, the more complex the iterations. If the display method is changed, it is basically a redo several times.

cell height calculation with pits: Difficult to understand strange problems

In the Tableview:heightforrowatindexpath: when calculating the height, there is a pit, for just contact with the iOS siege Lion, is almost incomprehensible strange problem. Here are two simple words, others can add:

• 0.1 height error problem when text height is calculated.

The cell often needs to use Textrectforbounds:limitedtonumberoflines: To calculate the display height of a text. Here, in fact there is a big hole, if you have not met can only show that you are lucky. Because of the existence of the floating-point rounding mechanism, I uilabel the last line cannot be displayed. The reason is also very strange: in your calculations, some of the value will be slightly less than 0. 01 of the error, in most cases, this error value can be safely ignored, but there is indeed the 0. The 01 error is exactly the cutoff value of the absolute line break and non-newline, because 0. 01 of the error, the height may be calculated is not enough to display the last few words. For security reasons, if you need to calculate the text height, I add an extra 0. One guarantee that the last line will definitely be displayed.

• Call Tableview:cellforrowatindexpath manually: Gets the cell, causing the lag problem.

This may also be confusing to some experienced developers: do not call Tableview:cellforrowatindexpath in your own code: method to get a cell in a location, to do some calculations about the cell, Because you call this method manually, the cells generated will not participate in cell reuse! A variety of reasons, but many explanations, in conclusion, as long as the system itself calls Tableview:cellforrowatindexpath: The method generated by the cell will participate in the cell reuse.

On this topic, it is easy to make a mistake is that there are developers in Tableview:heightforrowatindexpath: Call Tableview:cellforrowatindexpath: To get the cell, The cell height is then calculated. Then you will find that the interface that is slightly related to the display of the image, your display is right, but the scrolling is very slow, because you do not feel that you create n cells, and these cells will never participate in the reuse.

Why am I not afraid to write Uitabelview adaptive layouts now?

Yes, I'm not worried about it now. Handle various uitabelview layouts. Not because I have a so-called hard-working spirit of great work, but because I have found a solution. How do you do it specifically?

• Use AutoLayout to layout your cell

Frankly speaking, we are all just into the people, using AutoLayout layout, write a self-adaptive cell, we estimate will be. Can be used Xib, can also be written in pure code. If you are prepared to write in pure code, it is recommended that you study the masonry-AutoLayout adaptive layout for iOS apps using pure code

• Adaptive cell height using Uitableview-fdtemplatelayoutcell based on the constraints of cell contents

Blog discussion

Frankly, I used to be: Although the cell uses AutoLayout, but when calculating the cell height, it is also looking at the design to return a suitable value-think of the abuse of heart. The day before yesterday, an enthusiastic developer in my blog message said: He used masonry for the cell's height adaptive when encountered problems. My first reaction is: masonry can be used to calculate cell height?! Then he mentions a third-party Uitableview-fdtemplatelayoutcell, as if written by the great God of the country, and can be seen here: Optimizing the UITableViewCell height calculation. This article blogger about Uitableview-fdtemplatelayoutcell analysis is very detailed, with a summary is: A line of code to solve the cell height dynamic calculation problem.

• A small example of how masonry and Uitableview-fdtemplatelayoutcell are used together

A small example of how masonry and Uitableview-fdtemplatelayoutcell are used together

Example: Click to download

Thank you very much for the discussion of the future handsome guy, gave me a lot of inspiration and help, I also made a small example about the combination of masonry and Uitableview-fdtemplatelayoutcell to solve his problem: about how to make the left side of the picture is always not obscured.

Core Code Snippet:

1 2 3 4 5 6 7 8 9 10 11

-  (CGFloat) TableView: (uitableview *) Tableview heightforrowatindexpath: (nsindexpath *) Indexpath {          cgfloat height = [tableview  fd_heightforcellwithidentifier: nsstringfromclass ([Yfautolayoutcell class])   cachebyindexpath:indexpath configuration:^ (Yfautolayoutcell * cell)  {         YFAutoLayoutCellModel * model = [self.data  objectatindex: indexpath.row];                    cell.model = model;     }];           return height; }

1 2 3 4 5 6 7 8 9--------

/**  *   Initialize view.  */-  (void)  setupview {    self.imgview = [[uiimageview alloc ] init];     self.introLabel = [[UILabel alloc] init];           [self.contentView addSubview: self.imgView];     [self.contentView addSubview: self.introLabel];           self.introLabel.numberOfLines = 0;           [self.imgview makeconstraints:^ (Masconstraintmaker  *make)  {        make.top.left.equalto (8);          make.size.equalto (Cgsizemake (60, 60));         make.bottom.lessthanorequalto ( -8); //  here is the key      }];           [self.introlabel makeconstraints:^ (masconstraintmaker *make)  {         make.left.equalto (self.imgView.right). Offset (8);         make.top.equalto (Self.imgview);         make.right.equalto (-8);         make.bottom.equalto (-8);     }]; }

Summary

With auto layout, why are you still afraid to write Uitabelview's adaptive layout? Because you're still using the traditional way to calculate the cell's height! Auto Layout + Uitableview-fdtemplatelayoutcell + masonry, patiently study for a few hours, definitely let you benefit!

With auto layout, why are you still afraid of writing Uitabelview's adaptive layout?