Before we resolve any of these layout issues,

we need to understand how our views are sized and positioned in the first place.

So far in the past, we've added constraints to our views, but

never fully looked at how exactly the system knows where to place them.

Let's imagine this is an apple working with a blank canvas so

far that just contains a single base view.

The origin of this view is at the top left at zero zero.

Now, we add a sub view to this view.

How do we understand the layout and size of this view,

the sub view, relative to the rest of the screen?

When we talk about the size and position of a view,

we're typically talking about it in terms of the coordinate space of its super view.

The size and layout of a view

in its super views coordinate space is known as a views frame.

And is defined by a CGRect.

CGRect is a struct.

A c struct mind you, not a swift native struct

that encapsulates information about a view's origin and size.

A view's frame is a rectangle,

the smallest rectangle, that fully encloses a view.

Why do I say a smallest rectangle?

Well, you'll understand in a second.

The origin of a view's frame is the distance from the top left

of the super view's origin.

And the size of the frame is the size of the underlying view.

In this example, the frame of our sub view is 100, 200, 200, 200.

It's important to know that frame is actually not a stored property

on the view but a computed one.

When we learned about computed properties,

we learned that they could have getters and setters.

When you set of view's frame,

it actually changes a couple of their underlying properties of the view.

What properties does changing the frame change?

Well the first is the view center.

Every view has a center property that identifies the center of the view.

But does so in its super view's coordinate space.

In this example, the view center is 200, 300.

So, center defines a view's location in its super view.

Well, what about the size?

This is defined by a view's bounds.

Bounds is also a rect, again a CGRect, with both an origin and size.

The difference between the bounds and

frame is that the bounds is a rect in the view's own coordinate space

where the frame is a rect in the super view's coordinate space.

So bounds defines the size of the view in its own coordinate space.

In this case, our bound size is 200 200,

which for now matches exactly our frame size.

The bounds' origin, which is within the view's own coordinate space is 0,0.

Right now, we're going to just ignore the bounds' origin

because it isn't used in computing the frame.

When computing the frame,

there are several properties that are taken into account.

But when you change a view's frame, it changes a view's center and

bounds property only.

Remember that frame and center are defined in these super view's coordinate space,

while bounds is in the view's own coordinate space.

Now, despite what this example may indicate, bounds and

frame are not always the same thing.

To see how they differ, let's apply a transformation to our view and

scale it down 50%.

When we apply a transformation, we don't actually change the views bounds or

its size but we do change the views frame.

This is because transformation is also used in the computation of a view's frame.

The dotted line represents our old frame.

And the new frame is now 150, 250, 100,100.

So this is a simple case that highlights how the frame differs from the bounds.

While the underlying views, size and therefore bounds is the same,

the frame that displays the actual view inside the coordinate space of its

super view is now 50% smaller around the view's center.

Okay, now what would happen if we applied a rotation to our view?

Let's rotate our view 45 degrees around the center.

Here is what it would look like.

Now, our frame is 59, 59, 282, 282.

While the bounds is still 0, 0, 200, 200.

So what's going on with the frame here?

Remember, we said that the frame is the smallest rectangle that encloses a view.

Because the view is diagonally positioned within the super view,

there isn't a one to one mapping between the frame and bounds right now.

In this case, the bounds is still the original bounds, but

the frame is completely different.

When you position a view on screen, you position it and

size it always within the super view space.

Keep that in mind.

So even though bounds and center really determine the position and size.

We primarily interact with the frame and

then let it determine how to change the underlying properties.

The only time we'll worry about actually manipulating bounds, center, and

transform properties is when we're applying transformations to our view.

So for now all you need to know is that if you want to

change how a view is positioned and

sized on screen, you're going to change the frame of the view because that is how

the view is represented in its super view's coordinate space.

Now that you know about a view's frame, let's try and

manipulate these values ourselves in code to sort out our layout problems.