I'm wrestling trying to get some multiline labels behaving inside tableview cells. I've already moved away from stacks that didn't work reliably at all as described in this question
UILabel inside nested UIStackViews inside UITableViewCell sometimes truncating
I fixed one of my views with the help of the comments on that question but another view just wouldn't work for me, even after moving to an autolayout non-stackview setup. I then ended up moving the cell that i couldn't get to work into the view which was working with similar layout and got to a point where i have two cells in the same view, one that worked and one that didn't. I've exported this into a new test app which I've uploaded here
In this app there is a simple tableview with 2 cells within it. One cell displays the large multiline text properly and expands the cell as required. The other cell stops short and truncates the multiline label as you can see here
The two cells to me seem pretty much identical in their constraints so I'm very confused why one works and the other doesn't. Here's an overview of their constraints
There are a few constraints not installed as i've been experimenting trying to figure out what's causing one of the cells to not work.
If anyone could explain to me what is causing these two cells to not behave the same, or more importantly why one of the labels doesn't fill its table cell that'd be really appreciated as I've spent hours looking and just can't seem to figure it out.
Cheers!
Edit:
To explain what went wrong in the first place...
The Right-side "Tags Label" in Cell2 has an Explicit Preferred Width = 300. I don't know the internals, so can't say exactly what's happening, but I get the impression Auto-Layout will take that Preferred Width value into consideration when calculating the text bounding-box height, and then continue on with constraints, content, intrinsic size, etc.
Simply un-checking that explicit option will fix the issue.
Original Answer:
I found it easier to start a new Cell from scratch, rather than try to modify the constraints you had set up, so... This will hopefully be reproducible.
Prep: Add new “Cell3” class; make basic edits to code to accommodate Cell3. I also find things easier if I make some variables for label values and set background colors of elements for easy visual inspection and testing.
Step 1: Add a new prototype; purple background; TableViewCell3 class and “Cell3” reuse ID; stretch it vertically to make it tall enough to work with (it won't affect run-time height).
Step 2: Add a UIView for the Left Side labels. Leading = 8 to Superview. Width = 200; Height = 100; Center Vertically. The Height and Width values will be changed later.
Step 3: Add the two Left Side labels - 1 and 2 (Body font) - to the UIView. Constrain 1 Left = 0; Top = 0. Constrain 2 Left = 0; Bottom = 0.
Step 4: Add a vertical spacing constraint from 2 to 1 of 7.5 and change the Height constraint of the UIView to >= 20 (runtime will likely always exceed 20).
Step 5: Change the Width constraint of the UIView to >= 40 (runtime will likely always exceed 40); Add Trailing Space to Container constraints for both Left Side labels, and set them to >= 0.
Step 6: Add Top and Bottom “to Superview” constraints to the UIView of >= 0.
Step 7: Add the Right Side label (Caption 1 font, number of lines 0). Constrain Top >= 0, Right = 0, Bottom >= 0, all to Superview; also Center Vertically.
Step 8: Add a Horizontal spacing constraint from Right Side label to UIView, set to 20. Give Right Side label a Width constraint = 40 (runtime will likely always exceed 40), and set the Priority to 250. This allows the UIView containing the Left Side labels to be in control of the widths.
Step 9: Assign IBOutlets and run the app. Try changing up the text. Make the left side labels shorter or longer... try setting the right side label to only enough text for one line... etc.
At this point, things should look pretty good - until... you put too much text in one of the left side labels, at which point you'll have a very, very narrow, very very tall right side label. So...
Step 10: Add another Width constraint to the UIView and set it to <= 200. Depending on your actual content, you may want to modify that - or perhaps set it to <= to a percent of the width of the cell.
I updated my original GitHub repo so you can check it out. It should have a commit for each "step" listed above, which might make it easier to follow along - https://github.com/DonMag/CellTest2
Results:
Related
I am working on an iOS 11+ app and would like to create a view like in this picture:
The two labels are positioned to work as columns of different height depending on the label content. The content of both labels is variable due to custom text entered by the user. Thus I cannot be sure which of the the two labels is higher at runtime and there is also no limit to the height.
How can I position the BottomView to have a margin 20px to the higher of the two columns / labels?
Both labels should only use the min. height necessary to show all their text. Thus giving both labels an equal height is no solution.
I tried to use vertical spacing greater than 20px to both labels but this leads (of course) to an Inequality Constraint Ambiguity.
Is it possible to solve this simple task with Autolayout only or do I have to check / set the sizes and margins manually in code?
You can add labels to stackView
One way to do this is to assign equal height constraint to both label. By doing this height of label will always be equal to large label (Label with more content).
You can do this by selecting both labels and adding equal height constraint as mentioned in screen short.
Result would be some think like below
The answer given as https://stackoverflow.com/a/57571805/341994 does work, but it is not very educational. "Use a stack view." Yes, but what is a stack view? It is a view that makes constraints for you. It is not magic. What the stack view does, you can do. An ordinary view surrounding the two labels and sizing itself to the longer of them would do fine. The stack view, as a stack view, is not doing anything special here. You can build the same thing just using constraints yourself.
(Actually, the surrounding view is not really needed either, but it probably makes things a bit more encapsulated, so let's go with that.)
Here's a version of your project running on my machine:
And with the other label made longer:
So how is that done? It's just ordinary constraints. Here's the storyboard:
Both labels have a greater-than-or-equal constraint (which happens to have a constant of 20) from their bottom to the bottom of the superview. All their other constraints are obvious and I won't describe them here.
Okay, but that is not quite enough. There remains an ambiguity, and Xcode will tell you so. Inequalities need to be resolved somehow. We need something on the far side of the inequality to aim at. The solution is one more constraint: the superview itself has a height constraint of 1 with a priority of 749. That is a low enough priority to permit the compression resistance of the labels to operate.
So the labels get their full height, and the superview tries to collapse as short as possible to 1, but it is prevented by the two inequalities: its bottom must be more than 20 points below the bottom of both labels. And so we get the desired result: the bottom of the superview ends up exactly 20 points below the bottom of the longest label.
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 have a label in a tableview cell with several constraints in Interface builder.
The cell is self sizing and thats working fine.
My problem is, that the "trailing space" constraint is not working.
The text is not broken and goes to far to the right - out of the screen.
I dont understand this. If someone could help me out, what be fantastic, because I am now searching for hours and dont find the root cause.
The Label is set to 0 lines by:
cell.commentLabel?.numberOfLines = 0
http://picpaste.com/p1-AmKNGkwx.jpg
http://picpaste.com/p2-7ODUyyoc.jpg
The problem is that you're setting a fixed size (600 x 444 - based on your comments above) on your tableview, which is larger than the logical resolution of the width for most devices and this causes the cells to expand beyond the visible area.
So, you must remove the fixed constraints and add some relative ones (for example match the width of the superview & set the bottom of the tableview to the top of your 'footer' - or whatever makes sense in your case... you can even stick with the hardcoded 444 for its height - the width is the important one here)
Is there a way to achieve this? I have tried literally everything and nothing has worked for me yet.
So basically what i want to do is the following: I have a scroll view with some labels in it. All the labels get their text from a server and I have set their number of lines to 0 so that they change their height according to the amount of text. However, this does not affect the scrollview content size(even though my labels have constraints set up to the bottom,top,leading and trailing of the scrollview) and the labels go off screen and I am unable to scroll down. Can someone point me in the right direction to how I would set up my constraints, my view hierarchy and etc?
Any help is much appreciated! :)
Late, but this solved it for me:
Set leading (I have a 32pt inset), trailing and top constraints. The trailing will not actually seemingly do anything..
Make the trailing Greater Than or Equal to avoid localization alert.
Finally, add a new Equal Width constraint to the label matching the scrollview. Use the constant to subtract the required padding (I used 64 due to mirror my leading inset).
And voilà! The Label will align correctly both in IB and in-app.
In Scrollview the last view's bottom constraint is so important. You should set its priority to 250 and put it to Greater than or equal.
Remember you should only change the bottom constraint of the last view, which in my case it's the continue button.
I would consider using UITableView instead, it has several benefits:
It allows for reuse of cells, if all the cells look the same
It manages recycling of cells when the number of values you're getting from the server increases (decreases memory pressure when number of cells becomes substantial)
It allows for more flexibility with the content (it's quite often for design to change last second or to evolve over the course of the project)
Most importantly, UITableView support auto sizing cells (as of iOS8), you need to specify the constraints between the label and the borders of the cell
There are several resources to start with:
http://www.raywenderlich.com/73602/dynamic-table-view-cell-height-auto-layout
https://www.captechconsulting.com/blogs/ios-8-tutorial-series-auto-sizing-table-cells
http://www.appcoda.com/self-sizing-cells/
Use a container view in a scrollView
Add constraints to superview (leading, trailing, top, bottom, height,width)
Make IBOutlet of constraints that you are going to update.
Add you all labels inside that view.
Update constrains/frame of your label so that it fits the text.
How much you increase the label height you should increase the container height too.
If the label count is not fixed use custom label class to add subview.
Perhaps you should need to understand how ScrollView works in Storyboard with autolayout.
I have a cell that contains a container with 10 subviews (two of them are simply bounds and the others are labels). The scheme looks like this.
Dynamic labels may contain huge text so the cells should conform the appropriate size to fit the content. The question is how to set up all the constraints manually... I've tried a dozen of times to do it myself but seems I'm not that good at this. The table view supports auto dimension for row height and uses custom estimated height.
In Storyboard it looks this way.
Where blue views are a subviews of View C. A grey view behind is a View B. Bold labels are static and the others are dynamic.
Demo project.
How to setup constraints?
Thank you very much in advance!
I managed to setup your constraints so that you get the result you needed. This is what I get:
I hope this is how you wanted it to look like.
Here is a link with the project.
I will try to explain how I added the constraints so that it makes more sense.
First of all, you have view B which needs to be as big as the contentView. For this you add top/bottom/left/right constraints to the superView. Because you are using automatic dimensions, if you add all constraints with priority 1000(the maximum one), you will get some error with the constraints while running. This is because, before the cell size can be calculated automatically it is zero, so the constraints crash. Therefore, I set the priority for top and trailing space with a priority of 999 so that you don't see the error log anymore. The result is the same.
Then views C needs (top or bottom)/left/right and height constraint
Then you need to add the constraints for the labels. Since you need the right ones to have multiple lines, the constraints need to specify the vertical layout for this particular case. So, you have as follows: first label: top/left to name label and right to super view. All the other have top to the previous one,and bottom to the next one.
for the labels that don't need to resize you just need leading space to parent,horizontal space to the right label and static width. Also, you will need a constraint to align the top with the label on the right.
This is the result I get:
Hope my explanation made sense, just let me know if you have questions. Good luck with your project!