[ Music ]
>> Stanford University.
>> Alright, so welcome
to Stanford CS193p,
fall of 2013-14 academic year.
This is our very first
lecture and we are going
to be covering developing
applications
for iOS, so specifically iOS7.
Today's lecture kind of has a
first part and a second part.
The first part is a
little bit of logistics.
The second part is I'm
going to dive right
into the course material because
there's a lot to cover and so,
we need to start covering it.
[Pause] So, what will
I learn in this course?
I think you know what you're
going to learn in this course.
You're going to learn how
to build cool apps, okay?
iOS is a really cool
platform for building apps,
you probably already know that.
The apps look cool,
they've got animation.
What's really cool is
they're in your pockets
so you can whip them out and
show them to your friends.
You don't have to send them to
a website or go get a computer.
It's also really easy to
develop really powerful apps
in a really short amount of
time, as you're going to find.
This course is only
10 weeks long,
and while this is Stanford,
I know, you're all really,
really good programmers
and all that, it still,
10 weeks is not a lot of time,
so when we get to the end,
you're going to see that it's
a very leveraged platform
for building things.
And, you know, the
community is quite vibrant,
being able to distribute
your apps via the app store
and not have to put them in
a box and put them on a shelf
in a store, is really a big,
big difference when it comes
to marketing a product.
Okay? And you'll,
you'll see that.
The second thing
you're going to learn
in this course though is
real-world application,
a lot of the computer
science things you're learning
in other classes.
Okay? So, we're going
to be doing networking,
we're going to do multithreaded,
we're going to be doing
all kinds of graphics,
we're going to be
doing animation,
we're going to do
object-oriented databases,
we're going to do all
that stuff for real, okay?
You're going to see
what it looks
like to apply all those computer
science concepts, especially how
to combine them into
a real-world platform,
where you're making
real apps, okay?
And quite a few, many dozens
of my former students
have shipped their apps
on the app store and
you may well too.
Okay? So this is really, this is
a good course to kind of combine
or synthesize all of the
things you've learned in a lot
of your other computer
science classes and touch it
up against the real world.
Okay? The prerequisites for this
class are super duper important,
okay?
This, it's just key to make sure
you have these prerequisites
and really think long and hard,
if you don't, whether you want
to give this class ago.
CS 106 A&B or, or CS16x are
absolutely required, okay?
If you don't have that or
equivalent, definitely,
don't even think about it.
The second requirement
I've added this quarter,
based on experience, is CS107
or CS108, which is great,
by the way, if you're
taking CS108,
you'll really be
ready for this class.
Or even CS110, and part
of the reason I'm requiring
these extra classes is just
so you're farther along the
programming experience curve
because this class is a lot of
programming, and so for those
of you who are used to
a lot of programming,
you, you're used to it.
But for those of you who
aren't it's kind of like, whoa,
do a lot of programming here.
It's going to be a
little unbalancing.
So, that's why I've
required all those.
Now if you've done
a summer internship
of you've done some programming
or something like that,
that's definitely a substitute
for CS107, 108, or 110, right?
Or if you've done some other CS
class that's even more advanced
than these, that's fine too.
You've just got to understand
that this class is, you know,
a programming class,
there's a lot of programming.
And most importantly, you
got to really be comfortable
with object-oriented
programming.
So I put a bunch of terms
up here, like message
and instance variable and
superclass and subclass,
if you don't know these terms
like the back of your hand,
it's going to be hard for
you to get this class,
because I'm going to
be throwing those terms
out left, right, and center.
iOS7 is completely
object-oriented.
Okay, the whole structure,
the design of the thing,
is object-oriented.
So, you just got to know that,
and if you don't know that,
you definitely want
to go get that first.
Okay? Take CS106a&b
equivalent first,
and then get a little more
programming experience
and then you're good to go.
Okay? We're going, you're going
to be writing apps in this class
with dozens of classes
that you're going to write
by the fifth, sixth
week so, you know,
if the biggest app you've
ever written is got 3, or 4,
or 5 classes in it, oh, this
is going to be a step up.
Okay? The assignments, we've
got this weekly assignments
for the first six
or seven weeks,
and then you've got a
final project at the end.
All of the homework assignments
have detailed write-up
of the required task and
what we're evaluating you on.
And they also have hints in
there, because I'm not trying
to make the homework assignments
be really, really hard,
and all the homework assignments
also directly are re [pause],
they're basically reinforcing
what has been taught in lecture
in that week, they're
not a bunch
of random new stuff to learn.
I'm a big believer in a teaching
methodology, which is I'm going
to tell you about a concept,
via slides, and then I'm going
to show you it by
demoing it to you,
actually writing an application
that does, then I'm going
to ask you to do
it on the homework.
So that's three times
you're going
to see every single thing
pretty much in this class.
By the end of that, you're
going to know how to do it.
Okay? And you're going
to feel confident
and experienced to do it.
So the homework is
all about that.
It's about just doing what you
saw me do in class and talk
about in class and apply it.
Alright. Now I'm going to really
briefly go over what's in iOS,
I think most of you
know what's in iOS,
hopefully you've all seen an
iOS device or you have one
in your pocket, I bet 90
percent of you do in this room,
but I'm going to try
and summarize it,
this is really hard to do
because I'm going to try
and do it in four minutes
or less, or five minutes,
and it's so big that, I mean,
I could have two lectures
where I just talk about
all the different things
and just summarize them.
So, this is going to try and
group them into some sort
of sensible groups so you
have an idea of what's there
from a development
standpoint, then when we go off
and start doing it all then
you'll start realizing whoa,
and once you learn how to look
in the documentation you'll see,
oh, look at all that stuff in
there, and you'll figure it out.
So this is just a
high-level overview.
So, I, I've used this division
into these four, kind of groups.
Core OS, which is the stuff
that's close to the hardware.
Core services, which is an
object-oriented on top of that,
that kind of makes it
so you always are programming
an object-oriented layer.
Media, because these devices
are basically iPods with a phone
in them or with a
big screen on them,
but media is really
important to these devices,
and then finally Cocoa
Touch, which is the UI layer.
Okay? Of buttons and all the
switches, things like that.
So let's talk about what's in
each of those layers, kind of,
little skimming the surface
of what's in those layers.
At the Core OS layer, near the
hardware, is a Unix kernel.
Okay? This is a Unix operating
system on this device.
And BFD-based mock, and so
you get everything you get
with Unix.
You're getting sockets and
you're getting file system,
permissions, all that stuff,
plus you're getting a bunch
of other stuff that's kind of
specific to a mobile device
like this, like power
management, and key chain access
to kind of manage the
security of things.
Bonjour, which is
this kind of network,
finding other things
on the network.
So it's got all that stuff,
it's a very powerful
underlying operating system.
But all of that API
or most of it is in C,
and we want to be
programming kind
of purely object-oriented layer.
So we're going to be mostly
operating when we're talking,
touching those things at
the Core surfaces layer.
So this layer has things
like language, things that,
that kind of make the language
more powerful, like arrays
and dictionaries, and
strings and things like that,
plus it has object-oriented
ways to access the file system,
it has object-oriented ways
to find out the GPS location
of your device, for example.
It has ways to do
multithreading.
All this stuff what you want
to be able to do, but you want
to stay in an object-oriented
kind of mindset
as you're doing them all.
There's a huge layer,
foundational layer there
at Core services for doing that.
At the media layer, don't
sleep on this layer,
really important layer,
you've got video here,
you've got video editing,
you got images, of course,
that it can display, it's
incredibly powerful audio
for doing 3D audio,
if you have games,
you can make the
Thai fighters feel
like they're ripping
by you and stuff.
All that stuff is in here.
This is part of, the part of iOS
that really I can't
cover in a lot of depth.
I'm just going to try and
let you know that it's there
and you're going to dive
down depending on what kind
of applications, later in
your life, you want to build.
But there's an enormous
amount there.
This is a fundamentally, a
multimedia device, obviously,
and then, Cocoa Touch
is where we're going
to spend most of our time.
This is where you are going to
be building buttons and sliders
and text fields, talking to each
other, and animation happening,
things sliding in and
out, and, you know,
fading out and fading in.
If you want to get the,
a picture from the camera
from the user, you can do that.
Things like localization
so that you're app can run
in many countries in the world
and up your sales by doing that.
A whole map kit for
doing all the 3D maps
that you've probably
seen in iOS7 and all
that stuff is all in there.
And, there's even a view
in there that's an entire web
browser in a little rectangle
that you can just plop
right into your app.
So these are really high-level
objects, and we're going
to really be diving into
this layer, alright?
So this is really the primary.
And it's called Cocoa
Touch because the API
in here was originally
developed for Mac OS X,
and it was called Cocoa, and
of course then when they went
to iOS, they adapted, and
a lot of API is shared
between the two platforms,
and, in fact,
if you develop an iOS app
and then you say someday, oh,
I want to develop an app
for the Mac using Cocoa,
it's going to be very similar.
Okay? You're going to be really,
it's going to look familiar.
So Cocoa Touch, obviously,
is the touchscreen
version of that, of Cocoa.
Okay?
This technology, Cocoa, has
been around a long time, okay?
Probably almost 30
years, believe it or not.
From even before Apple
acquired it to make Mac OS,
what is now Mac OS X, and so
it's a very mature API, okay?
And it's very well thought
out, so, especially if you go
with the flow of
it, it's very easy
to build really powerful things.
So, that's what's in there.
So let's talk about the
tools we use as programmers,
as developers, to
build these apps, okay?
And I've divided those into
kind of four sections here.
One is the tools, the
actual programming tools,
and what's great,
on this platform,
is itÃ•s pretty much
a one-tool fits all.
Okay? There's this
one tool, XCode 5,
and everything's in there.
You're debugger's in there,
all your source code editing,
your source code
control, the UI building,
everything is in this one app.
There's a little adjunct there,
instruments, which is for things
like profiling your app
and things like that.
Memory usage, those kind of
things, but you're really,
all was inside XCode 5, which is
really nice because, you know,
when you're debugging, you're
usually editing your code
at the same time, back
and forth, back and forth,
you're going to different apps
and all that would be a pain
in the neck, and they've
really done a good job
of arranging the screen
space so that it's sharing
between all these different
tasks that you need to do.
So that's the primary tool,
XCode 5, you should all,
right after this class if you
want, go to the Mac App store,
not the store on you iOS
device, the Mac App Store
on your Mac, and download this.
It's free, available,
came out last Friday,
and you can download it,
install it, and, you know,
start playing around with it.
Some of you might have already
used XCode, like in CS106,
raise your hand if you've used
XCode before for anything.
Okay, so two-thirds or
more, three-quarters of you.
So, you're going to be used it.
You're just going to
start using XCode now
to develop for iOS, alright?
There's a new language for
you to learn, objective C,
it's kind of a funny-looking
language, okay,
its square brackets and colons,
no parentheses on message calls,
which is kind of weird
for people who are coming
from Java or C++ or whatever.
The arguments are not put
in parentheses or whatever,
and I'm going to show you
all about objective C,
I don't expect you to know
anything about it coming in,
and if you know Java and
C++, which you should
if you've taken CS106A&B,
then objective C is not going
to be a big leap for you.
It's a little bit
different language,
it's a little more fast and
loose than Java, for example,
and it's a little more, kind of
simple and elegant, than C++,
when it comes to the
object-oriented stuff.
So, I think you'll like it.
It won't. Some of you
who are very, you know,
correct programming kind
of thing, you love Java,
might find objective C a
little wild west for you,
but you'll get over it.
Frameworks, obviously, any big
system like this groups all
of its objects into
libraries, essentially.
We call them Frameworks in iOS,
so there are dozens
of frameworks in iOS.
The two main ones we're going
to look at, at the beginning
of the course, are
foundation, that's where all
that core services
stuff is, like arrays
and dictionaries and all that.
And then UI kit, okay, that's
where buttons and sliders
and all those things area, so
those are the two main ones,
but, there's a whole
bunch of other ones, like,
you see the Core Data
written up there,
that's the object-oriented
database.
Okay? So we're going
to be doing that.
Core Motion, that's the
gyro and accelerometer.
Map Kit, obviously the maps.
And there's dozens more, okay?
And we'll cover as
many of them as we can,
obviously we can't do
it all in 10 weeks,
but we'll do as much as we can.
And then the last part
of developing application
in this platform is a
design strategy called MVC.
Now, this is not unique to
iOS, other platforms use MVC,
Model View Controller, as their
fundamental design strategy.
So how many people in this room
have used MVC on any platform?
Okay, so about half, so
you'll know what this is.
So, I'm actually going to
go over MVC for those of you
who haven't and I'll go
through it pretty quickly,
because it looks like most of
you, half of you have done it,
and [pause] the main
thing to see in MVC here,
for those of you who
already know what it is,
is to see how I talk about it
so that when we get into iOS
and I start saying things like
your model is UI independent,
you'll know what
I'm talking about
and we'll all be
on the same page.
So this is mostly
kind of getting us all
on the same page
terminology-wise.
So MVC, Model View Controller,
is essentially a strategy
for how to organize all the
classes in your application.
And what we do fundamentally
is we divide all the classes
into one of three camps.
The model camp, the controller
camp, or the view camp,
and what, how you decide what
goes in each of these camps,
well, the model is essentially
the what of your program.
What is your program?
So, as we're doing this
MVC talk, I'm going to talk
about our first application
we're going to build
which is a card matching game.
Okay? So we're going to build
this game, it's gotta bunch
of cards on the screen, like
playing cards, you know,
Ace of Clubs and all that,
and you're going to be able
to go choose the cards
and you'll get certain
points if the match.
Like the suit matches or the
rank matches, or whatever,
you get more points, less points
whatever, but you're doing that.
In that kind of application,
a little card matching game,
the cards and the deck,
and even the logic
for how the game is played
are all UI independent
and in the model.
Okay?
So how the cards get drawn
on screen is the job
of the controller.
So the controller is, it's job
to figure out how am I going,
you know, take this set of cards
and display them on screen,
and then animate their
movement and things like that.
Okay? That's up to
the controller.
So the controller controls
how the model is presented
on screen, and the
view, the minions,
the classes that the
controller is going to use,
kind of like the building
blocks, the Lincoln Logs,
I don't know maybe that's before
all your time, but, you know,
the things we're going to do
build our UI we're going to use
in the view, so,
the stuff that's
in the view is pretty generic.
Generic UI elements, the stuff
in the controller is very
specific to how your UI works,
and the stuff in the model
is completely independent
of how you're UI works.
Okay? So, doing MVC is about
knowing where things go,
but also about how
to communicate
between these three camps
and so I'm going to try
and summarize how the
communication works
between these camps and
I've used road markings,
you see the double yellow line
and then the dashed white line,
so that's like you're driving
in your car, try to use them
as that I have an image for
how this communication happens,
where it's allowed,
where it's not allowed.
Okay? So let's talk about the
controller talking to the model.
Okay? Going from
that side of the road
over to the model side
is a dashed white line,
in other words, you can
head right across there,
you probably want to
look before you go,
but you can go right
across, okay?
The controller has to know
everything about the model
and it has to have complete
ability to talk to the model,
use its public API
as much as it wants,
because the controller's
job is to present the model
to the user using its
view as its minions,
so it has to have this access.
So that's full, unrestricted
access the controller has
talking to the model.
This is a one-way
era, or one-way arrow,
from the controller
to the model.
And similarly from the
controller to the view,
is also unlimited communication
because the controller is
responsible for talking, using,
it's own minions, the view is
the controllers' minions to lay
out the user interface
and all that stuff,
so the controller can
do anything it wants,
I've put that little
green word outlet up there
because when we have a property
of a controller that points
into the view, we
call it an outlet.
Okay? And you're going to see
that in the demo on Wednesday,
I'm going to say oh,
let's create an outlet
from our controller to our view
so our controller
can talk to its view.
Alright? What about
this communication?
Model to view, never,
and why is that?
100 percent obvious.
The model is completely
UI independent.
So there's absolutely no way it
could talk to a view or object
or anyone in that camp.
Because the view objects are
fundamentally UI objects,
they're kind of generic,
but they're still
fundamentally UI objects.
Similarly, since the view
objects are kind of generic,
they can't be talking
to any specific model.
They need a controller to
interpret a model for them.
Okay? So there's never any
communication this way,
that's why it's a
double yellow line,
that's why these lines are red,
that's why there's fire, okay?
Never go across that line, ever.
[Pause] What about the view
talking back to the controller?
You got these generic view
objects, like buttons,
can they talk to the controller?
Well...yes, they can, but
they have to be careful
because the view
objects are generic,
so they can't really know
much about the control, so,
they can only communicate
back to the controller
in a blind way, where
they don't know the class
of the thing they're talking
to, and, in a structured way,
a way where we all agree, we're
going to communicate this way,
between the view
and the controller,
so what's an example
of a structured way?
Well one is called
target action.
So the controller basically
drops a target on itself
and then it hands out an
action, which is like an arrow,
to the view and says
to the view, okay,
when you do what you
do, like you're a button
and someone touches
you or you're a slider
and someone moves you,
send me that action.
Okay? So in this way, the
generic button, or slider,
is communicating back to the
controller, it has no idea
that it's a card game controller
or a space game controller,
it doesn't know what
kind of controller it is,
all it knows is that when
something happens in itself,
boom, it sends messages
to targets.
So that's a blind, simple,
structured way for the view
to communicate with
the controller, okay?
But what about more
complicated ways?
Sometimes the view, things
are happening in the view
that are somewhat complicated
and the controller needs
to be informed of
what's going on,
synchronizing what's happening.
And one way to think about this
is these words I put here, will,
should, and did, when the
view is kind of like [pause],
let's say on the scroll view
and I'm scrolling around,
and I want to let the,
the controller, somebody,
know that the user
just did scroll.
Okay?
Or the user puts down the
touch and is about to scroll,
I want to let the controller
know the user will be scrolling.
Okay? Or the user puts a touch
down and the scroll view wants
to know, should I allow the user
to scroll here, is that allowed?
All those things, the scroll
view itself might not have
enough logic to know the
answer to those questions,
so what it does is it
delegates the authority
to answer those questions
to some other object.
Now it doesn't know the class
of that object, all it knows is
that other object can answer
these questions, will, should,
did, this, that or
the other thing, like,
should allow scrolling,
did scroll to point,
things like that.
So those are the kind of
methods you're going to see
in these delegate protocols.
Now I know that CS106A&B do not
teach protocols, the word proto,
how many people know what
the word protocol means
in object-oriented programming?
See, very few of you, so
I will be teaching that.
A protocol is just a blind
way to talk to another object.
You're, you're going, when
I teach you, you're going
to be like, oh yeah,
I know what that is,
we didn't really call it
protocol, or whatever.
But, that's how we
do delegation, okay,
this blind communication.
Also, another important thing is
that views should not own the
data that they're displaying.
They should not own it.
In other words, it shouldn't
be a property inside of them
where that's the
truth of that data.
And the easiest example for this
is all the songs in your iPhone,
on your phone or
your iPad, right?
You might have 10,000
songs in there.
So if you have some kind of
generic list view in your view,
you can't transfer all 10,000
songs to its instance variables
and expect it to hold 10,000
songs so it can list through it.
A, that would be inefficient,
and B, that information,
those 10,000 songs
belongs where?
In the model, okay?
Because you're song
database is a model.
It has nothing to do with UI's,
just a list of songs and artists
and albums and all
that, it's in the model.
Some controller has to
look at that database
and tell a view how to
display all those songs, okay?
So, we need that
communication to happen here
and the view is displaying
some sort of list,
and you're touching down and
you're flicking on the list
and trying to see more songs,
how does that communication
happen, and the answer is,
we have another special
kind of delegate,
which we call a data source.
Now the data source doesn't
do the will, did, should,
it's going to be asking
questions like count,
like how many songs are there?
And the controller looks
in the model, 10,000.
Response to the view,
there's 10,000.
The view makes space,
internally, for 10,000 things,
it doesn't know what they are,
moves the scroll bar indicator
a little bit, so that you know
where it is, and then you start
scrolling, flipping through it,
and its start sending the
message to the controller,
give me the data at [pause]
line 150, next 10 items.
See what I mean?
And then you flick down some
more, now it's saying 250,
10 more items, and so the
controller is going back
to the model and saying give
me more, give me more data,
and it's providing it to
the view in this blind way.
So see how the view is
getting data from the model
through the controller, in this
kind of blind structured way.
Okay? That makes
sense to everybody?
So data source is just a kind of
delegate, it's a specific kind
of delegate for getting data.
So you're going to see that
there are classes in iOS
that have a data source,
and they usually
also have a delegate.
Most sophisticated classes in
iOS have a delegate, the will,
did, should kind of things.
Some of them have a data source,
it depends on whether they're
showing a lot of data or not.
Now simple data, like if I had
a view, if I invented a view
for my card game called
playing card view,
and it just has a suit and a
rank, okay, we're not going
to do count data at for just
suit and rank, we are going
to set those properties.
And so the view then would have
those, that data set in it,
but it wouldn't be
owning it, right?
The model would still be
owning the suit and rank,
the view is just getting
that data to present it.
Okay? So simple data we
might transfer to the view,
but it's merely for
it to display it.
Okay. This all adds up to
the controller's job being
to interpret and format the
model data for the view.
That's the controller's job.
And when we do our demo, I'm
going to be marking like, oh,
see, I'm writing this code,
this makes the controller
perform its job,
which is to take the model data
and put it in, and using it
to view minions, put
it on screen, okay?
That's what the controller does.
What about this communication?
Can the model talk
to the controller?
Again, obviously that's verboten
because model knows nothing
about UI, so it couldn't
possibly talk
to a UI object like
the controller.
But sometimes things
change in the model
and the controller
needs to know about it.
Okay, data changes,
a database changes
or the model is some
network database
and somebody changes something
on the network and it changes,
and the controller
needs to find out.
So, how do we do
that communication?
We do that using kind of
a radio station model.
Okay? So the model, a
radio station concept,
the model will use this concept
to essentially broadcast
information
to anyone who's interested,
okay?
And the mechanisms
for doing this
in iOS are called notification
and key value observing,
KVO we call it, and so the
model can just say, oh,
anytime something changes
in my model, I'm just going
to broadcast on my radio station
and then the controller simply
tunes into that radio station.
And it can find out
things are changing.
And when it finds out
something changes,
it's going to communicate via
its green arrow to the model,
and say, okay, give me
that data that changed.
Alright? Does that make sense?
So towards the end
of the quarter,
we'll start seeing a little how
to do notification to find out,
for example, if the data
in the database changes.
We'll get a notification,
the UI can then, you know,
the controller can then go talk
to the model to get the info.
Okay? [Pause] Some people
have asked, can a view tune
into the radio station?
They probably could, but
you probably wouldn't want
to do that.
That would probably
be a violation of MVC.
Alright, so, we do this, we
have all this nice communication
and all these rules, and we
can imagine building something
simple using this,
but what if we want
to build a big, complicated app?
An app that has multiple
screens on our iPhone
or on an iPad it's
got, you know,
three or four different
areas on screen
where things are
happening, how do we do that?
Well, we're essentially going
to combine multiple MVC's, okay?
Because you, an MVC can use, as
part of its view, another MVC.
Okay? So, an MVC, an entire MVC,
can be one of the minions
of some bigger MVC.
Okay? And by doing that
and cascading it down,
we can build more and more
complicated applications.
So, an example of this is you
might have your calendar app,
and it's showing you the entire
year, and you click on a month,
and now it shows
you a month view.
Well a month view looks a lot
different than a year view.
Month view just has all the
days and maybe some circle
that tells you where you
have an appointment on a day,
and then when you click on a
day, and now you get a day view.
Okay? And the day is
showing you the hours
and what all your
appointments are, and you click
on an appointment, and now
you get an appointment view
and it's showing the
detail of where you're going
and when it is etc. Okay?
Well each of those views, the
year view, the month view,
the day view, and the
appointment view are their
own MVC's.
Okay? But you can see how the
last three, okay, are used as,
essentially, a minion
of the top-level view,
the year view, to
show more detail.
Okay? So the year view,
you click on a month,
it's going to use the month
view MVC to show more detail,
so it's part of its view, okay?
So, you see this also in iOS
with tab bar controllers, right?
You have the tab bar, along
the bottom, I have four
or five things you can choose,
well there's some MVC at the top
who has four pointers
to four minions,
which are the four MVC's
that are each going
to appear in a tab bar, okay?
We'll be doing that,
for example,
in assignment number
two or three,
where we'll be making a
tab bar and you're going
to have to do multiple MVC's.
Okay? So, that basically
results in a picture
that looks kind of like this.
Alright? Where you got this MVC
and you see the purple
one that's
like underneath the word
together there, and it points
to three other MVC's outside
of its view thing, okay?
That's how we're
going to build this,
that might be a tab
bar controller
and those might be
the three tabs.
Okay, and each one is
its own little MVC,
completely independent,
operates on its own,
doesn't even know it's
a generic, reusable view
like thing at this point,
it doesn't even know
that it's in a tab bar.
Okay? It just knows that it's
supposed to do whatever it does.
And so it's modular in that way.
You can also see that there's no
communication between any other,
there's no other arrows,
except for some of the models.
You see some of the models are
communicating with each other,
you know, a big application
might have single, shared model.
Or, you know, the models
might be split off into pieces
to be used by sub MVC's, okay?
But that's the only kind of
communication you're going
to have there, all other
communication is either the
structured communication we saw
in the MVC or it's using MVC's
as part of the view
of another MVC.
Any question about that?
So we definitely don't
want to be having designs
that look like this, okay?
Where everybody's
talking to everybody,
we can't tell who's talking
to what, it's just impossible
to debug a program like
this and it doesn't scale.
You can't build really
big programs this way,
it just becomes impossible
to know how touching anything
would break everything, right?
So we're definitely not
going to be doing that.
Okay? Okay, so that's MVC.
No questions about that?
Alright. Onto objective-C.
So, objective C is a
strict superset of C,
so everything you can do and
see, you can do in objective-C.
Okay? And we'll do a lot
of C things in this class.
We'll do a lot of
object-oriented stuff too,
but we're going to do a
lot of C things, as well.
But, there's obviously a
few things that you want
to think differently
about because you have
object-oriented stuff added
onto a language, and we're going
to talk about one of them today,
in addition to showing you
a little bit of the syntax,
we're going to talk about
one of these different,
think differently things about
objective-C that's different
than C++ or Java,
which is properties.
Okay? And I'm not going to
read through all of this,
I'm just going to
show it to you,
but properties are basically how
we access our instance variable,
right?
Everybody knows what I
mean by, raise your hand
if you know what I mean
by instance variable?
Okay good.
So pretty much everybody.
So, we want to access the
instance data of our objects.
And, normally, in Java or
in C++, you just, you know,
have some syntax to access
them and you just access them.
In objective-C we don't do that.
In objective-C, we have
what's called a property,
and a property is
basically a setter get method
and a getter method.
And that's how all access to
the instance variable goes,
through a setter
method to set the value
and a getter method to get it.
And some people who
maybe are kind
of [pause] performance
junkies might say, oh my gosh,
every instance variable I have
to call a method to
set it or get it?
But, remember, you're building
for a user interface
system here,
when the user touches down,
that's taking million,
a million code, you know,
you're executing a
million instructions there
in that amount of time.
So, having a few extra setters
and getters is completely
irrelevant, right?
So it's the old [inaudible]
thing, right?
You don't want to optimize
things that don't need
to be optimized, okay?
You want to optimize the things
that are taking a lot of time
and accessing instance variable
turns out not to be taking a lot
of your time, so, let's
look at what it looks like,
don't get freaked out here
by seeing this syntax.
It's all new, so, it's going
to take some getting used to.
In objective-C, every class we
have and the class I'm going
to show you today is a, is
in our, essentially our model
that we're going to build for
our card game matching app.
We're going to have a card and
a deck, and we're also going
to have a subclass of
card called playing card
and a subclass of deck
called playing card deck.
Those are the four classes
that are going to be
in our model, to start.
And, so, I'm going to show you,
in today's lecture I'm just
going to show you card,
only card, and then on
Wednesday I'll show you deck
and playing card deck
and playing card.
So, every class in objective-C,
you have a header file, card.h,
and you have an implementation
file, card.m. Okay, this is just
like in C++ you might have
that h and dot c, or whatever,
this is dot m, m I guess is for
implementation, I don't know.
But it's m [laughter], and so
you have these separate things,
the difference here is
card.h is the public API.
That's what your dot h is.
It's your public API.
Card.m is your private API and
all your implementation, okay?
Don't get confused about dot h
and dot m. All dot h is your
public API, that's all it is.
It's what methods in your
class you want to make public
so that other people
can call them, okay?
So, let's see what
the syntax looks like.
In your public API, you must
say who your superclass is.
Okay? You are not allowed
to make your superclass
be a secret, okay?
It has to be public so we have
to put it in the header file,
and you can see the syntax
we use is at sign interface,
the name of our class, which
should always match the name
of the file, by the way,
card.h should always have the
interface for the class card.
And then a colon and
then your superclass.
Now the superclass of the
card class is NSObject.
NSObject is in the
foundation framework
and it's pretty much the root
class of every single class
in all of iOS, including
all the classes you write.
Okay? It's this kind of basic
class, we'll talk about it
when we talk about
foundation, but it's going
to be the superclass eventually
of every single class.
Right? Everything, eventually,
inherits from NSObject.
Now, on the implementation
side, it looks very similar,
but instead of saying
at sign interface,
you say at sign implementation
and the name of the class.
And here you don't specify
your superclass, okay?
Because you're only allowed
to specify that once,
and its public, so it
goes in your header file.
Notice that the bottom
of both of these,
little at sign end,
do you see that?
Okay, that just means that's
the end of the interface
or of the implantation.
Okay? So all of your
public API goes inside this
at sign interface
block, at sign interface,
and all of your implementation,
your private implementation goes
in the at sign implementation
part.
Now, if you import, if you have
specified your superclass here,
you have to import it.
Okay? Which is like
pound sign, include.
It's a little more powerful than
pound sign, include, in fact,
it's a lot more powerful,
as I'll talk
about in a second here.
>> But you must import it,
otherwise the objective-C
compiler won't know what
that superclass is, so
you have to, obviously,
import your superclass.
However, we don't usually,
when our superclass is
something that's in iOS,
we don't usually import just
that classes header file,
which in this case
is foundation,
we actually import
the entire framework.
Okay? Now you might say,
oh, that's inefficient.
[Pause] A huge framework,
but of course this is all
precompiled and optimized.
And, in fact, in iOS7, the
syntax for this is really to say
at sign import foundation.
That means I'm going to
use all the public classes
in the foundation framework.
iOS7 still supports the old
important foundation slash
foundation.h so you can
use that if you want.
Now on our implementation file,
we have to import our
header file, obviously.
Okay? Because our
implementation file needs
to know what we're committing to
publicly, in terms of our API,
so we have to import that.
Makes perfect sense.
We can also have private
declarations, okay?
Declarations of properties and
methods that are private inside
of our implementation file
by putting this little
at sign interface,
name of our class,
open parentheses,
closed parentheses.
Okay? And then at sign end.
So we can have a
little space here
where we can little
private declarations.
Now, objective-C
does not require you
to declare something
before you use it in a file,
you know what I mean by that?
And there's a lot,
a lot of languages,
you have to declare a method
before you can call it, right?
But you can do it out
of order in objective-C,
you can implement a
method here that calls,
you can implement
method A, calls method B,
and then method B is implemented
down here later in the file.
Okay? So you don't have
to declare method B first,
then implement method A, and
then implement method B. So,
this little private at sign
interface we're mostly going
to use for properties.
Okay? Because when we declare
a property, as you'll see,
that setter and getter
get written for us.
So let's see what that looks
like to declare a property.
So here's a simple property.
It's called contents.
So this is the content
of the card.
This is what's on the card.
So this might be ace of clubs.
Okay? And because this
is your first day,
we're going to make the contents
be very simple, just a string.
Okay? So these cards, they can
be like a flashcard, maybe,
for learning a foreign
language, maybe this is the,
the contents are the word
that you're trying to learn
and maybe it's a
flashcard of images
where this content is the name
of some image and it's up to UI
to display an image
that matches it.
Or in the case of
our playing cards,
we're going to have this be
like, literally the character A
and then the character clubs,
because there's Unicode
character clubs, so the A clubs,
that would be the content.
So this is the content of
the card, what's on the card.
And you can see that
it's an NSString star.
You see at sign property is
how we're going to declare
that we need storage,
per instance of card,
in other words every card has
its own contents, and it's going
to be a string, and so we say
property NSString star, now,
it's important to understand
that in objective-C all objects,
all of them, live in the heap
and we have pointers to them.
Okay? There's no such thing as
making an object on the stack
or anything like that, okay?
They're all in the heap.
Everyone knows what the heap is?
Any questions about that?
That's just where you
allocate free memory.
So all objects are there.
What's' really cool
about objective-C is,
objective-C will manage
all that storage for you.
It will allocate for
you and free it for you.
Okay? Now how does it
know when to free it?
And the answer is
this strong thing,
you see the word strong there?
If, your properties can either
be strong, like this one,
or weak, two things,
strong or weak.
Okay? And all pointer properties
have to be strong or weak
because the objective-C
has to know what to do
with the memory and the heap.
Strong means keep
the memory for this,
for the thing this points
to, in the heap, as long as I
or anyone else has a
strong pointer to it.
Okay? So, this is called
reference counting,
it's not garbage collection,
its reference counting.
So we're going to, the
objective-C is going
to keep track of every single
strong pointer to an object
in the heap and as long as at
least one strong pointer exists,
it's going to keep
that thing in heap.
As soon as there are no
strong pointers left,
it will free the memory
out of the heap, instantly.
Not garbage collected later.
But actually instantly,
reclaim that memory.
Okay? So this is probably new
to you, you're probably used
to like garbage collection
in Java, for example,
or explicit memory
management in other languages.
This is called automatic
reference counting
and it's awesome.
It's really very
predictable, this is much better
than garbage collection,
because, you know,
the garbage collector can
come along later and do,
wreak havoc on the performance
of your application as it goes
and collects things
from the heap.
This is very predictable,
you know exactly
when things are going
to be released,
it's when there's no
strong pointers left to it.
What would it mean
if this was weak?
Okay, if you have a weak
pointer, that tells objective-C,
okay, I have a pointer to this
thing in the heap and keep it
in memory as long as someone
else has a strong pointer to it.
But as soon as no one else has
a strong pointer to that thing,
it gets freed from
memory and this pointer,
if it was weak, gets set to nil.
Nil means this pointer doesn't
point to anything, okay?
Nil is the same as zero.
Okay? In other languages, you're
probably afraid of nil pointers.
Okay? Because you do
reference a nil pointer,
it crashes your program, right?
In objective-C, you can send
messages to nil pointers even
and it will not crash
your program.
In fact, if you send a
message to a nil program,
to a nil pointer, it will not
execute any code, obviously,
because there's no
instance there.
And it will return zero from,
if that message had a return
value, it'll return zero.
So you have to be a
little careful of messages
that return structs, okay,
but as long as it returns a
primitive type or a pointer,
it'll just return zero.
So, this is going to
take getting used to.
The fact that we are
going to program knowing
that we can send
messages to nil,
to pointers that are nil
and that that's good.
We'll actually make our code
work nicely and we'll use
that to our advantage.
And that is definitely going to
be a change for you who are used
to if pointers not nil,
then send message
all the time, right?
Protecting against crashes, you
don't do that in objective-C,
you just don't code it that way.
Okay? So, this pointer could
have the value nil, n-i-l,
which means it doesn't
point to anything.
Alright? So if you have a
strong pointer and it points
to something and then
you set it to nil,
now that strong pointer
doesn't point to that thing,
as long as no one else
points to it, you can clean
up that memory, objective-C will
clean the memory up for you.
Or if you have a pointer that
points to something in the heap,
then you make it point to
something else in the heap,
then you no longer have a strong
pointer to that other thing
in the heap and as long as no
one does, it'll get cleaned up.
Okay? And remember weak
not only cleans it up,
but it sets your pointer to nil,
because you only wanted a weak
pointer, you only wanted it
to point to that thing as
long as someone else does.
Okay? So that's the
strong versus weak.
The other thing we're
going to put
in this little parentheses
is nonatomic, okay?
Nonatomic means calling this
setter and getter that go along
with this property
is not thread safe.
Okay, so you can't
have two threads trying
to set this property
at the same time.
Why do we say nonatomic
here, why do we want this
to not be thread safe?
Because the way we do
multithreading in iOS is not
by having a single object that
multiple threads are setting on,
we usually have a separate set
of objects that are running
in another thread, like
your model, and then other,
than your UI stuff is
running in the UI thread
and they're talking
thread to thread.
Okay? So we don't need this
and not only that, what's going
to happen here when we do this
at sign property is objective-C
is going to create that getter
and setter methods
that I told you
about to set these contents
automatically for us,
and we want them
to be simple, okay?
This is what they're
going to look like.
We want them to be simple.
If we don't say nonatomic,
there's going to be all kinds
of locking code in there, right?
If you have multiple threads and
you're allowing multiple threads
to access the setter
and getter here,
then you need locking code,
and we don't want locking code,
especially if we're going
to implement the setter
and getter ourselves, which
we're going to, sometimes.
Okay? But the default here is
that we don't implement
this setter and getter,
it's automatically
in there forest.
So you can see there's
three parts to this.
There's the at sign
synthesize, you see that?
That's basically just saying
underbar contents is the name
of the instance variable
in which the property
contents is going to be stored.
Now we could say at sign
synthesize contents equals foo
[phonetic], and then contents
property would be stored
in an instance variable
called foo.
But that would be
very confusing,
so we always use underbar
name of the property.
Okay? And so that's part one,
just basically allocating
an instance variable
to store this contents property.
Then there's the getter,
that's NSString contents,
return contents, so
the dash, parentheses,
NSString contents is a method
declaration in objective-C,
the dash means this is a method,
parentheses NSString star
means this is a method
that returns a pointer
to a string,
and contents is the
name of the method.
Okay? So the name of the method
of the getter is the same
as the name of the property.
Then, the implementation
is just return
that instance variable
that we synthesized.
Okay? And similarly, the
next method is a method
in objective-C for setting it.
And, again, dash
[inaudible] method.
Parentheses void means this
method does not return anything.
Okay? That's what
parentheses void means.
Then set contents
colon, that's the name
of this method, set
contents colon.
Parentheses NSString star is
the argument to this method.
Contents is just the name of
the argument, the local name
of the variable in the
local contents, context,
and the implementation is
just underbar contents,
our instance variable
equals that argument.
Okay? So, before I move on,
does everyone understand how
these two methods are allowing
you to set and get an NSString
storage space inside your card?
Everyone understand that?
Question? [Inaudible
background question] Okay,
so the synthesize line, again,
is just specifying the name
of the instance variable
that we're going to use
to store this stuff
in, underbar contents.
It's kind of weird, you could
maybe, it might be better saying
at sign synthesize contents
to use instance variable
with name, underbar contents.
That equals, I know,
is a little weird.
It sounds like it's assigning
something, but it's just,
that's what, think about
equals as, you know,
we'll use the instance variable
with the name, underbar
contents.
So that's what the
synthesize is doing.
If you don't put the
synthesize, it's not going
to create the space in your
card instance, and it won't,
there won't be any name for
it so you can't refer to it
in your getter and setter, okay?
Everyone understand this?
Any other questions?
Okay, now, the thing about
it is, when you type the
at sign property on the
left, this gets added to your
at sign implementation; however,
you will not see it there.
[Pause] Okay?
So it's there, but
you don't see it.
Okay, objective-C is, made it
for you, but it doesn't show it
to you, but it's there,
okay, that setter method
and that setter-getter
method are there.
Okay? They exist.
And not only that, they're
public, because you put
that at sign property
declaration in your header file.
Everyone got that?
So let's look at another
couple properties just
to see the syntax a little more.
So here's two properties
that are bullions [phonetic].
Okay? There's no
bullion primitive in C,
so objective-C has to find,
typedef all caps BULL,
probably a short or
something or an int or a char,
I don't know what, but you can
think of it as a primitive type,
it's a boolean, it's
value can either be yes,
which is some non-zero
value, or no which is zero.
And these properties don't
need the strong or weak.
Do you understand why that is?
Because they're primitive types,
they're not stored
in the heap, okay?
They're just a int or a float,
so there's no memory to manage
so you don't need to know
about strong and weak pointers,
there's no pointers
involved here,
this is just a BULL, a bullion.
So there's no strong or weak,
but we still have the nonatomic,
because we still want the setter
and the getter to be simple,
not having any locking code
or any of that business.
So we're always going
to have nonatomic
on every property in this class.
We will not have a single
property in this entire class
that is not nonatomic.
So just put it in there, I
wish it were the default.
Okay? So that's what
we're going to do.
You can see we've
synthesized them both
and we've got the setter and
the getter for them both,
and this is all being done
for us by objective-C.
Now, one thing that's kind of
cool is we may not like the name
of this getter, because we
want our code to read something
like if card is chosen,
then do something.
If card is matched,
then do something.
So we really want the
getter called is chosen,
not just chosen.
You know, if card chosen, not
as nice as if card is chosen.
So it's actually possible
to rename the getter
by saying getter equals
the new name you want.
Okay? And that's essentially
renamed it, same thing,
we'll do the same
thing with this one.
Getter equals is matched,
now that getter is
called is matched.
And I bring this up
because you're going
to see how iOS does this
with bullion properties,
it tends to rename them
to is this or has this,
depending on what
the verb there is.
Okay? And again, objective-C
is writing all this code on,
in the implementation,
but you don't see it.
But it's there.
Okay? Now, [pause]
we're going to talk
about why properties are
good and why it's better
than just accessing
instance variables directly,
[pause] in later lectures, but
the bottom-line is it's good
for doing things like
balance checking,
it's good for doing things
like when you set a property
and you want to updated the UI.
It's doing good for things
for initializing pointers.
Like that end string star
contents property is going
to start off nil.
All properties, in objective-C,
all of them, start off zero.
So for pointer, that's nil.
Okay? So that contents property,
when we create a new card,
it's going to not
point to any contents.
That cards going to be
blank, okay, it's not going
to have anything on it.
So, it's nice to use
the setter and getter,
we implement our own setter and
getter that will check to see
if it's nil, and if
it's not, and sometimes,
not with contents, but with
some properties, if it's nil,
we'll create something
in memory.
Okay? So that's another
reason you use it.
So you'll see all these
reasons why we want properties
in the next lecture basically.
Alright, so now, let's
look at a method.
Okay? Just a regular,
old method.
You've seen some methods, the
setter and getter methods,
but what if we wanted
to find our own method,
our own public method,
so I'm going
to define this method
called match.
Remember that I'm
building a model here
for a card matching game, where
I'm going to put all these cards
on the screen and the user is
going to try and match them.
Pick ones that match, alright?
So I need a match method.
A method that tells me
whether two cards match.
Okay? So, I'm trying
to make this simple,
so I've made a simple
match method
that has the following
semantics.
It takes another
card as the argument,
and it returns it an integer.
That integer is zero if the
cards don't match, otherwise,
it's an integer that is higher,
the better a match it is.
Okay? So like a really good
match might be a thousand,
but a not so good match
might only be a hundred, and,
or, or it could be one.
Now, the semantics of what
that number is, totally depends
on the cards, because we're
only going to match cards
against other cards, alright?
And we're going to find out
how good a match they are
by how that, whatever that
card class is, and we're going
to make a subclass of this
class, called playing card,
that's going to give more points
for matching the rank, okay,
than it is for matching
the suit.
Okay? But that's up
to subclasses of cards
to determine what the
point system is, okay?
So, for our implementation
of match, okay,
we're going to do a really
simple implementation, so,
first let's assume
that they don't match.
Okay, so I just made this local
variable int score equals zero,
you can see that you
can assign a variable,
actually all local
variables also start out zero,
so I don't even really
need that equals zero,
but I'm a big believer
in putting that in
if that's really, you
know, what you intend,
and in this case I intend the
score to be actually zero.
The score of this match
until I go and see
if these cards match, right?
So it's just a kind of
programming style thing here.
So, how I'm going to tell,
how am I going to tell
if this card that's been passed
in match, matches the card
that it's being sent to?
And the answer is I'm going
to send some messages, okay?
You see the open square
brackets notation there,
that's the first time you're
seeing me send a message
in objective-C, and I'm also
sending two other messages
in this one line.
Card.contents and self.contents,
you see both of those,
those are message
sends, as well.
So there's two different
syntaxes here
for sending a message.
One is open square
brackets, okay, and we'll talk
about that one in a second.
And another one is dot
notation, card.contents.
When do we use them?
We only use the dot
notation for properties.
That's how we call
the setter and getter
of properties, using
dot notation.
Okay? Now, here we're
calling the getter,
card.contents is
calling the getter
of the contents property
on the card instance.
Okay? How do we call the setter?
Exactly the same.
Card.contents, but we put it
on the left-hand
side of the equals.
Card.contents equals, now we're
calling the setter for contents.
You see? So here we're
calling the getter.
We're also calling the getter
for contents on self,
on our self.
So, in other language this
might be called this, right,
but you know what self is,
right, self is this instance
that this code is operating on.
So, we are going to compare
these two strings, card.contents
and self.contents to see if they
are equal and we are going to do
that with the NSString method
is equal to string colon.
So [inaudible] equal to
string colon can only be sent
to a string [pause], so is
equal to string can only be sent
to a string and card.contents
is a getter method
that returns a NSString,
so we're good to go, right?
We're sending is equal string
to a string, and the NS equal
to string takes as an argument,
an NSString and, again,
self.contents is a getter
method that returns NSString;
therefore, we have satisfied all
the requirements of this equal
to string and we put
square brackets around it,
and it's going to
return a bullion is equal
to string is defined to return
a bullion whether the contents
of those two strings
are the same.
Notice we did not
say equals equals.
Okay, we did not say
card.contents equals
equals self.contents.
Because we'd just be
impairing the pointers then,
not what the pointers
point to, okay?
Everyone understand why we
didn't use equals equals to see
if those two strings
are the same?
So if those strings
are the same,
I'm going to give
one point, okay?
So this is either the dirt
simple implementation of match,
which is if the cards
are exactly the same,
their contents are
exactly the same,
I'll get one point,
otherwise I get zero.
Okay? Now we're going to do much
better implementation in match
when we do playing card,
but this is our kind
of dirt simple one.
Now, to give you just a
little more about objective-C,
what if we changed this
method, oh, so, yeah,
here's a little bit
about who's the sender
and who's the receiver here.
You can look at this
in the slides later.
Okay? But I'm going to make
this a little more complicated.
I'm going to make the argument
to match be an array of cards.
Okay? So now I'm matching this
card that I'm sending this to,
to a whole bunch of other cards.
So now I'm going to need some
new algorithm to match, right?
So, again, a playing card match,
if let's say you had
matching three cards,
you might give a lot of points
if all three cards are the
same rank, they're all jacks,
you get a lot of points.
If only two of them are jacks
and the other one
is something else,
well you don't get very
many points at all.
If they're all through
the same suit,
you kind of get a medium amount
of points, you see what I mean?
So, here I'm changing
match to take an array
as the argument instead
of just a single card.
And how would I change
my implementation
to deal with that?
Well, I'm just going to put
a four-loop around my if
and iterate through
all the cards
and so this implementation,
hopefully those of you
who are quick thinkers, you
can know what this does,
this gives you one point
if the card that's
receiving this matches any
of the cards in the array.
Any, not all, any.
Okay? Now you can imagine a
lot better algorithms here.
Maybe you get one point
for every card you match
in the array or you get
two points for one match
and four points for two
and eight points for three,
you know, some sort of binary
thing, exponential point,
whatever, this is first day
of lecture, we're just going
to give one point if
it matches any, okay?
But mostly what I wanted to
show you here is what it looks
like to have an array
as the argument instead
of a single card.
So that you understand that
the argument, what the argument
to the method is and also
so I can show you
the four-loop there.
You see that four n [phonetic],
a lot of languages
have that these days.
That just basically means it's a
four-loop where it's going to go
through every object in that
NS array and assign it to card,
card is the iteration variable,
and execute that if once
for each of the cards
in the array.
Everyone understand that?
If you have a question
about that, ask?
No? Yeah? [Inaudible
background comment] Oh, okay.
That's a great question.
So the question is if I
just have that four-line,
but I said four card card,
not four card star card,
in other cards, okay?
We'd get a syntax error.
Why? Because all objects
are always pointed
to so we always have that star.
Okay? Always.
Alright? You can't have a card
not being a pointer to it,
so the, you know, objective-C
would give you a syntax error
there, it's impossible
to not have that star.
Whenever you have the
name of the class,
it's always going
to have that star.
Question? [Inaudible
background comment] Yes.
The question is,
another great one,
can I use the square
brackets to call the setter
and getter instead of
using that dot notation?
And that's a really
insightful question
and the answer is absolutely
you can, it's perfectly legal,
because that setter and getter
are completely normal methods.
There's nothing special
about them whatsoever.
Okay? That dot notation is a
nicety, syntactic sugar only.
The question is should you
use square brackets for setter
and getter, and I think
it's a matter of style.
You would definitely would want
to be 100 percent consistent,
you would never want
to mix them.
And I think most people,
most people would say
use the dot notation.
It makes it clearer, it's
a little simpler, nicer,
but, you know, you could.
In this class, please
use the dot notation just
so I know you know how
to use dot notation.
Question? [Inaudible
background comment] Okay,
awesome question again.
Gosh, you guys are so good.
Can I use dot notation for a
method that takes no arguments,
but is not a getter or a setter?
And the answer is objective-C
will warn you about that,
not give you an error,
but warn you,
and you should never
do that in this class.
Okay? That is really
not that good form,
whereas his question was
kind of like you can argue,
that one, don't do it.
Okay? So. Use dot notations
only for setters and getters.
Other questions?
Yeah?
>> How do you use a
setter with dot notations?
>> So, yeah, question is
how do you use a setter
with dot notation?
And it's exactly the
same as a getter,
it's just that you're using it
on the left-hand
side of an equals.
So card.contents equals,
you know, A of clubs,
that would call the setter of
contents, whereas, you know,
this is calling the
getter, because it's not
on the left-hand
side of the equal.
Okay? Excellent!
That's all I had today, so
on Wednesday, we will do deck
and playing card and playing
card and I'm going to dive right
into a big old demo of XCode 5
and show you how all this
stuff is actually done,
and then next week we'll
do, yet more objective-C.
Thank you very much!
>> For more, please
visit us at stanford.edu.
