Name: スタンフォード - SwiftでiOS 9アプリを開発する - 2.MVCの適用 (Stanford - Developing iOS 9 Apps with Swift - 2. Applying MVC)
Uploaded: 2021-01-14T06:36:26.000Z
Duration: 1 h 21 min 13 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

Stanford University.             >> Okay, well, welcome

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

the traffic is going in          the same direction, so

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?

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,

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

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

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.

字幕リスト動画再生

スタンフォード - SwiftでiOS 9アプリを開発する - 2.MVCの適用 (Stanford - Developing iOS 9 Apps with Swift - 2. Applying MVC)

stuff

basically

constant

method