[MUSIC]

Using auto layout can help you create smart, dynamic layouts.

In this workshop we're going to assume some familiarity with auto layout.

So if you're new to it, first check out the main Treehouse auto layout workshop

titled Using Auto Layout in iOS.

Today we'll demonstrate how to debug the two main issues you're likely to encounter

with Auto Layout.

First, we'll discuss unsatisfiable constraints.

This is when a view has conflicting constraints and

can't satisfy them all simultaneously.

We've basically created a game of musical chairs.

When the music stops, or rather at compile time, one of our constraints

isn't going to be applied, and we can't be certain which one it will be.

The compiler breaks the layout, removing constraints in the way it sees fit,

leaving you with a layout that probably wont look like what you're expecting.

These auto layout issues are actually the easiest to catch

because they'll be logged out in the console while running the app.

We'll take a look at this in a minute.

Second we'll discuss ambiguous layout, which is kind of the opposite case.

It's a little more difficult to identify but we'll show you how.

Ambiguous layout is what happens when the compiler has

too few constraints to draw the view with certainty.

The compiler is forced to pick values at random for the missing constraints.

And again, we're rolling the dice and could get a layout that's undesirable.

So lets take a look at a demo project with a few examples.

First, we'll create a single view project.

We'll call it debug auto layout.

[SOUND] In the ViewController.m,

we'll add a subview to it in ViewDidLoad.

We'll write UIView subview =UIView new.

Next is a very important step.

If you're going to be writing your auto layout in code, as we will here,

then usually you'll want to write subview.translatesAutoResizingMasksIntoCo-

nstraints = no.

iOS defaults to yes, which means that it converts a view's auto resizing masks

into constraints, as the name implies.

Forgetting to set this value to no is a common way for your views to end up with

extra unwanted constraints, likely causing unsatisfiable constraints.

Let's also set subview.backgroundColor = UIColor greenColor.

Then, we'll add the view as a subview with self.view addSubview: subview.

Next, we'll write our constraints.

We'll use visual format here since they'll be pretty simple.

We're going to pin our subview to its superviews edges with 30

points of padding.

We'll write self.view addConstraints, then build our array

of constraints with NSLayoutConstraint constraintsWithVisualFormat.

We'll add H to specify horizontal, |-

30 in parentheses to specify 30 points of padding.

Our subview in brackets, then

30 pixels of padding on the right side, and finally, the pipe.

We'll set options to zero, metrics nil, and

views NSDictionaryVariableBindings subview.

The last view's dictionary parameter is where you list the views

used in the visual format string.

Now let's copy and paste this line and

just change the H to a V to specify the vertical constraints.

Now if we launch our app in the simulator we'll see the view drawn as expected,

with 30 points of padding around the edges.

If we rotate in the simulator, with the command left or command right

arrow hotkey, we can see that the view is drawn as expected on rotation.

Great.

Lets go back to our auto layout, and specify a width for the sub view.

In our horizontal visual format string, after subview,

we'll add ==100 in parenthesis, which sets it to 100 points wide.

If we launch in the simulator again,

we'll see the console has dumped out a whole bunch of information.

Let's have a look.

The first line says, unable to simultaneously satisfy constraints.

And it says there's probably a constraint here we don't want.

It even has a note about if you see NSAutoResizingMaskLayoutConstraints

in the list below, then you may have forgotten to set

translatesAutoResizingMaskIntoConstraints to no as we discussed a few minutes ago.

Below that is our last of constraints that we couldn't make sense of.

They're all prefixed with H.

You can also see they're all referencing the same view.

These pieces actually look a lot like our visual format strings.

But basically they're broken up to their individual constraint components.

As you'll recall, the constraints with visual format method returns an array, so,

what we're seeing here are the individual constraints generated from this method.

The first one is the 30 points of padding between the super views left edge,

and our view.

The next is the 100 point width constraint on the view.

Next, is the 30 point padding on the right edge.

Finally, we have UI view encapsulated layout width set to 375.

But have a look at its hex address in memory written next to this view.

Its different than the other.

This is probably the view controller self.view or

the super view of our subview.

In other words, its saying that the super view is 375 points wide and

the math of these other constraints for the subview just don't add up.

Our example here is pretty straightforward but your views might be complicated.

We can use these hex addresses to right of each UI view in the log message to

match them to what we've written in the app.

Let's go back to the project and make that sub view a property.

We'll add it as property (nonatomic,strong) UIVew subview.

Then, set the view we created

with self.subview = subview.

[NOISE] Next, let's add a viewDidAppear method to this view controller,

just calling super within it, and let's add a break point here.

We'll run the app again.

And it will pause here.

We've already received the unsatisfiable constraints error, just as before.

But now that we're paused in viewDidAppear in this view controller,

we can print out properties that exist in this context, like our subview.

We can do this by writing po self.subview in the console.

We can now see it hex address which matches to the UI view that's causing

constraint problems.

We can also po self.view and see its hex address, which matches the UI

view encapsulated layout width constraint, which is also what we expected.

It even defines it as the pipe.

Or the super view of our sub view.

You can also look over to the variables view, to the left, to see these values.

If the filter setting below is set to auto,

you might want to change it to all variables.

You can also right click and print description of variables in the console.

So obviously the math doesn't add up for our horizontal constraints.

We're pinning to the edges of our super view which mean the entire width

is going to be whatever that number might be, in our case 375.

If we just have the 30 padding on each side,

the subview's width is calculated to be whatever is left.

In our demo case, that works out to 315.

But if we also say the width must equal 100,

than we have unsatisfiable constraints.

The simplest solution would be to remove the width equals 100 constraint.

But other solutions are possible.

For example, we could change the left padding to be greater than or equal to 30.

Let's try this and rerun the app.

As you can see, we no longer have conflicting constraints, and

the layout is different.

When we rotate, the bar stays pinned to the right adjusting the padding on

the left since we specified it as greater than or equal to 30.

Next, let's go back to our horizontal visual format string and

remove everything to the right of the subview right bracket.

[SOUND] We'll also remove the greater than or

equal from the left padding and

remove the 100 point width constraint on subview.

So now all we're really writing is a single horizontal constraint.

Pin subview to the super view's left edge with 30 points of padding.

If we run the app you'll notice that we don't even see the view.

This is likely a case of ambiguous layout.

We haven't specified enough constraints for

the compiler to draw our view with any certainty.

It's most likely just drawing our sub view with the width of zero,

since we never gave it a specific width and didn't pin it to the right edge.

We only specified the 30 point left padding.

In Xcode, hit the pause button next to the break point button.

This pauses the program.

In the console, we'll write po, again for print out, UIWindow

keyWindow_autoLayoutTrace and hit enter.

The debugger prints out our current view hierarchy starting at the key window

for our app.

Our app is pretty simple, just a UI window,

a UI view nested in it, which is our view controller's view,

then some layout guides, then another nested view which is our sub view.

To the right of its hex address, it says, ambiguous layout for

UI view, then a text address, then width.

Okay, so this is useful.

It's saying that it can't determine the width of our view.

Instead of width, you might see min x or

min y indicating other relevant positioning values on the view.

If we want to confirm that this is the view we think it is,

lets put our break point back in viewDidAppear, then launch the app.

We'll print out our auto-layout trace again which you can do easily by pushing

the up arrow then enter to get to the last command.

Then type po self.subview We can compare the hex addresses of our subview and

the view in the autolayout trace and see that they match.

So now we know we need to supply additional information about

the horizontal layout on this view so

that the compiler can determine its width properly.

We can pin the right edge to its superview or add a constant width to subview.

These two solutions will both remove the ambiguous layout but

each has a different result.

Let's give subview a constant width at 100 points with == 100 after subview.

Now lets remove our break point and relaunch the app.

We'll again pause while on our view, print out the auto layout trace,

and see that we no longer have ambiguous layout.

Great.

Here are some final thoughts.

To display without ambiguity, the general rule of thumb is that each

view needs two constraints vertically and two constraints horizontally.

If you isolate your thinking to just one axis at a time,

this starts to make a little more sense.

Let's just think horizontally for a second.

You can pin the left edge of something, and the right edge to something.

That would be two constraints.

The dynamic element is the width in this case or

you can pin to the left edge and set the width.

Again, two constraints and

in this case the right padding is calculated dynamically.

You could also pin the views center X to its superview center X for

the first constraint, then set its width.

That's two constraints, and the left and right padding is calculated dynamically.

You can even pin the center X to the superview center X,

then just set the left padding.

That one might take a little more thinking to get your brain around.

Since we're pinning the view's center and we have a distance from left

edge to center, the compiler can extrapolate its right half.

So at least two constraints per axis is a good sanity check when writing

your layout.

Just remember that if you have more than two, you should probably have some

other rules or conditional logic in there, such as greater than or

less than statements, to prevent unsatisfiable constraints.

Hopefully these auto-layout debug tips will help you keep those

UI designs happy and healthy.

Thanks for watching.