Autolayout Error with UITableView

谁说我不能喝 提交于 2019-12-30 04:03:05

问题


I have a TableView and I specify the height for each cell using the delegate method tableView:heightForRowAtIndexPath:.

When I rotate the view I get this error that I don't quite understand.

It can't satisfy the constraint below and breaks it to continue.

"<_UIScrollViewAutomaticContentSizeConstraint:0x8e8d040 UITableView:0x9423400.contentHeight{id: 213} == -1568.000000>"

Does anyone know what is happening and why I'm breaking this constraint?


回答1:


UPDATE: This issue is no longer relevant in iOS 8, which adds support for self-sizing cells. It is still relevant for iOS 7 however.

Original answer (iOS 7):

Greg's answer definitely worked for me - I needed to debug my tableView:estimatedHeightForRowAtIndexPath: method. I did some debugging and some quick experiments and here are some things I learned:

  1. Don't use UITableViewAutomaticDimension in the estimated row methods. This constant is for the header and footer methods. I guess I wasn't paying enough attention when I read the documentation :) UPDATE: UITableViewAutomaticDimension can now be used for row heights in iOS 8, part of the self-sizing cells functionality.

  2. Estimating row height of 1.0 results in an exception: "NSInternalInconsistencyException', reason: 'table view row height must not be negative...'" Estimating less than 1.0 has strange results as well.

  3. Estimating between 2.0 and the actual works just fine without any exceptions (although 2.0 is probably a bad choice for optimization reasons - you want to be as close to actual as possible).

  4. The constraint exception only occurs when the estimated row height is greater than the actual row height. The closer you are to the actual, the less likely the exception will occur. How far off your estimate can be before getting the exception seems to be related to several different factors: actual row height, the position of the row, etc.




回答2:


tl;dr: Look for actual height values drastically different than what you estimated. Or actual values that are negative or 0.


I just spent a few minutes debugging this constraint exception. I have a UITableView with cells, section headers, and section footers. Each of these had the iOS 7 estimatedHeightFor messages defined, returning a static const value. I removed cells, headers, and footers, one at a time until I determined the issue was coming from the footer (not important if you don't have footers, please read on).

If I eliminated estimatedHeightForFooterInSection:, the exception disappeared. In my heightForFooterInSection:, there is one path in which the height of the footer would be 0. When I restored the estimatedHeight message and eliminated the code path for an actual height of 0, the exception also went away. I replaced 0 with 22 and decreased this value all the way to 12 before the exception reappeared.

Regardless, I need the height of the footer to be 0 (I return nil from viewForFooterInSection: in that case) and I want to be able to estimate the height (I am supporting Dynamic Text). My solution was to account for the code path that would give me a 0 height in estimatedHeightForFooterInSection:. Once I added that, the exception went away.




回答3:


Try to debug your

(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath

implementation. In my case it was returning a negative integer in some rare cases, resulting in the message showing up in my log and messing with the scrolling behavior of my table view.



来源:https://stackoverflow.com/questions/18397206/autolayout-error-with-uitableview

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!