61

In this iOS 8 app I'm creating, I have a tableview and I need them to be self resizing. I implemented it using Auto Layout and it works. Almost. Here's how it looks now.

enter image description here

There are 3 labels inside a cell. Main label which has the lorem ipsum text. Subtitle which has the string of numbers (Those are two separate labels. Might be confusing because they have the same color.) Then the third label with the small black text.

The first label resized itself correctly with no problem and the second label moves up and down accordingly. But the problem is with the third small label. As you can see, its not resizing itself to fit all the text.

Now there's a weird thing happening. I turn it landscape and here's it is.

enter image description here

Since there is space the label is displaying the entire text its supposed to. Fine. Then I turn it back to portrait.

enter image description here

Now the small label has resized itself to fit all its text but it overflows the cells boundaries. I tried making the cell bigger but it didn't work. Since this is self sizing cells, I don't think that's the correct way even.

I'm not getting any errors or even warning on my auto layout constraints either.

enter image description here

I have set these two lines of code in the viewDidLoad() method.

tableView.estimatedRowHeight = 100
tableView.rowHeight = UITableViewAutomaticDimension

Can anyone please tell me what I might be doing wrong here?

Since its difficult to answer just by looking at images and I don't have any more code to post beside the above snippet, I uploaded a runnable Xcode project demonstrating the issue here. (There are 2 custom cells. Basically its the same cell just the height is increased in the second one.)

I've been fiddling with auto layout constraints but I can't seem to get this working. Any help would be appreciated.

Thank you.


UPDATE:

With the help of this tutorial I found some helpful pointers. According to it, each subview should have constraints that pin all its sides and there should be constraints that goes from top to bottom which helps auto layout to calculate the height of the cell. In my original post, I had vertical spaces between each label so I think that's the reason auto layout couldn't calculate the proper height.

So I made some changes.

  • I reduced the vertical space between labels to 0 and set the Vertical space constraints between top and middle labels and middle and bottom labels.
  • I added leading, top, trailing constraints to the top label.
  • Leading and trailing to the middle label.
  • Leading, bottom, trailing to the bottom label.

Now here's another weird part. When I first run it, the bottom label cropping issue is still there.

enter image description here

But if I rotate the device to landscape and turn it back to portrait, all the all the cells are resized properly to fit both labels!

enter image description here

Still can't figure out why this doesn't happen at first though. Updated Xcode project is here.

6
  • 3
    The table is finding it too difficult to estimate the exact height of the text in your labels before the view appears, but it is doing pretty well all the same. I found that if you move tableView.estimatedRowHeight = 100 to viewDidAppear then this solves the problem you're seeing Sep 21, 2014 at 14:21
  • 1
    ... or rather, it seems the table is using the estimated height as an excuse to not do an exact calculation on first loading the table. But if estimatedRowHeight is moved as described this solves the problem you're seeing. Removing it altogether creates redraw issues on rotate. Sep 21, 2014 at 14:29
  • @GoodbyeStackOverflow I did as you suggested but I'm facing some issues. This is how it looks when you run it and when you scroll down. I also applied the same to my second example and this is the result. Looks good in the first 3 cells but note that it's gotten messed up in the last cell.
    – Isuru
    Sep 21, 2014 at 17:04
  • @Isuru XCode project is not there. Can you please upload it again ? I am working on the same kind of things.
    – Hiren
    Sep 28, 2015 at 14:15
  • @Hiren Sorry, I don't have that project anymore. It was just a temporary project.
    – Isuru
    Sep 29, 2015 at 5:04

5 Answers 5

84

The issue here is with the multi-line labels' preferredMaxLayoutWidth property. This is the property that tells the label when it should word wrap. It must be set correctly in order for each label's intrinsicContentSize to have the correct height, which is ultimately what Auto Layout will be using to determine the cell's height.

Xcode 6 Interface Builder introduced a new option to have this property set to Automatic. Unfortunately, there are some serious bugs (as of Xcode 6.2/iOS 8.2) where this is not set correctly/automatically when loading a cell from a nib or Storyboard.

In order to work around this bug, we need to have the preferredMaxLayoutWidth set to be exactly equal to the final width of the label once it is displayed in the table view. Effectively, we want to do the following before returning the cell from tableView:cellForRowAtIndexPath::

cell.nameLabel.preferredMaxLayoutWidth = CGRectGetWidth(cell.nameLabel.frame)
cell.idLabel.preferredMaxLayoutWidth = CGRectGetWidth(cell.idLabel.frame)
cell.actionsLabel.preferredMaxLayoutWidth = CGRectGetWidth(cell.actionsLabel.frame)

The reason that just adding this code alone doesn't work is because when these 3 lines of code execute in tableView:cellForRowAtIndexPath:, we are using the width of each label to set the preferredMaxLayoutWidth -- however, if you check the width of the labels at this point in time, the label width is totally different from what it will end up being once the cell is displayed and its subviews have been laid out.

How do we get the label widths to be accurate at this point, so that they reflect their final width? Here's the code that makes it all come together:

// Inside of tableView:cellForRowAtIndexPath:, after dequeueing the cell

cell.bounds = CGRect(x: 0, y: 0, width: CGRectGetWidth(tableView.bounds), height: 99999)
cell.contentView.bounds = cell.bounds
cell.layoutIfNeeded()

cell.nameLabel.preferredMaxLayoutWidth = CGRectGetWidth(cell.nameLabel.frame)
cell.idLabel.preferredMaxLayoutWidth = CGRectGetWidth(cell.idLabel.frame)
cell.actionsLabel.preferredMaxLayoutWidth = CGRectGetWidth(cell.actionsLabel.frame)

OK, so what are we doing here? Well, you'll notice there are 3 new lines of code added. First, we need to set this table view cell's width so that it matches the actual width of the table view (this assumes the table view has already been laid out and has its final width, which should be the case). We're effectively just making the cell width correct early, since the table view is going to do this eventually.

You'll also notice that we're using 99999 for the height. What's that about? That is a simple workaround for the problem discussed in detail here, where if your constraints require more vertical space than the current height of the cell's contentView, you get a constraint exception that doesn't actually indicate any real problem. The height of the cell or any of its subviews doesn't actually matter at this point, because we only care about getting the final widths for each label.

Next, we make sure that the contentView of the cell has the same size as we just assigned to the cell itself, by setting the contentView's bounds to equal the cell's bounds. This is necessary because all of the auto layout constraints you have created are relative to the contentView, so the contentView must be the correct size in order for them to get solved correctly. Just setting the cell's size manually does not automatically size the contentView to match.

Finally, we force a layout pass on the cell, which will have the auto layout engine solve your constraints and update the frames of all the subviews. Since the cell & contentView now have the same widths they will at runtime in the table view, the label widths will also be correct, which means that the preferredMaxLayoutWidth set to each label will be accurate and will cause the label to wrap at the right time, which of course means the labels' heights will be set correctly when the cell is used in the table view!

This is definitely an Apple bug in UIKit that we have to workaround for now (so please do file bug reports with Apple so they prioritize a fix!).

One final note: this workaround will run into trouble if your table view cell's contentView width doesn't extend the full width of the table view, for example when there is a section index showing on the right. In this case, you'll need to make sure that you manually take this into account when setting the width of the cell -- you may need to hardcode these values, something like:

let cellWidth = CGRectGetWidth(tableView.bounds) - kTableViewSectionIndexWidth
cell.bounds = CGRect(x: 0, y: 0, width: cellWidth, height: 99999)
7
  • @Isuru The unsatisfiable constraint exceptions you're getting after forcing a layout pass on the cell are likely not a real issue, and can be worked around easily. See this thread for a complete discussion of the issue.
    – smileyborg
    Apr 1, 2015 at 15:54
  • Thanks. I spent 2 days trying everything I could find to get my labels to resize correctly. The weird thing was that some did resize, but other cell designs did not. I could not find a difference in the constraints or other settings. However, your solution worked great. I did create a UILabel subclass and put the preferredMaxLayoutWidth setting inside setBounds to avoid hard references to the UILabels in the table view controller. May 27, 2015 at 22:53
  • 2
    Great post. Thank you. It really helped me out and now my labels behave as intended
    – z2k
    Jul 9, 2015 at 19:31
  • Thanks! Exactly what I needed!
    – werm098
    Aug 18, 2015 at 14:44
  • 3
    Forcing preferredMaxLayoutWidth has unfortunately undesirable effects, such as breaking orientation change, and requires even more code. A 0 lines of code alternative is to use UITextView instead of multiple line UILabel. Feb 11, 2016 at 20:11
50

I met the same issue as you and I found a simple solution to resolve it.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
     // dequeue cell...

     // do autolayout staffs...or if the autolayout rule has been set in xib, do nothing

     [cell layoutIfNeeded];

     return cell;
}

And the self-sizing worked well. In my code, I laid two labels in vertical, both of them are dynamic height. The height of cell is correctly set to contain the two labels.

5
  • 3
    This the the best answer. The accepted answer of setting preferredMaxLayoutWidth still has issues in my experience. Nov 21, 2014 at 15:24
  • sheesh, i looked all over for an answer. all these complicated, inelegant solutions. here, one line of code. done...
    – jshbrmn
    Jan 30, 2015 at 17:11
  • 2
    Unfortunately I've found that this did not work for me, while smileyborg's solution did.
    – pr1001
    May 28, 2015 at 21:50
  • 1
    as of iOS8.3 this resolves layout issues when the multiline label is pinned between two other items. Jul 21, 2015 at 20:28
  • it worked for me for 8.1 adding this line cell.layoutIfNeeded() in above func. rest was already working
    – neelabh
    Jul 11, 2016 at 5:15
6

Assuming you don't have any errors with your constraints as others have suggested, this problem seems to stem from using a UILabel that allows multiple lines in conjunction with a UITableViewCellAccessory. When iOS lays out the cell and determines the height, it does not account for the offset change in width that occurs because of this accessory, and you get truncation where you wouldn't expect to.

Assuming you want the UILabel to extend the full width of the content view, I wrote up a method that fixes this for all font sizes

-(void)fixWidth:(UILabel *)label forCell:(UITableViewCell *)cell {
    float offset = 0;
    switch ([cell accessoryType]) {
        case UITableViewCellAccessoryCheckmark:
            offset = 39.0;
            break;
        case UITableViewCellAccessoryDetailButton:
            offset = 47.0;
            break;
        case UITableViewCellAccessoryDetailDisclosureButton:
            offset = 67.0;
            break;
        case UITableViewCellAccessoryDisclosureIndicator:
            offset = 33.0;
            break;
        case UITableViewCellAccessoryNone:
            offset = 0;
            break;
    }
    [label setPreferredMaxLayoutWidth:CGRectGetWidth([[self tableView]frame]) - offset - 8];
}

Simply put this in your cellForRowAtIndexPath

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    #Setup the cell
    ...
    // Fix layout with accessory view
    [self fixWidth:[cell label] forCell:cell];
    return cell;
}

Do this for any labels that are going to have multiple lines to adjust the width properly and then recalculate the appropriate heights. This works with dynamic font sizes as well.

Like smileyborg had mentioned, if you weren't using the full width of the contentView you could reference the constraints and subtract them from the width as well.

Edit: I previously was running 'layoutIfNeeded' on the cell but this was creating performance issues and didn't seem to be needed anyway. Removing it hasn't caused any problems for me.

4

You have two problems here.

1/ Right now, using Visual Format Language, your cell's vertical constraints can be translated like this:

Cell: "V:|-(10)-[nameLabel]-(67)-|"

Then, you set a second group of constraints:

Cell: "V:|-(10)-[nameLabel]-(8)-[pnrLabel]-(2)-[actionsLabel]"

Those two groups of constraints can't mix well and will reveal their ambiguity with your second problem.

2/ For some reasons, actionsLabel is limited to one line when you launch your app. Then, when you rotate your device to landscape mode, actionsLabel accepts to be displayed with two lines or more. Then, when you rotate your device back to portrait mode, actionsLabel keeps displaying two lines or more. But, because actionsLabel is not really part of your cell's height constraints, it overlap your cell's boundaries.

If you want to solve all those problems, I recommend first that you rebuild your xib file from scratch. This will cure your actionsLabel strange behavior (two lines or more only when you rotate your device).

Then, you will have to define your constraints like this:

Cell: "V:|-(10)-[nameLabel(>=21)]-(8)-[pnrLabel(>=21)]-(2)-[actionsLabel(>=21)]-(10)-|"

Of course, you can define other minimum height constraints for you labels than (>=21). In the same way, your bottom margin can be set to another value than -(10)-.

Addendum

In order to answer your question, I created a simple project with the previous constraints pattern in my .xib file. The following image may help you build your own constraints.

enter image description here

8
  • Great, concise answer.
    – memmons
    Sep 20, 2014 at 18:35
  • Thank you for the detailed answer. I managed to get it working but there's a slight problem. Since the width for these labels are fixed, when you turn the screen landscape they don't adjust to fill the extra space. Is there a way to counter this? Adding Trailing Space to Superview on those labels don't seem to work.
    – Isuru
    Sep 20, 2014 at 19:41
  • I've set width constraints for each label in my test project for testing purpose. In your app, don't set width constraints but set Trailing Space to Superview margins contraints for each label. Don't set width constraints AND Trailing Space to Superview margins contraints for each label at the same time: you have to make a choice between one or the other. Sep 20, 2014 at 19:46
  • @POB I tried that but removing the width constraints make it look like this. Here is my current auto layout view.
    – Isuru
    Sep 20, 2014 at 20:11
  • No, you are right. It's not working when using trailing space to superview margins contraints instead of width constraints... I try to find why. Sep 20, 2014 at 22:57
3

I tried the very easy and elegant looking solution of "fogisland" - and it did not work. Luckily I found out that one additional line makes it work in all directions. Just tell the system that you not only suggest a new layout (layoutIfNeeded), you explicitly ask for it (setNeedLayout)

cell.setNeedsLayout()
cell.layoutIfNeeded()
return cell

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.