Ijaw Dictionary Online

How Automobiles Work

Hey, everybody. This is Jerry. Welcome back to the auto
layout video tutorial series. In this tutorial, you’re going to
learn about the automatic constraints that some views create based on
their intrinsic content size. Some views have a size that
works best to fit their content. If you just have a UI view,
with no subviews, it doesn’t have any preference for
what size it is. But if you have a label with some text
assigned to it, the label has a width and a height that fits that text
based on the font assigned. Let’s look at an example. Here we have a label that has a top and
leading space constraint to its superview. Remember, each view should have
constraints defined that fully describe the X and Y position and
width and height of a view. In this case, we only see constraints
that define the X and Y position. So why is auto layout not
indicating any errors? Well, the intrinsic content size of
this label defines the width and height based on the font and
text of the label. That intrinsic content size, together
with the constraints we have defined, do fully describe the layout of this view. But you should always consider this
situation where the text is bigger than you expect, especially if your
app supports dynamic type. Dynamic type is a feature that allows
the user to specify the font size for text in your app. In our example, now the text is
running off the edge of the screen. It’s even worse if there’s another
view to the right of this label. And the text isn’t just getting clipped. It’s obscuring this button. We can define a horizontal spacing
constraint between the label and the button, but auto layout still doesn’t know what to do,
as you can see by the red error lines. The reason is that the constraint
that gets automatically created for the width of the label and the width of
the button have the same priority for content compression resistance. When dealing with intrinsic content size, there are two sets of constraints that
get automatically created for you. And you can control the priorities
of those constraints. The first set of constraints is called
content compression resistance. The priority of these constraints
deal with how much the view doesn’t want to shrink smaller than
the size of its content. The second set of constraints
is called content hugging. The priority of these constraints deal
with how much the view doesn’t want to grow larger than the size of its content. I say set of constraints because
there are separate constraints and priorities for the horizontal and vertical directions if the view
has an intrinsic width and height. Back to our example. The solution is to break
the tie between the label and the button horizontal
compression resistance. In this case, we would like our label
to compress, rather than the button. So we set the horizontal compression
resistance priority to be lower than the number for the button, and now
auto layout knows how to break the tie and the errors are gone. Other views have an intrinsic size in
just one direction, like a progress view. It has an intrinsic height but not width. For these views, the automatic constraints
will only be created in one direction. One final note about
intrinsic content size. Sometimes the content of a view will be
set in code and it will have an intrinsic content size, but
Interface Builder doesn’t know what it is. To avoid Interface Builder errors,
but without having to define extra constraints, you can define
a placeholder intrinsic size. As you can see from the text in Xcode,
these values are only used at design time. You’re still responsible for making sure
the intrinsic size is set at runtime.>>Let’s open up the project
from our previous demo and take a closer look at some
of these constraints. We changed the priority of
the centering constraint to low. What if we had just
changed it to 999 instead? Let’s look back at our
double-length pseudo language. The centering constraint
priority is no longer required. So why is this label not shifting left? Why is it clipping instead? Well, we have three
constraints at play here. If we look at the save button and
these priorities that are defined down at the bottom, and look at the content
compression resistance priority in the horizontal direction,
this is, has a priority of 750. And then the horizontal
compression resistance of the label is also 750, but
the centering constraint priority is 999. So both of those views, horizontal
compression resistance priority, is lower than our centering constraint. So the priority of the centering
constraint is taking precedence over the content compression resistance
of both of these views, and so they’re both getting compressed. The save button’s getting compressed
all the way down to zero and the label’s getting compressed and
clipping its content. If we change the compression
resistance of the button to required, now the button is no
longer getting compressed. But the centering constraint still has
priority over the compression resistance of the label, so
it’s still getting compressed. If we change the compression resistance
of the label also to required, now we see that they both have a higher
priority than the centering constraint. And so the centering constraint
is the one that gets broken, and that’s exactly what we wanted. Okay. Let’s add a couple of labels and
see how they interact with each other. So let’s say I have these two labels, and I want the first one to always say name,
and I want the second one to show a name. This will be set at runtime. I’m gonna constrain the first one to
the leading space and the vertical space. And then I’m gonna constrain
the second label to the first one, horizontal spacing and baseline. And I’m also going to constrain
the second one to the trailing space to the superview. So I have valid constraints for
both of these, but I’m seeing errors. Let’s open up the document outline and
see what errors I’m getting. This is telling me that my second label,
horizontal compression resistance priority, needs to be set, and
the hugging priority needs to be set, and the hugging priority of
the name needs to be set. Now, these are both already set. So what is the air panel here telling me? It’s giving me suggestions based on the
fact that these two labels have a tie for the priority of their compression
resistance and their hugging priority. Let’s take a look at those. The horizontal hugging priority
of this label is 251, and its horizontal compression resistance is
750, but it’s the same for this label. So outer layout is saying,
if I don’t have enough space to show the content of both of these
labels, I don’t know which one to clip. And if I have more space than I
need to show both of these labels, I don’t know which one to grow. Let’s fix that. The first label is the one that
we don’t want to clip, and so we’re gonna set its compression
resistance priority higher. The second label is the one
that we want to grow, and so we’re gonna set its
content hugging priority lower. Once we do that,
the ties are all broken, and auto layout knows which label to clip and
which label to grow in both situations if we don’t have enough space or
if we have more space than we need. Let’s take a look at how this behaves. Let’s change the background color of this
second label to make it easier to see. And let’s show the preview, see how
this behaves in different situations. Looks like it’s behaving
exactly how we want. And landscape and portrait orientations
on different form factors. Let’s go ahead and
set the name of this label and code and see how it looks at runtime. I’m gonna use control-drag to
create an outlet to this label. And then viewDidLoad, of course,
we’re gonna call super, but then we’re gonna set this name label
to the longest name ever recorded, and I have this copied to my clipboard. So this Hubert Blaine
Wolfeschlegelsteinhausenbergerdorff is the longest name ever recorded and
we’re gonna use that to test our layout. Let’s build and run. And just like we want,
the second label is getting clipped. Its compression resistance
priority was lower. And the first label is
not getting clipped. If I rotate to landscape,
we have more space than we need here, so it shows the full value, and it stretches the label to the right margin
of our superview, exactly what we wanted.>>Well, that’s it for
this video tutorial. As always,
we’d like to leave you with a challenge. For this challenge, you’ll create this
entertaining game about a book and see how to deal with the language
of your app changing at runtime. All of the details are in
the challenge document. I hope you enjoyed this tutorial. Thanks for watching. We’ll see you next time.

7 thoughts on “Introduction to Auto Layout in iOS: Intrinsic Content Size – raywenderlich.com

  1. It's exactly what I was looking for. It's been so hard for me to understand this part of intrinsic content size, but now I've it clearer and I'll be practicing autolayout every single fu***ng day! Lots of thanks Jerry from Mexico City.

Leave a Reply

Your email address will not be published. Required fields are marked *