Good morning. My name is Paul Marcos. It's great to see so many of you here this morning, even you, Dan. We have a terrific mix of people in the crowd here at WWDC this week. We've got a whole bunch of people that are familiar with the Mac already, like our friend Dan here.

And as such, you're familiar with the operating system and the tools and the language that we use for developing iPhone applications. And that gives you a great leg up. And then on the other hand, we have a whole bunch of new people to Apple and to WWDC, and a number of you are coming from other mobile device platforms like Windows Mobile or Symbian or Blackberry. And you guys understand the issues that face mobile application development, things like limited resources, a small screen size, the challenge of building a usable and friendly application on a small device like that.

And so we have this new platform now that faces all of those same challenges, but it's built on top of that great technology from Mac OS X that so many of you are familiar with. And that's what we're here to talk about this morning. So this presentation is going to be mostly conceptual in nature. We're going to look at a little bit of code. We'll do a little bit of interface stuff. But what I'm covering is primarily the designs behind Cocoa Touch on the phone and iPhone OS development.

There are a couple things that are helpful for you to know about going into iPhone app development. And the two primary ones are just object-oriented programming in general, and whether that's from Java or C++, or even some of the scripting languages that use object-oriented principles these days. And the second is the C language syntax. The language that we use is C-based, so understanding things like pointers and memory management is really helpful.

So the topics that I'm going to cover here this morning are just a real brief overview of the OS. You heard a lot about it yesterday. I can add a couple points to that. And then I want to go through three steps. And I remember when I joined the iPhone team about two and a half years ago, I thought what the heck am I doing developing for a mobile device? I've never done that in my life.

I had come out of the Mac OS X desktop world, and, you know, I was very intimidated and scared. And typically when I'm faced with a new platform, I like to break it down into three steps that I try to perform. The first is I just want to get something on screen. I just want to get the app to launch and get something on screen so that I understand, you know, the tools that are required to get that far and how to get something on screen.

And then the next thing, I want to make it do something very simple, just a button, hello world, something really, really basic. And then with all of those pieces in place, then I can kind of embark on building a mobile device that I can use to build the rest of the application and making it do something.

And so in my case, when I joined the team, I started on that app. I went through these simple steps. And that app that I had started and used as my beginning ultimately went on to become the Photos application that we ship on the phone today. So it turned out I was able to develop on a mobile platform. And it was actually very familiar, as you'll see here.

So let's just jump in with a quick overview of the OS. And as you saw yesterday, we have this layer diagram that we use showing all the different layers of the operating system. And the important points are the lower three are the same as Mac OS X. So for those of you coming from that direction, these are very familiar. They're the same layers.

As iPhone app developers, we're going to spend most of our time at the Cocoa Touch layer, because that's where most of the services that we use and that we need exist. And the point that I wanted to add here was for each of these lower layers, you can feel free to dive down as needed.

And in some cases, you may need to open a raw BSD socket. So you can just open that directly if you have existing code or whatever. Or at the core services layer, you may need to use SQLite. So you have those APIs. So you may kind of need to dive down for those.

Or even at the media layer, if you're doing something with audio, we have audio libraries for you to use there. So while we'll spend most of our time at the Cocoa Touch layer, just keep in mind, you can dive down as needed to any of these other layers that you need.

So talking about the Cocoa Touch layer, it's broken into two frameworks. The lower level one is Foundation Framework. And this is, again, the same as that exists on Mac OS X. So if you're familiar with that, you already know a whole bunch of these APIs. It's all the same. It's a subset of what we have there.

Paul Marcos And in this framework, we have object wrappers around basic data structures, arrays, and dictionaries. And then we also have object wrappers around a bunch of system services, like accessing the file system or some networking APIs. Paul Marcos So a lot of kind of lower level non-UI pieces. Paul Marcos The upper portion of Cocoa Touch is UIKit Framework. And that's where the machinery for running the application exists. Paul Marcos That's where the windows exist and the views that you're seeing. Paul Marcos So we've added some APIs for accessing the device of this same layer.

So I've used the term framework a couple times, so I want to just talk a little bit about what a framework is. So to Apple, a framework is a way of packaging our system interfaces. And it's physically a way of packaging it on disk, where we have a directory that contains not only the binary for the code that is in that framework, but also any associated resources, like the header files that you need to build and link against that framework, or things like in UIKit, the resources, the images and sounds, and all the pieces that we need to actually present the UI at runtime.

And since we ship in now a zillion languages, we also have all the localizations. So it's this nice self-contained unit where all of the pieces that are associated with the framework go. On Mac OS X, you're probably familiar with System Library Framework in the file system. When you install the iPhone OS SDK, they're installed in the platform SDK in this path.

And as an app developer, you live on top of the frameworks, and there's this notion of living with the frameworks, and most importantly, working with the frameworks, not against them. And so what do I mean by that? Well, for the people that are new to the platform especially, you may come to Cocoa Touch, and it's very natural to try to apply the same design approaches that you've applied on other platforms to this platform.

And what you may find is that you may encounter some impedance mismatch with the way that you've done things in the past and how we do them in Cocoa Touch. So it's important to step back and try to get your head around kind of the big picture design of Cocoa Touch, and that's what we're going to be trying to do here this morning and the course of this week.

For example, a lot of the classes in the frameworks that we provide are intended just to be used right out of the box. No modification. You just take them, you use them, they do something, and that's great. Other classes are explicitly intended to be subclassed. They provide some generic behavior, but really can't do anything without the use of a subclass. And one of the best ways to understand which of these cases you're looking at is just to use our documentation. So I'll give a plug to the documentation that we have.

In particular, there are two documents that I wanted to call out that are really important for you to understand. The first is the Cocoa Fundamentals Guide. And while written for the Mac OS X Cocoa framework, so many of the designs are the same in Cocoa Touch. So it just gives a great basis for a number of the designs, defines a lot of the terminology and whatnot that we use on the phone as well. And then the second is the iPhone OS Programming Guide, which is more specific to the phone itself. So two great documents give you an understanding of what the frameworks are all about.

So the design patterns that we're going to talk about here this morning, there are three that I'm going to focus on. The first, you've already heard some about each of these. Model View Controller. delegation, and target action. So let's just jump in with Model View Controller. The fundamental premise of Model-View-Controller, which you may already be familiar with from other platforms, is a separation of the model and the view.

And on the model side, you have kind of the back end state of your application. The data that's stored, some basic logic of your application, but nothing in the UI. And then on the view side, you have the presentation of that data. And you want to try to encapsulate both of these things separately so that they don't need to know much about each other. Ideally, nothing about each other.

But then you have this kind of division here where the rubber needs to meet the road at some point. How does that happen? Well, that's the job of the controller in the middle. And what the controller does is mediate between these two worlds. It pulls data out of the model and hands it to the view for presentation. And then as the user interacts with the view, it intercepts those interactions and performs some manipulation of the data.

So looking at how this breakdown of Model-View-Controller applies to the frameworks, we see on the model side, we have foundation framework. And as I said, that's the non-UI portion of the framework. And then on the view side, we have UIKit, and in particular, the UIView subclasses. And we'll talk about UIView a little bit later. And then in the center, since we only have two frameworks, we had to find a place for it, the controllers actually exist in UIKit.

And we've put the idea of controllers under this umbrella that we call "view controllers." And you'll hear that term in the iPhone sessions over and over because it's really, really fundamental and critical. But these pieces are only half of the picture. The other half is your code, which exists in all three places. Right, and so there's this notion of your code with the framework code, and that's what makes up the building blocks for the application.

And when we write our apps, and we've written a bunch of apps, we've kind of strived to keep this breakdown of the model view controller. And we try to do that because it really helps produce cleaner code. It forces us to think about, for particular chunks of functionality, where does it exist? Is it in the model? Is it in the view? Is it in the controller? We try to maintain a discipline of keeping clean APIs between these pieces.

It helps with just understanding how something works, especially as we get new engineers joining teams. They can kind of easily break down functionality in an application and get a quicker, a quick understanding of how the code works, how it's structured. It makes it easier to test when you have these nice APIs, these well-defined boundaries. You can do things like write unit tests and test the functionality of just an isolated component.

We've also found that it helps with reusability, so that when you do define these modular components, you can use them in ways that you never foresaw when you initially designed them. And for us, that happened when we decided to put a public API on top of our APIs. We realized we already have a whole bunch of these modular units that we could expose the APIs and give functionality to you very easily.

And perhaps most importantly, is when you do follow this model view controller paradigm, it just naturally aligns you with the way that Cocoa Touch works and kind of puts you in the same buckets and puts you amongst the friends and classes that we use in those same buckets. So that's just a brief overview of the fundamental concept behind Cocoa Touch and Cocoa on the desktop, Model View Controller. And what I wanted to do next is just start off with step number one. Let's get something on screen.

Now, in order to get something on screen, we need to understand the tools that we're using. And as you saw yesterday, we have some awesome tools for developing apps on the phone. We have Xcode for editing your source code and maintaining your project, Interface Builder for laying out your interface and graphically connecting objects. The iPhone simulator for doing rapid application development all on one screen, right in the convenience of your own Mac. You can just do it right on your screen.

It's really easy. You can turn around, compile, link, debug. It's a great environment. And then when you need to, flip a switch and you're running on the device. So these three we're going to look at today, and then the fourth, instruments, which is kind of outside of the scope of this presentation, for doing performance analysis and tuning.

So let me just start off with a quick demo just to set the stage for our concepts. And the demo that I'm going to be working on is a very simple app. If I can wake my notebook up. It's a hello world class application. So it's very simple, again, just to kind of set the stage for discussion. And it's basically just going to be a light bulb on the screen with a switch and a label that we update some status.

So I'm going to bring up Xcode here. We're just going to start a brand new project. And the template I'm going to use is this view-based application template, which is a very generic starting point. So we'll pick that. I'm going to save this as demo on my desktop. And here we have our project.

So as you saw, we have a number of classes in here. We're going to come back to the code later because our primary goal right now is just to get something on screen. We have a couple resources, which are the interface files that we'll be working with. And I have a few additional resources on the desktop, just some images. So I'm just going to drag those into my resources bucket, tell Xcode to copy them into my project.

And there we go. So in this template, we have two interface files that get created. And I just wanted to point out the first one is this main window nib. We're not actually going to do any work in here. I just want to call attention to a couple things. One is that in the document window, we have a handful of objects. And these objects live in the nib, or they may be proxies for other objects that live in the application. And we'll come back to talking about a couple of these objects in a little bit.

The other main thing that we have in this particular nib is the main window for the application. And again, we're not going to do anything with the main window. And generally, you don't need to know very much about the main window. Just that it's here in the main nib. It gets created automatically. And it's the container in which all of the views that you build go inside of.

And in this case, we see the contents of our main window is this view. NIB is telling us this particular view in this template is loaded from this demo view controller nib file. And that's actually where we're going to do our work. So let me go open that. So that's this second nib here, this demo view controller. And again, this nib has a couple objects up here that we'll come back to. And then it has our view file, which is our blank canvas for us to work in.

And the first thing I want to do is actually the background in this template is white. The images I'm using have a black background, so I want to change the background color. So if I go into the Tools menu and bring up the Attributes Inspector, I can just change the background of this view, and I'm going to change it to black. There we go.

And now I just want to pull out a couple of interface pieces. So I go over to the library window, switch to the media, and you see IB has recognized those resources that I dragged into my project. And I'm just going to drag out one of the images, this beautiful light bulb.

And then the other two interface elements that I want to pull out are the switch that I'll use for turning the light bulb on and off, and then a text label. And one subtle thing-- I think IB is such an awesome tool. I love it. You notice as I'm dragging this text label, it's black. And then as I drag it over the black background, IB notices and inverts it so it turns it white, which is just really nice, nice little touch. IB's full of those. So let me set some default state here. Turn the light on.

Oops, center that. And since the light actually is off, I'm going to change the state again in the attributes inspector so that the default position is off. So now we have some interface laid out. That's all we're going to do in Interface Builder at the moment. I'm going to go back over to Xcode. And the other thing I wanted to add was just an icon for our application. So I'm going to go to the Get Info window for the target we're building. And on the Properties tab, just fill in the icon name.

And I think that should be it. Let me just build and go there. We'll see what happens if I missed anything. So the app is built. The simulator launches automatically. It's installed in the simulator. And there we go. Now we have our interface. We've succeeded in step number one.

We've seen the tools. We've gotten the application built. And we've got something on screen. It doesn't do anything because we haven't hooked anything up. But that's a good starting point. And it sets the stage for-- if we go back to slides now-- So if we look at what we saw, what we got out of that, basically we got the application infrastructure.

We got the scaffolding of an application from which we're going to start to build. We got the main window loaded, and we had that empty interface that came out of the template, and we started adding stuff to it. One note, there's a handful of templates that come with the SDK, and you should kind of take a look at each one of those to understand, you know, for any given application, which one is the best starting point. This one is fairly vanilla. The other ones have a little bit more structure to them. So kind of get to know what the templates are.

So what I wanted to go through now was kind of what happened when the application launched and set the stage for the application lifecycle. And as I mentioned, we are a C-based language, and as just about every C-based program in the world, we start life in main. We have a main function that's in the template. You can see it. It doesn't do very much. It basically hands off control immediately to UIKit. And in particular, it calls a function called UIApplicationMain. And that's kind of where the application really starts to take off.

One of the main things UI Application Main does is it creates the UI Application Object, which is a shared global object that effectively runs the application. It's kind of in charge of all the app behavior. And at this point in time, at the launch time, its primary goal is to get us to the event loop as quickly as possible, because that defines what your launch time is. And we want our launch times to be as short as possible so that the apps feel responsive, And we're now listening to the user.

But along the way, we do a couple very important things. One of the most important things is we'll create this object on the side called the UI Application Delegate. And it's an object that works with the UI Application Object. And as you can see, it's a delegate. So what is a delegate? We're going to kind of take a little side turn here and talk about delegates a little bit. And this is the second kind of key concept that I want to cover here.

So what a delegate is, delegation is a way for you to customize complex behaviors. And you can do so in two ways. One is you can provide input kind of along the course of a behavior that's being done. So you can kind of fine tune the generic behavior that UIKit provides.

Paul Marcos And the second is there are clearly defined call outs for kind of beginning before something happens, you get a call out, and then after something is done being performed, you get a second call out. So you kind of have these interesting before and after points where you can hook in code and customize behavior.

Delegation is seen as, you can look at it as an alternative to subclassing. Where subclassing, sometimes you may want to override a behavior, but you don't want to override the entire behavior. You may just want to kind of interject certain things in the context of a superclass's method. And if you want to do it in the middle of a superclass's method, you really can't do that with a subclass. So using delegates kind of gives you those interesting points in the context of the superclass's implementation where you can interject some code and behavior.

Another problem with subclassing is it may be confusing, like, when do you invoke your superclasses implementation? Do you have to do it at the beginning? Can you do it at the end? Can you do it in the middle? Can you do it multiple times? Do you have to do it at all? I mean, usually the documentation will make this clear, but sometimes it doesn't.

And by separating these behaviors, and especially these chunks of code that get interjected in the context of a superclass's implementation, it keeps specific logic in the right place. The generic behavior in the superclass's UI kit implementation, and then specific code that's interjected kind of off on the side in your code.

So I wanted to go through an example of how delegate works, just to give you a flavor of the kind of interchange between the UIKit objects or the framework objects and your objects. And the example I'm going to use is a text field. So it's a pretty simple example, although editing text is, while simple, made up of a number of steps. So in UIKit, there's an object called UITextField, which is the visual representation of the text field. And it allows for a delegate.

And when the user comes in and clicks on the text field-- and I should also say, throughout the course of this week, all of the engineers are going to say click. And when we say click, we mean tap. We think of it roughly the same. It's a single event. You tap on something. So just in your mind, when we say click, think tap. So the user comes in and taps on the field.

And before the field is actually made editable, the UI text field will check in with the delegate and say, should I begin editing? And this is a point where you can refine this behavior. And you can determine, given the current state in my application, is it OK to allow the user to edit? And you can indicate yes or no.

And so in this case, we're going to say, yeah, sure, go ahead. And then just before the text field is actually made editable and the user starts editing, the text field will come back to its delegate and say, OK, I'm about to begin editing. And so this is kind of your before hook that you can hook into. And you can do any kind of setup or preparation that you need to in order to edit this text field.

And then after that, the text field is made editable. The user can edit the text. And when focus goes away from the text field, then the UI text will come back to its delegate and say, OK, now we're done editing. The operation is finished. And so you can take the value out of the text field. You can respond to it in whatever way you need to. And that's kind of a very typical flow of a framework object going to its delegate and asking for permission or clarification of what should be done.

And then a before the action and after the action callback. Thank you. And you'll see delegates used throughout our APIs. And here's just a small handful of them. The text field in the middle, the UI table views, even things like web views have delegates and participate in the complex operation of displaying and loading a web page.

So let's go back to our lifecycle diagram and drill into a little bit more detail of how the UI application object and its delegate work. And as I said, the UI application delegate is your code. So you specify or you provide the code for this object. And it conforms to the UI application delegate protocol.

And when we say the word protocol, all that really is is it's a specification of a set of methods that an object agrees to implement. Many of the methods in a protocol may be optional and they're defined as optional. Some of them are required. The required ones, obviously, you have to implement.

And in the UI Application Delegate case, here's just a couple of the methods that we have. UI Application did finish launching. And that's an interesting one because it's the first point where your code gets control of execution. And you almost always implement it. In fact, it's implemented in the template. I'll show you that in a second. It's a very, very common place for you to put some code. And then another very common place is in application will terminate. And that's kind of the last stop before the app exits.

If we look at the details of the application delegate and the application object, what happens at launch time, the UI application will load that main nib file that we saw. And along the way, it creates that main window. And one of those objects that I mentioned was in that interface file is actually the delegate itself. That's actually where it lives. And when that nib file is loaded, that's when the application comes into existence and is actually instantiated. and it gets set as the application delegate.

So once these things are done, then the UI application calls over to the application delegate and calls the application didFinishLaunching method if you implement it. And in that method, typically you will load some state and then configure the UI, whether that's the initial time your app is launched or you may be returning the user to whatever point they were at the last time they launched your app.

And the important point to note here is the main window, while it's been created, has not been shown on screen yet. So you can do any of this setup, and it's before the user sees anything. So whatever setup you make, that's the first thing they'll see. So once you're done here, then the main window is brought on screen, control flows back over to the UI application object, and then we drop into the main event loop, and the app is up and running.

So just to cover this briefly, UIKit drives the process. In reality, UIKit is really--it's in the driver's seat. You primarily are just kind of along for the ride. You're giving a lot of directions and telling us where to go, but UIKit is really driving the machinery. We've seen how you can customize the behavior in UIKit using delegates, and in particular, the UI application and its delegate work together through a set of methods where you can refine the behavior of the application.

So that's step number one. We've got something on screen. Now let's talk about making it do something, because that's the interesting part. And in order to make it do something, we have to cover two topics. The first is the language that we use, because we're going to write some code. And the second is how to actually connect the view to the controller in order to respond to the user in some way.

So the language that we use is Objective-C. For those of you that haven't seen Objective-C, it's a superset of ANSI C. So it's based on C. And on top of straight C, it adds object-oriented extensions. And it tries to do so in as minimal a fashion as possible in order to add these object-oriented principles-- encapsulation, polymorphism, inheritance, all the things we know and love about object orientation. It's single inheritance.

It has a dynamic runtime, so we can do things like the UI application object can ask whether an object implements application did finish launching. We can do that runtime dynamically. And we've gone to great lengths to prevent throwing in a kitchen sink, piling on a ton of syntax. We try to keep it as simple as possible.

It's a very easy language to learn. I've seen a ton of Apple engineers that are new to the company come in and learn it. And one of the common things that people ask when they come into Apple is, you know, oh, I'm going to have this ramp-up time with Objective-C.

You know, I'm going to need a week or so. And in many cases, like, by the end of the day, they're writing Objective-C code and feel very comfortable. And I think it's a fun language. It's very lighthearted. It's easy to learn. It's fun to use. I love it. And I hope you will, too.

For those of you that are familiar with it and already love it, I should point out we support Objective-C 2.0, which was added in Leopard. So things like properties and dot syntax and fast enumeration, we have support for those. One notable exception is we do not support garbage collection. So on the phone, memory is managed manually.

And that's critical. And we spend a lot of time focusing on memory management, making sure we're not leaking, making sure that we're allocating memory only when we need it and only the amount that we need. because we have limited resources, so it's important to keep your memory under control.

So let's just look through a couple simple examples. So in C++ and Java, you'd invoke a syntax method like this. In Objective-C, slightly different, same pieces involved. You'll see the square brackets around the message send. You'll come to love square brackets. They're a great thing in the language. And if I may, I hope not to offend anybody, but I consider myself part of this crowd. But for the older folks in the crowd, you might recognize some of this. It's similar to Smalltalk. In fact, Objective-C has kind of a heritage from Smalltalk.

Another example, looking at a method called with arguments. So here's what we'd call subtract with a couple arguments passed. Here you see a little bit, again, slight difference. Some identifiers that precede the arguments that are passed in. And this is a subtle thing and frequently sparks religious debates, but we think it's really important. And it helps just produce readable code, highly readable code. And when you couple this language feature with the design that we have of our APIs, you find that our APIs are very verbose. We're not afraid to use our words.

And we try to really make our APIs expressive. We also try-- and this is sometimes borders on the ridiculous-- we try to be grammatically correct. We have a subject and a verb. You know, we pay attention to these things. We have debates at Apple about these points of the API design.

But we take our APIs very, very seriously. We try to make them highly consistent. In fact, you'll see consistency not just from the Cocoa Touch layer, but even the layers beneath it. We try to maintain a consistency so that when you do encounter a new API, it feels familiar. And when you see new code, you can just start reading it and get an understanding of it.

Another example of declaring a method. Again, slightly different syntax, same basic principles. Is it an instance method? Is it a class method? What are the arguments? What's the return type? It's all the same basic C types, C stuff that you would need to put in there. So there's a session on Objective-C that would be a great thing to go to if you're familiar, if you're new to the language especially.

And then there's a lab on the Objective-C 2.0 specific features that have been added. And I wanted to point out about the labs. The labs are this remarkable opportunity, especially for the folks that are here in person, where you get to sit down and meet the engineers one-on-one. You can ask questions, and these are the people that designed this stuff, so we generally have an idea of how it works.

You can ask us any questions. We're happy to talk about the design of your apps, how you should use the APIs effectively, pitfalls, things that you might want to avoid, stuff like that. So go to the labs. They're really, really awesome. We've got a ton of engineers here. They're a great, great opportunity to take advantage of them.

There's also some documentation. Again, documentation is great that we have on this. There's an Objective-C 2.0 language guide, covers all the details of the language itself. And then another guide that I wanted to point out is this object-oriented programming with Objective-C. And as you look at any kind of object-oriented environment, everybody has their own spin on it. They have a certain set of terminology, they use the terminology in a certain way, and we're no different.

And the important thing about this document is it gives you our view of object-oriented programming from the perspective of Objective-C and also from the perspective of our frameworks. So again, it helps with that step back, get a big picture around the frameworks, the designs that we use, and reduce that impedance mismatch.

So that's the language that we have. And now let's talk about how we connect the views to the controllers. So that we can listen, we can respond to the user input. And so the user interacts with the device, with the user interface through the views, and they do so through three primary means. One is through standard controls, the buttons and sliders and switches and things.

The second one is through custom views that you create, and whether that's custom controls or a custom view where you're presenting data in a certain way and allowing the user to interact with that in a particular way. And then the third way is through sensors on the phone and the iPod Touch, through sensors like the accelerometer, where the user can just turn the device, and that's a form of input indicating that they want to either rotate the interface or that they need to see something in landscape mode.

And so the controller objects tend to be the ones that are responding to that input and actually performing some action. So the views that the user interacts with are instances of the UIView class. And UIView provides two key roles. The first is it just gives you that rectangular region on screen to present content, whether it's an image or content that you're drawing on the fly. It's just that space in the screen real estate that you have to work in. And then the second thing UIView does is it responds--it handles the events. It's kind of where the basic event mechanism is hooked in.

And one note on the event side, UI views are single touch by default. So when you create a UI view, it will only respond to a single finger. If you do put two fingers down or more fingers down, it will only respond to the first one that we see. The other ones will basically be dead to us. There's a switch that you can flip to turn on multi-touch, but just keep that in mind that views are single touch by default.

In the context of responding to the user, the interesting subclass of UIView is UIControl. And both UIView and UIControl are abstract classes. In the case of UIControl, we have this whole collection of controls that we have out of the box, all the common things that you would expect.

And what UI Control adds to the party is the notion of responding to events and invoking actions. And the events that it responds to are things like touchdown, touch up, drag events, or in the case we're going to use here of the switch, just a simple value change. So we've gone from off to on.

And in response to particular events, a control will invoke an action commonly on the controller. And we've given a name to this idea, and that's target action. And this is the third main concept that I wanted to cover here today. So simply put, target action is just connecting this control to the controller.

And in the example I'm going to use, the event that's going to be generated is a value changed event. So when the switch moves and turns on, the value is changed. And in response to that event, the control will invoke an action on the target, the target here being our controller object. And the action that it's going to invoke is this toggle light method. And we'll see that in code in a second.

And this notion of the target action, controls responding to an event, invoking an action on its target, is the same as what's in Cocoa on OS X. So for those folks coming from that direction, same exact concept, same exact mechanism. And you're familiar with the limitation of a control has a single target action. And sometimes if you've needed to invoke multiple actions, you've had to do that in your code, have the control invoke your action, and then you manually invoke other actions. Well, in Cocoa Touch, we've extended this.

And we've added the support for having multiple targets and actions. So now in the demo that I'll do here, we're going to have a second action that's invoked on our controller, which is the update label method. And so you can have an arbitrary number of actions triggered by different events. They don't all have to be the same event. You can hook different actions up to different targets to different events. So it's -- it's a nice set of flexibility that's kind of grown out of Cocoa.

So with that stage set of the language and now knowing how we hook up the view to the controller, let's actually write a little bit of code. And so these are the two things that we're going to do is actually connect the views graphically in Interface Builder and then add action methods. So let me go back to our demo.

I should point out from our previous demo, you can see we have our beautiful icon here. It has the lovely glass reflection added automatically. That wasn't in the icon itself. So now to add the code, let's have a look at some of the classes that got created here.

Give myself a little room. So here you see we have the AppDelegate class. This is in the template already. If we look at the code briefly here, you can see here's the application didFinishLaunching method. So we're all ready for just hooking in whatever launching logic you need to add in there.

We're not going to do anything with the AppDelegate. It works just fine as it is. Where we're going to add our code is over in the ViewController. So this is our controller class. And I'm going to add two things in the header file. The first is a handful of instance variables, one for the image view, which was that light that I dragged into the interface, and the second is for the label that was up at the top of the window.

And then in addition to these instance variables, I'm going to add declarations for a couple action methods, the toggle light and the update label method that we saw a second ago. And I wanted to point out a little bit of the syntax here, just because this historically has caused some confusion for people, and people seem to wrestle with it, so I'll try to demystify some of it.

There are these IB outlet and IB action keywords, and those aren't part of the language, those are just a little bit of syntax that gives a hint to Interface Builder that these things are items that should appear in the lists in Interface Builder that the user can connect to. So in this case, the IB outlet for the two instance variables, those are outlets that can point to user interface elements, and the IB action indicates that these are action methods that are going to be used to connect to the user interface.

Paul Marcos And then in addition to these instance variables, I'm going to add a little bit of syntax here, just because this historically has caused some confusion for people, and people seem to wrestle with it, so I'll try to demystify some of these instance variables, those are outlets that can point to user interface.

So now with those hints in place, actually if we go over to Interface Builder now-- actually, let me get rid of the simulator there. If we go back over to Interface Builder to our demo view controller nib file, I wanted to talk a little bit about the objects that are here.

This files owner, again, this is a concept that takes a little bit of getting your head around. But what the files owner is, this icon is a representation of the object that is loading this nib file. And it gives us that icon that we can graphically connect things to. And those connections are formed at runtime. This object doesn't actually live in the interface file. We just have an icon here, which at runtime, the the real object is plugged into.

And in our case, the files owner is our demo view controller object, the one that I just added a few instance variables and action methods to. And if we look at -- let me bring up the view here. If I select the files owner over here and I go down to the connections inspector under the tools menu, we can see the list of things that can be connected to this object. And now this list contains those items that I added in the header file, namely the image view, the label, and the two action methods down here.

So those are the pieces that we're going to connect. And first I'm going to add-- I'm going to form connections for the outlets. So for the image view, I just drag from the little connection circle here, drag over to the light, and let go. And that sets that connection. And then for the label, I just drag that over to the label and let go.

And now we have those connections formed. And when the nib file is loaded, those instance variables will be set to point to the objects that are in the interface.

And now we can see in the inspector we have multiple target action connections from our single switch for the value changed event.

And I think those are all the connections we need to make since this is a simple app. So I'm going to save the nib file and we'll go back to Xcode and now actually add some code. And you can see from-- oops, that won't be good. Well, you can see in the template, there's some methods here that are implemented that you can choose to add, extend if you need to. But we're just adding these two new action methods.

And like any good cooking show, I have it ready in the oven. So we have toggle light and update method. Both of these are basically the same. Again, I'm just using this as a setting the stage for the discussion. In both of these cases, the methods take a single argument, which is the sender. And the sender is the object that is invoking this action. In our case, it's the instance of that UI switch object.

And so in both of these cases, we're just going to ask, is the switch on? And if it is on, we're going to do one thing. And if it's off, we'll do something else. In the case of when it's on, we set the image of the image view to the on PNG image. And if it's off, we set it to the off PNG image. Those were two of the images that I dragged in earlier.

And for the update label, we do basically the same thing. If the switch is on, we set the text of the label to one thing. And otherwise, we set it to something else. And so now we've implemented our actions. Let me save that, build and go. And now hopefully-- there we go. Now our light turns on, the label changes at the top. And you can see that single event, the value changed, is triggering multiple actions at the same time.

So that's, I think, the rest of that demo. Oh, and then as you saw yesterday, In order to build it on the device, we would just select the device from the active SDK, build and run, and would install it on the actual device, and we'd be off and running.

So now we've accomplished goal number two. And if we go back to the slides-- We can see the things that we saw there were we connected the user interface to the controller in the back. We implemented a couple action methods, and we used target action to respond to an event in order to invoke an action on our controller.

And we used multiple target actions for a single control. So a couple other points about the actions. You can define your actions in three ways. This is again an extension from the Cocoa mechanism, where we use the middle one, which is the same one that Cocoa uses. But there's a single sender argument.

You can also define the action methods with no arguments if you don't care who it's coming from. Or if you need additional details about the event that caused this action to be invoked, you can pass an optional with event argument. And then you can introspect the event and see what was going on in more detail.

Our outlets that we hooked up to the user interface get defined as instance variables. And again, just to drill this point home, IB action, IB outlet, these two lines are copy and pasted from our source code. They're nothing special. IB outlet, in fact, just disappears altogether. IB action is synonymous with void. So don't let that confuse you in any way. It's really, really simple.

There are a couple sessions on Interface Builder and designing apps. There's an introductory one and a more advanced one. And then the third-- oh, our session got renamed. 2D Graphics and Animations for the iPhone and Mac. Learn about animations. If you're going to incorporate animations into your application, you can do so and learn about controls and views.

And just to wrap up the make it do something section. So when you're writing Cocoa Touch code, you're writing that in Objective-C. Keep in mind that the lower level frameworks are primarily C-based. So you may have this mix of Objective-C and C code if you're using lower level frameworks. And you're also free to use C++ if you have existing classes that you want to leverage on the iPhone. You can bring those over and you can intermix all three of these. You have a lot of flexibility there.

Paul Marcos Target action for control, connecting your controls to invoking actions in response to particular events. And we used Interface Builder for forming those connections graphically. You can certainly do the, make those connections. In code, if you want, it's just a heck of a lot easier in NIV just to drag them.

So that's step number two. We've made our app do something. And that brings us to step number three of expand it and actually turn it into a real app. And at this point, you're faced with probably one of two choices in which direction you're going to go. Either you'll probably go an OpenGL direction if you're doing game development, say, or you may stick with the native UI kit Cocoa Touch interfaces, such as most of the apps that we ship on the phone.

If you are doing game development using OpenGL, we have OpenGL ES 1.1. If you have existing OpenGL ES stuff from another platform, another mobile platform, say, you should be able to bring that over. And we've seen a ton of these games come over in no time because they're implemented using OpenGL.

There's a session for game development for the phone in particular, and then a more general 3D graphics for the phone using OpenGL ES. So if you're doing game development, these are of interest to you. And we're not going to talk much about the OpenGL stuff. I'm not an OpenGL programmer. We're going to talk about the native interface side.

And as you expand your app, one of the things that we found when we expanded our apps and turned them into real apps was we saw this design approach kind of emerge of designing our applications one screen at a time. And you'll hear this a number of times through the session of focusing on presenting one screen of data at a time.

Paul Marcos And here's an example of our clock application where we have a small number of features in the application, each one presented in its own screen with control at the bottom for the user to switch between those screens. Paul Marcos So we just present one piece of functionality in a screen at a time. And this is a pretty common design that we've seen emerge, this kind of tab switching approach.

A second one that we've seen emerge is a hierarchical navigation of data. You see this in the iPod application or in this example, the app that's near and dear to my heart, the Photos application, where we have three primary levels in the hierarchy. We have the list of albums that the user has in their photo library.

As they select one of the albums, we drill down to a second level that shows the thumbnails. And then as they select one of the thumbnails, we go down to the full screen display of that image. So one screen at a time, presenting specific information along the way.

Another design aspect that we saw emerge as we built these things is the notion of coupling the screen with a specific controller. So a one-to-one mapping of a screen full of content with the controller that manages that screen. Paul Marcos In this case, we have a library controller that's solely responsible for the list of albums. We have a thumbnail controller, which is just responsible for the presentation of the thumbnails. And then we have a separate controller for the full screen display of displaying just that one image.

Paul Marcos And each controller is just responsible for the screen full of content that it's managing and responding to the user as they interact with that. Paul Marcos So you can see we have this very clear separation of the view from the controller and sitting behind that to roundup the screen. Paul Marcos And what we found out the model view controller design is the image database that we have of images synced over from iTunes or taken on the camera from the phone.

Paul Marcos So very clearly delineated model view controller pieces. We practice what we preach. Paul Marcos And this notion of pairing the screen full of data with the controller gives you this nice modular unit of functionality, which then as a module can be plugged together with other modules in interesting ways.

Paul Marcos So here we see these three are plugged together hierarchically. Paul Marcos And in UIKit, there's an object that facilitates that hierarchical navigation, which is in the view controller category. Paul Marcos We call it a navigation controller. Paul Marcos And it manages this navigation from one unit of functionality to another, where you're providing the logic in that controller for any one screen full of content at a time. Paul Marcos There's a second one from the previous screen, the tab controller, which facilitates switching between the tabs. Paul Marcos Again, where each screen full of content has a tab. has its own controller.

This notion of the view controllers that you write managing specific screenfuls of content and the ones that we provide to help with that fall under this umbrella of view controllers. And it's really, really important. This is, I would say, this whole week, one of the biggest goals that you should have is understand view controllers, understand how to use them efficiently, how you should design your apps using them in order to achieve this one screenful of content at a time.

And to help with that, there's a couple sessions that you should absolutely go to. These are not to be missed. Understanding view controllers is an introductory session. Explains the design behind it, kind of the basics of how they work, what you do with them. And then later in the week, there's a mastering iPhone view controllers, which goes into a little bit more detail. There's two labs for view controllers.

We think it's that important we get two labs. So come down, meet the engineers that design this stuff, the folks that are using it. And then we'll have a little bit of a discussion about how we think you should use view controllers for our applications. Again, we'd love to discuss, you know, the design of your application, how we think you should use view controllers for really effective use.

So view control is very important in case you missed that point. And then the rest-- excuse me. The rest of the slides, I just wanted to go through some functional areas to kind of call attention to them. The first one, table views. This is another very important UI element that we see cropping up in a lot of our apps and a lot of your apps as well.

So hierarchical presentation of data is commonly done with a table view. You can also use them just for displaying straight lists. They're highly customizable. You can customize them to suit your application. There's a view controller that is associated with table views for helping manage that screen full of content. There are two sessions, again, an introductory and a more advanced session for table views. And there's also a lab for table views that you can go to.

And then the next area is multi-touch. So as I said, the UI views are by default single touch. If you do flip that switch to enable multi-touch, you can do some fascinating things with multi-touch. And I think we're just scratching the surface of what apps will do with this.

There's a couple methods in UIView that you can override for hooking into the event processing system and getting all the access to the details about the touches and what's going on with them. If you are going to be doing multi-touch development, I'd suggest going to the multi-touch session. It talks about gestures and events, how they hook into the views, what the overall process is.

The next one is a set of APIs that we put under the umbrella of device APIs. There are three of them. The first one is the image picker and the camera interface. This is an example of a delegate-based API where you create the image picker, you bring it on screen, and then the user navigates through their library or takes a picture, and then the delegate object that you provide gets a callback. Image picker controller did finish picking image. Here you can see an example of one of our verbose APIs. Hopefully, did finish picking image. It's kind of clear when that'll be called.

Another device API that we have is Core Location. So location-aware software would use this. Again, a delegate-based API. The general idea is very simple. You turn on the location manager, indicating you are interested in location events. And as the device gets a new fix on a location, The delegate gets a call back, did update to location, from location. So you're given the old and the new position. And then you can do something with that.

The third one is the accelerometer. A delegate-based API again. You turn the accelerometer on, and then at that point, the delegate that you provide gets this steady stream at a fixed interval that you define, indicating what's happening with the sensor and what's being detected in terms of the acceleration going on. So accelerometer did accelerate.

There's a session that covers the device APIs, and it goes into details like how do you actually process the acceleration data that's given to you? Or what are the details of the locations that are handed to your delegate when you get called back? So it's a good session to go to if you're using some of the device APIs.

And then the last one was the address book. So if you need to integrate contact information into your application or if you have contact-like information that you want to present, we have two levels of API here, a lower level and a higher level. The lower level gives you access to the user's contact database in a structured fashion so you don't have to write SQLite directly.

You would use this if you have contact information that you want to fill into particular fields in the contacts database that is relevant to your application that would be stored with a particular contact. And then the high-level APIs are the UI pieces for allowing the user to pick a contact. There's a people picker.

If you're creating new contacts, you can show that to the user and let them add it to an existing contact or create a new contact for it. Or if you just have contact information that you want to display in a consistent fashion with how we display contact information, the nice little rounded bubbles where we have the addresses and phone numbers or whatever, we have API for that. There's a session on Address Book to give you all the details about how to integrate contacts and information into your application.

And so that's just a list of a bunch of sessions. As a parting thought, I just want to say, remember the fundamentals. Work with the frameworks, not against them. Take that step back. Take the time to read some of the documentation and really understand the concepts that go into the frameworks and the designs that we've chosen to implement. Learn the designs, the three that we covered here, Model View Controller, so fundamental to all the designs that we have both on the phone as well as on the desktop.

Delegation, where you can customize default behavior in the frameworks, and target action for connecting the view to the controls. And again, for doing iPhone app development, use the view controllers. There's a ton of functionality in the view controller layer that you get for free. We found as we developed our apps, we would do the same thing over and over, and actually we have a rule of three, that on the third time we do it, we stop and we factor it out.

So we've done that factoring, and now all of that existing behavior that's so generic to so many apps is just there for you to use through view controllers. So for more information that you didn't get from here or in the labs that you'll go to, you can contact Derek Horn, our application technologies evangelist.

And with that, I'd just like to say thank you. Have a great week. The engineers at Apple are thrilled to see the apps that you guys are making. We are seeing awesome applications come out. We're really excited to see what you do with the frameworks we provide. We're really interested in meeting you in the labs and talking one-on-one. So have a great week at WWDC. Thank you very much.