How to fix strange NSLayoutConstraint errors that don't seem to affect the layout in a custom UITableViewCell

Every time one of my custom UITableViewCells is drawn tableView: cellForRowAtIndexPath: the console spits out a bunch of NSLayoutConstraint inconsistencies. I understand most of them:

Unable to simultaneously satisfy constraints. ...boring stuff.. "<NSLayoutConstraint:0x8b0eb60 V:|-(NSSpace(20))-[UILabel:0x8b0cb30] (Names: '|':UITableViewCellContentView:0x8bd7d40 )>", "<NSLayoutConstraint:0x8b0db70 V:[UILabel:0x8b0cb30]-(NSSpace(8))-[UITextView:0x91dba00]>", "<NSLayoutConstraint:0x8b0dba0 V:[UITextView:0x91dba00]-(NSSpace(20))-| (Names: '|':UITableViewCellContentView:0x8bd7d40 )>", "<NSLayoutConstraint:0x8b0d5a0 V:[UITextView:0x91dba00(1000)]>", "<NSAutoresizingMaskLayoutConstraint:0x8b00330 h=--& v=--& V:[UITableViewCellContentView:0x8bd7d40(44)]>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x8b0db70 V:[UILabel:0x8b0cb30]-(NSSpace(8))-[UITextView:0x91dba00]> 

Or at least I think I know. What really puzzles me is that my UITableViewCell is working, and no restrictions seem to be broken. I think that some of the limitations listed in the error, especially the latter, are limitations added by the system. Is this possible if I do not use .xibs and just add restrictions to the code? The last line of the error applies to me, in particular, because I dynamically generate the height for each code, but I noticed that there is 44, the default cell height.

Some of these restrictions are added by default, for example, when I call [super updateConstraints] ? How can I solve these errors or find out where they come from?

On the side of the note, I understand that diving into Core Text works much better than my UITextView + Auto Layout solution. I'm currently working on caching cell heights. However, can these layout errors cause lag during scrolling or simply because I use Auto Layout to calculate the height of each cell when it appears on the screen?

I posted a project in which these errors occur on Github if someone wants to download and experience weirdness for themselves.

+6
source share
1 answer

According to Aaron’s suggestion, I manually change the height of the cell when it is initialized, so that restrictions can then correct it when Auto Layout does its calculations. Without setting the original content frame, the default frame is {0, 0, 320, 44} . This is too small and cannot satisfy the limitations and errors displayed in the console.

Similarly, when reusing cells, the old contentView.frame (calculated using Auto Layout) is used. This is normal if you use the same amount of text - or less - but if the new cell needs more text (and therefore a larger contentView.frame), we are faced with the same problem, contentView.frame is too small and not may satisfy restrictions.

So, in my custom UITableViewCell, I now manually set contentView.frame.height in initWithStyle: and prepareForReuse: to a constant sufficient to accommodate any amount of text (enough for an App.net message and some extra margin of safety). This does not guarantee errors when Auto Layout performs its calculations.

I might even think of setting this value a little higher or even dynamically to accommodate dynamic text in iOS 7. As for scrolling, it seems that the errors did not exacerbate the mutable scrolling, that's all because of the automatic layout calculations (I think). The next step is to calculate the cell height when calling viewDidAppear: ...

+2
source

Source: https://habr.com/ru/post/957763/


All Articles