I use autolayout. I am displaying 2 labels in custom UITableViewCell. Label1 is above Label2. Their text is dynamic.
The issue is the height of one of the labels when displayed is larger than its text.
I tried changing their Content Hugging Priority.
So what happens is, if that priority is same or Label1's priority is higher, then Label1 is having exact height to fit its text but Label2 has larger hight than required. And when Label2's hugging priority is higher than issue is with Label1's height.
Any idea how to solve it?
It looks like you are expecting your cells to auto-size based on auto-layout's constraint information, but UITableView sizes it's cells using frames/autosizing masks. If this is the expectation and you aren't autosizing the cells like in this question, then your labels are going to either force-clip themselves in order to fit inside the cells with the sizes they were given from the table view or grow to satisfy all of the margin-constraints.
Since the content hugging and content compression resistance priority values are less than required (less than 1000), they are considered "optional" and will be satisfied as close as they can be without violating any of the other required constraints. This is why your label begins growing (or clipping itself).
This can be solved in a couple of ways off the top of my head:
If you don't care about the cell having a variable height and are fine with the labels migrating toward the top of the cell, then make the constraint that pins the bottom label to the lower edge of the superview be non-required. More specifically, make that constraint have a priority lower than the vertical contentHuggingPriority for both of the labels. This way the content hugging priority constraints will take precedence over the lower constraint.
Make your cells auto-size themselves (using auto layout or otherwise) so that the system never has to consider the vertical contentHuggingPriority of each label 'optional'.
I solved this after experimenting with lot of things. The only thing I had to do is to set horizontal and vertical content compression resistance priority to required.i.e. 1000.
I did this for all labels because I don't want any of the labels to trim their content.
One more thing which is too much important is Getting Right Height Of Cell. If there is even 1pt of error in calculating custom cell's height it will not be displayed as expected.
Hint :
If height of any view is greater than expected then possibly calculated height of cell is greater than what is actually required.
If any of views is shrinking vertically or not displaying whole content then possibly calculated height of cell is lesser than what is actually required.
Yoy can test if height is wrong by adding/removing constant value to height (variable) you calculate for cell.
Related
I want to dynamically resize my UITableView based on its content. As an UITableView has no intrinsic content size, I have to manipulate the height constraint programmatically. However, I want to have a max_height after which the UITableView stops growing.
With each reload, I set the UITableView's height constraint to its contentSize. If the contentSize is bigger than what fits into the defined boundaries, AutoLayout complains it "can not satisfy constraints simultaneously". So I tried giving the UITableView's height constraint the priority 999. In my understanding, if AutoLayout has to break constraints, it breaks the ones with the lowest priority first and tries to get as close to the constant as possible. (Perfect!)
If everything above the TableView is of fixed height, this works fine as seen in:
As soon as anything above the TableView relies on intrinsic contentSize (like a StackView with two labels) it doesn't work anymore. As soon as the height constraint gets too big, anything without a fixed height gets compressed. (Setting the compression resistance to 751 and content hugging priority to 249 does not change this)
To make it easier to verify I have created a GitHub project (https://github.com/Shanakor/SelfSizing-TableView/branches). On branch "master" you will find the working copy and on branch "not_working" you will find the alternative approach.
Thanks for your help.
Even after your change in Question description the reason is in constraints' priorities. Your stackview height is defined from its' intrinsic size. Which in turn is defined according to intrinsic sizes or height constraints of the arranged views (in this case it's intrinsic size of labels). So if you want your stack view to keep it's size (i.e. resist compression), the priority of the compression resistance(of the stack view and all its' arranged views) should be higher than the priority of table view height constraint.
So you need to set table view height constraint priority lower than UILayoutPriorityDefaultHigh (i.e. at least 749) and the default compression resistance for the stackView
I came across a problem when configuing the cell of UITableView. I add two labels vertically in the content view of the UITableViewCell, and I also add constraints for the top, leading and bottom layout attributes:
I think that the height of the cell can be caculated dynamically as I have set all the vertical layout and with the instrinct size of the label, the height can be inferred.
so, I can not understand the error message that IB told me.
The second problem is that the height of cell appear on the IB is not changed with the constraint I`ve make. If I decrease the bottom constraint for example, and it is the label to change its size to fit the constraint, but not the cell change its height.
If you need to add top , leading and trailing(or width) to the 1st label. Then add bottom ,leading and trailing(or width)for the bottom label. Then add bottom constraint for 1st label to 2nd label.Then by selecting both labels, add equal height constraint.It will solve your problem.
The meaning of this conflict is that when your label content is increasing dynamically, which label's content is needed to give more priority before whom.
More precisely it can be said that if you increase one of the label's content hugging priority i.e. 252 then that label's content increment and size will be given more priority for incrementing it foremost. As autolayout executes according to the priority of constraints, it faces ambiguity in terms of increasing the views of labels if you do not set the content hugging priority.
I'm trying to use dynamic heights in a UITableView with a specific cell layout. Consider the following illustrative representation of that layout:
I have the horizontal constraints working properly (15px from both edges, 15px between them, equal widths) but I'm struggling with the vertical constraints. Here are the vertical requirements for this layout:
The vertical intrinsic content size of both the green and blue rectangles are based on external data which is passed to the cell at the time of creation.
Both rectangles are vertically centered within their superview
There will always be a minimum space of 15px between the top/bottom edges of the rectangles and the respective edges on the superview. In other words, whichever one is taller dictates the height of the superview (i.e. the cell)
To that end, here's what I have constraint-wise so far:
Vertical center constraints for both rectangles
Height constraints of the rectangles equal to or less than the height of the superview minus 30 (i.e. if the rectangle's height is 40, the superview must be a minimum of 70. This theoretically achieves the same effect as setting separate top and bottom '>= 15' constraints while using two less.)
Vertical content Hugging on the superview set to 'required' (i.e. 1000)
The third point is because the second points together only define the minimum height for the superview (yellow), but not a maximum. In theory, if it had a height of 10,000 it would still satisfy those constraints.
My thought is setting its content hugging to 'required' would make the superview as short as possible without violating the other constraints, thus at all times, either the green rectangle or the blue rectangle would be 15 px from the edge depending on whichever was taller. However, the height still seems to be 'stretched out' as seen here...
Note: The views on the inside are properly vertically centered and correctly maintain a minimum distance from the top/bottom edges. The problem I'm trying to solve is restricting the height of the superview to be as small as possible.
It doesn't appear that I'm getting any ambiguous constraint messages (I don't see anything in the logs, but I believe I should be because again <= constraints aren't enough on their own, so I'm not sure exactly how to use the tools to debug this, or to find out which constraint is driving the height.
So, can anyone help?
P.S. To ensure it wasn't something external to the cell, like forgetting to configure auto-heights for the UITableView, I removed the two rectangles and replaced them with a simple multi-line label pinned to all four edges. When I ran it with that, the cell properly shrank in size as expected. I bring that up to hopefully stave off answers suggesting that's potentially the problem.
Reading the requirements you provided I have added constraints shown below:
For demonstration purpose I have used a simple view container instead of a cell. Since inner boxes will have intrinsic content size derived externally, I have taken labels to mimic that.
To reiterate, constraints added are:
Horizontal
Container view(orange) has leading and trailing constraints with the super view.
Inner views has leading, trailing constraints with 15points of space.
Both labels have leading and trailing constraints with 9 points.
Both inner views have equal width constriant.
Vertical
Container view is vertically in center.
Both inner views have vertically center constraint applied.
Both inner views have top and bottom constraints with >= 15 condition.
Both inner labels have top and bottom constraints with their super views.
I set the no. of lines property of both labels to zero so that they can grow at run time.
At runtime I changed the text of one of the label and the box and container grew accordingly.
To refresh your cell height implement heightForRow method and provide the latest height. A typical snippet will look something like this (assuming you have already initialized the cell):
cell.needsUpdateConstraints()
cell.updateConstraintsIfNeeded()
cell.contentView.setNeedsLayout()
cell.contentView.layoutIfNeeded()
let height = cell.contentView.systemLayoutSizeFittingSize(UILayoutFittingCompressedSize).height + 1
return height
Hope this will help.
Ok, so I was going in the right direction with the content hugging, but the correct way to handle this was to specify a height constraint on the yellow view of 0 and with a low priority. I used 100 to be even lower than the default 250. When I did that, the solver tries to get as close to zero as it can while still respecting the other constraints, therefore 'hugging' the content. Still don't know why content hugging on its own didn't work, but that addressed the issue.
I'm trying to lay out the following simple UI using auto layout:
So far, I've set 5 constraints:
The left edge of the textfield is constrained to the left alignment guide
The top edge of the textfield is contained to the top alignment guide
The right edge of the label is constrained to the right alignment guide
The top edge of the label is constrained to the top alignment guide
The right edge of the textfield is constrained to be 20 points from the leading edge of the label
Based on these constraints, I would think that the width of the textbook would be determined by the size of the label, and horizontal layout for both would be implied. This is indeed how these constraints behave when I change the size of the button, but I'm still receiving the following warning in xcode:
My question is why? Width and horizontal position can be determined by the information provided, and providing additional information (like a fixed width) would only mess with the flexibility of the interface.
Well Width can't be calculated based on the constraints you applied.
Both textField and label grow and shrink based on content.
What will happen If at runtime I add much more text or increase text(content) of both the fields. Then there will be ambiguity about which field to fill full and which to trim.
So one thing need to be fixed based on that other width can be calculated.
You can add one Extra width constraint to Add Activity.
My extra width constraint would be less than or equal to the width you assign. And its priority would be greater than its leading.
Or you would want to play with content hugging priority. With changing content hugging priority one can make it possible for label not to grow.
Cocoa Autolayout: content hugging vs content compression resistance priority
If you don't want to add Extra width constraint Then increasing horizontal hugging of Add Activity to 251 (greater then textfield hugging) will resolve the ambiguous constraint issue.
I'm trying to use Auto Layout to take advantage of the self-sizing UITableViewCells.
I have one UILabel at the top of the cell and another beneath it. I set the top constraints to be pinned to the top, left and right, and the bottom to be pinned to the top left and right of the upper label.
Now as I go to set the bottom label's final constraint (its distance from the bottom) I set it to 10pt from the bottom of the cell. However this sparks a bunch of Auto Layout complaints. It says I have to make one of the labels have a higher vertical hugging priority. Why is this?
And in the WWDC video, the engineer sets the bottom one to be greater than or equal, instead of just equal. This seems like a poor solution at least in my case, because I never want it to be greater than what I set.
The IB issue you are seeing is due to the fact that the content that you currently have in the labels and all your constraints doesn't fit the UITableViewCell height (it doesn't autosize in IB yet). The autosizing happens at runtime, and setting it to greater than or equal is fine as the code autosizing will find the smallest size that acceptably fits all your content.