[MUSIC]

The last feature we're going to implement in this app is probably the most

interesting.

Everything we did so far was a variation, or

level up, in some knowledge that we have already learned about.

Core data, data sources, and so on.

To implement pinched zoom and panning, we need to learn about scroll views.

Scroll views, in UI kit, while not fundamentally different from a regular

view, allow us to extend, so to speak, our views beyond the edge of the screen.

So far, unless we've used a class like UI table view, or UI collection view,

any views that we defined are restricted to the bounds of the screen,

to the screen size.

UIScrollViews lets you surpass this constraint, but it does so

in an interesting way.

So rather than just jumping right in and writing code to use ScrollViews,

let's take a second to talk about coordinate systems in views.

It's been a while since we learned about the coordinate system in iOS, so

first, a refresher.

UIkit defines a default coordinate system with the origin in the top left corner,

and axis extending to the right, and down from the origin point.

Views are laid out within this coordinate system to position and size them.

In addition to this Default Coordinate System,

which we'll call the Screen Coordinate System, an app's window and

views also define their own Local Coordinate System.

Let's look at a singe view, a view object tracks it's size and

location using a frame and bounds.

A frame is a rectangle, which specifies the size and

location of the view within its SuperView coordinate system.

A bounds rectangle, on the other hand,

specifies the size of the view within its own local coordinate system.

Let's give this views some dimensions, a width of 100, and a height of 80.

In terms of the properties we talked about earlier,

the views bounds is {0, 0, 100, 80}.

Since bounds is a rectangle, those value correspond to x-origin,

y-origin, width, and height.

What about the frame though?

Since the frame is how we talk about a view relative to it's SuperView,

that is the view that contains it, we don't have a frame here

since we don't have a SuperView, we just have the one view.

Let's go ahead and introduce a second view.

To avoid some confusion, we'll call the first one a button, so

you know which view I'm referring to.

Our new view has a balance of {0,0,120,100}.

Again, since this is a rectangle in it's local coordinate system

that means an origin of 0 0, a width of 120 and a height of 100.

Let's place the button inside the new view,

which we'll call something like GreenView.

Now in doing so, the button is now a SubView of the GreenView.

The GreenView is the button's SuperVeiw.

Since the button now has a SuperView, we can define its frame.

The button's frame, at the point that we've placed it, is {0, 0, 100, 80}.

You might have noticed that this is the same as the button's bounds.

When placed at the origin in a SuperView, a view's bounds and frame are the same.

Let's move the button around.

If we shift the button 20 points to the right, what does this change?

Since the bounds is the rectangle defined within the button's own coordinate space,

bounds hasn't changed at all by doing a translation of this view to the right.

The frame on the other hand, is now {20, 0, 100, 80}.

Since we shifted the button 20 points to the right,

it sits at an x-origin of 20, y is unchanged.

If we move the button down by 20 points, again the bounds are unchanged,

but now the frame is {20, 20, 100, 80}.

What happens if we shift the button to the right again by 20 points?

Now the button's frame now is {40, 20, 100, 80}.

Since the button's frame exceeds the GreenViews bounds,

the button is now clipped, [NOISE] and

we only see a portion of the button that is drawn inside the GreenView's bounds.

Okay, that's enough of our refresher, and

if this was new to you hopefully it all made sense.

So how does this play into scroll views?

Well if we look at our example here, the button is clipped,

because [NOISE] part of it is outside the GreenView's frame.

If we wanted to see the entire button again, we could adjust its frame so

that it's back in view.

If we decrease both x and

y origin by 20 on the buttons frame, the button would be back at its original spot.

Why does this matter, again?

Well this is one way in which we can simulate a scrolling.

So let's take a look at this example, but in the context of our phone screens.

So here the GreenView fills up the entire screen, and again, the button is only

partially visible, because [NOISE] its frame is outside the GreenView's bounds.

To mimic scrolling, we could track the user's finger movement across the screen,

and adjust the buttons' frame by the amount of that movements.

If I scroll from right to left,

I can modify the buttons' frame's origin values to bring it back into view.

Now, if that's confusing to you, and I'll be honest, this is a confusing topic.

Think of it this way.

You have a house with an object inside, and a window looking into the house.

The window represents the mainView, while the object represents a subView

of this mainView, just like the button was a subView of the greenView.

Right now, we can see a single object through the window, a chair, but

only part of it.

Much like we adjusted the buttons' frame, we can move the chair around

relative to the window's coordinates to make it fully visible.

The chair's role here is analogous to the button in the earlier example.

But there's a problem here, imagine that instead of just a chair,

this house is full of objects and we want to look at them.

If we took the approach we just did, moving the actual object into view, or

in iOS terms, modifying the frame of each view,

then to mimic scrolling we have a lot of frame adjusting to do.

So in the left corner of our room, there's a table.

To move that table into view we could push it over, thereby adjusting its frame.

But now all of the other objects are out of place relative to the table.

We need to maintain the layout we had earlier, so

we need to shift every single object in the room by the same amount.

In a complex view hierarchy, that's a lot of frame math and

adjustment that we have to do.

But there is another way, an easier way.

In the right corner of the room, there's a lamp.

If we wanted to see that lamp, instead of moving everything else in the room,

what if we moved the window over in front of the lamp?

Now I realize in the real world you can't just move a window, but bear with me.

Rather than moving every other object in the room,

by moving the window around we can see the parts of the room that we want to.

So let's try and relate this to actual views now.

Remember that each view has a frame and bounds.

Again, frame is relative to the SuperView's coordinates.

Bounds are relative to local coordinates.

So each object in this room has its own bounds rectangle, and

a frame rectangle [NOISE].

Frame rectangles are relative to the super view, so

each of them has a frame that determines where it lives in the super view space.

If the window is the main view,

then its bounds rectangle is as shown with {0, 0} in the top left.

So objects within that space have frame values relative to where this {0,0} is.

Now all of this time, we've been thinking of this window as a view that was defined

by this border, so let's modify that.

What if instead of the window, the entire wall was the view, and

the window is just the portion of the view that we see on the screen?

So far nothing has changed, except mentally we need to adjust for

the fact that a window now represents a slice of the view that we see, and

the actual view extends beyond the edges of the screen.

Let's make one more change.

Let's move this window to the top-left corner.

Since the entire wall represents the view, the window is now at x-zero,

y-zero, with some width and height.

If we move the window 20 points to the right, we're now at x-20,

y-20, and we can see a different set of objects.

What we just did was to move a rectangle around the view

within it's own coordinate space.

Since bounds is just a rectangle defined with a views local coordinate space,

all we're doing right here is modifying the main views bounds

when we move this window around, this physical window.

By moving this window around, that is by adjusting the bounds rectangle

within the main view,we can bring different objects back into view.

This is essentially how a ScrollView works.

When we add a ScrollView, we define its content size.

The content size of the ScrollView defines,

as the name implies, the size of the view that contains content.

This is also the scrollable area of this view.

Now the scrollable area doesn't affect the bounds of the view, but

it affects how large the view is.

So going back to our house analogy, the content size, or

the scrollable area of the ScrollView is the same as this entire wall.

The bounds of the ScrollView, which is our window in this example,

is the section of the scroll view that we see on screen.

When the content size of the ScrollView is larger than its bounds,

then we can scroll the view by moving or adjusting the bounds rectangle.

If the content size is the same size as the bounds, we can't scroll,

there's nowhere to go.

Now this way, if we have several subviews in our scrollable view,

rather than move the subviews around so they appear in the bounds area,

we can adjust the bounds to display different sections of the scrollable area.

Let's take a break here.

This is a lot of new information, which you've probably already forgotten or

gotten confused about, and that is totally okay.

Just rewatch this video, get a sort of general sense of it and how these parts

relate to each other, and when you're ready, join me in the next video.

Writing code will actually help cement this concept into place.