Learn why you should use Auto Layout and why you should use Auto Layout programmatically.
- By losing our buttons in landscape, you've begun to see the problem with using frames alone. They are static and set for a specific width and height of super view. The portrait for iPhone Eight Plus is one height and width. Landscape is a different height and width. Rotating the phone changes the visible frame. The buttons have a Y origin point of 450, outside the visible frame in landscape. With frames alone, you'd have to detect the size of the screen, and then execute code to change the frames to make up the difference.
That's a bit of a pain to do, but it gets worse. This is only one device. There's four phones and three iPad resolutions you must develop for. Double that for landscape, and add a few more for multitasking. That's close to 30 different configurations on phones, and way too much work for anyone. The next time Apple introduces a new phone, you'd have to write two more methods to deal with the frame and five for an iPad.
This is just one view controller. But you'd have to do that for every view controller. What if you instead describe the view in relation to each other? Instead of working from the top left corner alone, use the relation to the sides of the other views. For example, the back button could be scribed as 20 points from the bottom, and 10 points from the leading side of left. I defined the order button as ten points away from the end of the back button, and the tops of the two buttons are aligned.
When you change the size of the view, as in a rotation, the buttons stay in the same place relative to the bottom and each other. This is the idea of auto layout. Use relative positions between the views instead of an absolute position to the origin. iOS does the work of figuring out what frame should be given the relationships that exist. This saves a lot of work. Now there's two ways to do auto layout. The first is on the story board.
You can set these relationships visually with a few menus, buttons, and properties. For those using the story board for adding views, this is an ideal way to do auto layout. If you want to learn more about this, check out some of the other courses in the library. However, if you don't have a story board, it's a different story. This can happen for three major reasons. First, you're coding it an Xcode or iPad Swift playground, which has no access to a story board. Secondly, you're one of those people who hates story boards, and prefers coding your views.
Many of those do this for the third and most important reason. Without a story board file, code is much more portable. Everything is right there in one file in the code. There's a fourth reason, which is a double edged sword. In code, auto layout is a lot more precise than story boards. You have to spell out everything, leaving no room for ambiguity that can creep into story boards. That also means you do have to do all the work, not just some of it like story boards. In this course, we'll skip story boards completely and look deeply into coding your auto layout.
There's many ways you can do this, some simple, some complex. All require a few important concepts that if you don't understand, things will get very messy very quickly.
- When and why to use Auto Layout programmatically
- Creating constraints in Swift
- Resolving errors in Auto Layout
- Using the safe area
- Working with the Visual Format Language
- Adding a stack view
- Harnessing the power of inequalities and priorities in constraints
- Understanding traits and size classes