to Stanford CS193P. This is spring quarter of 2016, and

this is lecture number 2. And today, we are going to talk

about MVC, okay, I'm gonna try and really briefly cover that

because I know only about half of you know what MVC is, and

it's a very important part of doing any iOS development.

And then after I'm done with that, I'm gonna continue

the demo from last time, we'll use MVC and learn yet

some more things about Swift and Objective C, all right?

All right, so MVC, what is it? As I mentioned last time, it's

essentially a way of dividing up your application or

your source code into three different camps,

okay? The three camps pictured here are the model camp.

The model camp is what your application does. Okay,

nothing about how it's drawn on screen or

anything like that, okay. It's not how it's displayed,

it's just what it is. So for a calculator app,

what it is it's a calculator, so the model is probably gonna

be the part that does calculating,

okay. Next piece is the controller.

The controller is how your model is displayed on screen.

Okay, it's kind of the how. This is basically all your

UI logic, goes into your controller, all right? And

the view, you can think of as your controller's minions,

okay, the things that the controller's gonna use to put

things on screen. So that's buttons and labels and

tables and all those kinda things that the controller

needs to display what's in the model and

to get input from the user to update the model as well,

okay? So those are the three camps.

Now it's one thing to decide where things go

based on the description of the camp, but a really

important piece of it is the communication between camps,

what's allowed, what's allowed, what's not.

And when communication is allowed, how do you do it,

okay, in iOS? How, how is that communication facilitated?

So, to help with this, I've kind of, drew, drawn here this

little Y in the middle. It's kinda like road signs, okay?

It's like double yellow at the bottom there is don't cross.

And then solid white is yeah, you can cross, but

you're not really supposed to generally do this without

being very careful.

the traffic is going in the same direction, so

you can pretty much crossover.

Probably wanna put your turn indicator on,

but off you go. Okay, so let's talk about how that works for

these three camps. First let's talk about controller talking

to the model. The controller can talk to the model all it

wants. It knows everything about the model.

It can send any message it wants to the model.

The controller is in complete control of the model. Okay,

and the controller needs that because the controller's

job is to present what's in the model to the user or

to get information from the user and update the model.

So it needs full control, so that's a full green arrow,

dashed white road sign, road line there can do anything at

once. Same thing on the other side, the controller obviously

needs to be able to use its minions however it wants to

display the model. And most of the time, the connection

between the controller and its minions is via an outlet.

And you remember we had an outlet on Monday, right?

It was the display?

You remember that, it was a var instance variable.

Display with an optional UI label. And that connection is

how the controller was talking to it's view.

That label, that UI label was part of it's view.

It was a minion in it's view. So that's

full green communication, kind of do whatever it wants,

controller knows everything about both sides.

It has to. Let's talk about the model in the view.

Those never speak to each other. Why is that? Simple,

the model is UI independent,

so there's absolutely nothing it has to say to the view,

which is completely UI dependent,

that's all the view is. The view is just the minions

of the controller. And so, you know, it makes no sense for

these two to talk to each other. So that fire, that's

double yellow line, don't ever do that in this class, okay?

No communication there at all. Okay, all communication in

the model, in the view goes through the controller.

All right, what about from the view to the controller?

Can the view, like a label and stuff like that,

talk to its controller? Well, yes and

no. The problem with the view is all the minions

in there are generic objects like UIButton or UILabel.

Those were written by Apple years ago.

They know absolutely nothing about a calculator.

So there's way to kind of for them to talk to a calculator

and know it's a calculator. Okay, so there's limited

communication between the view and the controller. But

off course the view needs to talk to the controller because

it's the controller's minions and things happen in the U.I.

and need to tell the controller what's going on so.

The kind of communication we have there has to be blind and

structured.

Blind meaning the objects in the view don't know what class

they're talking to. 'Kay?

Cause view, buttons don't know anything about calculator view

controllers. And it's structured because

since there is no knowledge of the Objects on either end.

They have to communicate in a well-defined, pre-defined way,

okay. So let's talk about some of those structured ways that

the view minions talk to the controller. One of them

you learned last time is target action, okay. So

target action's very simple, the controller hangs a target

on itself by defining a method with at sign ib action on it,

usually, in Xcode, so

that little dot will work, okay. And

then the view when it wants to talk to the controller simply

calls that method and that connection. Okay.

The action being sent, from the view controller,

is wired up usually with control drag. You saw us do

that. It can be done in code. But 99% of the time we control

drag to create this target action connection.

So there's an example. Very simple communication between.

Menu in the View like the UI button and the Controller,

the other method. Okay? Simple one. All right, what else,

what other kind of communication we had

besides Target action? Well, sometimes the View needs to

communicate something a little more complicated than just

I was touched or something like that. Okay. For example,

it might be a school view, that's a generic view minion.

And it might need to tell the controller,

hey, this guy just started scrolling. Okay.

Or the person zoomed into this zoom scale. All right.

So let's notify the controller cuz the controller might need

to know that and react to that, okay.

Maybe it effects the model when you zoom in or out.

Also maybe the view like the scroll view needs to make sure

it's okay to do something, like if the scroll view says

should I allow vertical scrolling right now?

Maybe it wants to ask the controller that. So you have

a lot of messages that have words in them like should,

will, and did, okay? That the minions wanna ask

questions of the controller involved with controller.

Okay? So, [COUGH] This is done via what's called

a delegate. And we're gonna talk about delegation next

week. And the word delegate is appropriate here because

it's essentially the view's minions are delegating

some responsibility to the controller Okay. The way this

is implemented is very simple. Delegate, the delegate is just

a property in the view and that property,

you might ask, what's the class of that property,

because the view doesn't know anything about the calculator

view controller. The answer is, it's not gonna be a class.

It's going to be what's called a protocol. Okay, and

we're gonna talk about what protocols are.

Protocols are basically just a description of a bunch of

methods that the other guy promises to implement. Okay,

and so if you can imagine if the controller

would promise to implement these will, should, and did

things, then the viewer could talk to it even if the view

doesn't know what class it is. Okay, no similarly There's

an important aspect of MVC which is the views,

okay, the view can not own the data they are displaying. Now,

how are they going to display it if they don't own it?

Well, they're going to ask for it from the controller all

the time and the controller is going to get it from

the model. Okay, so that's another kind of protocol but

instead of will did and

should you've got messages in that protocol like give

me the data at this location and how many pieces of data

are there, okay? Things that are asking about the data so

the viewer can figure out what's going on and

display it, okay. And that's also done with delegation,

although we call that Delegate the Data Source. Okay, so

there'd be another property on some views called

the Data Source, which is this protocol based pointer,

basically, to another object and

the controller sets itself as that so it can get involved.