I know that the auto layout chain consists in basically 3 different process.
What's is not totally clear to me is the inner difference between -setNeedsLayout
and -setNeedsUpdateConstraints
. From Apple Docs:
Call this method on your application’s main thread when you want to adjust the layout of a view’s subviews. This method makes a note of the request and returns immediately. Because this method does not force an immediate update, but instead waits for the next update cycle, you can use it to invalidate the layout of multiple views before any of those views are updated. This behavior allows you to consolidate all of your layout updates to one update cycle, which is usually better for performance.
When a property of your custom view changes in a way that would impact constraints, you can call this method to indicate that the constraints need to be updated at some point in the future. The system will then call updateConstraints as part of its normal layout pass. Updating constraints all at once just before they are needed ensures that you don’t needlessly recalculate constraints when multiple changes are made to your view in between layout passes.
When I want to animate a view after modifying a constraint and animate the changes I usually call for instance:
[UIView animateWithDuration:1.0f delay:0.0f usingSpringWithDamping:0.5f initialSpringVelocity:1 options:UIViewAnimationOptionCurveEaseInOut animations:^{
[self.modifConstrView setNeedsUpdateConstraints];
[self.modifConstrView layoutIfNeeded];
} completion:NULL];
I've found out that if I use -setNeedsLayout
instead of -setNeedsUpdateConstraints
everything work as expected, but if I change -layoutIfNeeded
with -updateConstraintsIfNeeded
, the animation won't happen.
I've tried to make my own conclusion:
-updateConstraintsIfNeeded
only update constraints but doesn't force the layout to come into the process, thus original frames are still preserved-setNeedsLayout
calls also -updateContraints
methodSo when is ok to use one instead of the other? and about the layout methods, do I need to call them on the view that has a change in a constraint or on the parent view?
Your conclusions are right. The basic scheme is:
setNeedsUpdateConstraints
makes sure a future call to updateConstraintsIfNeeded
calls updateConstraints
.setNeedsLayout
makes sure a future call to layoutIfNeeded
calls layoutSubviews
.When layoutSubviews
is called, it also calls updateConstraintsIfNeeded
, so calling it manually is rarely needed in my experience. In fact, I have never called it except when debugging layouts.
Updating constraints using setNeedsUpdateConstraints
is pretty rare too, objc.io–a must read about autolayouts–says:
If something changes later on that invalidates one of your constraints, you should remove the constraint immediately and call setNeedsUpdateConstraints. In fact, that’s the only case where you should have to trigger a constraint update pass.
In addition, in my experience, I have never had to invalidate constraints, and not set the setNeedsLayout
in the next line of the code, because new constraints pretty much are asking for a new layout.
The rules of thumb are:
setNeedsLayout
.updateConstraints
method (a recommended way to change constraints, btw), call setNeedsUpdateConstraints
, and most of the time, setNeedsLayout
after that.layoutIfNeeded
.Also, in your animation code, I believe setNeedsUpdateConstraints
is unneeded, since constraints are updated before the animation manually, and the animation only re-lays-out the view based on differences between the old and new ones.