Stanford CS193p: Developing Applications For iOS Spring 2016

Stanford CS193p
Developing Applications for iOS

Spring 2016
CS193p
Spring 2016
Today
MVC
Object-Oriented Design Pattern
Continuation of Calculator Demo

Computed Properties, MVC, Laying out the UI to work with different devices
CS193p
Spring 2016
MVC
Controller
Model View
Divide objects in your program into 3 “camps.”

CS193p
Spring 2016
MVC
Controller
Model View
Model = What your application is (but not how it is displayed)

CS193p
Spring 2016
MVC
Controller
Model View
Controller = How your Model is presented to the user (UI logic)

CS193p
Spring 2016
MVC
Controller
Model View
View = Your Controller’s minions

CS193p
Spring 2016
MVC
Controller
Model View
It’s all about managing communication between camps

CS193p
Spring 2016
MVC
Controller
Model View
Controllers can always talk directly to their Model.

CS193p
Spring 2016
MVC
Controller
outlet
Model View
Controllers can also talk directly to their View.

CS193p
Spring 2016
MVC
Controller
outlet
Model View
The Model and View should never speak to each other.

CS193p
Spring 2016
MVC
Controller
?
outlet
Model View
Can the View speak to its Controller?

CS193p
Spring 2016
MVC
Controller
outlet
Model View
Sort of. Communication is “blind” and structured.

CS193p
Spring 2016
MVC
target
Controller
outlet
Model View
The Controller can drop a target on itself.

CS193p
Spring 2016
MVC
target
action
Controller
outlet
Model View
Then hand out an action to the View.

CS193p
Spring 2016
MVC
target
Controller
outlet
action
Model View
Then hand out an action to the View.

CS193p
Spring 2016
MVC
target
Controller
outlet
action
Model View
The View sends the action when things happen in the UI.
CS193p
Spring 2016
MVC
target
Controller
outlet
action
should
will did
Model View
Sometimes the View needs to synchronize with the Controller.

CS193p
Spring 2016
MVC
should target
will did
Controller
outlet
de
le
g
at
action
e
Model View
The Controller sets itself as the View’s delegate.

CS193p
Spring 2016
MVC
should target
will did
Controller
outlet
de
le
g
at
action
e
Model View
The delegate is set via a protocol (i.e. it’s “blind” to class).

CS193p
Spring 2016
MVC
should target
will did
Controller
outlet
de
le
g
at
action
e
Model View
Views do not own the data they display.

CS193p
Spring 2016
MVC
should target
will did
Controller
outlet
de
le
g
at
action
e
Model data View
count
at
So, if needed, they have a protocol to acquire it.

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
ta
le
g
so
at
u action
e
rc
e
Model View
Controllers are almost always that data source (not Model!).

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
ta
le
g
so
at
u action
e
rc
e
Model View
Controllers interpret/format Model information for the View.

CS193p
Spring 2016
MVC
should target
will did
Controller
data outlet
?
count
at
da
de
ta
le
g
so
at
u action
e
rc
e
Model View
Can the Model talk directly to the Controller?

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
ta
le
g
so
at
u action
e
rc
e
Model View
No. The Model is (should be) UI independent.

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
ta
le
g
so
at
u action
e
rc
e
Model View
So what if the Model has information to update or something?

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
Notification
ta
le
& KVO
g
so
at
u action
e
rc
e
Model View
It uses a “radio station”-like broadcast mechanism.

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
Notification
ta
le
& KVO
g
so
at
u action
e
rc
e
Model View
Controllers (or other Model) “tune in” to interesting stuff.

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
Notification
ta
le
& KVO
g
so
at
u action
e
rc
e
Model View
A View might “tune in,” but probably not to a Model’s “station.”

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
Notification
ta
le
& KVO
g
so
at
u action
e
rc
e
Model View
Now combine MVC groups to make complicated programs ...

CS193p
Spring 2016
MVC
should target
will did
Controller
data
count
outlet
at
da
de
Notification
ta
le
& KVO
g
so
at
u action
e
rc
e
Model View
Now combine MVC groups to make complicated programs ...

CS193p
Spring 2016
MVCs working together
CS193p
Spring 2016
MVCs not working together
CS193p
Spring 2016
Demo
Calculator continued …
“Computed” properties (instance variables which are computed rather than stored)
switch
Functions as types
Closure syntax for defining functions “on the fly”
UIStackView
CS193p
Spring 2016

Stanford CS193p: Developing Applications For iOS Spring 2016

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Stanford CS193p: Developing Applications For iOS Spring 2016

Transféré par

Droits d'auteur :

Formats disponibles

Stanford CS193p

Developing Applications for iOS

Continuation of Calculator Demo

Divide objects in your program into 3 “camps.”

Model = What your application is (but not how it is displayed)

Controller = How your Model is presented to the user (UI logic)

View = Your Controller’s minions

It’s all about managing communication between camps

Controllers can always talk directly to their Model.

Controllers can also talk directly to their View.

The Model and View should never speak to each other.

Can the View speak to its Controller?

Sort of. Communication is “blind” and structured.

The Controller can drop a target on itself.

Then hand out an action to the View.

Then hand out an action to the View.

Sometimes the View needs to synchronize with the Controller.

The Controller sets itself as the View’s delegate.

The delegate is set via a protocol (i.e. it’s “blind” to class).

Views do not own the data they display.

So, if needed, they have a protocol to acquire it.

Controllers are almost always that data source (not Model!).

Controllers interpret/format Model information for the View.

Can the Model talk directly to the Controller?

No. The Model is (should be) UI independent.

So what if the Model has information to update or something?

It uses a “radio station”-like broadcast mechanism.

Controllers (or other Model) “tune in” to interesting stuff.

A View might “tune in,” but probably not to a Model’s “station.”

Now combine MVC groups to make complicated programs ...

Now combine MVC groups to make complicated programs ...

Vous aimerez peut-être aussi