Good afternoon. My name is Jon Hess and I'm going to be joined today by Kelly Keenan and together we're going to teach you everything you need to know about Interface Builder 3.0 and building applications from start to finish.

Interface Builder 3.0. Interface Builder 3.0 has received a major update from Mac OS X on Leopard.

For those of you who are returning to us from WWDC 2006, we're going to be telling you about everything that is new with Interface Builder 3.0. For those of you who are new to the Mac OS X platform we're going to be teaching you everything you need to know to build interfaces on Mac OS X with Interface Builder 3.0.

Mac OS X provides a highly graphical user experience and has beautiful applications across the system. And in order for you to build a great interface that will stun your users you need a great design tool and on Mac OS X Interface Builder 3.0 is that design tool. Interface Builder 3.0 is accompanied with all the great controls that the framework developers of Mac OS X have integrated into our platform. There's hundreds of controls ready for you to use in your applications.

Because of the cohesiveness of the Cocoa frameworks on Mac OS X, Interface Builder is able to use real objects from start to finish. As you design your Interface Builder documents you'll use real instances of window, push button, menus and toolbars to compose your user interface and because those are the same objects that you'll be using at run time Interface Builder is able to give you a true what you see is what you get editing experience. Interface Builder also places a clean separation between your user interface design and your source code. This means that Interface Builder is a great tool for both software engineers and user interface designers.

Let's take a step back for a moment and look at where Interface Builder fits into the development process on Mac OS X. At design time we use Interface Builder to configure visual representation of our interface. We configure these real objects that we're going to use at design time and when we're ready with our interface and have configured it precisely the way that we like it, we save it to disk.

Interface Builder takes the object that we saved and it serializes it on, it freeze dries them into a package and places them on disk. At build time we use Xcode to copy our interface that we built with Interface Builder into our application and at run time the Cocoa APIs take that freeze dried file that represents our interface and reconstitute all the objects that we previously were working with in Interface Builder into the run time of our application.

So what are we going to teach you today? We're going to teach you to construct and layout a user interface with Interface Builder. We're going to teach you how to configure all the user interface elements to behave precisely the way that you'd like them to. We're going to learn how to integrate our user interface elements with our source code and finally we're going to learn how to deploy an Interface Builder document in our application with Xcode.

As we teach you about all the features of Interface Builder today we're going use a sample project. We're going to start with a blank window; we're going to learn how to add scroll bars and toolbars and configure them in Interface Builder. We're going to learn to make a side sheet that will have resizing rules and perform actions with our source code and finally we'll build a tool palette that we'll use to let the user edit our icons in the icon editor that we'll be making today.

As we progress through our presentation today we're going to start with the fundamentals of Interface Builder. I'm going to teach you just the basics of everything you need to know. We'll move on to editing objects which will include laying out our interfaces; we'll take precise control over all of our interface elements with Interface Builder inspectors; we'll learn to make connections that will allow us to establish relationships between our user interface objects and our source code and we'll learn how to deploy our Interface Builder documents with Xcode. Let's get started and take a look at the fundamentals of Interface Builder.

The first component you'll become familiar with as part of your Interface Builder documents is the document window. Every Interface Builder document has a document window and the document window shows all of the content of your user interfaces; shows all of your push buttons, shows all of your menus, shows everything. It's also your starting place to get started editing the content of your documents. You'll be able to double click on any of the content that's shown in your document window to jump straight into what you see is what you get editor.

We're also going to learn about Interface Builder's library. The library in Interface Builder is how you get all the content that you'd like to integrate into your Interface Builder documents. It's filled with all the controls from Mac OS X and all the images and sounds that are available to your Interface Builder documents through your Xcode projects.

The great Cocoa frameworks in Mac OS X let us put real controls into Interface Builder's libraries. If you'll scroll through Interface Builder's library those instances that you see are really push buttons, they're really menus and they're really array controllers; they're not always just images. Besides being able to drag all the controls from it. Interface Builder's library is also completely customizable. You can create your own smart groups and your own favorite groups and besides being able to drag content out of the library you're also able to drag content back into the library for later reuse.

Because there are so many controls available to the Mac OS X frameworks in Interface Builder and we've integrated them all for you to drag and drop into your applications there's a lot of information for you to deal with and we've brought in two great features to help you work with all the controls that are available in Interface Builder. The first is that the library is completely searchable. If you know what content you're looking for in Interface Builder's library you can jump straight to it with the search field in the library.

There's also hundreds of controls in Interface Builder and with all those controls you're bound to find new ones as you scroll through Interface Builder's library. I know that with every new release of Mac OS X we provide more and more controls and often the first time that you'll encounter the control as a software developer is while scrolling through Interface Builder's library. We offer inline documentation in Interface Builder's library to help teach you about all the new controls that are available with each release of Mac OS X; so as you see something that you aren't familiar with you can simply select it and get a brief summary of how the control can be used and integrated into your application. That covers the fundamentals of Interface Builder 3.0. Now I'm going to turn it over to Kelly Keenan so we can get into the details of laying out an interface.

Good afternoon. Now I'm kind of curious how many of you are actually new to Interface Builder? Okay, we have a few. These next few slides are definitely for you. A lot of you who have used Interface Builder 2.0, your job now is to figure out what's changed between Interface Builder 2.0.0 and Interface Builder 3.0. We're going to go through editing objects and the best way to do that is to start by tempting the demo Gods.

So, John and I have already started a project, our icon editor, and I'm going to start by opening up our nib.

Now the first thing you'll notice is the document window that John spoke of. Some of the changes that we've done to the document window is that there's now three views. The first view is the icon view and the icon view shows you all of the top level items in your interface; so for example, our main menu in our main window are here as well as files on our first responder which John will talk more about later.

The second view is the outline view. I like to use the outline view to find some of those hard to reach places like, you know, a hidden button inside of a tab view, inside of a window and you can just use this to go through the hierarchy of your interface.

I see you're excited about that. For those of you who don't like the outline view as much as the browser view we also have that so now you can look at just one line of the hierarchy.

Personally I'm a big fan of the icon view mainly because I like the pretty pictures so we'll stick there for now. You'll also notice that our document window now comes with a search field which is great for searching for those items that you're really looking for.

For example, I want to find the speech menu item and now you'll see the entire hierarchy reaching down to the speech menu item or for example, that line view also shows the ID and the type and I can search for ID if I know the ID of a certain widget I can search for 300 and I find the format menu or you can search for any type.

So I can search for NS application and get file zone or an application; another great way to find information in the document window. And at the bottom you'll notice we've added a status bar. John will talk more about this but right now you'll see that it shows us that we're connected to our Xcode project.

Now that you've opened up the document window and, you know, we've just gotten started here, I'm going to open up a main window. Now it would be great if I added some controls to this, right? So what do we need for that? The library. So we open up the new library.

One of the things that you'll notice if you've gone to some of the earlier sessions, the library is the same in Interface Builder as it is in Xray and Dashcode so a lot of the things that I show you here you can use in those two applications as well. It stores all of our objects and media; so you can see here all of the controls that John was talking about earlier as well as all the media that's available to us in our Xcode project are on the system.

So, if you're familiar with Interface Builder 2.0 the library is replacing the old palettes and I know one of the things that I always wondered about in the palettes was I looked at some of the icons and said, "What are they?" Well, now if you mouse over an item it will give you a short description of what that item is. You can also turn on labels so that now you can see labels for each of the items that are in the library or you can also see short descriptions of all the items.

At the bottom you'll notice as well that there's a longer description, so now we've really worked some documentation into our library so that especially for anybody who's new you'll be able to quickly get up to speed with what each of our controls does and if you've been around for a while it'll also let you know what one of those objects was that you never could figure out, what it did and why it existed.

Now at the top of the library you'll notice that things are grouped in an hierarchy. We've done this so that you could easily find all of the widgets that you're looking for. So for example, we have the Cocoa plug-in which has all of the Cocoa controls, PDF kit, Automator, and this is where all of...if you build a plug-in, your plug-in will show up in this list as well and if you come to our session on Friday you'll learn how to build a plug-in.

Now the best part, one of my favorite parts, is the search field, because a lot of times all I want to do is find a window really quickly and I can just type it in now or I know that I want controllers and I can just start typing in controllers and easily find what I'm looking for.

I'm going to switch this back to icon view so we can see things a little easier...and next...Sometimes these groups aren't exactly what I'm looking for. I'd really like to make my own group; so we've also added that option. So, for example, I can make a smart group and here I'd like to keep all of my text fields, in one group. So I'm going to set my predicate to be "is kind of" and say NS text field.

So now you'll see a new smart group has been added and it includes all of the text fields and subclasses of text field that I have available to me in my library. Now I might not want a specific group that I can use a predicate for; instead, I might just want to random group of all of my favorite controls. So in this case some of my favorite controls are a array controller, let's see, I really like to use a window a lot, and maybe a table.

So now you'll see that all of my favorite controls are in this group. Now lucky for me this is also very useful for giving demonstrations; so I've already created a group of all the items that I'm going to use in today's presentation. Hopefully this will remind me what I need to do next.

Let's start by adding a button to my window. In Interface Builder, it's as easy as just dragging things from the library and throwing them into your window. And now I'd like to duplicate this button, because one of the things that you often do is have an OK/cancel button.

OK and cancel buttons at the bottom of your window. Notice here that I have some guides that show me where I should put my second button in relation to the first button; this helps to keep my interface within the human interface guidelines so that your application will be a first class citizen on Mac OS X.

Now to edit your objects one of the easiest things to do is to double click them and you can change things like the title so that now this can be the cancelled title if I can type correctly and we're going to make this the OK button. Now I use these two buttons a lot in my work and so what I'm going to do now is select both of them and if I hold down the option key I can copy them back into my library.

I can give them a title...we'll call them (applause). So I can give them a short description which is also my favorite buttons and a long description, These buttons Rock!... fabulous. Okay and notice there's also an image up here of what it's going to look like. And now the widgets I've created are in my library and I can just drag them out as often as I want, do whatever I want with them, they're great.

So this is awesome for those times that you have a control that you've customized and you want to use that control over and over again in different parts of your application; just drag it back to the library; every time you open up Interface Builder it'll still be there and you can use in other applications. Now I'm going to go ahead and delete these.

So, getting back to the icon editor I have just an empty window. What do I want do next? Well, the first thing is if I think about it when I put an icon on here it might be to big for this window so I'm going to use a scroll view. So let's just drag out a scroll view and I can move it around and again you'll see the Aqua guides and I'm going to stretch the scroll view to fill up my window.

Now I've forgotten that I really, really wanted to add that toolbar that you guys are all excited about and all I have to do now is drag it from the library and drop it onto my window.

And now I want to customize it and I'm going to have to go to code for that, just kidding.

So, I'm just going to click on it; I want to add a new zoom button so I'm just going to drag out my pop up; I'm going to double click on it here, edit the list, so that I have a 1 time zoom, let's say 2x and 10x zoom and I'm going to make it default to 1x zoom and then I'm going to select, oh, actually it's a little big so I'm just going to resize it...just by sliding it around and so now it's ready to go and I'm just going to drag it right up into my toolbar and now I'm done. Now one of the things you'll notice is I didn't change the title.

There's a lot of things that you can do when editing your controls just by double clicking on them to change titles or resizing just by grabbing the resizing knobs, but occasionally there are things that you can't do and for those you need the inspector. So, let's go back to slides.

Quick recap of what we just saw, we talked about the document window; this is the first thing that you're going to see when you open Interface Builder and open a new nib; it's the starting point. We have three views, icon view where you can see all of the top level items in your project; outline view to make it easy to drill through the hierarchy and find some to those hard to find items; column view for those of you who don't really like outline view, there's column view; and it's searchable so that you can easily get to that hidden button.

The second thing was the library; the library is where all of your controls are stored whether they're your controls, plugs-ins that you added from another developer or plug-ins you made yourself. You have access to all of your objects and media including all of the images that were in your Xcode project.

It's grouped in a hierarchy so that you can easily find subgroups like objects and controls or windows, things like that. There's a rich set of components. Like John said there's over a hundred that we ship with the system already and that's not to count all of the other ones that you're going to install and we've added inline documentation so that you can easily see what each of those controls is used for and it's all searchable. And if there aren't enough controls already, like I said, you can customize all the controls you want, drag them back to the library and drag them back out again when you need them.

We also use the design surface The design surface is really your entire desktop. Now for those of you with those 30 inch cinema0 displays don't forget that some people have 13 inch MacBooks; so when you're designing you may have a huge space but don't forget about those people.

Using the design surface is as easy as just dragging a window out and dropping it on your desktop. It makes it easy to edit all of your windows, toolbars, and menus and we give you guides to make sure that you, your application can conform to the human interface guidelines.

So that's what I wanted to say about editing objects. Now, we have that toolbar item that we want to change the title for and in order to do that we need the inspector. So the inspector is what you will use to edit all of the properties of your controls.

The inspectors are grouped by type; so we've put all of the attributes together, all of the animations, all of the size constraints, they're in a separate tab and such like that. We've also divided them by inheritance; this makes it easier for us to be able to find attributes that are common in different controls.

For example, the tool tip is actually part of NS view and will now always be at the bottom in the NS view section whereas the state, the enabled state, is in control and you'll be able to find that in the same section every time no matter what control you're using.

There are three inspectors that I'm going to talk about right now; the first is the attributes inspector. We use this in the case where say I have a label and I'd like to change to the title. I can change the title; I can change the alignment, the border, all of the attributes of that label in the inspector.

The second that I'm not going to talk about except for this one moment is the animations inspector; hopefully you went to the two animations talks yesterday and got a good idea about how the animations inspector works and if I wanted to turn on layer backing for this view it's as easy as setting the content view in the animations inspector and then you can do things like turning on shadows and other fun stuff like that...and one transition I forgot, sorry.

The third is the size inspector; you're going to use this a lot and the reason is that you need to make sure that all of your controls work well when their containing view is resized; so you're going to use the auto resizing rules in this section a lot.

You'll also notice if you've used Interface Builder 2.0 before that the control size has moved now from the attributes inspector to the size inspector and with multiple inspection you can now select all of your controls and change the type from regular to small to mini all at the same time.

You'll also notice if you've used IB 2.0 before that the group placement and the alignment has moved to the size inspector as well. One quick example of why you need the size inspector, how many of you have had a window like this that when it was resized it looked like this? This is what we need the size inspector for.

One thing that I want to point out in the size inspector is the auto sizing section. For example in the window I just showed you that text field I wanted to stretch all the way across the window when the window is resized; so in order to do that I'm going to set the anchor to the left side of my containing view; I'm going to set it to stretch in the center and I'm also going to set the anchor to the right side so that now it's anchored on both sides and stretches in the center and will resize when my window resizes. These same rules apply vertically as well as horizontally. You'll also notice that there's a new animation and we'll see this in the demo of how these work. So, let's go back to the demo machine.

So when we last left the demo machine we were wondering how to change the title of this pop up button. So, let's bring up the attributes inspector and in the attributes inspector I can select the pop up button and change the label to zoom. Now you're going to notice that there's two labels here; one is the label and one is a palette label and the reason for this is that when you're users are editing or customizing their toolbar, for example, with the flexible space you don't want a title when it's actually in the toolbar but you do want a title in the sheet that comes out when they're customizing so this lets you set both of those titles so that you can one in, one title for one thing and a different title when it's in the sheet.

So I think that our window here looks pretty good so I'm going to put that away for now. And let's start by building the tools palette. If I drag out a panel I can just drop it anywhere on my design surface; otherwise known as my desktop and you'll notice that it shows up in my document window.

The first thing I'd like to do is add some buttons; so we'll use the Aqua guidelines and I can grab any of the resizing knobs and just start resizing my button. Now I have an idea of exactly how big I want my button to be and so I'm going to change the size inspector and in the size inspector I can set my button to be exactly 34 x 36.

So, now my button is 34 x 36 and that's exactly what I'd like so I'm going to duplicate it, if I pick the right menu, and I'm going to make six of these. Now one of the things I have a hard time with is mousing. For some reason when I mouse things go everywhere and so to move things in small increments I can also use the arrow keys so that I can make sure that things line up perfectly. Okay, great. I have six buttons but I forgot that I really wanted them to all be toggle buttons.

So, thanks to multiple inspection I can go back to the attributes inspector, select all of my buttons and change them from momentary push in to toggle and now each one of them is set to toggle; a lot easier than it used to be when I would have had to change each one.

I'd also like for each of these buttons to have an icon it in. Well I'd really like the first one to be a pencil and so in the attributes inspector I can select the image attribute. You'll notice that there's a tool tip that popped up and that tool tip when using the inspectors you'll find that we've added tool tips with short explanations of what each of the attributes does.

So now I can type in pencil and notice it filled in pencil already for me; if I just hit return my pencil shows up. If I look at the pop down menu I'll see that all of the icons that I have available in my Xcode project are here already; so I can just make the next one a paint bucket and maybe the third one is going to be the eyedropper and the image up here, I never can remember the name of, so it would be really helpful if I had a picture of it.

If I go back to the library and select media I can turn this down and select today's project, notice that all of the icons from my Xcode project show up automatically in the media and now I realize that I really wanted this marquee button and let's add a line and a hand tool.

So now I have all of the images that I'd like to use and the last thing that I think I need is if we go back here I need a color palette so that I can change the colors that I'm using with my icon. And now I can resize my window and I have a tool palette.

Now personally I like the Aqua human interface guidelines but sometimes I think I know better than they do and I know you all feel that way sometimes so I'm going to show you some tricks. One is that I'd like the edge of my window to be about 8 pixels away from all the content; in that case I want to use some guides so I'm going to add a horizontal guide and drag it towards the top; you'll notice that there's two small little tool tips there and they tell me exactly how far my guide is from the containing view.

I'm going to do the same thing with a vertical guide and move that over 8 pixels from the left...dragging all of my controls over; now I need to get rid of this extra space. Well when I resize I get the Aqua guides and that's not exactly what I'm looking for.

So one of the things that I'm going to do is hold down the option key; if I hold down the option key while I'm dragging you'll notice that the tool tips pop up again that tell me exactly how far my containing view is from the views inside of it so that I can set it so that it's exactly 8 pixels from the objects inside.

Now that I have my tool palette exactly how I want it, I don't really want my users to change it; so I don't want it to be resizable. So, I'm going to go back to the size inspector and if I switch to my panel you'll see the size inspector changes.

We've done something special with windows so that now you can set the minimum size; you can say that my panel has a minimum size and I'm going to use the current size as the minimum size. I'm also going to set the maximum size so that I use the current size as a maximum size and now my panel is no longer resizable.

Another part of the windows size inspector is that in Interface Builder 2.0 wherever I left my window last while I was designing it is where it showed up when the user opened the application for the first time. So now we've made it so that you can use this little replica of your desktop to decide where your window is going to show up on the desktop when the application is run.

By clicking on the little knobs you can anchor it to the sides of the window so in this case I want to anchor it to the top left and just move it to a position that I think I'd like it to show up in when I first open the application.

Okay, now I think, yeah, I think I'm done with the tools palette, so we can put that away for now and the next thing I want to add is the size sheet. So, let's just drag out a window again into my design surface, and if you remember the size sheet earlier had two fields, one was width and one was height; so we'll drag out some labels, and I'm going to make this a little bigger to work with for now and drag out a text field and use the Aqua guidelines to line it up for me, make it a little bigger and now I can duplicate this, and now I have two and I'd like to change this to width and I'll set the other one to height. Again I love multiple inspection because I'd like to set both of these to be aligned on the right; so if I go back to the attributes inspector I can change the align, if I select both of them, I can change the alignment now to the right instead of natural and I'd also, I made these bigger so that I could work with them but I'd like to make them the same size as the text that I have in them so I'm going to use the size to fit option from the layout menu and now my text field is the same size as the text inside of it.

So, the next thing I need to add are the OK/cancel buttons. So, luckily I made those earlier and I can just drag them right back out. I told you I'd use them later; so, now when the user goes to actually use this, a lot of times you want to just be able to press return and make that be the same as OK.

So, if I select the OK button I can set the queue equivalent in the attributes inspector by just pressing return in the key equivalent field. Same thing goes for cancel; I'd like to be able to escape, use escape, to cancel out of my sheet and so I'm going to set the key equivalent by just hitting escape.

( Applause ) You can clap. It's okay. And while I'm talking about what the user is going to do, I don't know about you but when I'm a user I have a bad habit of typing random characters in the text fields or, you know, I'm chatting with somebody else and accidently am in a text field instead of the iChat window and start typing away; well I'd like some user validation into these text fields that I have because I really only want them to be able to put whole numbers into the text field.

For that we're going to use the formatter; so if I just drag the formatter out I can drop into a text field and when I select the text field you'll notice there's a little badge here that shows me there's a formatter and I can select the formatter and I'm going to use here; I'm just going to use the presets that come with this formatter and set it up so that it only uses whole numbers. I'd also like it to not allow negative numbers so I'm going to set the minimum to zero.

So now we've set up formatters, we've set the OK/cancel button so that we can use key equivalents; so let's finish up with just cleaning up our interface by moving these buttons up into the corner and resizing the window. Now, if I resize the window now; if I just run the application and resize the window those fields aren't going to do anything. So the last thing I'd like to do is set some of the resizing rules. So now let's go back to our size inspector.

We'll start by selecting the labels. I'd like those labels to stay in the upper left corner; so notice that they are already set, they're already anchored to the upper left corner and you can see this by watching the animation next to it that shows you what a view inside of a view that's changing will do.

Now let's select the text fields; now the text fields I'd like those to get bigger when the window gets bigger and smaller when the window gets smaller. I'd like them to stay to the top so I'm going to keep them attached to the top but I'm going to anchor them to both sides and set the stretching in the center; notice our animation changed to show us exactly what's going to happen.

So now you have a good idea when you change the auto sizing rules what's going to happen to your control when the containing control changes size. The last thing is I'd like the two buttons at the bottom to be anchored to the lower left, to the lower right, sorry. So, I'm going to set the anchors on the right and the bottom and remove the anchors on the left and top and now you'll see that it's anchored in the bottom.

Lastly I'd like to set the window so that it has a minimum size and we're going to use current again and it has a maximum size. I'll start with the current but I don't, I would actually like people to be able to change the size horizontally so I'm going to change the width and say that they can go up to 350.

So now if I'd like to test those resizing rules I can go to the layout menu and select enabled auto resizing and if I resize my window I can see how my window is going to react when the user changes the size of their window and now that we're done with the size sheet...the next thing we're going to want to do is to set up some connections and we're going to do that next. So let's go back to the slides...and let's recap some of the stuff that we just talked about.

One of the things was the new inspector that's arranged in groups so that all the properties that you have in the inspector you can now easily, you have a good understanding of how they map to the API that they're associated with and it makes it easier to do multiple inspection. We've added a resizing animation in the size inspector as well as moved the control size to the size inspector; also the alignment and the grouping are here as well and we talked about formatters. This is a great way to restrict and validate user input.

There are four inspectors that I didn't talk about and those are all inspectors that allow you to connect to your view to your code. So the next thing we're going to talk about is making connections and John is going to come back up to talk to you about that.

Thanks. So far we've learned about all the great features of Interface Builder that will help you build the superb view layer of your application. Now to breathe life into our view layer we need to associate it with source code and in Cocoa application, that Cocoa applications, that typically means integrating our view layer with our controller layer and Interface Builder allows us to do that with the technology called connections.

There are two types of connections that we're going to learn about today. The first are outlet connections. An outlet is a name for an instance variable and it's a name for instance variable that we're going to use to connect part of our, to connect one of our instance variables to user interface elements in our Interface Builder documents.

We tell Interface Builder that instance variable and a source code is an outlet by tagging it with an IB outlet key word. The next type of connection that we're going to be use in Interface Builder is an action connection. An action connection is like an outlet connection except instead of associating a piece of our user interface with one of our instance variables we use it to associate a piece of our interface with one of our methods.

So, for example, to have one of our methods be envoked every time a user interface item like a button is clicked or a menu is selected we would use an action connection in Interface Builder. In order to tell Interface Builder that one on our methods is to be used with an action in Interface Builder we tag the return tag with the IB action keyword.

So I've told you what connections are and I've told you how we use them to integrate our view layer with our controller layer and our source code but so far we haven's seen how to integrate our controllers into Interface Builder. We integrate our controllers into Interface Builder the same way that we integrate any other user interface content; we use the library and the document window to do drag and drop.

We can start in the library with an instance of object. Among all the various controls that Interface Builder provides in the library one of them is just a simple object and you can drag that to your Interface Builder documents like anything else. Once we've done that we can use one of Interface Builders additional inspectors, the identity inspector and in the identity inspector we can configure the class of our object and we can change it from an instance of object to an instance of our controller.

Now after we've added an instance of our controller to our Interface Builder document we can tell Interface Builder about some of the actions it's able to perform and the outlets that it is able to refer to interface elements and source code with by using the action and outlet inspectors.

After we've declared actions and outlets and it has created an instance of our controller we're ready to actually make connections and to hook up parts of our controllers, the parts of our user interface so that we can utilize them in source code. To do this we use Interface Builder connections inspector.

In the connections inspector you'll see all the actions and outlets that pertain to your class and you'll be able to drag from the connection hot spot to some user interface element in your Interface Builder document to connect them together so that they're available to use as source code and to show you that I'd like to demonstrate something to you. Can we switch to the demo machines?

I'm going to return to the project that Kelly and I have been working on today, the icon editor, and I'm going to start by building and running the project.

Right now we don't have any source code and we don't have any connections; we just have an interface that we've created in Interface Builder. If I switch to the application we can see that we have the window that we designed in Interface Builder and we have the tool palette but our sheet is nowhere to be found and our buttons don't work quite the way that we would like them to. So, let's return to Interface Builder and make some connections between our user interface elements and our source code so that we can breathe some life into our application.

I'm going to return to our document, and I'm going to go to the library and I'm going to find the instance of object; it's right here and I'm going to drag it to our application. Once we have this instance of object in our application we can use identity inspector to change the class to an instance of my controller.

Notice the auto completion; we find this by synchronizing with Xcode. Now that I've declared that I have an instance of my controller in my document I can go ahead and declare some actions and outlets. We're going to need a couple of actions and outlets in order to show some functionality for our user interface.

We're going to start with some actions and outlets for the OK and cancel buttons on our size sheet so let's add an action called OK size sheet. We'll have this evoked every time the user clicks the OK button in our size sheet. We'll have a complimenting action, cancel size sheet.

We'll also need an action for when the user selects some of the tool widgets, the tool buttons in our tool palette. So, let's add a toggle tool action. Finally we're going to need a couple of outlets in Interface Builder so that we can refer to the elements of our interface in our source code.

I'm going to add a main window outlet so that we can refer to our window in source code and I'm also going to add a size sheet window so we can refer to our size sheet from source code. So at this point we can move over to Interface Builder's connections inspector and begin to make connections. I can drag from our main window connection, the connections hot spot, over to our window and Interface Builder will highlight the window to indicate that I can connect them.

I can also drag a connection from our size sheet outlet to our size sheet and from our OK size sheet to our push button and our cancel size sheet to our other push button. So now when the user click our OK and cancel buttons our methods OK size sheet and cancel size sheet and code will be envoked. We also need connections for Interface Builder for our toggle tool action.

Now for this I'm going to show you something else. When you're going to make lots of connections you can take advantage of Interface Builder's inline connections inspector. We can right click or control click on any element in Interface Builder to bring up the inline connections inspector and once we've done this...thanks...once we've done this we're able to make action outlet connections just like with normal connections inspector. So, I'm going to start dragging a connection for my toggle tool outlet; notice that I drag over the HUD; it gets out of my way in case I want to make a connection to something behind it.

Now I've started to drag but I forgot to open up my tool palette before I started to drag. I don't have to abandon the drag there because Interface Builder's connection mechanism is all fully spring loaded. So I can mouse over my tool palette and if I wait for just a second Interface Builder is going to open the window for me; so now I can go ahead and proceed with making my connections and I'm going to connect these one at a time to all the elements in this palette interface.

Now you'll notice that as I mouse over the different elements in the inline connections inspector Interface Builder is telling me what each of those actions and outlets is associated to by highlighting them on the editor surface. So, for example this toggle tool action that's connected to multiple elements in my interface and as I mouse over Interface Builder shows me all of them. I can disclose this to see a list of each of them individually.

Now you might have also noticed that I accidently connected the toggle tool action to my color well and that was a mistake and Interface Builder has undo and redo integrated throughout all of Interface Builder including making connections. So I can undo and redo this; I can undo this because if feel that I made a mistake and I can redo it to re-add the connection. If I see a connection that I've made that I've decided I no longer need there's an X button in both the inspector and the inline inspector that I can use to disconnect a connection.

So at this point I've made all the connections that I need to integrate my view layer with my source code but I need backing source code for all of them. For that I can return to Interface Builder's identity inspector and look at actions and outlets that I was working with earlier.

If I select each of the actions and outlets that I defined in Interface Builder I can drag them back to Xcode. So I drag these here; they're going to show up in my Xcode project.

I can do the same thing for my outlets.

Now of course I'd need a backing implementation for these actions in order to make them perform something and if we switch to the .m file for our controller I've already written implements simple limitations for each of our actions. So I'm going to un-comment them and we're going to run our application again.

So, now we've run our application and we've immediately be presented with a size sheet; so interface said we were able to do that through our outlet connections. We also made an action connections from the buttons inter size sheet and now I can press the OK and cancel buttons to confirm or reject the sheet. Our tool palette also behaves as expected selecting one tool at a time. So now I've showed you how to make connections to Interface Builder and to integrate your view layer with your source code, let's return to the slides.

To recap what we have heard in the demo we learned how to integrate custom instances of our objects that are represented in our Xcode project into our Interface Builder documents by dragging instances of objects from the library into our document and then using Interface Builder's identity inspector to change the class of our objects from objects to instances of our controllers.

We've learned how we can define actions and outlets in Interface Builder and drag them back to Xcode and how we can use the connections inspector to establish relationships between our objects and our interface layer. Now up until this point in our presentation there's been three objects that have been part of every one of our Interface Builder documents that we've been ignoring. Those objects are the file's owner, the first responder, and the application.

The first object that I'd like to talk to you about is the file's owner. When nibs are loaded at run time they're loaded with NSBundle API, loadNibNamed:owner. The first parameter to API is simple; it's the name of your Interface Builder document. The second parameter to this method is the owner and this owner is used to resolve the file's owner in Interface Builder.

The file's owner object that you see in Interface Builder is a proxy object and it's a proxy object it doesn't represent an object inside your nib but instead an object that lives outside your nib and that proxy is resolved as the parameter that you pass in to the loadNibNamed:owner method as the owner.

So the primary purpose of the file's owner is to allow you to make connections from objects inside your nib to objects outside of your nib. So if you have an Interface Builder, if you have a controller in your application that loads content from multiple interfaces a great way to do that is with the file's owner.

The next Interface Builder object that I'd like to talk to you about that acts as a proxy for you to make connections to is the first responder but before I can describe to you that what the first responder is used for I need to first describe to you a Cocoa concept and that concept is the responder chain. Let's look at this example.

Cocoa delivers many events to the focus user interface element and in Cocoa we call the focus user interface element the first responder. And the first responder along with its parents in this simplified example, a window in an application, together form the responder chain, and as events are delivered in Cocoa they'll first present to the first responder and if he's able to satisfy those, to respond to those events it will; otherwise it will pass the events up the responder chain. So for example, if we use the edit menu and select copy, a copy message will be sent to the first responder. In our example text fields understand the copy message and they'll take their selected text and place it on the clipboard and satisfy the copy request.

As an alternative example if we use the file close menu a perform close message will be sent to the first responder in the responder chain. Now text fields don't understand performClose so instead of performing the close action the text field forwards the message on to the next responder; in our example that's the window. The window happily accepts the message and closes. So now that we know what the responder chain is I can tell you how to use the first responder in Interface Builder.

Just like the file's owner, the first responder is a proxy object that represents objects outside of your nib except unlike the file's owner, the first responder represents a dynamic object; it represents an object that's not resolved until your user interface action, the click of a button, the selection of a menu item, is pressed. So we use the first responder for action connections. We typically use it for menu items and toolbar items so that they can work on the front most user interface element.

In addition to the file's owner and the first responder there's one additional connection target that we're going to use in all of our Interface Builder documents and that's the application. Every Cocoa application has one instance of an NSApplication either direct instance within this application or custom subclass that you're providing with your application and this object is always available for you to make connections to and from with Interface Builder 3.0.

So now I've described connections to you and how you can use connections to integrate the view layer of your application with the controller layer of your application and to breathe life into you interface and give it functionality. Now we're going to move on to how we can integrate our interface with Xcode and deploy it on Mac OS X.

Xcode and Interface Builder have a lot of information. Xcode knows about all the classes in you project and all the images and sounds and you need all this information when you're working with Interface Builder and with Interface Builder 3.0 and Xcode 3.0 on Leopard we've automated this entire information exchange process.

Your key to this information exchange process will be Interface Builder's document window. If you're working with a document in Interface Builder and that document is associated with a project in Xcode and that project is currently open then Interface Builder and Xcode are going to be talking and working together to share all the information that you need to build your interface; this includes all the class information.

So as you build classes in Xcode if you return to Interface Builder they'll be available. This also includes all your images and sounds. This light at the bottom of your document window is your key to the synchronization status. When you're working with an Xcode project and Interface Builder is syncing, this light will turn green and refer to you project.

Perhaps the biggest benefit of the automatic synchronization that's new in Interface Builder 3.0 is the class synchronization. When you edit your source code if you type actions and outlets directly into your header files they'll automatically show up in Interface Builder in the identity inspector. Interface Builder's synchronizing all of your class information with Xcode and with Interface Builder 3.0 we're able to provide great features to you by doing this and all the places in Interface Builder where you might type a class name we're able to auto complete that class name to make sure you don't make mistakes. In Interface Builder 3.0 we also offer first class support for in addition to Objective-C, Ruby and Python.

So you can now build first class Cocoa applications with Ruby and Python on Mac OS X using Xcode and Interface Builder. A big feature for Xcode in version 3.0 is refactoring support and if you refactor your project with Xcodes refactoring engine that also provides full integration with Interface Builder.

So if you use refactoring to rename your actions or outlets or move them up or down to class hierarchy or sideways left and right, Interface Builder will respond to those refactorings and will automatically update your connections, outlets and actions in your Interface Builder documents. Interface Builder, by synchronizing with Xcode and finding out about all of your classes is also able to help you to detect broken connections.

I find that it's often the case that I'll return to some component of my application that I haven't worked with in a long time and I'll see actions and outlets that I don't think are in use anymore and I might delete them. If I delete them and they actually are in use and I return to Interface Builder, Interface Builder is able to tell to me that I have actions and outlets connected with no backing source code and we figure all this out by automatically synchronizing with Xcode.

Beyond synchronizing your class information Interface Builder also synchronizes all the images and sounds in your Xcode project and when you use images and sounds in Interface Builder, Interface Builder refers to those images and sounds by name; this means that if you use an image multiple times in your interface they'll only be one instance in your running application; this saves memory.

This also means that Interface Builder gets to always show you the latest image data that you have in your project in your Interface Builder documents and as Kelly showed you in your demo it also lets us auto complete in all the places in Interface Builder that accept images.

We make all this possible in Mac OS X with nib files. As we've started at the beginning of the presentation we saw the Interface Builder offers nib files and nibs files are free stride contents of your interfaces. All versions of Interface Builder have edited nib files and nib files are editable with, of course, all versions of Interface Builder; they're also buildable with all versions of Xcode and deployable on all recent versions of Mac OS X 10.2 and later for the nibs files in Interface Builder 3.0 offers. Unfortunately the nib 2.0 files are incompatible with some of the newest features that we've added to Interface Builder 3.0; such as toolbars, connections to cells and custom cell classes.

With Interface Builder 3.0 on Leopard we're introducing a new file format and that's XIB files. Interface Builder 2.0 nib files were file packages and they were often awkward to integrate with SCM systems. Interface Builder XIB files provide first class SCM integration; they're single textual files; they're human readable and you can get diff them with common utilities like file merge in Xcode's SCM Integration.

Now textual XML files are great for source code development but they're not the best format for deploying your interface; for that we want fast, small binary files so that we can get the best performance and the smallest memory usage and so in order to achieve that we compile your Interface Builder documents when you build an Xcode; so now Interface Builder documents are compiled as you deploy your interface.

Because we're compiling your Interface Builder documents we're able to give you build warnings and errors in your Xcode build. So if you're targeting Mac OS 10.2 with your XIB files in your Xcode project and you use controls from Interface Builder that weren't available on Mac OS 10.2, Interface Builder will be able to tell you as part of the build with a build error that you've caused such a problem and you can take action to rectify the situation.

XIB files are only editable with Interface Builder 3.0; they're only buildable with Xcode 3.0 but they're deployable on all versions of Mac OS X; so you can still use Interface Builder 3.0 and Xcode 3.0 and take advantage of all the great SCM features of the XIB files and deploy the previous versions of Mac OS X.

We're also introducing a third migrational file format and that's the Interface Builder 3.0.0 nib file. This nib file provides for all the features of Interface Builder 3.0. You can use toolbars, custom cell classes; you can connect the cells and use every other feature of Interface Builder 3.0. These files are also deployable everywhere just like XIB files and nib 2.0 files; they're also buildable everywhere; that's their key difference between nib and XIB files, between nib 2.0 and XIB files so you can build them with all the different Xcode tool chains; again they're only editable with Interface Builder 3.0.

So with me just presenting three file formats to you, you may be asking which one should I be using in my applications? If you're editing and building on Mac OS X 10.5 with the Xcode 3.0 tool chain you should be using XIB files; that's the preferred file format of Interface Builder 3.0 to support all the features of Interface Builder 3.0 it's going to give you the best run time characteristics by compiling your user files into small binary representations and it's going to provide great SCM and build warnings and errors.

Now if some of you, if you've have a mixed it all team where some of your teams are working on Tiger and some of your team is sometimes working on Leopard you can still take advantage of many of the great features in Interface Builder 3.0 including toolbars by using Interface Builder 3.0 nib files. These files are still on editable on Interface Builder 3.0 on Leopard but you can still build them with the Xcode 2.0 tool chain on either Tiger, a previous release of Xcode if you're going that far back or Leopard.

Last if you have the occasion to edit with Interface Builder 3.0 on Leopard but mostly your team is sticking with the Interface Builder 2.0 tool chain you can use Interface Builder 2.0 nib files with Interface Builder 3.0; this will restrict you slightly in the amount features that you can use such as toolbars, for example, but you still get to take advantage of all Interface Builders great editing enhancements like multiple selection, the library, the new connections mechanisms, Xcode integration and on. So now that we've learned about all the file formats in Xcode's and Interface Builder's automatic information exchange, we've learned how to deploy our interfaces. Let's take a quick moment to go over a summary of what we've learned so far.

We learned how to use Interface Builder's library to add new content to our documents. We learned that we can customize the library with custom groups and smart groups. We learned that the library has real objects in it and we can extend it with our own plug-ins if we're a framework developer.

We learned how to lay out objects in Interface Builder; how to take advantage of the Aqua guides, how to bring our own user guides in and that we can use the option key to mouse over elements of our interface and see the relative distances between them. We learned how to use inspectors to take precise control over the various elements of our interface and to configure their behavior down to the smallest details.

We've also learned how to connect objects in Interface Builder using the identity inspector to integrate our controllers and the connections inspector to make connections between our various interface elements so we can integrate them with source code and breathe life into our interfaces and last we learned how to deploy our interfaces on Mac OS X with Xcode, take great advantage of new features like Interface Builders XIB files for great SCM integration and build warnings and errors. With that I'd like to point you to some more information; there's developer documentation and sample code available at developer.apple.com for the WWDC attendees section and on your Xcode CDs is an Interface Builder 3.0 Getting Started Guide that's available in Xcode's documentation.