Where-to-put-the-auto-layout-code (where should the AutoLayout code be placed?)

<title>Where-to-put-the-auto-layout-code</title>

where to put the Auto Layout code where do you put AutoLayout? Reference document A Reference Document B Conclusion original link

Where to put the Auto Layout code where do you put AutoLayout?

Auto Layout is kind of magic. Like a sorcerer, the elements where to position and how to behave. You don ' t put the elements to those positions yourself. The universe moves them because of your spells. Kind of. (AutoLayout is like a magic.) It seems that if you read a few spells, the wizard can help you lay out the elements.)

But when should the spells is spoken? In other words if not using Interface Builder, where should the Auto Layout code go? (The question is: When do you think of the mantra when you don't use IB ?)

Reference document A

From the documentation of the UIView method updateconstraints:

Custom views the set up constraints themselves should does so by overriding this method.

Because of this sentence I all thought Apple asks me to put the layout codein this method. But this is the Problem:this method was called more than once by UIKit and adding the same constraint more than once I s an error. The suggested approach I found in the Internet? is to add a Boolean to the view class and set it in Updateconstraints () to make sure to only run the layout code once. (I thought Apple had let me put AutoLayout's code here, but in Uikit this method would be called multiple times, and the solution would be to add a Boolean variable that would allow the code to execute only once.)

Reference Document B

From the documentation again:

When your custom view notes This a change have been made to the view this invalidates one of its constraints, it should IMM ediately Remove the constraint, and then the call setneedsupdateconstraints to note the constraints need to be updated.

This means updateconstraints () are meant to being used in the case and the constraints within a view change because of so Me events. For this scenario the name of the method makes much more sense.

In nearly all of my layouts the constraints is fixed. Sometimes I need to the constant of a constraint. This can is done without removing and re-adding the constraint. (The constant of a nslayoutconstraint is the only thing so can be changed after creation.) (a constant that changes a constraint.)

Because of this, I started to put all the layout code in init (frame:). But I wasn't really comfortable with it because of the documentation mentioned above. (Put all the AutoLayout code in the Init method.)

But then I heard in a session video of the WWDC this year an Apple engineer suggesting exactlythat. And just yesterday I received a answer to a bug on which I described the ' bug ' that updateconstraints () isn ' t call Ed. Turns out It wasn ' t a bug.

The Apple engineer wrote:

In general, if the constraints would is only created once, it should is done with an initialization method (such as-init or -viewdidload, and so forth). Save-updateconstraints for things that is expected to change over the course of running the App.

In general, if a constraint is created only once, the code for this constraint should be placed in the initialization method (for example, Init,viewdidload)

Nice. I love when my feeling on how code should was written is suggested by Apple.

An example of where I put my layout code can is found here.

Happy layouting!

If you enjoyed the this post and then make sure your subscribe to my feed

Update:ole Begemann wrote about when should you implement updateconstraints on his great blog.

No related posts.

Conclusion

In general, if a constraint is created only once, the code for this constraint should be placed in the initialization method (for example, Init,viewdidload)

Original link

http://swiftandpainless.com/where-to-put-the-auto-layout-code/

Where-to-put-the-auto-layout-code (where should the AutoLayout code be placed?)