iOS8 - constraints ambiguously suggest a height of

Question

Has anyone got any idea how to debug this?

Warning once only: Detected a case where constraints ambiguously suggest a height of zero for a tableview cell's content view. We're considering the collapse unintentional and using standard height instead.

The rows have a fixed height as set by

- (CGFloat)tableView:(UITableView *)tableView 
           heightForRowAtIndexPath:(NSIndexPath *)indexPath{
   return 34.0;
}

And all the constraints seem to be happy...

Answer 1

For a bog standard fix, no constraints, no estimating heights, or over engineering the problem. I created a default project, wired up the tableview but forgot to put the height delegate in the view controller. To simply make this warning go away you need this.

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
    return 44;
}

In your table's view controller.

Answer 2

In Swift forcing a return height fixed my problem:

override func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
    if(indexPath.row == 0){
       return CGFloat(131.0)
    }else if(indexPath.row == 8){
       return CGFloat(97.0)
    }else{
       return CGFloat(44.0)
    }
}

Answer 3

Forcing a return height and estimated height made the warning disappear in my case.

- (CGFloat)tableView:(UITableView *)tableView 
           estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 44;
}

- (CGFloat)tableView:(UITableView *)tableView 
           heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 44;
}

Another solution where you don't need the two overrides is simply to use self.tableView.rowHeight = 44; in your loadView or init method.

Answer 4

What can also be done is adding vertical constraints from the top and to the bottom of the content view. This will make autolayout happy (because he now knows how to calculate the height of the cell himself).

Answer 5

While the answers on this page discussing adding height constraints or manually returning rowHeights like 44 in heightForRowAtIndexPath cause the warning to go away, they are superfluous because this is a bug in Xcode visible in at least Version 6.3.2 (6D2105).

If you set a breakpoint in viewDidLoad, you'll see that self.tableView.rowHeight = -1 (UITableViewAutomaticDimension) even if you specify a row height of 44 in the storyboard. This is because Apple incorrectly assumes that you want dynamic row heights if you leave the row height at 44, because they didn't provide a flag for you to specify your preference.

Here are some possible solutions and their results:

• Set row height to 43 or 45 in storyboard (works).

• Manually return a height of 44 in heightForRowAtIndexPath (works).

• Add height constraints between the UITableViewCell’s elements and its contentView (works).

Unfortunately, these solutions either require you to change your design, add unnecessary constraints or add unnecessary code to work around a bug. I tried (what I thought to be) the simplest solution:

• Set each UITableViewCell’s height to 44 (Custom) in the storyboard (fails).

I really wanted a pure storyboard solution to this, so finally I tried:

• Add a user-defined runtime attribute to the UITableView in the storyboard, and name the UITableView with a note about how its rowHeight is being set so future developers can find it: (works):



These bugs are all too common in iOS development and force developers to spend excessive time weighing the ramifications of how their solutions will affect maintainability in the long run.

Since finding a conceptually correct solution that is maintainable and doesn’t seem obfuscated is so elusive, and assuming that Apple will fix the bug and that 44 is going to be the default row height for the foreseeable future, then the constraint or user-defined runtime attribute solutions are probably the most maintainable.