In this recipe, we're going to build a two view layout,

where each view occupies a varying width depending on the available space.

We'll have two views, a red and a blue view,

where we want the red view to be double the width of the blue view if possible.

The catch is that the blue view can't be too narrow either.

And we want to enforce a minimum width.

We'll need to use a combination of inequality relations and

constrained priorities to build this relationship.

I've gone ahead and added a file to my project named ComplexWidthViews.

And in here I have a custom UIViewController subclass.

So inside this class, we have some starter code that defines a blue and

a redView, and that's really all I've done here.

In viewDidLoad, I've set these views to have the right background colors.

And then the first thing we always want to do when setting constraints in code

is to disable autoresizing masks.

This is handled automatically in interface builder,

but it's important to be aware of this in code.

Otherwise you'll end up with constraints you didn't add,

which will break your layout.

So I've added that inside viewWillLayoutSubviews, and

then I've added the views as subviews of the root view.

So ensure you do this step every single time

before you activate any constraints in code.

Now for this layout, we won't be doing anything special in the vertical axis, so

let's get some basic constraints in place.

We'll send vertical spacing constraints of eight points to the top and bottom for

both the views.

I'm building this layout in XCode 9 against the iOS 11 SDK,

which means I can make use of the new safe area layout guide APIs.

But we also need to ensure that this builds for versions prior to iOS 11.

So we're going to use the if available syntax to target all the different cases.

We'll start by saying if #available, so if #available,

and the platform is iOS and the version is 11.

And if we're in version 11 of iOS,

then we'll use as a guide the view's safeAreaLayoutGuide.

Otherwise we'll execute some code in the else case.

In the iOS 11 case, we can use the view.safeAreaLayoutGuides,

like I mentioned.

But in any other case, prior to iOS 11, we'll fall back to the standard top and

bottom layout guides or margins.

The first set of constraints affected by this are the top and

bottom constraints on the blue view, so let's add those in.

We'll use the NSLayoutConstraint class, and

we'll call a class method activate that takes a series of constraints.

So we'll say blueView.topAnchor.constraint(equalTo:

guide.topAnchor, constant: 8.0).

We also want to add a similar constraint to the bottom anchor to space it out,

so constraint(equalTo: guide.bottomAnchor, constant: -8.0).

This time, making sure it's negative to take into account the direction.

Okay, so this is the case for the safeAreaLayoutGuides.

In the else case, we'll create another NSLayoutConstraint,

where we'll call the activate method here.

And this time, so we'll copy this constraint over, so blueView.topAnchor.

But instead of going to the guide's top anchor,

here we'll say topLayoutGuide.bottomAnchor.

And then we'll copy paste the first one, or rather the second one,

the bottom anchor constraint.

And here we'll say bottomLayoutGuide.topAnchor.

Okay, remember we're doing an 8 point vertical space constraint

on the redView as well, so we need to mimic these.

And we can simply just copy these over, I'll leave data, in here.

And then we'll paste, and here, we'll say redView for each of these.

And that should be it.

And so we can do the same right here.

Copy, paste, and we will change this to redView.

That takes care of the vertical constraints.

In the horizontal axis, regardless of the width of the views,

we're going to space them 8 points on either side.

So let's add those constraints in before we define any of the width constraints.

In iOS 11 and above,

we'll add these constraints from the subviews to the safe area.

While in versions prior to iOS 11, we'll add them to the super view.

So I will put that right here and we'll say blueView.leadingAnchor.

You can do left anchor because there's no content in here really, but

we'll just go ahead with the leadingAnchor.

And we'll say constraint(equalTo:

guide.leadingAnchor, constant: 8.0).

Then we'll do redView.trailingAnchor.constraint(equalTo:

guide.trailingAnchor, constant: -8.0).

You'll notice that I'm not adding the blueView's trailing constraint here.

And that's because safe area doesn't matter there.

Now we're going to add that to the red view, so

we can do it outside this if else clause.

Okay, we need to do the same thing at the bottom, so add a comma.

And we'll say blueView.leadingAnchor.constraint(equalTo:

view.trailingAnchor, right?

There's no layout guide here, so we're adding directly to the root view.

With a constant value of 8 points, and then finally

redView.trailingAnchor.constraint(equalTo: view,

oops, view.leading for the blue.

Make sure you correct that as well, and then view.trailing for the red.

The constant value here is -8.0.

We have one horizontal space constraint to add between the two views.

But again, since this does not depend on either the safe area layout guides or

any traditional layout guides,

we can add it to the hierarchy outside the if else block.

So NSLayoutConstraint.activate, and

this constraint is blueView.trailingAnchor.constraint(equa-

lTo: redView.leadingAnchor, constant: -8.0).

With these spacing constraints out of the way, let's focus on our width constraints.

We'll start by setting a with constraint on the blueView.

Remember when we said that while we want the blueView to adjust its size to

accommodate a growing redView, we don't want it to get too narrow.

So we're going to enforce a minimum width constraint by setting a greater than or

equal relation.

So we'll say blueView.widthAnchor.constraint, now make

sure you pick greater than or equal to constant here, and we'll say 150 points.

Now this constraint alone is insufficient information.

Now it's hard to kind of imagine this, but the blueView,

since it's allowed to grow more than 150 points, it could take up nearly all of

the available space, shrinking the red view down to a 1 point width.

And technically our layout would be satisfied.

It could also fit a wide range of widths between where we're at now, so let's say

the blue view is 150, and up to where the width allows for a 1 point wide red view.

So that's not what we want, so we need to add more constraints.

Unfortunately this is hard to visualize, like I've said.

If you've taken the interface builder version of this video,

you can see that visually.

But here we just kind of have to imagine.

To fix this, we need to define some constraints

that allows auto layout to determine a width for the red view.

With a width for the redView, we can then figure out what the width for

the blueView needs to be.

In this particular recipe,

we want the redView to be twice as wide as the blueView if possible.

I say if possible because we can only do that up to a certain limit.

In the portrait orientation, with the minimum width constraint,

there's not enough room to accommodate a redView that's twice as wide.

But that's okay, in that case,

we would want the redView to just fill up the remaining space.

But in the case that there is available space to grow up to twice as wide,

then we want it to do so.

This seems complicated, but it can be achieved with one constraint.

And instead of defining this constraint inside the array directly like we've been

doing, I'm going to assign it to a local constant, so we'll do it up here.

So we'll say, let redViewWidthConstraint =

redView.widthAnchor.constraint(equalTo:.

Now we're not going to select the constant one, we're going to look for

the method that takes a multiplier.

So we'll say equalTo: blueView.widthAnchor.

And the multiplier is 2.0, so we want it to be twice as wide as the blueView.

Let's add this constraint to our array of activated constraints, so

comma redViewWidthConstraint.

If you run the project now, the layout will still be broken.

And that's because with our new constraint, we're violating the minimum

width constraint on the blue view, at least in portrait mode.

In portrait mode, we cannot have a situation where the blue view has

a minimum width of 150 points and where the red view is twice that or 300 points.

There's just not enough space.

So the layout is unresolved.

To fix this, the last adjustment we need to make is to drop the priority

on this redViewWidthConstraint to 750, or

to make it high in the default or the predefined values.

This is why we assigned the constraint to a local constant.

We can only change priorities on a constraint after it has been created.

So we'll say redViewWidthConstraint.priority.

Now you can simply say 750 here.

But that's not what we want.

Well, we do want that, but there's an easier way.

We can simply say .defaultHigh.

So this is actually a type UILayoutPriority.

Click here, so we can go see it.

So jump to definition, priority, and

you'll see that UILayoutPriority is a struct.

And you can initialize it with a float,

which is why we were able to assign 750 directly to it.

But it also has these static properties required, defaultHigh,

defaultLow, and so on.

So we're saying defaultHigh, that avoids us being magic numbery.

By lowering the priority on the proportional width constraint,

we've effectively made it act like a less than or equal to constraint.

Since the greater than or equal constraint has a higher priority, auto layout will

first make sure that a minimum width of 150 points is enforced for the blue view.

Having a lower priority than 1000, the proportional width

constraint in a scenario of conflict is treated as optional.

Which means that along with the horizontal spacing constraints on either side,

auto layout will simply set the red view's width as the remaining available space.

This means that technically the red view can be any width

less than double the blue view's width and at most the blue view's width,

which is essentially what a less than or equal relation would define.

It is important to note however that while it might seem that way,

auto layout does not view it as a less than or equal relationship.

If we were to modify this proportional width constraint that we've defined here

to have a less than or

equal relation with the priority of 1,000, the layout will not be satisfied.

So the key here is that for our layout to work, the lower priority allows auto

layout to ignore the constraint when it cannot accommodate it.

Let us see what this looks like.

Head over to Main.storyboard, select the view controller in here.

And in the backing class in the identity inspector,

we'll switch it to what we just wrote, which is ComplexWidthController.

And let's run it.

So you can see here, in the portrait mode,

we're enforcing the minimum width constraint on the blue view.

So there's not enough space here for the red view to be twice as wide, so

we've set the blue view to 150 points.

And then the red view simply fills up whatever available space is left.

Now, if we switch to landscape orientation,

we can see how these constraints adapt.

In this view we see that the red view is double the width of the blue view.

But what's interesting, and you can't really measure it here, but

what is interesting is that the blue view is wider, as well.

Since the blue view has a greater than or

equal constraint in this orientation, there's enough room for

it to grow after the minimum width constraint has been satisfied.

Effectively what this allows auto layout to do is to take the available space

after the horizontal spaces between the views have been deducted and then allocate

two-thirds of that space to the red view and then one-third to the blue view.

When it does this, it allows the red view to be double the width of the blue view.

And after doing this, since there's more than 150 points of space available

in that one-third allocation, the blue view can grow to fit this space

since its width is defined using a greater than or equal constraint.

So here we have a complex width scenario

that was achieved with two constraints in the horizontal direction.

If you're interested in learning how to do this in interface builder,

check the notes section for a link to this video.