"Turn" with auto layout, why are you still afraid to write Uitabelview's adaptive layout?

Apple is the company that attaches the most importance to the application development experience. From Xib to storyboard, from auto layout to size Class, every update is a great convenience for iOS apps. However, for an absolute majority of iOS siege Lions, We're still afraid of writing Uitabelview's adaptive layouts. Of course, fear is not because we don'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? Data type uncertainty: The more types, the more complex the page.

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 of these data types requires at least a single cell to render, each cell's layout, are going to write alone. 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.

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 displayed 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 the application of other companies. You may say: the top of a non-microblogging text area to a fixed height, the text area dynamic calculation of height, picture part, picture height fixed, dynamic calculation height according to quantity; The height can then be dynamically returned based on the data in the agent method of the Tabelview tableView:heightForRowAtIndexPath: . Yes, that's the idea, but you're sure the product manager hasn't changed the demand? Are you sure you don't need to fit 6plus? Are you sure your app doesn't want to show more images on a large screen? Are you sure the boss isn't thinking about the ipad version and giving it to you for maintenance? So, for a design that is uncertain about the length of the data but requires a full display, the most complex is not the implementation, but the later iterations. The more mutable fields, The more complex the iteration. If the display is changed, it's basically a matter of re-doing it several times.

Cell height calculation with pits: Difficult to understand strange problems

In the tableView:heightForRowAtIndexPath: calculation of 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:

1.0.1 height error problem when writing height calculation.

Cells often need to be used textRectForBounds: limitedToNumberOfLines: to calculate the height of the display of a text. Here, there is actually a big hole, if you don't meet can only show you are lucky. Because of the floating-point rounding mechanism, I uilabel the last line cannot be displayed. The reason is also very strange: when you calculate, Part of the value will be a little more than 0.01 of the error, in most cases, this error value can be safely ignored, but there is a 0.01 error is exactly the absolute line break with the cutoff value, because 0.01 of the error, may not calculate the height is not enough to display the last few words. For the sake of safety, If I need to calculate the text height, I will add an extra 0.1来 to ensure that the last line is definitely visible.

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

This may also be confusing to some experienced developers: do not call a method in your own code tableView:cellForRowAtIndexPath: to get a cell in a location, to do some calculations about the cell, because you manually call this method generated by the cell will not participate in the cell reuse! Various reasons, However, the conclusion is that, as long as the system itself calls the tableView:cellForRowAtIndexPath: method generated by the cell will participate in the cell reuse.
On this topic, it is easy to make the mistake is that there are developers in

tableView:heightForRowAtIndexPath:Call tableView:cellForRowAtIndexPath: to get the cell, and then calculate the cell height. Then you'll find that your display is the right one when it comes to the image display, but scrolling is very slow because you create n cells without your own awareness, 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 dealing with a variety of uitabelview layouts right now. Not because I have a so-called hard-working spirit of great work, but because I have found a solution. What should I do?

1. Use AutoLayout to layout your cell

Frankly speaking, we are all just into the line, using the AutoLayout layout, write a self-adaptive cell, we estimate will be. You can use Xib, or you can write with pure code. If you are prepared to write with pure code, we recommend that you study it first masonry- AutoLayout adaptive layouts for iOS apps using pure code

2. Use Uitableview-fdtemplatelayoutcell to adapt cell height according to the constraints of cell contents

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 heart. The day before yesterday, an enthusiastic developer in my blog message said: He used masonry There was a problem when the cell was highly adaptive. My first reaction is: masonry can be used to calculate the 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. The blogger of this article about Uitableview-fdtemplatelayoutcell analysis is very detailed, with a summary is: A line of code to solve the cell height dynamic calculation problem.

3. A small example of the combined use of masonry and Uitableview-fdtemplatelayoutcell

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:

- (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;}

/** * 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< Span class= "hljs-variable" >.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!

iOS122

Original address: http://www.cnblogs.com/ios122/p/4832859.html#3272858

"Turn" with auto layout, why are you still afraid to write Uitabelview's adaptive layout?