I'm asking this (somehow) simple question just to be finicky, because sometimes I'm worried about a misuse I might be doing of many UIView's APIs, especially when it comes to autolayout.
To make it super simple I'll go with an example, let's assume I need an UIView subclass that has an image icon and a multiline label; the behaviour I want is that the height of my view changes with the height of the label (to fit the text inside), also, I'm laying it out with Interface builder, so I have something like this:
with some constraints that give fixed width and height to the image view, and fixed width and position (relative to the image view) to the label:
Now, if I set some text to the label, I want the view to be resized in height to fit it properly, or remain with the same height it has in the xib. Before autolayout I would have done always something like this:
In the CustoView subclass file I would have overridden sizeThatFits:
like so:
- (CGSize) sizeThatFits:(CGSize)size{ //this stands for whichever method I would have used //to calculate the height needed to display the text based on the font CGSize labelSize = [self.titleLabel intrinsicContentSize]; //check if we're bigger than what's in ib, otherwise resize CGFloat newHeight = (labelSize.height <= 21) ? 51: labelSize.height+20; size.height = newHeight; return size; }
And than I would have called something like:
myView.titleLabel.text = @"a big text to display that should be more than a line"; [myView sizeToFit];
Now, thinking in constraints, I know that autolayout systems calls intrinsicContentSize
on the view tree elements to know what their size is and make its calculations, therefore I should override intrinsicContentSize
in my subview to return the exact same things it returns in the sizeThatFits:
method previously shown, except for the fact that, previously, when calling sizeToFit
I had my view properly resized, but now with autolayout, in combination with a xib, this is not going to happen.
Of course I might be calling sizeToFit
every time I edit text in my subclass, along with an overridden intrinsicContentSize
that returns the exact same size of sizeThatFits:
, but somehow I don't think this is the proper way of doing it.
I was thinking about overriding needsUpdateConstraints
and updateConstraints
, but still makes not much sense since my view's width and height are inferred and translated from autoresizing mask from the xib.
So long, what do you think is the cleanest and most correct way to make exactly what I show here and support fully autolayout?
Setting the intrinsic content size of a custom view lets auto layout know how big that view would like to be. In order to set it, you need to override intrinsicContentSize . Whenever your custom view's intrinsic content size changes and the frame should be updated.
Asks the view to calculate and return the size that best fits the specified size.
Intrinsic content size is information that a view has about how big it should be based on what it displays. For example, a label's intrinsic content size is based on how much text it is displaying. In your case, the image view's intrinsic content size is the size of the image that you selected.
Auto Layout constraints allow us to create views that dynamically adjust to different size classes and positions. The constraints will make sure that your views adjust to any size changes without having to manually update frames or positions.
I don't think you need to define an intrinsicContentSize.
Here's two reasons to think that:
When the Auto Layout documentation discusses intrinsicContentSize
, it refers to it as relevant to "leaf-views" like buttons or labels where a size can be computed purely based on their content. The idea is that they are the leafs in the view hierarchy tree, not branches, because they are not composed of other views.
IntrinsicContentSize is not really a "fundamental" concept in Auto Layout. The fundamental concepts are just constraints and the attributes bound by constraints. The intrinsicContentSize, the content-hugging priorities, and the compression-resistance priorities are really just conveniences to be used to generate internal constraints concerning size. The final size is just the result of those constraints interacting with all other constraints in the usual way.
So what? So if your "custom view" is really just an assembly of a couple other views, then you don't need to define an intrinsicContentSize. You can just define the constraints that create the layout you want, and those constraints will also produce the size you want.
In the particular case that you describe, I'd set a >=0 bottom space constraint from the label to the superview, another one from the image to the superview, and then also a low priority constraint of height zero for the view as a whole. The low priority constraint will try to shrink the assembly, while the other constraints stop it from shrinking so far that it clips its subviews.
If you never define the intrinsicContentSize explicitly, how do you see the size resulting from these constraints? One way is to force layout and then observe the results.
Another way is to use systemLayoutSizeFittingSize:
(and in iOS8, the little-heralded systemLayoutSizeFittingSize:withHorizontalFittingPriority:verticalFittingPriority:
). This is a closer cousin to sizeThatFits:
than is intrinsicContentSize
. It's what the system will use to calculate your view's appropriate size, taking into account all constraints it contains, including intrinsic content size constraints as well as all the others.
Unfortunately, if you have a multi-line label, you'll likely also need to configure preferredMaxLayoutWidth
to get a good result, but that's another story...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With