English Subtitles for Stanford University Developing iOS 7 Apps: Lecture 2 - Xcode 5

Subtitles / Closed Captions - English

>> 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.

Video Description

This is the second lecture of the course as it was published by Stanford University. It has Creative Commons rights.