add AutoLayout constraint methods

[jlandon]

Added

• New constraint methods
  • constraintWidth, constrainHeight, pinLeft, pinRight, pinTop, pinBottom, pinLeading, pinTrailing, pinCenterX, and pinCenterY
  • These constraints use the existing constraint methods, but offer a few advantages (shown below)

// Current
view.constrain(.Left, to: superview, .Left)

// New. Instead of requiring specification of both constraint attributes,
// you can simply use the corresponding `pin`/`constrain` method
view.pinLeft(to: superview)

// Current
view.constrain(.Left, to: superview, .Left)
view.constrain(.Top, to: superview, .Top)
view.constrain(.Width, to: 50)
view.constrain(.Height, to: 50)

// New. Since the new methods return `self`, they can easily be chained together
// to minimize the lines of code related to AutoLayout
view.pinLeft(to: superview).pinTop(to: superview).constrainWidth(to: 50).constrainHeight(to: 50)

Updated

• The default priority for all constraint methods is now UILayoutPriorityRequired - 1
  • Given that activating/deactivating and changing the priorities of constraints at runtime is not uncommon (and changing a constraint's priority from required and non-required at runtime is not allowed), I feel it makes more sense to default the priority argument to the highest non-required priority
• constrainSizeToFit(_:) has been moved to an extension on UIView (previously only UILabel)

[apcorc]

I'm cautious about making the default priority less than Required. You can still set active = false on a required constraint and I think having less-than-required constraints without explicitly defining them as such could cause layout bugs that are hard to detect and fix. This becomes doubly true if these methods are inter-mixed with constraints defined in Storyboard (I know @jlandon's option of that, but we need to keep in mind how other people will use this) being that they are Required by default.

[hsoi]

Hrm. I'm a little mixed on this.

It seems to be just some syntactic sugar, moving the first argument from being an argument into being part of the function name (more or less). And it also constrains (no pun intended) the user to same-side pinning -- e.g. you can't say "pin leading of X to trailing of Y". So really -- what's gained here? And now, we have a lot of API clutter. The one nice gain is return of self so you can chain, but again is there real gain here or just syntactic sugar?

I'll also second @apcorc 's reservations about the default priority.

[apcorc]

@hsoi You can optionally add a second layout attribute a la:

view.pinLeft(otherView, .Right, plus: 10)

[hsoi]

I'll say this tho... the syntactic sugar and API growth... I can live with those.

I think my bigger problem is the priority default.

[apcorc]

You can even adjust the constant of a required constraint. The only thing you can't do is reduce the priority of a constraint that has a required priority. Between changing the constant property and the active flag I think that covers the most common runtime layout changes.

[jlandon]

Yeah, that's a fair point about the default priority. I can change that back to required.

Regarding the syntactic sugar, it has been quite useful on several project lately in cutting down duplication

view.constrain(.Left, to: superview, .Left) vs. view.pinLeft(to: superview)

Sure, it doesn't save a ton of typing over the current constraint methods, but it adds up over time. And especially with fuzzy autocomplete in Xcode, it makes adding constraints that much quicker. :)

[apcorc]

I agree it has been really convenient on a few projects lately. I got used to it and now is so inconvenient when I don't have it.

👍

[hsoi]

OK, that's a winning point that I can take -- especially if it helps with the fuzzy autocomplete.

So ok: 👍