0

I usually set all my auto layout code in the updateCOnstratins method of my view controller for the constraints of all the subclasses defining the view. Then in the subviews I place my constraints in the updateConstraints methods there. This makes me have a property of every single view in my class so I can reference it later on after I set translates.... to false. But Im reading that you don't have to set it in updateConstraints. Just not I read an article where the person says an apple engineer said that if the constraints are only made once then you can put them pretty much where ever. Yet, if you have constrains that change during the views lifecycle you place them in updateConstraints? Here are the links http://swiftandpainless.com/where-to-put-the-auto-layout-code/ http://swiftandpainless.com/dont-put-view-code-into-your-view-controller/.

So where should It go? Was this just an old way of doing this and now it has changed?

Dima
  • 23,484
  • 6
  • 56
  • 83
Esko918
  • 1,397
  • 1
  • 12
  • 25

2 Answers2

0

What you said in your post is what you would generally want to do. Put any constraints that might change in updateConstraints. This also means you should keep a reference to them to be able to update them or remove/replace them. Any static ones can be put after your initialization code (the init method of a UIView or the viewDidLoad method of a UIViewController, for instance). The only real requirement there is you can only add constraints to views that are actually in a view hierarchy together, so anytime after you've added the appropriate views would be fine.

Dima
  • 23,484
  • 6
  • 56
  • 83
  • Well thats good news then since I have been doing this since the dawn of auto layout. I just thought you might have never needed to put them in updateConstraints if you set it up a certain way. – Esko918 Mar 18 '18 at 03:57
0

There is usually no reason not to put your constraint creation code in viewDidLoad, which has the advantage of being called only once. For constraints that change, I like to associate that code with whatever directly precipitates the change, such as a change in size class or the removal or insertion of a view.

matt
  • 515,959
  • 87
  • 875
  • 1,141