In iOS 8 our table view cells are first displaying with the height from the xib file rather than with the height resulting after the appearance proxies are applied. For example, the fonts from the appearance proxy are present, but the label height is taken from the xib file. When the view is scrolled off and back on, the height is correct. This problem does not occur in iOS 9.
Any ideas how to address? We've tried setNeedsLayout followed by layoutIfNeeded and every other recommendation we've found on SO. We've also tried setting estimatedRowHeight.
The only workarounds we know of are to either ensure that in the xib file all the cell elements are the same height as their themed counterparts or to explicitly set the cell height through tableView:heightForRowAtIndexPath. Both of these cause the loss of much of the benefit of appearance proxies.
Related
I get this mini-horror sawtooth artifact at the bottom
of the cell on UITableViewCell selection
is there any cure?
ios version agnostic, happens on 9 and 10
both real devices and simulator
UPD: using first answer here: UITableView separator line disappears when selecting cells in iOS7
switching from blue selection style to style none masks this issue,
not sure if feedbackless cell selection style would be acceptable
for my employer though.
First check is height for your cell is correct or not.
If using autolayout and height is correct then verify the constraint for this label with proper hugging priority and compression resistance.
If using autolayout, also make sure you have set the preferredMaxLayoutWidth for your label
Also call layoutIfNeeded for your cell [cell layoutIfNeeded]
The minimal sufficient change to kill the artifact was to change
the default background for the label from default to white
to match the cell background.
In any event killing transparency fixed this, whatever that was.
A bug in GPU or GLES driver or higher up the stack. Whatever.
UPD20171024: closeViewAndMoveMapToPlase: is the culprit in another table.
This looks like a single symptom multiple causes issue.
My cells, at the UITableViewCell level, have a height of 44 points. The contentView says 43 points, and it's greyed out in IB. How can I make the content the same size as the cell?
Note that I'm designing my cells in separate xib files.
I want my cells to have no margin between each other.
I have also set None as separator style of the table view.
Row height in IB is also set to 44 points. Not using any sections.
If you're using storyboards setting the Separator of the tableView to None (instead of Default) gets rid of the 1pt separator and the contentView's height becomes equal to the cell's height (even though it's grayed out)
Note: This solution doesn't work with xib files (at least doesn't update the IB, didn't check at run-time).
I figured it out. I was using full sized background images as background for the cells. As soon as I stopped putting separate UIImageView:s as background in the contentView, and instead assigned the background UIImageView:s to the cell's backgroundView property, and then set the height of the cell as well as the height of each cell in the uitableview (and also set the contentView background color to fully transparent!), things started working as I wanted them to. The contentView height will still be one point smaller, but now the cells align perfectly to each other. For this I don't need to have the contentView height match the UITableViewCell height.
This is the craziest problem I've ever faced in iOS development. Basically I have a xib file:
This xib file is loaded as a row in a UITableView. In this xib file I have an UILabel ("Texto do comentário"), that is a multiline uilabel and will expand according to its content. To do so, I've added the following constraints and content hugging:
And all this actually works fine when I run and replace the content with a big text. This is how it looks like:
OK, now it begins the weird things, if I scroll up to the other cell (that uses the same xib file), the text view expanded its width and height in a way that doesn't respect my constraints:
Now if I scroll back to my cell that was working fine before, it has the same problem, the uilabel's width and height are not respecting my constraints anymore:
I've tried to inspect what actually happens to the constraints, if they are being ignored by some reason, and here is what I've found out. Both the constraints of my uilabel that has the right size and the ones in the uilabel that has the wrong size are the same.
I'm really starting to thing that this an iOS bug. Thank you in advance for your help
After trying, at least everything. The fix I found is to use UITextView instead of UILabel. This fix made me be sure that this is a UILabel bug.
I would say the problem you have is that you changes the Content Hugging Priority and Content Compression Resistance Priority values, which will make the UILabel not resize as you would expect.
You could try resetting the values to the default ones and if your other constraints are correct, the height of the label and of the cell should be calculated correctly.
Probably the UITextView worked because you did not change the default values for these properties.
Hope this helps.
This looks like another bug I previously encountered with self-sizing cells in a table view. Originally, I worked around it by explicitly setting the preferredMaxLayoutWidth of my cell's labels but I then discovered that sending an -updateConstraintsIfNeeded message to my cell in -tableView:cellForRowAtIndexPath: also worked around the issue without needing to set the preferredMaxLayoutWidth.
Hope this helps.
This isn'an a question, just a results log on an issue I had with XCode 4.5 storyboards and dynamic height UITableCell with a UILabel.
The issue was; the initial display of a cell would only show part of the resized UILabel contents, and that the visual UILabel was not resized. It would only display correctly after scrolling off the top of the Table and back down.
I did the calculations in hieghtForRowAtIndexPath and sizeToFit the UILabel in rowAtIndexPath. The sizes where coming up ok in debug, but the device was not updating the display with the correct size and UILable.text value.
I had created the dynamic UITableCell in a storyboard. However, I had set the width and height to a nominal value (290x44). It turns out, this was causing my issues.
I set the width and height to zero (0) in the story board, and everything started working correctly. (i.e. the UILabels displayed at the correct size with full content).
I was unable to find anything online on this issue, except for some references to creating the custom table cell with a frame of zero. Turns out, that was really the answer (for me).
I ran into the same problem and solved it by simply unchecking "Use Autolayout" in storyboard. You might want to give it a try.
I was unable to find anything online on this issue, except for some references to creating the custom table cell with a frame of zero. Turns out, that was really the answer (for me).
On iOS < 5.0, this code for a grouped table cell of mine:
NSLog(#"%f", cell.contentView.bounds.size.width);
returns 302.
But on iOS5, the same code returns 320 (that is, including the margin of the grouped cell layout in the width).
Is that expected behaviour?
And if so, how to I then reliable get the width of a grouped, tableview cell not including the margin?
I think this change has to do with the timing of the layout of the cell and the width of 302 is set in a viewWill* or viewDid* method when more is known about accessories, tableview style, etc.
When I ran into this I fixed it by setting the autoresizingMask property appropriately for when the contentView was adjusted to the with of 302 later in the code.
Since I was getting the bounds width so I could add a text field on the right side of the cell, simply adding:
valueTextField.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin;
made it pop back to where it was before iOS5. I suspect I would get better behavior with this if the device was rotated or go in and out of edit mode but this particular tableview does not do either of these.
Hope this helps ya!