iOS Autolayout is a groundbreaking feature that has been around since iOS 6.0. Yet, there are apprehensions in developers against using autolayout. These concerns usually stem from 3 facts:
- Late adoption of Autolayout: Most developers realize it quite late their app must be usable across various sized devices and orientations. There is already lot of Objective C / Swift code that is based on fixed frames (320, 480) or (786, 1024). Moving this code means killing something that already works. Creating it on paper, and rendering it on to storyboards / XIBs with generalized / specialized constraints for each device / orientation combination is tremendous work of calculations.
- Misleading autolayout shortcuts: Some of the inertia against autolayout stems from the fact that IB’s controls aren’t intuitive enough when it comes to autolayout. Microsoft Visual Studio’s designer tool was great in aligning / stacking elements – by simply using menu shortcuts. In XCode, aligning is already there, but stacking isn’t there yet. Making commonly used features readily available is something that autolayout IB lacks.
- Autolayout errors and warnings defy novice developer: Despite autolayout being a great tool aimed at making a developer’s job easy, it ended up trying to be panacea for every possible UI layout – thus producing confusing semantics, hard to reach actions, and counter intuitive errors / warnings. Problems?
- The moment you start with your first constraint, it starts complaining about missing constraints. This sometimes defeats the purpose of a simplification tool. It would be good to have “validate constraints” button to check them all at once.
- It does fine job of pointing out missing constraints, but when it comes to conflicting ones, it often fails to point out the culprits.
- There are visible inconsistencies in the tool, even until XCode 9, and here they are:
In this relative width constraint, the only variation that one can add is of the constant, despite the fact that multiplier has bigger impact. Although it’s a known fact that one could always separate constraint with trait variation for multiplier, it is counter-intuitive. Which brings us to another point.
The Add variation box following + sign looks like it adds a constraint for each variation – but all it does is specifying the fact that this constraint will be used for the variation you are specifying.
If you want to add 2nd variation, you need to go back to elements, and add another constraint, and specify the desired 2nd variation there. Besides, you must also uncheck “Install” box, or you will end up having the constraint for all variations, not alone wRhC.
In any case, it’s Apple’s job to improve upon it’s autolayout tool. Meanwhile, we will focus upon some basic principles that make this tool work – according to our wishes.
Was it too hard? Let us go through some basics first:
- A constraint is x, y, width, or height value for a given view, for a given size class.
- A size class is a combination of device width and device height, according to orientation.
- Apple defines size classes for various devices over here.
What are XCode Autolayout errors and warnings:
When it comes to errors and warnings in auto layout, there are three situations:
- If you don’t specify ANY constraint at all, and just position your elements, there probably won’t be any errors. IB will simply assume absolute positions and sizes for all elements. And this will ONLY BE VALID for the size class.
- If you specify just one constraint / some constraints for some of the elements, this will begin the nightmare. XCode will start complaining about the missing constraints, using red arrow error sign in “Document outline”.
- You will then usually go through the nitty-gritty details of measurements, and specify constraints for each UI elements. Note that a view’s resulting constraints are the final result of all constraints that the view is part of. XCode will keep popping “Conflicting constraints” error until you have got them all right.
- If an element is misplaced with respect to its specified constraint in given size class, it will show up a warning (yellow arrow in Document outline).
To fix them all, you need to follow a set of principles. For a fairly complex view which spans ipad, iphones and both orientation, spare a day or half for autolayout, until you get expert at it.
It is recommended to have your coffee, sit down calmly at your mac, and do it in one go rather than committing, rolling back, merging with others and so on.
- Each element must have x, y, width, and height dimensions defined (unless you have no constraint at all in the view). What this means is,
- This principle must be followed by all views except top level view. Dimensions of top level view are decided, also using an auto-generated constraints, by UIKit at runtime. No need to worry about it. But all elements except top level view must have their dimensions defined.
- This becomes nasty because in order to really exploit auto-layout, you will have relative constraints (one view’s right edge touching another view’s left, one view’s width is half than its superview, and so on.). Hence, you must satisfy all four dimensions in a chained-manner
- Which brings us to the question – where to begin. So you must start with a favorite subview in whose relation you will position / size others. There is no rule of thumb for choosing this favorite. Once you see your UI layout in wireframe, you will know which element it will be. This favorite view will usually pin itself to one of the corners / edges of the root view, and will have some proportional width/height to the root view. Others will follow this favorite as far as position is concerned, and will also relate to the superview when it comes to width/height.
- Four Dimensions (x, y, width, height) does not necessarily mean constraints for leading / trailing, top / bottom, width, and height. They can be defined using various combinations of auto layout constraints. Look at the following table:
|x||Leading, Trailing, Horizontal Center|
|y||Top, Bottom, Vertical Center|
|Width||Width (Absolute number) / proportional to superview, Aspect Ratio|
|Height||Height (Absolute number) / proportional to superview, Aspect Ratio|
Practical Autolayout Considerations:
While designing for iPhone and iPad, with portrait and landscape orientations in mind, following are general auto layout practices that can make your life lot easier:
- Use absolute size constraints (width = constant, height = constant) for buttons, and labels with small amount of text. This is because user expects certain action in the UI at certain position / size, and absolute values make his life easier. Also, fixed sizes make it better for text visibility across devices as far as it is not variable length text.
- Use relative constraints (width = superview.width * 0.4, height = superview.height * 0.6) for container views, dynamically sizing text views, labels etc. This is an obvious guideline considering the look and feel and principles of proportions.
- It makes tremendous sense to group elements in single screen under common subview, acting as a container. For example, if you have four labels all along each other placed vertically / horizontally, you could use a common container for all of them, and pin them (using x,y, width, height dimensional constraints) to this container’s edges. This way, if you decide to move them all, you just need to move this common container, and only disrupt the container’s constraints within the superview. See Container1 and Container2 below:
Keeping above principles in mind will fix most of your auto-layout errors/warnings, and make your XIB/storyboard clean and without yellow/red error marks.
There is still a major source of auto-layout headaches that this has not covered: UIScrollviews. In our next post, we will discuss the key to unlock how to resolve auto layout errors related to scroll view.