[MUSIC PLAYING]
Hey there, iOS developers.
If you watched our previous quick tip,
you learned that you don't have to give up your fancy UI View
Animations just because you're using constraints.
The trick is that, instead of directly animating
your views' positions themselves,
you can animate their constraints either by animating
the constant associated with those constraints,
or by enabling and disabling completely different sets
of constraints to make your views do different things,
and then calling layout, if needed,
within the animation block.
But this came with a couple of extra quick tips
from one of Google's very own engineers, Jessica Horowitz.
Jessica is an engineer working on some cool new native iOS
search features.
And she had a few notes on how you could best optimize
your constraint animation.
So in our previous video, you'll recall
that I could make these three views
switch from being left-aligned to right-aligned
simply by removing and then adding
different sets of constraints.
It turns out, however, that adding and removing constraints
from your layout requires quite a bit of work
from the auto layout engine and can be pretty CPU intensive.
And as some folks around here are fond of saying,
performance matters.
Ah!
Don't do that.
Shoo.
So instead of enabling and disabling
different sets of constraints, Jessica
recommends you enable all the constraints at design time.
Let me show you.
So here, I'm going back into Interface Builder.
And I'm going to enable the constraints
that both left align and right align my views.
Of course, when you do that, Xcode
will once again complain that you
have conflicting constraints.
But don't freak out.
Are you freaking out?
Stop it.
Instead, go into your inspector here,
and change the priorities of your constraints.
In my example, I'm going to change
the priorities of the ones I want
Xcode to ignore for now to 1.
And I'll change the priorities of the ones
I want to keep to 999.
Now, we can go back into our code.
And instead of enabling or disabling
our two sets of constraints, we can just change the priorities
back and forth between 999 and 1,
a little something like this.
I have the same behavior as before.
But this kind of priority chaining
is much more efficient than enabling and disabling
constraints entirely.
By the way, in case you're wondering
why I had to change my high priority constraints to 999
instead of leaving them at the default value of 1,000,
it's because iOS interprets constraints
set at 1,000 as required constraints,
meaning that I can't set them later to anything lower.
Setting it to 999 means it'll probably take priority,
but it's also optional.
So I'm able to lower it later on.
Now, in addition, Jessica had a second tip for you.
You'll notice that in my samples I've
been calling layout if needed on self.view right
there in the view controller.
Now, in many cases, particularly little examples like this,
it'll work just fine.
But in some more complex cases, it will not.
Let's take a look at this example here.
You can see I have a container view
controller-- this red and blue thing--
placed inside another view controller, where
I've added these gray bars here at the top and the bottom.
Now, watch what happens when I animate a few constraints
within the container view controller and then call
self.view.layoutifneeded.
You can see that this container itself animates smoothly.
But these bars at the top and bottom, as well as
the placement of the container pops, which kind of ruins
that whole smooth transition look I was going for.
So the trick here, and our second quick tip of the day,
is that you really need to call layout
if needed on the deepest view whose size or position
won't be affected by the constraints you're animating.
So in this example, I found that I
was able to get a smooth animation by calling layout
if needed not on my view controller's view
but on my view controller's view's super view's super view.
So that's much better.
But how did I figure that out?
Well, I would love to tell you it's
because I logically analyzed my view's hierarchy
and calculated the appropriate level from there.
But honestly, I just kept adding super views until I
got something that worked.
Trial and error, it's great.
So that said, you could always break out the big guns
and call layout if needed on your view's window--
this thing here-- which basically
forces auto layout to recalculate
your entire hierarchy.
But that, as you can imagine, gets pretty expensive
and is probably excessive in most cases.
Remember, perf matters.
Oh.
Go away.
You've got your own show.
Leave mine alone.
So thank you, once again, to Jessica for the tips.
Jessica, I know you work here, but you've totally earned
yourself a Google T-shirt too.
What about you?
Got a quick tip?
Send it to me at this address here,
and you can be just like Jessica.
Well, I mean, in the fact that you'll get a T-shirt.
I can't guarantee you'll get to be
an engineer here or anything.
But you know, we are hiring.
Just saying.
So thanks, once again, for watching.
And I will see you soon on Route 85.
[MUSIC PLAYING]