What Are Constraints?
If someone would come up to you on the street and ask you what constraints are, what would you answer? – Admittedly, that’s most likely never going to happen, but I’m trying to make a point here. – Would you know what to say to that stranger? A couple of months ago, I certainly didn’t.
When I started learning Swift, I would have answered:
„Isn’t that the thing with the auto-layout in Xcode? I can’t ever get those right!“
Or I would have lied and tried to pull myself out of the situation to hide that fact that I didn’t really know what to do with them.
If you’re like me at that time, don’t worry. I have a couple of resources prepared for you to get your auto-layout knowledge on track.
Why Would You Use Them?
First of all, what do constraints actually do?
Well as you probably know, they manage the layout of views on your storyboards and basically determine the behavior of your apps user interface. That’s a huge deal.
Think of all the screen sizes, rotations, split view and side bar view options there are in Apples product palette. But in order to understand how powerful constraints are, let’s just assume we would implement something like this on our own. I mean, how hard can it be?
So to start of, we would need to define where a view should belong when starting the app. So this would mean we would need to define the size- width and height – and position -X- and Y-position – of the view.
Then we would need tor create some kind of routine that is triggered when screen size changes occur. This would mean we would need to recalculate all our width, height, x- and y-positions if any changes on the superview occur. But we’re clever, we could spend some time and create sophisticated math equations that can take care of that in a way that makes sense.
But in order to do this whole task in a way that doesn’t disrupt the UX, we would need to make use of threading. If we didn’t that would mean that we would see jitter and lag on the screen as the application recalculates all the positions and sizes. Also we would need to make sure that the thread(s) don’t interfere with each other while they communicate their values to the surrounding views.
If we were to take all of that upon us, that would leave us with a – hopefully well – working solution to layout our apps as we go. Now we could spend some time an the UX and create nice animations for the transitions and make the views adapt in a way that is pleasing to the eye.
That would in fact leave us with a working solution that can do something similar to Auto-Layout. It’s most probably not as flexible, and to be honest, it lacks convenience, but hey! It’s working.
Only thing: We don’t have a nice UI to apply those „self made constraints“ to our vies so we would need to manage everything in code ourselves. To write something like this would take ten more work.
So if you could build something like this on your own, why use the solution from apple?
The thing is: Apple provides a very elegant, fast, secure and easy solution to dealign with this rather complex problem.
They already spent hours upon hours perfecting the system making it adaptable and easy to use. Also it is flexible enough to create any layout you can dream of. And it is blazingly fast. And we have UI tools to create the layout visually. But that doesn’t mean we can not do it in code. We can.
i think I don’t have to g into any more detail but to me it is already clear that I am not willing to work on a solution that someone else has implemented in a better way then I could ever dream of. I’d much rather spend my time working on the apps functionality itself.
How Do They Work?
But how do Constraints actually work?
Well, constraints are mathematical equations that are solved by the auto-layout framework. So basically you describe relations between views using sets of math equations.
Auto-Layout takes the equations, solves them and adjusts the layout. The auto-layout solver is triggered every time a change occurs, like rotation of the device, changing screen sizes, sidebar or split-view mode. All of this is happening autonomously. You don’t have to worry about triggering the size changes. You don’t need to care about writing the functions that set the new positions and sizes of the views. You can leave all of this to Apples auto-layout system. Fantastic, right?
And the flexibility is awesome too! You can use auto-layout constraints to vertically and horizontally center any view. You can use the width and height constraint to set the height and with of the view directly, or you can just make use of the top, bottom, left and right constraints and chain them to the superviews bounds. It’s up to you where to place the constraint. The flexibility is just phenomenal.
Anatomy Of A Constraint
But what information does auto-layout actually need from us to create those layouts? I’ve talked about placing constraints to different places on a view. But how does the code know what to do?
I mentioned before that constraints are just math equations that describe the relationship between different parts of different views.
Apple has found a great way to explain that in a super easy way. I replicated their example, which you can find right here.
By the way, this is a slide I pulled out of the Auto-Layout Module.
See The Auto-Layout Module
What Are Constraints?
Essentially what constraints need is the two view that interact with each other. In this example this would be the two views: red and blue.
The next information that is necessary, are two attributes. These attributes tell auto-layout, which values of the view to adjust to make the relation true. In our case here, this would be the left edge of the red view and the right edge of the right view.
The relation by the way is the third thing we need. This can be equals, greater-or-equals or lesser-or-equals.
The last two things that are left are a multiplier and a constant. In our case here, our constant is 8, which means that the gap between the two views is 8 points big. Setting the multiplier to 2.0 would cause the gap to double in size.
Unfortunately I can’t cover more in a single blog post than this, but rest assured there is another one coming next week. Let’s wrap up.
An Elegant Solution To A Painful Problem
I know that at first the concept of constraints can be a little intimidating. I know it, because I’ve stayed away from them as far as I could, but after some time there was no way around.
It was at the time where I started to work an my first serious project in Swift. All this time I was okay with not knowing how to use constraints in the proper way. I always used the same simulator – the one matching my device – to test the app and I turned of device rotation so that I never noticed that the layout didn’t adapt. It was not pretty but I didn’t want to pay attention to auto-layout. It seemed confusing and it used to frustrate me.
This project however made me take the leap. I had to get the project right and to do it right, meant to do it with auto-layout. I immersed myself in the framework and figured a lot of the stuff out by reading and the try-and-error. It worked well but there were some fundamentals missing that no one taught me.
I research more and more and finally I felt like I had mastered auto-layout. This was when I decided to create the Auto-Layout module that is coming to the site soon.
In creating the module, I had to research even more to make sure everything was perfect. At the time of this writing, production for the module is in full progress and I can’t wait to help you understand the fundamentals of auto-layout. I want to teach you everything you can possibly know about this topic, because I’ve learned to love it. I can’t tell you how much value this concept will have to you and I promise you that investing time in learning this concept is going to pay off! Don’t be intimidated by the complexity this topic seems to hold at first. The Value it brings to you will leave you with a greater sense of joy and fulfillment in Swift than almost anything else could.
I hope you enjoyed this small lesson. See you next week!
See The Auto-Layout Module