>> Stanford University.
>> Paul Hegarty: Okay.
Well, welcome to lecture
number two of CS 193P for fall 
of 2013/2014 academic year.
And today we're going to have
some slides at the beginning, 
little more talking,
and then I'm going 
to have quite a big
demo that's going to try 
and hopefully synthesize all
the things I've been talking 
about on the slides for
the first two lectures, 
which is that we're going to
start building our card game. 
Okay. This card matching game
is going to be our substrate 
for the first two weeks of
learning some Objective-C, 
learning about Xcode,
learning about how iOS hooks 
up the controller, and the view,
and the model to make a UI. 
So if you remember from last
time, we did this card thing 
that -- we did the entire card.
It was a very simple class.
Got a couple of properties --
three properties there
-- and one method. 
And that's pretty much it.
And so today we're going to
go on and do another class, 
which is a deck, okay?
The deck of cards.
And remember, that card
and deck are generic; 
they're not specific to
playing cards, right? 
A playing card, like the ace of
clubs or the king of hearts -- 
something that has
all that in it -- 
that's a playing card thing.
These are general
cards and decks. 
So this could be a
deck of flash cards, 
a deck of foreign language
words you're trying 
to learn or whatever.
So we're trying to
keep these deck 
and card classes
somewhat generic. 
So here's deck.
It should look familiar in terms
of its basic structure, right? 
We're importing our
superclasses framework there, 
and then obviously
importing our own header file 
in our implementation.
And the interface for deck is
going to have these two kind 
of fundamental methods:
One adds a card to the deck 
and one draws a random
card out of the deck. 
Okay? And the add a card to the
deck is a little bit new to you 
because you can see
it has two arguments. 
Okay? This is the first
method you've seen 
that has two arguments.
So far you've only seen methods
with no arguments or a method 
with one argument
like that -- match -- 
match had one argument
or the setters, 
they also have one argument.
So notice that when you
have multiple arguments 
and objectives, see
they're kind of interspersed 
with the names of the methods.
Okay? So the name
of this method, 
this long method is add
card colon at top colon. 
That's the name of this method.
Okay? So the at top
part is actually part 
of the name of this method.
And the arguments, like the
card that you're going to add 
and at top -- which is a Boolean
whether to add it at the top 
of the deck or at the
bottom of the deck -- 
okay, those arguments
are interspersed. 
And we'll see how you call
such a method in a moment here. 
And then draw a random
card is like a, you know, 
similar to a getter in
that it returns a value 
and it has no arguments.
But this is not a getter because
we didn't make this a property. 
And it's kind of important
to understand you could
have made this a property 
like a read-only property
or something that reads it, 
but since draw a random
card kind of does something, 
it has kind of an algorithm
to it -- a mechanism -- 
you usually wouldn't
make that a property. 
It's kind of an abuse
of a getter to do that. 
A getter is really just
setting and getting a value. 
It might have side effects, like
setting it might update the UI 
or getting it might make sure
it's initialized first -- 
those kind of things.
You're not going to --
something that does something 
like drawing a card is not
going to be a property. 
Now, if you want to have, like,
that at top argument be
optional, okay, the only way 
to do that in Objective-C --
obviously we need our
header file there -- 
the only way to do
that in Objective-C is 
to declare a new method, add
card colon with no at top on it. 
So this is a totally different
method, totally unrelated 
to the other method except
for that in its implementation 
of this other method
we're just going 
to call the other one, okay?
So in add card we're going to
say self add card at top colon, 
whatever we want
the default to be, 
which I'm going to say is no.
Okay? So just understand that,
you know, in some languages, 
like, some arguments can
be optional or you can kind 
of overload things to have
the same method name have 
different arguments.
No. In Objective-C every
method is completely distinct 
and has a distinct name.
And extra arguments are
interspersed like that. 
Okay? So these would be
two different methods. 
That make sense?
All right.
So let's talk about our
implementation of our deck. 
So our deck is just going
to contain a bunch of cards. 
We need some sort of
internal data structure 
to store all our cards in.
And what we're going do is we're
going to get a mutable array. 
So you've already seen
the class NS array, 
which is the foundation
class array, 
which is an array of objects.
Those objects, by the way,
in array can be of any class. 
There's really no way to
specify what kind of class 
of object is in an array.
Some languages allow
you to do that. 
You can specify "This
is an array 
of strings" and it knows that.
But in Objective-C
you can't do that. 
And we're going to talk
about how we deal with that. 
That's a little bit of the
wild west of Objective-C, 
but there are ways
to kind of check 
and see what the
objects are if you want 
to be really safe about it.
But in this case we just
have this mutable array. 
And mutable means that we
can add objects to the array. 
Normally an NS array
is immutable. 
Okay? Once it's created,
whatever objects enter it, 
that's the objects that
are in it forever -- 
you can't take any out
and you can't put any in. 
So if we want array
where we can add stuff, 
we have to use this subclass
of NS array called
NS mutable array. 
Okay? You can see
that it's a property. 
It's strong because we want
this array to stay in the heap 
as long as we're pointing at it.
And of course, we always
put nonatomic there. 
Okay? So this is going
to be an array of cards. 
Now that we have this, we could
easily implement add card, 
for example, by just saying,
"If at top, then insert object," 
the card, which is the
argument to this method -- 
first argument --
"add index zero." 
So insert object add index is
a method in NS mutable array, 
not in NS array -- only
in NS mutable array 
because that would
be mutating it -- 
that inserts the object
at that index in the array 
and index zero is
going to be the top 
that we're going to define.
And then otherwise if we're
not going to put it at the top, 
we're going to put
it at the bottom, 
we're going to use a different
NS mutable array method called 
add object.
And that just adds something
at the end of the array. 
So everyone cool with that?
So I mostly just put
this method in here just 
to show you there's a
couple of different methods 
on mutable array and, you know,
how we can use the arguments. 
It's no big thing here; it's
just kind of to get more used 
to what's going on here.
All right.
So that's add card.
Very, very simple.
And there's a problem, though.
In this add cards, if
we just created a deck 
and then called add
card, it would not work. 
Okay? It would do nothing.
Why would it do nothing?
Because the property
cards, okay -- 
self.cards is how we're
accessing our own property -- 
its getter looks
like that by default. 
If we don't give a getter,
that's what the getter
looks like. 
It's just going to
return this underbar cards 
instance variable.
Well, that underbar cards
instance variable's going 
to start out at zero because
all instance variables 
in an Objective-C
object start out zero. 
All of them.
Okay? So including pointers.
So that pointer will be
zero, which is we call nil, 
which means it doesn't
point to anything, 
which means there
is no array, okay? 
We got a pointer to an
array that doesn't point 
to anything right now.
Okay? So that's a problem.
So when we execute
the code in add cards 
like self.cards add object
card, that's going to not crash 
but not do anything, either.
Okay? Because I told you that
you can send messages to nil, 
send messages to pointers, to
objects where it's not pointing 
to one at the time,
and it will not crash. 
If you send a message
that returns a value, 
that message will
not execute any code 
but it will return zero.
Okay? So a lot of zeros
flying around here. 
Okay? So how are we
going to fix this? 
How are we going make it
so that add card works? 
Well, we could put something
at the beginning of add card 
that says, "If self.cards is
nil, then go allocate an array 
in the heap and point to
it, and then we'll use it." 
Okay? But that would mean
every single time we have 
to use self.cards we'd
have to go around and check 
and make sure it's not nil.
And that would be very annoying.
Okay? That would be very
error-prone, bug-prone, 
we forget to do it somewhere.
All these things.
So a great place
to do that little 
if check is in the getter, okay?
That getter that we have
right there for cards -- 
that's the getter for our
private property cards -- 
instead of just returning the
cards, let's put a line right 
in front that says,
"If the cards is nil, 
then let's go allocate one
in the heap and assign it 
to the instance variable."
Okay? So the way you
allocate an array 
in the heap is you use NS
mutable array alloc init. 
So that's two message calls
nested inside of each other. 
The alloc allocates
the member in the heap, 
and init initializes that
memory so that it's a, 
you know, sensible array.
And we're going to see how
we build our own initializer 
in a couple slides here.
So this way every single
time you call self.cards, 
you can be sure that
it's not nil; 
it's at least going
to be an empty array. 
Does everyone understand
this code? 
It's important to
understand this. 
Yeah.
[ Inaudible ]
>> Paul Hegarty: Okay.
So the question is: Instead
of having this initialization
code be in this getter, 
why don't I make an initializer
like an init for deck 
and put this inside deck?
Okay? And that is
another option. 
And again, we're going
to see initializer 
for playing card deck, we're
going to make an initializer. 
And we could do that.
But having the initialization
of this thing be closer 
to the actual getting of
the property is more -- 
it makes your init less full
of a bunch of junk like that. 
And this is called
lazy instantiation, 
by the way, doing it this way.
We are lazily waiting
to the last second
until we instantiate. 
This pattern is something
everyone 
in Objective-C is used to,
and you should definitely
use it rather 
than doing things in your init.
In init you want to, you know,
set things, set values that, 
you know, can't easily
be defaulted like this. 
Okay? But that's a
very good question. 
And we'll see init
in a couple slides. 
Okay? So this way we're
guaranteed self.cards is 
never nil.
Yeah?
>> [Inaudible]
>> Paul Hegarty: Yeah.
So the underscore is
from last lecture. 
Remember that when
we create a property, 
Objective-C automatically does
this thing, assign synthesize: 
Cards equals underbar cards.
So in other words, it assigns
an instance variable called 
underbar name of property
to be the storage space
for that property. 
So that's why underbar cards
are automatically created 
for us there behind the scenes.
That at sign synthesizes
a pop up in our code, 
but it's there behind
the scenes. 
That's a very good question.
Any other questions about this?
Okay. So let's collapse down
some of this stuff and look 
at draw a random card, okay?
So draw a random card, all it
wants to do is get a random card 
out of that self.cards, okay?
So that code is very
simple as well. 
So we just get a random integer.
That's what arc 4 random
does if you don't know. 
It's just a C library function.
It gets a random integer.
Then that little percent
after it means mod -- 
okay, integer modulo -- and then
self.cards.count is the number 
of cards in our self.cards.
Okay? So we're just going to get
a random index into self.cards, 
then assign a random card
to be self.cards square
brackets index, okay? 
So this is that same
square brackets 
to access an array
kind of syntax. 
And it's interesting,
that self.cards square
brackets index, actually, 
that's a message send
believe it or not. 
That's same as self.cards
object at index index. 
Okay? It's just some special
syntax and syntactic sugar 
to make it so that
you don't have 
to have long object add index.
It's actually object at
subscripted index or something 
with a real long method name.
So this is just a beautiful,
little simple syntax. 
But that is a message
send to get the card 
at that index out of the array.
And then we're also
going to remove that card 
out of the array because this
is draw a random card, okay? 
It's draw the card
out of the deck. 
So it's not in the
deck anymore, right? 
Now, there's a problem with
this code as well, which is: 
What if the deck is empty?
Okay? If the deck is empty, then
that unsigned index is going 
to be zero, right,
because it's going 
to be arc 4 random mod zero.
That's going to be zero.
And so you're going to say,
"Random card equals
self.card sub zero." 
Well, that's going
to crash your program 
because if self.cards
is an empty array, 
then there's no object at
index zero and you're going 
to get array index
out of bounds. 
Okay? So be careful of that.
The index -- you
cannot get the index -- 
if an array doesn't
have an object 
of that index, you can't get it.
So that's easy to fix, though.
We're just going to say,
"If self.cards count," 
in other words if
there are things 
in the array, "then
we'll do that. 
Otherwise we're just going
to return random card," 
which I happily initialized
to nil 
at the beginning of my method.
And that's why I kind of like
this thing of initialize it 
to the default value you want,
then set it, and then return. 
And that way if the setting
fails for some reason 
like this -- it fails because
there's no cards in the deck -- 
it will return the
reasonable default. 
That's just kind of
a coding style thing. 
Okay? We did that same
thing with score and match. 
Okay? Any questions about that?
Yeah?
[ Inaudible ]
>> Paul Hegarty: Great question.
So the question is: When do I
use NS integer or NSU integer 
versus int or even NS
number, which is an object 
which we haven't
talked about yet? 
And the answer is it's
a matter of style. 
And we'll talk a little
bit about that style 
and when to use these things.
Here I don't really want to use
an NS number which is an object 
when I'm just using
it, you know, 
as a little local
thing like that. 
You would never do that.
You're using NS numbers
basically 
to pass them to methods.
And even then you could pass
ints, you know, and floats. 
So it will be become obvious
as I talk about NS number, 
which we'll do next week.
Okay. So that's it for deck.
Deck, very simple class as well.
So let's move onto another
class, which is playing card. 
Okay? The reason I'm
showing you playing cards, 
I just want to show you what it
looks like to make a subclass 
of another class
that you've written. 
So playing card is
a subclass of card. 
And this is the specific
card like king of hearts, 
three of diamonds, that
kind of card, okay? 
Now, it has properties that
are specific to a playing card, 
which is the suit and rank.
Okay? The rank being
like a three, 
four, a jack, king, right?
And the suit being
hearts, diamonds, clubs. 
And I'm going to represent the
suit as a single character -- 
the hearts characters,
the clubs character. 
Remember I typed the
clubs character I think 
in the card we might
have shown that. 
I don't know.
But you can type a
single character. 
Unicode has a character
for each of the four suits. 
So that's what my
suit is going to be. 
And then the rank is
going to be a number 
between zero and thirteen.
Is that king?
Yeah. Representing the rank.
So that's how I'm going to
represent in my public API. 
And here I'm using notice NSU
integer instead of unsigned int. 
So NSU integer and unsigned
int are almost exactly the 
same thing.
The only thing about NSU
integer is it's typedef. 
It might be a little different
on different platforms. 
For example, the new iPhone
5s are 64-bit processers. 
So NSU integer is going
to be a 64-bit int, 
unsigned int on an iPhone 5.
And it might only
about a 32-bit one back 
on an iPhone 4 and before.
Okay? So that's a
little bit different. 
So a minor int.
We were probably not
representing integers. 
Certainly here we're only
going zero to thirteen. 
Probably doesn't matter.
But, you know, we're not
representing integers that are 
so gigantic that we're going
to be using the 33rd bit. 
So notice that in playing
card we're overriding card 
method contents.
Okay? We inherit contents
from our superclass. 
And by default contents
just returns the value 
of whatever the contents
property is. 
But here in the playing card
we're going to override contents 
to actually calculate
our contents, 
based on these other
two properties. 
Okay? So we're overriding
the getter of contents 
so that it always
returns a string -- 
the contents of this
playing card -- 
that is calculated
from the suit and rank. 
You see what we're doing here?
So we're basically taking
the storage of contents -- 
underbar contents -- from our
superclass and ignoring it 
because we're overriding
its getter. 
Okay? So this is a perfectly
valid reason why we do these 
properties as well because
we might have a better way 
to do things than the storage.
Now, here's a way we
could implement it: 
We can just return
a string, okay? 
NS string, string with format
just like printf-ing a string. 
Don't worry about
that syntax too much. 
And I'm printf-ing a string with
percent D and percent at sign. 
So percent D means integer;
percent at sign means an object. 
Okay? A string representation
of an object. 
And then I'm just using
the rank and suit. 
So this would be one
way to do my contents. 
It's not a very good way
because, for example, 
the jack of hearts would
say 11 hearts, okay? 
It's not going to say J at
least; we want to say J, not 11. 
So this is not a very good way.
So instead I'm going
to make an array 
that has all the right
things like an A for a one, 
and a J for 11, and a Q for
12, and a K for 13, right? 
So I'm just making
this array here. 
In the middle there I had to
cut out to make it fit, right? 
And I even made zero
be question mark. 
So if your rank is zero,
it's going to be, like, 
question mark, like, unset.
You know, your rank
is basically not set. 
And then I return a string,
which is taking the rank out of 
that array and appending onto
it the little suit string, 
the heart, or the
club, or the diamond. 
Everyone understand this?
I'm kind of giving you this so
you can see how we're mixing 
in the array notation, and
message sending, and it all kind 
of seamlessly mixes in there.
Okay? So now contents
returns J hearts, 
or 5 diamonds, or whatever.
Notice that our rank
is really nice 
because if our rank is zero,
which it starts out being 
when we say new playing card --
all the instance variables are
zero so rank would be zero -- 
we get this nice question mark.
But our suit starts out as
nil, and it would be nice 
if the suit also
returned question mark 
if it was unsaid, if it was nil.
So here I'm just overriding
the getter of suit to say, 
"If return, if my suit is nil,
then return the question mark, 
otherwise when my
suit's not nil, 
then return what the suit is."
Okay? So I'm just kind
of protecting my API 
to make sure I always
return question mark 
when the rank or
suit is not set. 
Yeah.
>> [Inaudible]
>> Paul Hegarty: Sorry.
All little at signs -- the
red at signs, you mean? 
Yeah. Guess we didn't
get to that in card. 
But we might have.
But remember that all strings
that we're going to work 
with in this class
are string objects, 
not const care stars, right?
They're string objects.
And the compiler, if you put an
at sign in front of a string, 
it will make a string
object for you, okay? 
So that's what those
at signs do, 
they make all those
strings be string objects 
because we can't put a const
care star in an NS array. 
NS array is for objects,
so we have to put objects 
in there like NS strings.
Those are objects.
Okay? Good question.
Yeah?
[ Inaudible ]
>> Paul Hegarty: Yes.
Okay. That's a good question.
If we had used that getter
equals notation that we used 
for is chosen and is
matched to change the name, 
then when we override we
have to use the new name. 
We'd have to is whatever.
Now, this is not the case here.
But I know what you're
saying, and yes, 
you would have to
use the new name. 
Great question.
Any other questions about this?
Okay. So that helps the suit
always return question mark 
if the suit is nil or not set.
Let's also protect
people setting the suit 
to something wrong.
Okay? Let's only let people set
the suit using this property, 
the public setter
of the property. 
We'll only let people
set the suit 
to be one of the four suits.
So I just on the fly
in the middle there created
an array of those four suits. 
And then I use this
method contains object; 
what class do you think contains
object is from that bit on? 
Anyone? [Inaudible]
>> [Inaudible]
>> Paul Hegarty: It's an
NS array method, exactly. 
So contains object is
an NS array method. 
I'm sending it to the array that
I create right in place there. 
The array that has
hearts, diamonds, 
spades, and clubs in it.
And I'm just asking: Do
you contain this string? 
And that contains object is
going to compare the contents 
of this string against all
these using a method is equal. 
Actually, it's going to say
is equal to all four of them 
with the suit as the
argument; not is equal 
to string -- is equal.
And in string is equal is
implemented by calling is equal 
to string if the
argument's a string. 
Anyway, more detail than
you need probably there. 
But this is obviously
protecting it. 
So there's no way we can set our
internal suit storage variable 
to anything except
for those four suits. 
Yeah?
[ Inaudible ]
>> Paul Hegarty: Great question.
You guys are right on top of it.
So every time I use the at
sign open square bracket -- 
the blue one -- to
create an array, 
that's actually creating
a new array every time. 
Okay? Because I told you that
that at sign square bracket 
and all this array stuff is
really just calling methods? 
Well, that's calling a method
like alloc init with array 
with objects or something
like that. 
Right? So it is creating it.
So it would be nice to move it
out, and we're going to do that. 
Although, again, be
careful not to preoptimize. 
It probably wouldn't
make any different. 
I'm only going to move it
out to make my code cleaner; 
I'm not going to move it out
for any performance reason. 
Yeah?
>> [Inaudible]
>> Paul Hegarty: Yeah.
>> [Inaudible]
>> Paul Hegarty: The question
is: Would LLVM just take care 
of that, optimize
that out for you? 
And it probably wouldn't
because that's a message send; 
it's not sure what there
might be side effects of it. 
But in any case, we're
just going to do it just 
to make our code look cleaner.
And the performance
would be negligible here. 
We're talking about UI.
It's not even close.
One thing to note, though,
before we do that is 
since we've implemented both the
setter and the getter of suit, 
we are now required to do
the at sign synthesize. 
Okay? In other words,
normally we don't have 
to do this at sign synthesize.
It gets done for us.
But if we implement
both the setter 
and the getter, now we do.
It's easy to do because it's
always of this exact same form. 
But we do have to do it.
Okay. So here's -- let's
do what we were saying. 
Let's take that little array
of suits we have in there 
and put it in another method.
Now, again, I'm not getting any
performance by doing this, okay? 
I'm just getting code
cleanliness by doing this 
because I'm still -- every
time I call valid suits, 
it's going to create it again.
Now, I could use
a static variable. 
This is C. I could
store this array. 
Started out being nil.
If it's nil, set
it to this array, 
and then it would
only create it once. 
But be careful.
Again, code cleanliness
and understandably ten
times more important 
than performance like this.
So unless you're going
to call valid suits 
in the inner loop
thousands of times, 
it's not really going to matter.
But once I move that up
into a different method, 
this kind of method that I moved
it to is a little different. 
Notice it has a plus.
You see a plus there instead
of a minus starting it? 
Plus NS array valid suits?
Okay. A plus method
is a class method. 
Okay? That means you
send it to the class, 
not to an instance of an object.
All right?
So since you're not
sending it to an instance, 
you can't use any instance
variables or anything like that. 
You can only just kind
of do generic stuff. 
So the only thing we really use
plus methods for, class methods, 
is two things really:
Creating things 
like in the previous slide when
we had string with format -- 
that's a class method that
was creating a string for us; 
and then also utility
methods like this, 
like the return constants
and things that, you know, 
our class wants and
utility methods. 
But here's an example.
And the way we call
the class method -- 
you've already seen me
call a few of them -- 
but here's calling it here is
we put open square bracket, 
the name of the class,
the name of the method. 
And again, it could
have arguments. 
It's just like any other method.
But everyone understand this?
Okay. And if you go back
and look a couple slides 
and you see open square bracket
NS string, string with format, 
same exact type of syntax.
Okay? So that's what a
class method looks like. 
Again, for creating
things basically 
and for utility methods.
And we'll talk about
the difference of: 
When do we create something
with a class method
versus alloc init? 
We'll talk about that soon.
I'm also going to make
valid suits public. 
And that way people who are
using my playing card know what 
the valid suits are.
And all I need to do is
put it in the header file. 
Boom, it's public now.
Okay? So let's do a
similar thing here 
with those rank strings.
Okay? So I'm going to take
those ranks strings -- 
that array of rank
strings right up there -- 
and I'm going to put
that in a class method. 
Okay? And again, this is
for readability,
not for performance. 
Because every time I call
rank strings, it's still going 
to create that thing again.
And then I call it
instead up there. 
And I'm not going to make
rank strings itself public, 
but I am going to make another
class method called max rank, 
which just looks at how many
strings are in rank strings. 
And I'm going to return
that as a public method. 
So there's three class methods
for you to sink your teeth 
into -- two of them
public, one not. 
All right.
And so they're all
utility methods, right? 
We're not accessing any
instance variables in any 
of those methods, okay?
That's the only reason
I'm showing those, 
is just so you see what a
class method looks like. 
We also could override
the setter of rank just 
to be complete here to make
sure it doesn't allow you 
to set a wrong rank
like set rank 15 -- 
there's no such card as 15.
So let's make sure that the
rank is less than the max rank, 
which is the utility
method we just did. 
Okay? Does that all come
together for you, make sense? 
So this is kind of
reference material. 
You have these slides that
have all the annotations 
of all the things I'm saying.
So feel free to go back and
look at it and remind yourself 
about all these NS
array, syntax, 
and all the class
methods, all that stuff. 
Okay. The last thing
we're going to look 
at is the init method business.
Okay? So we're going to have
another class here called 
playing card deck.
All right?
And a playing card deck
is a subclass of deck. 
All right?
And it has no public API.
It's just going to
override a method 
that it inherits
indirectly from NS object -- 
okay, NS object through deck,
which doesn't touch it -- 
all the way to playing
card deck. 
And that method is called init.
Okay? So this is the same
init, same kind of method 
that when we created
that array -- 
that mutable array we said
NS mutable array alloc init. 
So someone is going to call this
playing card deck init method -- 
namely you in your homework
are going to call this 
by doing playing
card deck alloc, 
and then on the outside, init.
Okay? And that's
how you're going 
to create a playing card deck.
And that is how we create most
instances of objects -- not all. 
Sometimes we do things like the
NS string, string with format. 
But most of the time --
more than half the time -- 
we do alloc and then
on the outside init. 
Okay. Listen carefully:
Never call that alloc thing 
without wrapping
an init around it. 
Okay? Don't ever do that.
That makes no sense to
have an object allocated 
in the heap that's
never been initialized. 
Always have that nested.
And vice versa: Never
call that init except 
for when you wrap
it around an alloc. 
And definitely never call
that init more than once. 
Okay? And if you obey my rule
of only calling it wrapped 
around an alloc, you can't
call it more than once. 
Okay? Init is not something
like you can re-init. 
Init happens once right
after alloc, and that's it. 
Okay? That is a hard and
fast rule we never break. 
Okay? So you heard it here.
Don't forget.
All right.
Let's look at the whacky return
type to this init method, okay? 
You might think this init method
should return a playing card 
deck star because it's
kind of initializing 
and maybe it returns itself.
And in fact, init does
always return self, okay? 
So init is always
going to return self. 
Okay. More whackiness there,
which I'm going to describe. 
Just for convenience, it always
returns self so that you can do, 
like, playing card deck alloc
init, sent it a message. 
Okay? So it's just convenience
that it returns self. 
But it can't really have its
return type being playing card 
deck star because it
inherited this from NS object. 
And NS object already
defined it as NS object star. 
You see? So it's kind of weird
that you're inheriting a method
whose return value would have 
to change every time you,
you know, overrode it. 
So they invented this new
thing -- this is new for iOS 7, 
by the way -- called
instance type. 
And what instance type
means is this is going 
to return an object that
is of the same instance -- 
same type, same class type --
as the object you
sent this message to. 
Okay? Which makes
perfect sense for inits. 
And in this class that's
probably all you're going 
to use this for right here.
So if you don't really
understand what I just said -- 
it's explained in the slides --
but if you don't
really understand it, 
just know that whenever
you do an initializer, 
it's going to return instance
type as its return type 
and you're always
going to return self. 
Okay? Now, also just
take my word for it. 
We're going to do these
next lines of codes as well 
because they are really strange.
That first line, self equals
super init, that is weird. 
That is super weird.
Okay? Assigning something
to self in Objective-C -- 
just never do that,
except for this one time 
and that's in your init.
Okay? You take self
and you assign it 
to calling your superclasses
initializer 
so that your superclass
gets initialized. 
Why do we assign
the result to self? 
It's kind of ancient history
as to why this has been
done for a long time. 
Basically we're checking the
return of our superclasses init 
to make sure it properly
initialized. 
Because at any time if your
initializer cannot initialize 
itself, it should return nil.
Okay? And that lets everybody
know any of your subclasses 
or anyone trying to
alloc and initialize you, 
you could not create
a well-formed object. 
Okay? So you can see how this
code, strange as it is -- 
self equals super
init, and then if self, 
I'm going to initialize
myself, return self -- 
that's going to ensure
that I don't even try 
to initialize myself
if my superclass, 
when I call its init, you
know, can't initialize itself. 
Okay? So just do it.
If you don't understand it,
don't worry about it too much. 
Just do it.
Now, one thing here
is we're talking 
about init with no arguments.
It is possible to have
initializers with arguments 
because sometimes
you need arguments 
to properly initialize a class.
And we're going to talk about
that a little more on Monday. 
Okay? So today we're just going
to kind of bare bones init. 
So what does this
init need to do? 
What do I need to do to have a
well-formed initialized playing 
card deck?
Well, a playing card
deck has 52 cards in it, 
one of each kind of card.
Okay? King of clubs, three of
diamonds -- all 52 of them. 
So I just need to iterate to
all the suits, and then iterate 
through all the ranks,
and create a card,
and add it to myself. 
So here's me iterating
through the suits, 
iterating through the ranks.
Everyone cool with that?
Then I'm going to import
playing card because I'm going 
to create a playing card,
playing card alloc init. 
Then I'm going to set
that card's rank,
set that card's suit. 
Rank and suit are my little
iteration variables there. 
And then I'm going
to add it to myself. 
I'm a deck, so that's
perfectly fine. 
Everybody cool with that code?
So now I'm a well-formed playing
card deck and I can be used 
to draw random cards and all
that stuff, which you will need 
to do for your homework.
Okay? And in fact, for your
homework you're going to have 
to type all four of
these classes in. 
I want you to get
experience entering classes, 
typing a thing, watching
as Xcode complains at you 
as you mistype things,
and stuff like that. 
And then you're going
to be using playing card
deck and playing card. 
Well, playing card deck and card
really are the two main ones 
you're going to be using
to do your homework. 
Okay? Questions about that?
Okay. So that's it
for the slides. 
So now I'm going to
do a big old demo. 
And this demo is going
to integrate everything
you've seen so far, okay? 
Most notably that MVC
stuff we talked about, 
like target action, you
know, dropping the target 
and shooting the action
or the green arrow outlet 
that points the other way.
Okay? We're going
to show you what 
that actually looks
like in Xcode. 
I think when I asked who
of you have done Xcode, 
almost every single one
of you raised your hands. 
So I'm not going to spend
too much time talking 
about all the buttons in Xcode.
I think I'll quickly
pass over those. 
But if you haven't used Xcode,
it's in very much detail 
in the lecture slides.
There's kind of this
walkthrough. 
By the way, if you're following
along in the lecture slides, 
my demo's not going
to be exactly 
like what's in the slides.
The slides cover a little
bit more than I can cover 
in forty minutes here.
And it's also reference
material. 
Okay? So if I do something today
in this demo and you're like, 
"Oh, how did he do that?"
if you go look in those
slides, it will tell you. 
So do not feel like, "I
got to furiously write 
down every button
click he's going to do 
in the next forty minutes."
No way. Okay?
Follow along in those
slides if you want, 
or just close your laptop,
and watch, and let it sink 
in because you're going to have
to reproduce what I'm doing 
in the next forty
minutes for your homework. 
And those slides are
going to walk you 
through step by step
how to do it. 
So do not feel like you need
to do anything right now 
but let this all sink in.
Get a feel for what's going on.
Okay? And then when
you sit down to do it, 
you'll be guided through it.
Next week we're going to talk
a lot more about Objective-C, 
answer some of these
more detailed questions 
like NS number and some of these
other things people are asking. 
And we'll talk about some
of the specific things 
about Objective-C like
dynamic binding, and protocols, 
and things that you don't
generally see as much 
in other languages or don't
exist in other languages. 
So we'll try and cover all that.
So by the end of
next week you're 
up to speed in Objective-C.
You're starting to
really run with Xcode. 
And so the week after that we
can really start doing some, 
you know, high power
iOS 7 stuff. 
Okay. So demo here.
[Inaudible] that.
All right.
So the demo I'm going
to run in Xcode. 
So I'm just going
to launch Xcode. 
So Xcode you get by running --
going to your Mac app store. 
That's this thing
down here, right? 
Get the app store on your Mac,
and you just search
for Xcode, find it. 
It's free.
You download it and you run it.
Okay? It's as simple as that.
This is what it's going to look
like when you first bring it up, 
this splash screen here.
As the quarter goes
on, this will fill 
up with all the projects
that you're doing. 
You're probably used to
that if you know Xcode. 
And what we're going to do
today is create a new project. 
You can either check an existing
project out of source control 
or you can create a new one.
And so we're going
to create a new one. 
So when we create a new one, it
wants to give us a little bit 
of help by offering to create
a template for different kinds 
of applications like
an openGL game. 
Okay. It will create some
framework for that for you. 
Master detail applications,
something we're going 
to do later in the quarter,
although we're going 
to build all the code ourselves;
we're not going to
use this template. 
And this single view application
one right here is basically a 
single MVC, which is how
we're going it start all 
of our applications in this
classroom -- with a single MVC. 
Then we're going to add
more MVCs and build up. 
Okay? So this is your
basic single MVC app. 
So I'm going to click that.
And here it's going to ask
for some information about it 
like what do you want
to call this app? 
This is a card matching
game I have decided 
to call Machismo, okay?
So that's going to be the
name of our app just for fun. 
And organization name
can be anything you want. 
It's going to appear
in the headers 
of all the classes
that you create. 
So I make mine be
Stanford University. 
You can make yours be Bob's
Game House or whatever. 
This identifier should
be unique to you. 
So I have
edu.Stanford.cs193p.instructor. 
You might have
edu.Stanford.cs193p dot your 
SUNet ID.
That will be completely unique.
These reverse DNS
is a really good way 
to create a unique name.
And it's going to create
a unique name for this app 
by combining this
with the names. 
So you can see it's done that
here, this bundle identifier. 
And then this class prefix --
this template is going to create
a view and a controller for us. 
And this is saying, "What
do you want the name 
of your controller class to be?"
By default it's going to be
called "view controller," okay? 
But if you type something here
like "card game," now it's going 
to be called "card
game view controller," 
which is a little
better name for us. 
So that's just the prefix
it's going to put on the name 
of your controller that
it creates for you. 
And then finally here we
can create an app here just 
for iPad, or just for
iPhone, or a universal app 
that will run on both platforms.
Now, when you create a
universal app, you still have 
to design your UI's separately
because if you have more
screen rules, you're just going 
to design a different UI.
Okay? iPad is not
just a big iPhone. 
You can do a lot more stuff
if you have more
screen real estate. 
But you still might have a lot
of your MVC's shared, right, 
because that iPad might have
little subareas that are in MVC 
that are exactly the same as on
an iPhone or very, very similar. 
So totally supported
in iOS 7 to build apps 
that target both platforms
and has great tools 
for letting you build
your two UI's separately 
and share all the
MVCs underneath. 
Okay? We're going to do
iPhone only here just 
because it keeps the
screen small and I only have 
so much real estate here.
[ Inaudible ]
>> Paul Hegarty: Yeah.
So the question is:
If I'm on my iPad 
and I run an app
that's iPhone only, yes, 
there's an emulation mode
essentially that will kind 
of make a big iPhone-shaped
thing on the iPad screen. 
So we're going to
do iPhone here. 
So that's it.
I'm going to hit next.
Next it wants to know,
"Where are you going
it put this project?" 
I strongly recommend putting
it in your home directory -- 
in a directory called
"developer" 
in your home directory.
Okay? Unless maybe we're
working on different class. 
Maybe you have the CS 193P
in your home directory
and then other class. 
But bottom line: Put it in your
home directory; do not put it, 
like, in root or
somewhere like that. 
That has in the past
caused problems. 
But a great place
to put it here. 
This is my home directory,
CS 193P there. 
I see home directory, developer.
This is where I'm
going to put it. 
I don't have any projects yet.
This little thing down
here, source control, 
we will be talking about that.
It's really nicely integrated
into Xcode, but we're not going 
to talk about it today.
So leave that unclicked.
And so here's our new project.
You can see it shows us
this screen, which you get 
to by clicking on this
very top thing up here. 
So this is kind of like
our project settings. 
And there's a whole
bunch of settings here. 
We'll be talk being all this
stuff as the quarter goes on. 
But today we're not going
to talk about any of it 
because we want to
focus on our MVC. 
And our MVC, this right here,
main.storyboard, is our view. 
Okay? That's our
view of our MVC. 
And then you see this card
game view controller M and H? 
That's our controller.
There's no model here.
Your model is going to
be those four classes -- 
deck, card, playing card,
playing card deck -- 
that's going to be your model.
So you'll have to enter that in.
I'll show you at the
end how to do that. 
This little thing here, card
game [inaudible] dot H and M, 
we'll talk about that briefly,
especially when we start talking 
about things like multitasking.
But I like to just move
those out of the way. 
So I often put them down here
in this supporting files folder. 
And you can just pick
up any file, by the way, 
and move them anywhere
you want here to kind 
of clean up your view.
So here I've got my view and my
controller only showing here. 
Okay? So let's go
straight to the view 
and see what that looks like.
So here's my view.
It's a blank iPhone
5 sized, right? 
A tall and thin view.
And it's blank.
Nothing new.
It's white.
This area on the left, by
the way, where we clicked 
on these files, that's
called the "navigator." 
And you can not only
navigate all your files here, 
but you can navigate your break
points, and build problems, 
and your class hierarchies.
All that stuff up here.
So again, most of
you know Xcode, 
so you probably know
most of this stuff. 
We'll be demoing all this
as the quarter goes on. 
And this area over here is
called the "utilities area." 
And this is where you
basically find out detail 
about what's going on here.
So inspectors for attributes,
and dimensions, and connections, 
and things like that go here.
And this is also where you
can drag out the things 
that you're going to use to
build your user interface 
because we're going to build
our view entirely graphically. 
Okay? We're not going
to write code, 
for the most part,
to build our view. 
As the quarter goes on, we'll
learn a little more about how 
to build our view in code,
but we're going to start 
out just purely doing our view
by graphically dragging things 
out and wiring them up.
And we'll put our code
in our controller. 
This two sides can be hidden and
shown with these two buttons. 
See? You can hide those.
[Inaudible] This might appear
also, this area right here, 
this little button down here.
This is called the
"document outline." 
This is really handy dandy.
But again, we're not going
it talk about that today. 
We can only talk
about so much at once. 
The document outline.
This just shows you all
the instances of objects 
in your view in a
common outline form. 
So you can really
easily find them 
and their relationships
to each other. 
The other thing you can do is I
don't want this iPhone 5 sized 
thing because my screen
is low resolution here 
so it works on the projector.
So I'm going to click this
little button down here, 
which reduces me down
to iPhone 4 size. 
Okay? Or iPhone 4S.
Now I'm tall and thin.
But you can click back and
forth and move them back forth. 
And I'm just trying to make
everything fit on screen here. 
Okay. So let's just dive right
into building our view here. 
What our view is going to
be today is a single card 
with an ace of clubs
written on it. 
Okay? That's going to be it.
And I'm going to be able
to click on the card 
and it will flip over, show the
back of the card, and then click 
on it again, it will flip
back to show me the ace 
of club again -- back and
forth, back and forth. 
Okay? And your homework
is going to be to make it 
so when the card flips up it
doesn't show the ace of clubs, 
it shows a random card
drawn from the deck. 
Okay? That's going to be your
entire homework that's due 
on Monday.
Okay. So let's do this.
Really simple.
We go to this area right
here, this object library. 
Okay? That's the third button
over here, show object library. 
And this is where
all our objects are. 
If you look in here and you
don't see these objects, 
it might be worth
clicking on your view. 
Sometimes Xcode wants to
know what the destination is 
that you're going to be
dragging things into. 
So if you click on it, then
you'll see these things. 
And we're just going to grab
one of these buttons right here. 
So I'm going to pick this
button up and drag it out. 
And notice, as I drag it out,
these little blue lines
appear -- these guidelines. 
Okay. These guidelines
are super important. 
They seem just like
a convenience 
for helping you put it
right in the middle or right 
in the right-hand corner.
And they are, but they're
really important for making sure 
that all the things in your
view are kind of, like, 
standard space apart, right?
And lined up against edges.
So that as the users go
from one app to another, 
things will all be separated
by predictable spaces 
and everything will
be consistent. 
It's really important.
And there's a mechanism -- you
can see this switch right here, 
use auto layout, which
was introduced in iOS 6 
and vastly improved in iOS
7, especially in Xcode -- 
that allows when your user
interface changes size, 
like it goes from being an
iPhone 4 to an iPhone 5, 
or it rotates from being
vertical to being horizontal, 
or it's on an iPad
in a bigger space. 
For all the buttons and
everything to kind of move 
to a new position
that makes sense 
or at least most of them, right?
And then maybe you might have
to move a few of them by hand, 
depending on what's going on.
But it mostly automatically
lays it out. 
And this is really important
because I'm sure devices will
continue to be differing sizes 
as new, you know, devices
come out over the years. 
So doing auto layout
is important, 
and these blue guidelines are
the number one most important 
thing for auto layout.
We're going to cover
auto layout in detail, 
and there's a lot to it.
All these buttons down here
have to do with auto layout. 
But getting those
blue guidelines, 
making sure you drop things
with at least one blue guideline
somewhere is really important 
to kind get you going
down the right path 
with the properly
auto laid out UI. 
So we have this button here.
But before -- and of
course, we can go over here 
to this is the attributes
inspector and click on it. 
And we'll see all
kinds of attributes. 
In fact, if I hide
this, tons and tons 
of attributes for this button.
Okay? Not just the
button itself, 
but actually its
superclass has attributes. 
Control is its superclass,
and then view is
control's superclass 
and it has attributes.
Okay. So this is an
objective-oriented inspector 
that will show all the
attributes of all the things 
through the inheritance
hierarchy. 
And what's happening here
is we're actually editing an 
instance of a button here.
So we are not -- and I know
in some systems you layout
the button, you set the size, 
and you set the attributes.
And then, you know,
behind the scenes a bunch 
of code is being generated
to create the button. 
That's not what we're
doing here. 
We're actually editing
live objects. 
They're essentially
going to be freeze dried. 
And then when your app runs, add
water, they come to life, okay, 
with their attributes set, and
all their sizes and positions, 
and all their auto layout
information in the object. 
Okay? So it's a little
different than you might be used 
to in some other systems.
So anyway, before we edit the
attributes of this button, 
though, let's change
our background 
because this is a card game.
And most card games are on,
like, green felt, right? 
So let's make our background
be more like a green felt. 
So I'm just going to
click on the background, 
which is this view right here,
and you can see its properties. 
So I'm going to change
a couple -- 
or just one of its properties
-- which is the background. 
You see this background
white color right here? 
So if I click on this, I have
some recently used colors. 
I have all these kind of
black and white colors. 
And I also have other.
And I bring up other,
brings up the crayons, okay? 
It also brings up other
ways to choose colors, 
but I like the crayons.
Okay? And so where
are my crayons? 
There they are.
So let's pick a green,
like, moss is a good green. 
Clover. I kind of
like moss better. 
So that's kind of a
card game background. 
And that's it.
So we've set the background
color of our views. 
Okay? And all the attribute
setting is just like this: 
You just set it and forget it.
So let's go back to the
button and its properties. 
Okay. The button I want
to look like a card. 
Well, a button in iOS
7 basically looks a lot 
like a hyperlink on a web page,
just like that button
does right there. 
Okay? That blue button.
That's not really
appropriate for what we want. 
We want it to look like a card
with a little rounded rect 
and a white background, right?
And I want the back of
the card to look the same 
but have some kind of design
on it or something like that. 
So the way I'm going
to do that is I'm going 
to set a background
image for my button. 
Okay? A background image
that's like a rounded rect. 
So let's take a little
aside here and talk about: 
How do we get images
into our app? 
Okay. We want to use images
in our app; it's very common 
to want to use images
in a graphical application
like on a phone. 
So how do you do it?
And the answer is you go down
here to this place called the 
"image asset library" --
images.xc assets
or Xcode assets. 
And you can see there's
already a couple 
of slots for icons here.
They're not set, but
this is the app icon. 
And also you can have a launch
image that will appear instantly 
when someone launches your app.
And then as you're initializing,
having behind the launch image, 
and then it will show
you are actual UI. 
So it's kind of quick
launch image. 
And we'll talk about
this on Monday. 
We'll set the app
background for Machismo here. 
But I'm going to actually
drag in some other image. 
So I have some images here.
And for example, I've got
this Stanford logo right here. 
So I'm going to drag
that Stanford logo 
in because I want to use it.
And that's it; you
just drag it in here. 
It says Stanford.
But notice that it kind
of has this weird thing
here, this 1X and 2X. 
You see that?
And that's because every
image that you're going to use 
in iOS wants to have a normal
resolution version that's going 
to be used like on the iPhone 4
-- nonretina displays basically. 
And then a 2X, twice
as high resolution -- 
one that will be used on retina.
And it will automatically
pick the right one, 
depending on what
you're running on. 
Okay? You don't have to
do anything about it. 
But you do want to provide
these higher res ones. 
And these higher res ones aren't
just necessarily the same exact 
image, just, you know,
made more high resolution. 
They might allow you to do --
for example, here I've
got a Stanford logo 
with the little tree.
See? See the tree in there?
So maybe this is
too low resolution 
to really get a good-looking
tree. 
But I can get the tree in
at a higher resolution, 
so I put it in there.
So it's not that common that
the two ones would be actually 
different-looking
but they could be. 
Certainly allowed they could be.
I also don't want to
really call this "Stanford." 
I'm going to use this
as my backup card. 
Instead of having, you
know, some kind of design, 
I'm going to have the Stanford
logo be the back of my card. 
When my card's flipped
down and I see the back, 
I'm going to see
the standard logo. 
So I'm going to call
this "card back." 
I can call it anything I want.
I also have things
for the front here. 
This one right here.
This is blank card
with a rounded corner. 
There it is.
You can't see it.
Because it's a white
card so you can't see it. 
But I'm going to use that.
I'm going to call
this "card front." 
And I'm also going to
have a high-res version 
of that as well.
Okay. So that's good.
So as much as we can see of it.
Okay. So now I got some images.
And now I want to
use them in my view. 
I kind of want to set
this card to use this. 
So I'm going to start with
my card here being face 
up when it runs.
When my app runs, the card's
going to start face up. 
In your app when you get your
homework you're probably going 
to want to start it facedown.
The reason for that is my
app only shows one card: 
Ace of clubs.
So it's fine if it comes
up with ace of clubs. 
But you don't want your card to
come up ace of clubs for sure. 
And it might be a little
more work for you coding-wise 
to initialize it to come
up with some random card. 
So I'll just have
it come up facedown. 
Make it a lot easier on you.
Okay? So how do we set that?
Really simple.
I've got the button
selected here. 
Here's its properties.
One of its properties
is its background image. 
Okay? So I'm just going to
click here, and you can see 
that all images that are in my
assets library will be here. 
Okay? And if there was
a really lot of them, 
you can type and
it will match it. 
So I'm going to make
it be the card front. 
So it made it the card
front, but I don't see -- 
where's the rounded rect?
Okay? I can't see
the rounded rect. 
And that's because
it's too small 
to see the rounded
corners very well here. 
So you can just take
this thing and resize it. 
Okay? And I'm going
to make it -- 
I want it to be about
two to three [inaudible]. 
So I'm going to make
it 64 by 96. 
I know this happens to be a very
good size, and I've resized it. 
And now you can see the
little rounded corners. 
You see? So this is
that image I dragged 
in with button written
on top of it. 
And of course, I moved it a
little so I can put it back 
in the middle using my
blue guidelines, right? 
And of course, I don't want
my card to say "button" it; 
I want the ace of clubs on here.
So I'm going to just
double-click on it. 
I could also edit that up here.
You see right here
where it says "button"? 
Click it here.
I'm just going to
double-click directly on it. 
I'm going to type "ace."
And how do I type
clubs, anyone know? 
Alt something or other.
I like to do this way.
I go to edit menu,
special characters, 
get this magic thing.
You ever seen this,
kind of cool? 
Just double-click -- find
the clubs and double-click. 
All right.
So there's my ace of clubs.
Now but, you know, that's
not quite right, either. 
I don't really like that blue A.
I really want the A to be black. 
And it could be a little bigger.
There's more room for it.
So I can go over here, for
example, and change the font. 
I can change it by clicking this
little thing to make it bigger, 
or I can actually click on this
T and even set which font it is. 
One thing that's
really important 
in iOS 7 is the typography.
Okay? Picking the right
text styles is really, 
really important in iOS 7.
And we're not going to
really talk about it here; 
we're just going to
use the system font. 
But that's something we'll
talk about in lecture, 
is making sure you pick the
right fonts in the right places 
to make the UI look really nice.
I can change the size
here, maybe 24 point 
or something like that.
That will still fit.
And then I don't want this
blue, so that's this text color. 
So let's go ahead
and make that black. 
All right.
So I got the card
looking the way I want. 
That's good.
All these properties that
we're setting, by the way, 
if you look at button, you see
this state config right here? 
Default? We can actually set
all these things differently 
for the highlighted
state of the button, 
or a selected state,
or disabled state. 
But we're setting
these as the default. 
So all our buttons always going
to be displaying
the default state. 
Okay? So buttons
are pretty powerful. 
You can have them look different
as they highlight or whatever, 
but we're going to be working
all in what's called the 
"normal" or "default"
state of the button. 
You'll see that when
we get to the code. 
So we can actually
run this right now. 
So running.
You've all -- most,
again, done Xcode. 
You know how to run.
It's this little play button.
You can actually hold it down,
and there's other things you
can do like test and analyze. 
But we're just going to run.
So I click run, and it's going
to run this in a simulator. 
Okay? And here it is.
And you can see that
the simulator's 
so big it doesn't
even fit on my screen. 
So I kind of have to
scroll around in it. 
And when I click it,
it doesn't do anything. 
Okay? So that's not good.
All right.
Because I haven't put any code
in my controller to respond 
to that thing being touched.
So that's what we're
going to do next. 
So let's go back here and stop.
Okay. So how do we do that?
Well, it's pretty interesting
how we do that, actually. 
I'm going to make
some more space here. 
And what we need to do is
connect up to our controller. 
And we do that by putting
our controller's code side 
by side with our view.
All right?
So I'm going to click this
little button right here, 
this button icon, and
that puts side by side. 
And by default if you have
a view up here on the left, 
it's going to put that
controller's code on the right. 
And you can move this
to get more space 
for the code if you want.
You can also switch between
the header if you want 
to do public stuff or
the implementation. 
Okay? So that's good.
Now, this code right
here is part 
of the view controller
lifecycle, which we're going 
to talk about in
two or three weeks. 
But today we're not
going to talk about it. 
So we can just get rid of it.
And let's just start by saying,
"When this button gets touched, 
we want it to flip over."
So we need to make a connection
between our view
and the controller. 
And we're going to do that
thing where we hang the target 
out and shoot the arrow.
Okay? Called "target action."
And this is going to
be kind of whacky. 
You're probably not even going
to believe this when you see it. 
The way to do this is you
hold down the control key. 
So I'm holding down the control
key, and I'm dragging a line 
from the view directly
into our code. 
All right?
Okay? And I let go.
And it says, "Oh, you want a
connection between your view 
and your controller, do you?
Here's what I need to know."
So it's asking us,
"What you do you want 
to call this connection?"
So this is going to be
the name of the method. 
It's actually going to create
a method here that gets called 
when the button gets touched.
I'm going to call it
"touch card button." 
That's a good name.
Here it's saying, "What
you do you want the type 
of the argument to be?"
We'll talk about this later,
but for now we obviously want
the argument to be the button 
that is sending us
this action, okay? 
Which is going to be nice
because then we're going 
to talk back to it and tell
it to flip itself over. 
There's other things
we can set here like: 
What kind of event do you
want to send this action? 
And you can actually set
it so there's no argument, 
it just sends touch card
button with no arguments. 
But here we want it to have
the argument of the sender, 
the button sending this message.
You can even send the
touch event along, 
but we almost never do that -- a
tenth of a percent of the time. 
So here I'm going
to have the sender. 
So when I click connect,
it creates a new method. 
And that method is
wired up to that button. 
In fact, you see this
little round circle? 
If I mouse over it, it will
show you that's what it's 
connected to.
Okay? So this is just some
pretty normal-looking method 
right here.
The return type, IB action,
that's actually typedef void. 
This method actually
returns void. 
The reason that Xcode
puts IB action there 
and typedef's IB action to void,
it's just so that it can tell 
which methods are target action
so that it can do
stuff like this. 
Okay? The mouse over.
But the compiler ignores it.
The compiler sees it as void
because it's typedef to void. 
It's purely an Xcode thing
to this IB action thing. 
And then you can see this
method has one argument, 
which is the sender.
That's the button
sending us this message. 
And it's going to send this
message every time a touch goes 
up inside the button.
Touch up inside, right?
That was the event.
So that's when it's going
to send this message. 
So that's perfect.
That's what we want.
So every time this happens,
what do we want to do? 
Well, we want to
flip the card over. 
Okay. So let's start by just
flipping it over to the back. 
And the way we're going
to do that is we're going 
to create a local variable
called "card image." 
Okay. And you noticed it was
trying to help me type there, 
and you're going to see
a lot of helping here. 
And UI image is another
class in iOS, okay, 
just like UI button is a class.
UI image is the class, as you
can imagine, stores an image. 
Could be a JPEG image,
could be an animated GIF, 
it could be a TIFF
image, whatever. 
Okay? So it's very powerful
image holding class. 
And it has a class method
called "image named," 
and you give it a string like
card front or card back, right? 
And it will look in the assets
library and give an image 
of the right resolution,
depending on whether it's going 
to be go on -- actually,
it will give you an image 
with both resolutions.
And then depending on where you
display it, it will, you know, 
pick the right resolution,
whether it's on a retina or not. 
So that's cool.
We got the image.
So now we're just going to
tell the button to set this 
as its background image instead
of whatever's on it right now. 
So to talk to the button, we
do open square bracket sender. 
Right? You see that the sender
is the button sending us 
this message.
Okay? Set.
Okay, I'm going to start
typing set background. 
And you see as I start to
type, Xcode is suggesting 
to me what I might want.
Now, it knows that the
sender's a UI button, 
so it's only suggesting
button methods here that start 
with set B -- set
background color, 
set background image,
and set bounds. 
Okay? Notice I'm also getting
some help at the bottom. 
See, isn't that cool?
A little one or two
lines of help? 
And I could click on this link
and it would take me
to the documentation. 
We're not going to do
that for time reasons. 
But I can also just click
one and it picks that one 
and immediately selects
the first argument. 
So I can take that.
Okay? So I'll do that.
Card image.
And notice here when I type
CA, there's a lot of things 
that start with CA
that could go there. 
But Xcode's pretty smart.
It knows that a local variable
is much more likely what you 
want here than all
these other CA -- 
functions that start with CA.
So it automatically
selects that for me. 
And if I hit tab, by the way,
it's going to basically
escape complete it. 
[Inaudible] And if I hit
another tab, it goes over here. 
This little four state thing
is just what I was talking 
about where you can set this
for the highlighted state, 
or the selected state,
or disabled state. 
We're just going
to do the normal 
or default state of this button.
Okay? So we're setting
the background image 
for this button.
And we also need to set the
title because we don't want 
to see that ace of clubs when
we flip it over backwards. 
So I'm just going
to set it to that. 
Okay. That's the empty string.
I could also say nil there.
Okay. But I'm saying
empty string just 
to see what empty
string looks like. 
So actually if we run
this, command three. 
Okay, let's try that.
Oh, cool. [Inaudible]
So there you go. 
So there's a miniature
version of it. 
Okay. So here's our card.
And if I click on it,
oh yeah, it flips over. 
Yes. Stanford logo
with the tree. 
But now if I click, it
doesn't do anything else; 
it always flips over
to the back, 
which is exactly what
our code does, right? 
So that's good.
So let's fix it so that
it flips both ways. 
Okay? And I'm going to do
that by saying if the -- 
actually, I'm going to
do one other thing first 
to make this code a
little simpler is instead 
of having this local
variable, I can just take this 
and pop it right in there.
Okay? And that's very
common to do that. 
And if I wanted to wrap it,
it will automatically wrap 
if I make this too short.
But I can also put
a return in there. 
And when I do, look what
it does with the colons. 
See how it lines the colons up?
It will always do that.
If you press return in the
middle of a message send 
that has multiple arguments,
it will line the colons 
up for all the arguments.
Really cool.
So you can see all the arguments
lined up left and right. 
So anyway, I'm going to check
to see if the current title -- 
okay, that's a button
method -- if it's a string. 
If that length, okay,
is nonzero, okay -- 
so that's testing there to see
if the length of nonzero -- 
that's a cool way to do
it because that will work 
if the button title is nil
or it's if the empty string. 
Because the button
title starts out nil. 
If you don't set it to
anything, it starts out nil. 
So here with one line of code
I've checked both the initial 
state possibly -- not in our
case because we set the title 
to the A club -- but in
your case it might be. 
Then we'll set it to one thing,
else we'll set it
to the other thing. 
So we just wanted
to set this to this. 
All right?
So if there's a title
on the button, 
in other words it has the ace
of clubs, then we're going 
to switch over to the back.
And if there's no title on
the button, then we're going 
to switch back to the front.
Okay? Ace of clubs.
Okay? So now when we run,
our card will flip both ways. 
Okay? So really simple
to wire stuff 
into your controller
to do what you want. 
The next thing we're
going to do is in the -- 
okay, I'll show you
really quickly here. 
If you hold down the option
key, a very important key, 
do you see how it
puts a question mark 
and starts highlighting things?
That's going to allow
to you to transition 
into the documentation.
So if I want to know more
about this current title, 
if I hit option, click on it --
see, I get a little
bit of help right here. 
It's a property.
It's read-only, it's nonatomic.
By the way, if you see
"retain" in the documentation, 
that's the same as "strong."
Okay? Retain is the same
as strong basically. 
Little bit of description
here but also hyperlinks. 
And if I click on one of these
hyperlinks, like this one, 
it takes me into
the documentation. 
This is a separate
window right here. 
And you can navigate around
in this documentation. 
You really want to get
familiar with all this. 
I can't really show it all to
you today for time constraints, 
but you can do things
like search, 
like I can go find
UI button here. 
Okay. There's UI button.
I might scroll down
and go to, for example, 
set background image
or set background image 
for state, which we just saw.
Maybe I'll click to go UI image.
You see all this.
There's nice descriptions of
the class in the beginning 
and then all the methods,
etc., etc. So definitely want 
to become a master of
that documentation. 
You can also option
double-click on things 
and it will send you
straight to the documentation. 
If you don't want to get
the little help one first, 
you can go straight in.
So option is the
key one for that. 
Let's go ahead -- okay.
Notice that this little space
along the bottom here appeared 
when we ran the application
-- you see that? 
This is the debugger
on the left, 
and this is the console
on the right. 
Okay? And you are definitely
going to be using the debugger 
and the console both
in this class. 
And actually, I might
have time to do a quick -- 
show you how to do the console.
But anyway, you can hide it
by dragging it down or also 
by clicking this
thing [inaudible]. 
All right.
So the next thing we're
going to do is we're going 
to put a little label on our
UI that counts the flips. 
Okay? A little incremental thing
that increments every
time there's a flip. 
And we do that by
going back to here 
and grabbing ourselves a label.
So a label is a read-only piece
of text, noneditable text. 
And I'm just going
to drag it over here 
and put it in the lower left.
I'm going to double-click on it
to call it "flips colon zero." 
This is what I want it to look
like when my UI first launches. 
Now here, I'm never going
to be tapping on this 
and causing a message to
be sent like the button; 
it's the other way around.
My controller wants to
talk to this and tell it 
when the flips changes
all the time. 
Okay? So you might think that
you would drag from your code 
down to this flips, but
unfortunately you don't do that. 
You still hold down
control and drag from here. 
But instead of dragging it down
into your implementation area, 
you drag it into the interface
area because you're going 
to create a property
that connects 
to that label basically.
So we do that.
We get a thing here.
It's asking us a little
bit different questions: 
"What's the name
of this property?" 
I'm going to call
it "flips label." 
Okay? Notice that
this property is weak. 
Okay? When I click connect, it's
going to make a property here 
and it's going to be weak.
This is the first time we've
seen weak versus strong. 
The reason this is weak is
because this label is held
strongly by the view itself. 
So we don't need to have
a strong pointer to it, 
to keep it in the heap.
The view will.
And if this label
ever leaves the view, 
it will get cleaned
out from the heap. 
And this property --
this pointer to it -- 
will get set to nil, which
is exactly what we want. 
Because if that flips label's
not in the view, we don't want 
to be updating it and
sending messages to it. 
So it's a great use
of weak right here. 
This is normal property
that you're used to except 
for maybe this IB outlet.
That's just like IB action.
It's a meaningless thing
the compiler ignores 
that Xcode is using.
Okay? So that it can do this
-- show you what it's connected 
to when you mouse over it.
Okay? By the way, you can
see all the connections 
by also right-clicking
on things. 
So here I just right-clicked
on the button 
and you can see its connections.
If you ever want to rename --
like if I don't like touch card
button, I want to rename it 
to something, you can't
just rename unfortunately. 
You have to go in
here, right-click, 
use this little thing
to disconnect it, 
and then control drag again.
Okay? Everybody got that?
It's unfortunate.
It would be really nice
if Xcode could track 
that for you but it can't.
So if you ever want
to rename something, 
you have to disconnect it
here by right-clicking on it, 
and then control drag a new
one and set the name that way. 
You can also right-click
on this little guy 
and it will show you all the
connections for your controller. 
Brings up this window.
And I can see the label.
You see? I'm mousing
over the button. 
Label. There's also this
little property here, 
which is something
you haven't seen, 
which is basically a
property that points 
to the entire view
from your controller. 
So this is the connections
to your controllers. 
See, it says "card
game view controller"? 
Okay? So that's right-clicking.
I'm right-clicking over here.
All right.
So how are we going to
make this flips label work? 
We are going to put
it aside for a second. 
Let's not think about it.
Let's instead do
another property. 
Property. Which is
nonatomic, which is just going 
to be an int, which I'm
going to call "flip count." 
Okay? So flip count is just
an integer that's going 
to keep the count of flips.
And watch this.
Some more space here.
Go there. I'm just
going to go down here 
and say self.flip
count plus plus. 
Okay? Now, does that
call the setter 
or the getter for flip count?
Both. Exactly.
That is calling both the
setter and the getter. 
It's calling the getter
to get the flip count, 
then it's plus plussing it;
and then it's calling the
setter to set it back. 
Okay. So that's kind of a funky
lining of code right there. 
That's the same as saying
self.flip count equals self.flip 
count plus one.
So it's calling the
getter and the setter. 
Okay. So now we've got
this nice flip count. 
It's keeping track of the
count; how do we hook that up 
to this thing over here?
Which I'm going to make a
little bigger, by the way. 
Okay. How do we hook that up
so that says flips colon one, 
flips colon two,
flips colon three? 
Well, we're going to do it
using the setter for flip count. 
Okay? So normally a setter for
flip count would look like this. 
Okay? And here's another great
use of setters and getters, 
which is to keep UI in
sync with a property. 
And I'll just do this by
saying self.flips label -- 
flips label.text
equals -- oops, sorry. 
It's hard to type standing up.
Equals NS string,
string with format, 
which you've seen before, flips
colon percent D self.flip count. 
Okay? So now every time flip
count is changed we're going 
to update the UI.
Make sense?
Any questions about that?
Okay. So let's run.
Okay. Here's our thing.
So click, flips over,
flip count updates. 
Flip, flip, flip, flip.
Back and forth working, and
the flip count is keeping track 
of how many flips we're doing.
Okay? So you can see this stuff
is really simple to wire up. 
Okay? And, you know,
when you get 
into building even
complicated applications, 
because you're always going
to use these same mechanisms 
with target action and
outlets and you're going 
to be using setters and
getters to keep things in sync, 
it's going to be easy for people
to understand how
your code works. 
They know where to look to
see where UI updating happens, 
etc. I'm going to do
one other thing here. 
Take a minute and
show you NS log. 
Okay. I told you that you could
log something in the console. 
So let's do every time
this thing changes, 
let's do an NS log.
So it's just a C function.
And you give it a format
string like printf. 
So I'll say flip count equals
percent V self.flip count. 
Okay? So you just put
that NS log in there, 
and now when we run you're
going to see it in the console. 
It's going to come up when
I click, and it's going 
to say what happened here.
By the way, of course,
I can make that wider. 
And go back to the simulator.
Let's see.
Okay. So NS logging --
awesome way to debug. 
Okay? Sometimes a lot easier
than setting a breakpoint 
and then when you
get there looking 
at the variables and stuff.
It just prints out what's
going on and you can watch it. 
Especially in the UI things
are sometimes animated, 
they're happening over time.
It's sometimes hard to set
a breakpoint in the middle 
of an animation to
see what's going on. 
But if you do some
NS logs, you can kind 
of see how things progress.
All right.
The last thing I'm going
to show you here is how 
to add a new class to your app
because you're going
to need to do that. 
You're going to add
four classes to this. 
Okay? You're going to
start with this, okay, 
and then you're going
to add four classes -- 
card, deck, etc. And the way
you add a class is you -- 
and in fact, the way you add
any file to your project -- 
is you go to the
file menu, new file. 
Okay? And there's
all different kinds 
of things you can add
here, database file, 
schema files and everything.
But you want this one
top-left Objective-C class. 
Okay? Here you're just going
to type the name of the class. 
So for example, if
I'm going to add card 
and the name of the superclass.
Okay. If you are doing playing
card, you can type card here. 
It doesn't have to be something
that's chosen from this list, 
okay, which are the iOS ones.
So here I'm going to make card.
I could put card right here.
It's asking where to store this.
I could put it right
in the same place 
that my card game
controller is, you see? 
But I'm actually a big fan
of putting your model
in its own directory. 
So you would use new
folder down here. 
Let's create like
a model directory, 
and that creates a
model directory here. 
There's a controller,
here's the model directory. 
And so create.
So that's going to create card
dot H and M. Here's card dot H 
and M, okay, kind of
blank versions of them. 
You can switch back and
forth between them here. 
Notice that if I
switch the left, 
the right changes to match.
You see? Change this,
this matches. 
That's because I have
counterparts chosen right here. 
If you go to manual and
pick this file manually, 
then it won't be doing
that magic anymore. 
But you can always go
back to counterparts 
and it will keep them in sync.
Okay. So you can have -- some
people like their header file 
on the left, some on
the right, whatever. 
Also, notice over
here it would be nice 
if I can also group these
things in the navigator. 
And I can by having them
selected right-click new group. 
Say model.
Right here.
And now I've put my model in
its own little place right here. 
I can even move this around,
put it down here, whatever. 
I could put all my
four classes in there. 
It is possible to link this
group to the file system. 
In fact, if you just click on a
file and bring up the inspector 
on it right here, you can see
that it's got this location 
where you can specify
whether it's an absolute path, 
or relevant to the group
it's in, or whatever. 
So you can control that.
And that's it.
So I think that's all you
need to do your homework. 
You're just going to type in
all your code here for card 
and add your three other ones.
Type all that code in.
And then all you got to do
is make that card instead 
of showing ace of
clubs all the time, 
needs to go through
the deck, okay? 
There's a detailed
homework write up posted. 
It has all kinds of hints
and help, and tells you 
about what the required
tasks are, 
and evaluation criteria,
and all that stuff. 
So definitely read that
thing in detail, okay? 
Don't skip that stuff and just
try to go straight to doing it. 
And if you have questions,
I'll be here. 
That's it.
>> For more, please
visit us at Stanford.edu. 
