Autolayout on A+ programming moments

No headache: auto layout tips in Interface Builder

Sat, 28 Mar 2020 12:01:00 +0000

I wrote previously how to setup your main views so that embedding properly respects safe areas on whatever device it’s being run on. The key thing: setup inner constraints towards VC.view to use superview margins. Easiest way to do this is to:

add one UIView as direct child of VC.view
setup constraints of that view so its edges are all connected to VC.view’s margins
All your content then goes into that “real” content view and you are set

This will solve at least 90% of layouts you’ll ever need to do.

Don’t forget an older tip about setting priority 999 for some of the sides of realContentView.

Another great guideline: when you have a series of child sibling views inside a container, either horizontal or vertical, your job will be much easier if you prioritise making constraints among siblings and avoid superview as much as possible.

Between vertical siblings, it looks like this:

Few things:

Make sure to use default (standard) spacing because then you follow HIG and app will generally look better.
First sibling in a (vertical) row will have constraints to leading, top and trailing edges of the superview.
The following child views will align each other.
The last child will align to superview’s bottom edge.
By doing this, you will have just one place to change spacing for all the children.

Or you can use UIStackView for this, although I find that component useful only with repeating identical views. In all other cases it’s more trouble than it’s worth. Additionally in case you want to create a layout that autosizes per contentSizeCategory, then stack views can make that impossible, depending on the layout.

Speaking of dynamic type, always, always use Text styles for all your UILabel, UITextField, UITextView etc. And make sure to set this “Automatically Adjusts Font” checkbox:

and make sure to set Lines: 0 so the text is fully visible regardless what content category size is used by end customer.

UIButton sadly does not have this option, but you can enforce it for its titleLabel:

You’ll need to include this simple extension somewhere in your code:

extension UIButton {
	///	Allows automatic response on contentSize change (dynamic type)
    @IBInspectable
    var adjustsFontForContentSizeCategory: Bool {
        set {
            self.titleLabel?.adjustsFontForContentSizeCategory = newValue
        }
        get {
            return self.titleLabel?.adjustsFontForContentSizeCategory ?? false
        }
    }
}

for that option to appear in Interface Builder.

For buttons, also make sure to use greaterThanOrEqual height constraint:

Final tip for today: IB does not have easy ability to setup rounded corners that are so prevalent in many designs, especially for buttons and various containers. Thus many devs resort to using this in code:

textView.layer.borderWidth = 1
textView.layer.borderColor = UIColor.lightGrey.cgColor
textView.layer.cornerRadius = 4

You can use runtime attributes for this, in the Identity panel (rather strange place for it):

The code above is almost always followed by this file as well, to actually have those rounded corners rendered:

textView.layer.masksToBounds = true

This line is also not needed as the same thing is achieved by simply setting “Clips to bounds” on View subsection in the Attributes panel.

One solution for 90% of Auto Layout exceptions

Sun, 15 Oct 2017 10:49:40 +0000

How many times have you seen this output in Xcode console:

(
    "< NSAutoresizingMaskLayoutConstraint:0x60c00028d5c0 h=-&- v=-&- _UIVisualEffectContentView:0x7faa9f7054e0.width == UIVisualEffectView:0x7faa9f705090.width   (active)>",
    "< NSLayoutConstraint:0x60000028eb50 UIView:0x7faa9f7056e0.trailing == UISegmentedControl:0x7faa9f1607d0.trailing   (active)>",
    "< NSLayoutConstraint:0x60000028ebf0 UIView:0x7faa9f7056e0.leading == UISegmentedControl:0x7faa9f1607d0.leading   (active)>",
    "< NSLayoutConstraint:0x60000028ec90 UISegmentedControl:0x7faa9f1607d0.leading == _UIVisualEffectContentView:0x7faa9f7054e0.leadingMargin   (active)>",
    "< NSLayoutConstraint:0x60000028ece0 _UIVisualEffectContentView:0x7faa9f7054e0.trailingMargin == UISegmentedControl:0x7faa9f1607d0.trailing   (active)>",
    "< NSLayoutConstraint:0x60000028f460 H:|-(0)-[UIVisualEffectView:0x7faa9f705090]   (active, names: '|':UIView:0x7faa9f704eb0 )>",
    "< NSLayoutConstraint:0x60000028f4b0 H:[UIVisualEffectView:0x7faa9f705090]-(0)-|   (active, names: '|':UIView:0x7faa9f704eb0 )>",
    "< NSLayoutConstraint:0x60c00028cdf0 'UIView-Encapsulated-Layout-Width' UIView:0x7faa9f704eb0.width == 0   (active)>"
)

Here’s another, much simpler example:

(
    "< NSLayoutConstraint:0x608000291990 H:[UITableView:0x7f8207122000]-(8)-|   (active, names: '|':UIView:0x7f8206c3f9c0 )>",
    "< NSLayoutConstraint:0x6080002919e0 H:|-(8)-[UITableView:0x7f8207122000]   (active, names: '|':UIView:0x7f8206c3f9c0 )>",
    "< NSLayoutConstraint:0x600000294be0 'UIView-Encapsulated-Layout-Width' UIView:0x7f8206c3f9c0.width == 0   (active)>"
)

Or another variant:

2017-10-11 12:39:44.819705+0200 Stage[7072:165152] [LayoutConstraints] Unable to simultaneously satisfy constraints.
	Probably at least one of the constraints in the following list is one you don't want. 
	Try this: 
		(1) look at each constraint and try to figure out which you don't expect; 
		(2) find the code that added the unwanted constraint or constraints and fix it. 
	(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "< NSAutoresizingMaskLayoutConstraint:0x60c00068cd50 h=--& v=--& Stage.LoadingView:0x7fe7ae499850.width == 0   (active)>",
    "< NSLayoutConstraint:0x600000687b20 UILabel:0x7fe7ae499c50'Please wait...'.centerX == Stage.LoadingView:0x7fe7ae499850.centerXWithinMargins   (active)>",
    "< NSLayoutConstraint:0x600000680960 UILabel:0x7fe7ae499c50'Please wait...'.leading >= Stage.LoadingView:0x7fe7ae499850.leadingMargin   (active)>"
)

Will attempt to recover by breaking constraint 
< NSLayoutConstraint:0x600000680960 UILabel:0x7fe7ae499c50'Sačekajte...'.leading >= Stage.LoadingView:0x7fe7ae499850.leadingMargin   (active)>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.

I left the hints Apple developers output only in the last example, since it’s always the same text.

So, what’s the issue here and how to solve it?

No, it’s not that…

Tricky red herring:

(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, 
refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)

In my case at least, it’s never that – I have enough experience that I rarely forget to set this:

view.translatesAutoresizingMaskIntoConstraints = false

…it’s actually this

"< NSLayoutConstraint:0x600000294be0 'UIView-Encapsulated-Layout-Width' UIView:0x7f8206c3f9c0.width == 0   (active)>"

plus your constraints. UIView-Encapsulated-Layout-Width and its counterpart UIView-Encapsulated-Layout-Height is an internal UIKit thingie that’s outside your reach. You can’t control it, you can’t access it, you can’t override it.

This is the constraint used by UIKit to control the outside size of the views where you as non-Apple developer work in. For instance on UITableViewCell, where actual width and height is set internally by UITableView. It’s found on their container views, like when you setup your view as say UITableView.backgroundView.

That’s exactly what’s happening here:

(
    "< NSAutoresizingMaskLayoutConstraint:0x60c00068cd50 h=--& v=--& Stage.LoadingView:0x7fe7ae499850.width == 0   (active)>",
    "< NSLayoutConstraint:0x600000687b20 UILabel:0x7fe7ae499c50'Please wait...'.centerX == Stage.LoadingView:0x7fe7ae499850.centerXWithinMargins   (active)>",
    "< NSLayoutConstraint:0x600000680960 UILabel:0x7fe7ae499c50'Please wait...'.leading >= Stage.LoadingView:0x7fe7ae499850.leadingMargin   (active)>"
)

I have a simple view with the UILabel x-centered within margins and with both sides of label set to be >= of its superview horizontal margins.

Those margins are 8pt, so my LoadingView requires at least 16pt wide container, in the edge case where label.text = nil. However, in this particular moment, UITableView has its width set to 0:

< NSAutoresizingMaskLayoutConstraint:0x60c00068cd50 h=--& v=--& Stage.LoadingView:0x7fe7ae499850.width == 0   (active)>

which causes this Auto Layout exception.

Why?

Label’s both leading and trailing constraint have priority = 1000 plus the center-X-to-superview constraint is also set to priority=1000. Thus all 3 must be obeyed, which requires a minimum of 16pt-wide container which can’t fit into 0-width specified by UITableView, hence ka-boom.

“But everything looks fine on the screen, UITableView is not 0-width” I hear you say. Yes, that’s true - at the end of transition that happens while this particular view is being shown. But for way too brief moment, UITableView was 0-wide sometime along the way and that caused the error output.

Solution? Give the Auto Layout some degree of freedom.

By settings both leading and trailing constraint’s priority to 999, you allow Auto Layout engine to temporary ignore the margins.

That’s my greatest Auto Layout trick:

set priority to 999 for half of your constraints in horizontal and/or vertical dimension

Here’s another example, with self-sizing UITableViewCell:

Label showing actual date value is bottom aligned to superview’s margin thus requires at least 8pt at the bottom. It’s also baseline-aligned to the Date label next to it, from where there’s constraint chain that goes up the vertical axis right until the ID label’s top aligned to superview’s top margin. Plus I have set both Date and ID label’s compression resistance to 1000.

When you do insertRows or deleteRows with certain animation types, UIKit will animate the row height from 0 to full height or back. At the 0-end of that animation, the layout equations are impossible to solve if entire vertical axis is set to priority=1000. But lower just one constraint to 999 – say that bottom space to superview margin – and all is fine; the content will just drop-down, outside the cell’s bounds.

Hence the promised one solution to most of your head-scratching Auto Layout issues: for every view you add that has a connection to a superview that you do not control, make sure that one side of that connection has priority less than 1000. I usually set trailing and bottom constraint to 999 + make sure that the said superview has clipsToBounds=true.

Happy layout-ing.