Determine width of UITextView in heightForRowAtIndexPath with auto layout - ios

A rather convoluted problem, looking for an elegant solution:
A UITableViewCell subclass has a UILabel on the left and a UITextView on the right. Both label and text view have dynamic content. I am using the text view rather than another label because I need the address link recognition.
The label has a higher compression resistance than the text view, so that its right edge will expand towards the right as needed (up to a certain limit). The text view's width will in turn be compressed. The text view is set to word wrap to expand downward.
Because a text view is a itself a UIScrollView, the normal automatic dimension mechanism of a dynamically sized table view cells view will not work (i.e. using UITableViewAutomaticDimension). Thus, I tried to implement heightForRowAtIndexPath. To determine the necessary height, I thought just need:
The text in the label, plus its attributes
The text in the text view, plus its attributes
The width of the table view (as it is "plain" rather than "grouped")
With this information, I reckoned, I can use sizeThatFits on helper objects to determine the necessary height.
However, I am reluctant to hard-code the horizontal margins between the label and the text view into my size calculation, so theoretically I additionally need NSLayoutConstraint outlets for
The left margin of the label to its superview
The max allowed width of the label
The horizontal distance between the label and the text field
The right margin of the text field to its superview
This seems really insane! While I was writing the implementation of this, I asked myself if there is not an easier way to accomplish the same. (That's why I did not yet write the code to post here.) After all, the only hard problem here is how to get the available width for the text view, but the way to getting there seems unduly complex.
Any ideas for a concise, elegant solution?
Side notes: This has to be calculated before the cell is rendered to be displayed. Also, setting the text view's scrollingEnabled to false produces weird results when using sizeThatFits.

Related

Fitting text in UILabel inside a Table View Cell

I am using a TableViewController with "Right Detail" style cells. To fit the text into the cell.textLabel I use cell.textLabel?.sizeToFit(). But the problem is, that the cell.detailTextLabel gets pushed out of the view. Whats the best way to solve this problem?
This is the result I am getting right now
I haven't used .sizeToFit(), so i can't say what it is actually for but you don't need it. Lower the compression resistance of your label.
Content Compression Resistance explained:
Sets the priority with which a view resists being made smaller than its
intrinsic size. Setting a higher value means that we don’t want the view
to shrink smaller than the intrinsic content size.
Read more about it here: https://medium.com/#abhimuralidharan/ios-content-hugging-and-content-compression-resistance-priorities-476fb5828ef
I would suggest make your own custom cell.
1.you can crop left label if it is too wide.
2.expand left label to multiple lines and make cell height self constraint.

Stop UITextField from expanding horizontally

I have a UITextField positioned in a view next to a button. It has a trailing constraint of 8 to the button (which has a trailing constraint of 8 to the superview) and when I type long text in it, it simply scrolls along, which is I want. However, in order to retain the text typed in the field if the view is switched to another one (it's in a tab controller), I save the text in a holder variable and when it switches back to that view, I set the text in the field to the saved text.
The problem is that this causes the field to expand horizontally if the text is long enough, sometimes pushing the button off-screen, even with the trailing 8 constraint. I have tried to save the original frame of the field in a holder variable, and then after setting the text, set the frame to the saved original frame like so:
fieldFrame = messageField.frame
println(messageField.frame.width)
messageField.text = holderMessage
println(messageField.frame.width)
messageField.frame = fieldFrame
However, the field still expands, and it printed out 502.0 twice. My current thought is that the frame hasn't registered the change in width after the setting of the text in time for the println, but I'm not sure if this is correct.
Also, I've read some similar questions that suggested using a width constraint. If I use a less than or equal to width constraint on the field, will it still expand if on a device that's thinner? That is to say, since I'm currently using an any width and any height storyboard, it's wider than, say, an iPhone 6. So if I set a less than or equal to width constraint on the current width of the field, it seems possible that the field can still expand on a smaller device and not break that constraint.
Is there a better way to do such a width constraint? If not, how else can I keep the field from expanding and pushing the button offscreen?
Here's the problem. The text field has a tendency to size itself horizontally to its contents. The button has a tendency to size itself horizontally to its contents. Thus you have an ambiguity: those tendencies have the same priority, so the runtime doesn't know which one to collapse as the text field's text gets too long.
The solution is to adjust those priorities. You must lower the horizontal compression and hugging priorities for the text field - one point lower should be sufficient. Now the button will have a stronger tendency to match its own size to its contents, and the text field will clip its contents.
You can also lower the Content Compression Resistance programmatically (this also works if you are using a UIViewRepresentable in SwiftUi):
uiTextField.setContentCompressionResistancePriority(.defaultLow, for: .horizontal)
For more info on this topic please refer to:
https://medium.com/#dineshk1389/content-hugging-and-compression-resistance-in-ios-35a0e8f19118
Selecting the Text view, then within Size inspector:
1) Set "Layout Margins" to "Fixed".
2) Under "Content Compression Resistance Priority", set the "Horizontal" to be "Low (250)".

UILabel that has unnecessary padding in a cell

I'm trying to make a Facebook clone for practicing iOS and I can't see why a label I have on my news feed gets unnecessary padding.
It only occurs on some labels, others on my news feed turn out fine. However for a select few there's a block of white pace above and below. At first I thought it was an alignment issue so I changed the labels background to green to show that the constraints hold out.
Anyone know as to why it's placing the padding, only for a select few?
By default UILabel will center its content vertically. Therefore, if label.bounds.size.height is greater than size of the text, the label's instinct is to center the content vertically, which will results in the vertical padding that you see in the attached image. Ensure that the label's height is being set according to the height of the text it contains and the problem should go away.
As dbart pointed out your label's frame is likely higher than the text needed. You can fix this by calling -sizeToFit. You can also check the amount of space the label is actually using for text by using +textRectWithBounds:maximumNumberOfLines:
If your cell is using autolayout to determine the height of the label you should set the preferredmaxlayoutwidth to an appropriate value (for example table width) before laying out the cell.

Multiline UILabel with auto layout does not work

I'm trying to set constraints to get a multiline label in a static table view cell, but apparently this does not work for me, the label is still in one single line. I've set the numberOfLines property to 0 and also the height constraint to greater than or equal. And I'm setting the height for the cell correctly in tableView:heightForRowAtIndexPath. Please have a look at my screenshot to see the settings in IB.
In the comments above you mentioned you're not currently setting preferredMaxLayoutWidth. This property tells your label that it should lay out its text over the width of that property's value. In UILabel.h:
If nonzero, this is used when determining -intrinsicContentSize for multiline labels
In other words, if you don't set that, the label's intrinsic content size is whatever width the label needs to draw its text. If you set this property to the label's bounds, it will start drawing on the next line (or else it will cut the text off if numberOfLines is 0).
In your case, I would probably do that in tableView:willDisplayCell:forRowAtIndexPath:.
You can set the preferredMaxLayoutWidth in code, but when designing your user interface in storyboard, you still see a long one-line label that gets cut off at the edges. An alternative is to manually insert line breaks anywhere in your text right within the storyboard using Option-Return. You then just set the number of lines to more than your text will fit. Then select your label, hit Cmd-=. This will calculate the intrinsic content size for your label with the line breaks exactly where you want them to be.
Theoretically, I think setting the preferredMaxLayoutWidth is the more correct way to go about this, especially using Autolayout. However, I found it more practical to use the method I described above because it lets you see the layout at design time right in the storyboard, and you have total control of your line breaks. This usually works better for labels with text that don't change often. If you are dynamically changing the label text, setting preferredMaxLayoutWidth is the preferred way.

resize superview after subviews change dynamically using autolayout

I cant for the love of god the the hang of this resizing superview.
I have a UIView *superview with 4 UILabels. 2 function as header for the 2 others.
The content in all 4 are dynamic coming from database.
SizeToFit vs SizeThatFits:(CGSize) vs UIView systemLayoutSizeFittingSize:, passing either UILayoutFittingCompressedSize or UILayoutFittingExpandedSize.
I use autolayout programatically and have set the superview height to be equal or greater to a dummy number.
where and how do I use these SizeToFit vs sizeThatFits:(CGSize) vs UIView systemLayoutSizeFittingSize:, passing either UILayoutFittingCompressedSize or UILayoutFittingExpandedSize. I have read a lot of tips here on stack but ended up with nothing.
DO I need to recalculate the constraints for the superview somewhere specific. Maby setting the height to be ´#property` in its controller class and remove and readd it?
Atm I have tried to put everything everywhere and then some. Still I get the same size end result with the dummy height and text floating outside. Even after setting clipsToBound on subview.
I am scratching my hair of.. help
If you're using Auto Layout, here's what you need to do:
Make sure you aren't adding fixed width and/or height constraints to any of your subviews (depending on which dimension(s) you want to dynamically size). The idea is to let the intrinsic content size of each subview determine the subview's height. UILabels come with 4 automatic implicit constraints which will (with less than Required priority) attempt to keep the label's frame at the exact size required to fit all the text inside.
Make sure that the edges of each label are connected rigidly (with Required priority constraints) to the edges of each other and their superview. You want to make sure that if you imagine one of the labels growing in size, this would force the other labels to make room for it and most importantly force the superview to expand as well.
Only add constraints to the superview to set its position, not size (at least, not for the dimension(s) you want it to size dynamically). Remember that if you set the internal constraints up correctly, its size will be determined by the sizes of all the subviews, since its edges are connected to theirs in some fashion.
That's it. You don't need to call sizeToFit or systemLayoutSizeFittingSize: to get this to work, just load your views and set the text and that should be it. The system layout engine will do the calculations for you to solve your constraints. (If anything, you might need to call setNeedsLayout on the superview...but this shouldn't be required.)
Use container views
In the following example I have a 30x30 image, and the UILabel is smaller than the containing view with the placeholder text. I needed the containing view to be at least as big as the image, but it needed to grow to contain multi-line text.
In visual format the inner container looks like this:
H:|-(15.0)-[image(30.0)]-(15.0)-[label]-(15.0)-|
V:|[image(30.0)]|
V:|[label(>=30.0)]|
Then, set the containing view to match the height of the label. Now the containing view will ride the size of the label.
As #smileyborg pointed out in his answer, connecting the content rigidly to the superview informs the layout engine that the simple container view should cause it to grow.
Yellow alignment rectangles
If you want the yellow alignment rectangles add -UIViewShowAlignmentRects YES in your scheme's list of run arguments.
This almost follows #smileyborg answer and comes with a concrete example.
Won't describe all constraints, but those related to the calculation of the height of UI objects.
[Label] Labels must not have a fixed height constraint, in this case, AutoLayout won't resize labels to fit the text, so setting edge constraints is the key. (green arrows)
[Subview] Steps 1 and 3 are very easy to follow, but this step can be misunderstood. As in the case with labels, subviews must not have height constraint set. All subviews must have top constraint set, ignoring bottom constraint, which can make you think will trigger unsatisfied constraint exception at runtime, but it won't if you set bottom constraint for the last subview. Missing to do so will blow the layout. (red arrows)
[Superview] Set all constraints the way you need, but pay big attention to the
height constraint. Assign it a random value, but make it optional, AutoLayout will set the height exactly to fit the subviews. (blue arrows)
This works perfectly, there is no need to call any additional system-layout update methods.
This was made dramatically easier with the introduction of Stack Views in iOS 9. Use a stack view inside your view to contain all your content that resizes, and then simply call
view.setNeedsUpdateConstraints()
view.updateConstraintsIfNeeded()
view.setNeedsLayout()
view.layoutIfNeeded()
after changing your content. Then you can get your new size by calling
view.systemLayoutSizeFittingSize(UILayoutFittingCompressedSize)
if you ever need to calculate the exact size required for a view.

Resources