Video hosted by Apple at devstreaming-cdn.apple.com

Configure player

Close

WWDC Index does not host video files

If you have access to video files, you can configure a URL pattern to be used in a video player.

URL pattern

preview

Use any of these variables in your URL pattern, the pattern is stored in your browsers' local storage.

$id
ID of session: wwdc2011-309
$eventId
ID of event: wwdc2011
$eventContentId
ID of session without event part: 309
$eventShortId
Shortened ID of event: wwdc11
$year
Year of session: 2011
$extension
Extension of original filename: m4v
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: [2011] [Session 309] Introducing...

WWDC11 • Session 309

Introducing Interface Builder Storyboarding

Developer Tools • iOS • 50:04

Discover how Xcode's Interface Builder support for Storyboarding in iOS 5 makes designing your iOS apps so much easier. Storyboarding allows you to graphically arrange all your views within a single design canvas, where you can then define the app's logical flow, and even assign transition animations. Learn how to use Storyboarding to quickly go from concept, to creating your next great app.

Speakers: Rob Marini, Joshua Pennington

Unlisted on Apple Developer site

Downloads from Apple

HD Video (733 MB)

Transcript

This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.

My name is Joshua Pennington, and I'm an engineer on the Interface Builder team. And I'm going to be joined later on by my colleague Rob. And we're here today to talk about building apps using Storyboarding. Storyboarding is a great new way for you to build your applications. Now, we made Storyboarding because most applications are composed of many screens of content.

And what we wanted to do is have a way for you to view and edit your entire interface for the entire application in one place. And so we put together a tool to do that. This is Storyboarding. And as you can see, we display each screen of content or major component area for something like an iPad split view controller. And we display the transitions between the scenes in the canvas as lines. And these show the flow of information and transitions throughout your app. application. So we're going to cover a couple things today.

We're going to start out by talking about the key concepts of Storyboarding and what makes it unique. And then we're going to move on and talk about how to move data through your Storyboard. Most applications involve a lot of data transfer. You need to pass information through the various screens of content.

Then Rob's going to come on stage and he's going to talk for a bit about the API, and what it's like to use Storyboarding at runtime. And he's going to finish off by showing you how you can begin to integrate Storyboards into your applications today. So, let's get started. There really are two primary concepts that make Storyboarding unique. The first one is that of a scene.

A scene represents one screen full of content, or major component area like a pane in the split view controller on iPad. And this is very familiar to the existing editor affordances. You have an Interface Builder today. So, if you're familiar with Interface Builder, this part's going to be a breeze. You can drag and drop views in and rearrange them, and resize the controls. Once again, this is very familiar to the existing Interface Builder. And below each scene, we have what we call the Dock.

Now, the Dock is like the top level objects area in a Nib file. And this is where we have the view controller that represents the scene at runtime. And you can also drag and drop objects in. So, if you have a data source object, you can just drag one of those from the library in and put it in there.

Then you can wire up an outlet to it and get access to it. So, that's the first concept that is present in storyboarding, the scene. The second concept is that of a Segway. A Segway represents a transition between one scene to another one. And it also is used to represent the presentation of another scene. Say, for instance, with a popover.

We have different types of Segways. So, a very common one would be a Push Segway, which is where you would use a navigation controller to slide another scene onto the screen. Or you could display a modal view controller and slide one up. We have all the built-in modal transition styles, such as cross dissolve and flip.

And as an added benefit, you can customize these Segways by subclassing it and overriding a method to perform your own visual transition. So, you know, if there's not a built-in style that you need, there's a very clearly defined place for you to customize that. So, that's the second key concept present in storyboarding.

Most applications involve a lot of transfer of data between the different screens of content. So, we're going to cover a couple of those and talk about some best practices you can use for doing this in your applications. Most applications are going to have a lot of screens of content connected by these Segways. And you need to sometimes pass information down to a scene that's being presented so it can display the correct information. So, that's one form of data transfer.

The second type of transfer would be getting information back or receiving notification that an event has occurred from a scene that's already been presented. And we use a central choke point for all these types of data transfer. And so, if there's one thing you need to remember about storyboarding, it's this method, prepare for Segway.

This is a method on UI view controller that is invoked on the source view controller whenever a Segway is initiated. And this gives you the chance to prepare for that scene, be it passing it information or updating some state inside the scene that is doing the presentation. So, let's say you have a list of brewing sessions and when the user taps on a table view cell, you display the detail view controller.

What's some more information about that? Well, it's really easy to define that transition. You just connect a Segway to have a navigation controller push across that other scene to display the details. And then to tell the detail scene what it should be displaying, you would override prepare for Segway on that source list view controller.

And you would wire up and pass across your object that defines whatever it is that needs to be displayed. And then that detailed view controller could do whatever it needs to display that. So that is how we pass information down to a scene that's being presented. Now, the second type of data transfer is getting information back from a scene that's already been presented.

So what would this look like? Well, in this example where we have a list of brewing sessions, let's say we have an add button, that when you tap that, we slide up an add sheet. So users can enter in information and say maybe hit a done button to commit that to the model and continue on with their application.

So how do we get this information back when the user hits the done button so we can continue? Well, we would use that prepare for segue method to wire up a delegate from the add session controller to the other view controller. And so we would create a custom protocol on the add session scene. And this is just a standard Objective C language mechanism. And we'd have a property on that called delegate.

And we would use prepare for segue to wire up that delegate from the add session scene over to the other view controller. And then we'd have an action from the done button. And when that action is invoked on the add session scene, it would do whatever it needs to do to commit that object to the model. It would pull the details out of the various fields in there and commit it to, say, a core data store. And then it would wire the information back across the delegate.

And then the original list could do whatever it needs with it, and dismiss the controller. So that is how we bring information back. The other form of transferring and viewing information in Storyboards is with table views. We have a great new feature for table views in Storyboards, and that is prototype-based tables. Now, prototype-based tables allow you to design the cells that go into a table view in Interface Builder, and easily dequeue those at runtime.

So, what this means is that you can drag a cell out from the library in Interface Builder and configure it, drag in some labels maybe, and add an image view or whatever. It's up to you. And then you can assign that cell a reuse identifier. And at runtime, in the familiar table view data source methods, you could simply ask the table view to, make you a new cell, make you a copy of that cell from the Storyboard. And it'll do all the work for you, and grab that cell from the Storyboard and put it in the table view for display.

So, this is really easy to use, and it's also very efficient, because we've done some cool things behind the scenes to avoid redundancy. We think this is really neat, in that it's going to help you save a lot of time when you're designing your table views in Interface Builder.

That's great if you have a standard table view where you've got a list of information that's data-driven. But, we often know what we want to display in our table views before the application even runs. Maybe what we really want are static table views. So, we've introduced that as well. You can now statically define table views within a Storyboard.

Yeah. I'm pretty excited about this. So what you can do is, you can design the cells in line in the table view. You can drag in sections and headers and footers, all the normal affordances you'd have in a table view that's powered by a delegate and a data source.

Except that, you can do it all with an Interface Builder, so it's really quick, and it's immediately obvious to you as you're designing it, what it's going to look like when you hit build and run. And the beauty of it is, you do not have to write a data source. So you can just build and run, and what you have in the canvas in Interface Builder is going to show up in your application at runtime.

And you can even wire up outlets to the contents of these table view cells, so you can customize them with data at runtime, if you happen to know how many cells you want. You can design that part statically and fill in the details. So we've covered a couple things here for dealing with data in Storyboards. So let's use these things to build an application. Now, I really like coffee.

A lot. And I also really like data. And I would love nothing more than to take the two and to slam them together and make an app that I could use to keep track of the coffees that I've tried and the various cups of coffee that I've brewed. So let's build an application together. And this app is going to be composed of really three main parts. So we're going to start with the list of the brewing sessions that the users participated in. So they can refer to it later on.

We're going to have an add button that they can tap. And when that's tapped, we'll present a controller where they can enter in information about a brewing session. They can enter in some details about it. And when they tap on that coffee cell, we're going to present a list of coffees so they can choose which coffee it was they used. So with that, let's get started. So I'm going to go ahead and start my demo over here. And I've got a new project that I created that uses a storyboard.

I'm going to resize that to be a little bit bigger. And this is just a standard storyboard-based project. We have these in the Xcode templates now. And we've got a blank canvas here. And this is where we're going to flesh out the interface for our application. I'm going to add a new scene to our application.

Scenes in Interface Builder are represented by view controllers. So I'm going to drag one out of the library in the lower right. I'm going to scroll down and just drag out a new table view controller to manage this list of brewing sessions. It's going to plop it down on the canvas.

[Transcript missing]

Now, when the user taps on one of these cells, I want to push across our detail view controller, using a navigation controller. So let's add a navigation controller into the mix, so we can get that behavior. I'm going to use the new editor embed navigation command for this. Give it a click, editor embed navigation controller. And we've added a navigation controller.

Rob Marini, Joshua Pennington Now, you'll notice that the Storyboard automatically showed a navigation bar for us. This is very important, because it means that our table view is going to be the correct height. So when we design our interface, everything's going to be lined up and perfectly arranged, as it will be at runtime. So I'm just going to give this guy a title. I'm going to double click the tab item. And I'm going to give this the name of our app, Daily Buzz.

All right, now let's design that table view cell that's going to show some information about our brewing sessions. I'm going to drag out some labels. Just going to scroll up in the library here and drag out a new label. All right, I'm going to resize that to be a little bit wider with the resize handle.

And I'm going to duplicate that using Command + D, and rearrange it here. That's going to be for the temperature of the water, and I'm going to duplicate it again for the date label, so we can know when this brewing session took place. I'm gonna make this label a little shorter and right aligned. I'm going to use the attributes inspector for this. I'm gonna use the alignment control and change that to right aligned.

All right, perfect. So let's customize this label here. This is going to represent the name of the coffee that was used in the brewing session. So I'm going to give it some information here. Coffee name. And I think that we should make that bold, because that's a very important part of a brewing session. Just gonna use the font inspector to change that to be system bold. All right. And this label here is going to represent the temperature of the water that we used. So I'm just going to give it some placeholder data.

All right, and do the same for the date label. OK, so like I said, we have a subclass of TableViewCell, which has three outlets that we're going to wire up to these labels. So when we copy this cell at runtime, we can fill it in with the relevant information for the particular brewing session that is being displayed by that cell. So I'm going to select a cell and change its class in the identity inspector to be our subclass of TableViewCell. Once again, I'm going to use the custom class inspector. And I'm going to change that to our cell subclass.

And we have those three outlets. So we can use outlets and actions just like we always have in Interface Builder. So I'm going to wire up this outlet that we have defined on our subclass to these labels by control dragging from the cell and selecting the labels. So I'm going to control drag here and choose that date label.

I'm going to choose the-- oh, I'm sorry. I used the wrong subclass. It usually helps if you choose the right one. There we go. All right. So I'm going to connect the date label up. and choose date label. Gonna do the same for the coffee name label. Alright. And once again for the temperature label.

Okay, so we have our cell configured here in Interface Builder, ready to be copied at runtime to display the table view's data. So, to refer to this cell at runtime, we need to assign it a reuse identifier, so we can have some way to access it. So, in the attributes inspector for this table view cell, I'm going to assign it an identifier. I'm going to give it the name BrewSessionCell.

And we have everything on the Storyboard side for this list right now. So let's hop over to that subclass of TableViewController that manages this list. So we can fill out its TableViewDataSource method that grabs a cell for a particular row, so the TableView can display it. We're going to use the jump bar to hop over to that file. And I'm going to go to Bruce Sessions' ViewController.

And we've got a really simple class here. It just grabs some information from core data and fills out some basic TableViewDataSource methods. I'm going to paste in that TableViewDataSource method I referred to a second ago. And what this method does is it grabs the model object that represents a brewing session, and it then asks the TableView for a copy of that cell we just designed in the storyboard.

And there's a property on that subclass of that TableView cell that we can assign that model object to. And when we do so, it's going to access those outlets we just established through those labels. And it's going to take the details from the model object and display them on there. So it's a very straightforward process. So I'm going to hit Build and Run, and we'll take a look.

Xcode's compiling our project and launching it in the simulator. And we can see here that our application is launched, and it's displaying the list of brewing sessions that are already in our core data model. So you can see how quickly we were able to build a table view that's powered by data at runtime and display some information. So let's continue to flesh this out to show our detail view controller. I'm gonna quit the simulator. And I'm gonna hop back over to that storyboard using the jump bar.

Let's add another scene to represent that detail view controller. Once again, we just grab a new view controller out of the library and add it to the canvas. So I'm going to scroll down and grab another table view controller. And this time, I'm going to use a static table view to display the information, because we already know that there's going to be three pieces of information that we're going to display.

So we can just drag out three cells and design them there in line in the table view. What we want to have happen is, we want to display this detail scene when the user taps on one of these table views. To do so, we're going to create a segue. Now, segues are created just like actions or outlets are in Interface Builder. We control drag from an event source and choose the destination. So I'm going to control drag from that table view cell and select our scene.

Control drag, and it's going to ask for confirmation. I'm going to choose segue. And you can see it has created a push segue for us. Now, the storyboard automatically chose to use a push segue, because it could tell that our application was living in the context of a navigation controller. And that was probably what we wanted to do. So when the user taps on that cell, we're going to slide across that scene automatically. It's going to give this guy a title.

Let's go Brew Session or Brew Details. All right, and let's use a static table view. We can change a table view controller to use a static table view by selecting its table view, and in the attributes inspector, we'll change the content type from dynamic prototypes to static cells. Let's give that a click. I would like to use a grouped table view for this, because I like the way that looks. I'm just going to change the style to grouped.

And I'm going to start out with just one cell for now. I'm just going to give those two a delete. So you can see, we're able to design the cells right there inline in Interface Builder. And this is going to look exactly how it will at runtime. So, let's drag out a label to act as kind of some information about what we're trying to display here. I'm gonna resize that to give us a bit of room. And let's make this right align, so I'm gonna use that alignment property. And I think we're gonna give that the name Coffee.

All right, and let's make that bold as well. Gonna use the font inspector. And now we need to add a label that's going to correspond to the value we're going to update at runtime. So I'm gonna drag out another label and add it alongside. I'm gonna resize that as well to make sure we have room.

Let's change the text color to something a bit lighter. Gonna choose steel, I like that color. Okay, so we've got our first cell. I would like to duplicate this to add room for the other two pieces of information we're going to display information about. So I'm going to select the table view section in the jump bar.

And I'm going to bump up the number of rows from one to three. Give it two clicks. And you can see that the table view editor automatically copied the contents of these cells for us. Yeah, it's pretty neat. I wouldn't want to do this any other way. So let's change the label on the left here to be temperature. And I'm going to change this bottom one to be date.

I have another subclass of TableViewController, which knows how to get the information out of that brew session model object, much like that TableView cell, and display it on three labels that we're going to wire up inside of our TableView. So I'm just going to change the class of this TableViewController to be that subclass.

I'm going to change that and choose brew session details. and I'm going to control drag from the table view controller, and select those three outlets. I'm gonna start with the coffee name. Just gonna wire that up, choose coffee name. You can do the same for temperature. I'm gonna choose that. And for date.

Okay, so we've got the DetailViewController fleshed out. We've got our list. We have a segue that tells it to slide across. Now all that's left is we need to tell that DetailViewController what it's supposed to show information about. So we're going to use that piece of API I referred to earlier, prepareForSegue. So let's hop over to our implementation file for the list and implement that method. Now, before we do so, we should give this segue an identifier so we can refer to it at runtime.

I'm going to click on the segue and view its inspector. Segues are just like any other object in Interface Builder, in that you can select them and interact with their properties. I'm going to switch over to the Attributes Inspector. And in the identifier field, I'm going to give it a name. ShowBrewDetails. All right. And now I'm going to hop over to that implementation file. implementation file.

I'm going to add my prepare for segue method. Let's paste that in. All right, so let's take a look at what this does. The first thing we do is we check the identifier to make sure that we're interacting with the segue that we think we are. This is a simple future-proofing mechanism. What if you go and add a segue later on? You wouldn't want to be doing the same setup work for that. So you always want to check for this.

And then after that, we get the model object out of our core database, and we assign it to the detail view controller of the segue. The segue gives us all of the context for how it's being presented, in that it has the destination view controller. That's the scene that's being presented.

In our case, that's the detail view controller. It also contains some other information that Rob's going to talk about later on. So we give that brewing session object to our detail view controller, and the storyboard does the rest for us. So let's hit build and run and take a look.

So we've got our list again. And now when we tap on one of these table view cells, We're going to see the details about it. So you can see that we were very easily able to put together these two scenes, connect them up with a segue so that we can get this transition at runtime using the navigation controller. And then we were able to pass context to that scene as it's presented, so it can display the correct information.

So that's how you pass information down into a scene that's being presented. What about the other way we talked about? What about bringing information back from a scene that's already been presented? Let's talk about that. I've got another storyboard that I'm going to jump to. And I've used these same fundamental techniques of building table views and connecting segues to continue to flesh out our coffee app. Let's take a look. So I'm going to open up this other project here and quit the simulator. Just going to give that a quick. And I'm going to open up that other project.

And you can see here, we have another Storyboard. And we've added a bit of extra content to it. We've got three more scenes at the top. Let's talk about those. But first, you may notice that we are zoomed out right now. Storyboards have the concept of a zoom level on the canvas.

So you can both zoom into the editing level, so you can interact with the controls. And this is just a standard mode that Interface Builder has always used. Or you can zoom out to get an overview of all the scenes in your application. This is really good for getting a high level conceptual overview of your application, because it allows you to see at a glance the flow of your application. So let's take a look at what we've added. I'm going to zoom in by double clicking on the canvas.

And you'll see that we've added a plus button here that you can tap to show a controller that allows the user to enter in information about a brewing session. Now, the way we've implemented this particular scene is we have a modal segue that presents a navigation controller. And that navigation controller has the ad scene as its root view controller.

We've done this, we've added this navigation controller as well, so that we can use the navigation controller to slide on another screen whenever the user taps on the coffee cell that's present in the ad scene. So, we've got this ad scene here. It's got its table view configured, and it's got two buttons at the top. What we're going to use is we're going to wire up two actions from those buttons to two different methods that are in our ad session scene view controller subclass.

That are going to refer back to the list via a delegate to tell it that the user has hit cancel or done, so it can continue on and do the correct thing. We've already implemented that delegate here, and I'm sure you're all going to be really curious about how to do that. So, we're going to do it in a second. But first, we're going to wire up these two buttons to those two existing methods in our subclass.

So I'm going to control drag from the cancel button, and choose the view controller. This is just like making an action in Interface Builder. So I'm going to control drag, choose the view controller, and I'm going to select the cancel method. Going to do the same with the done button. Going to wire that up to the scene there, and choose done. Save that and hit build and run.

And we'll take a look at what we have. So once again, we've got our list. When you tap on one of the cells, we'll show the detail view controller. But now, when you tap on that Add button, we present a modal view controller. And we have those two buttons that are wired up to two methods on our add scene view controller. And those are going to communicate back using a delegate to the list. And when they do that, the list is going to call dismiss view controller to get rid of the modal view controller. So let's hit cancel and take a look.

So you can see, it worked. So I'm gonna quit the simulator, and we're gonna talk about this coffees list here. I have another scene that's kind of floating there for you in the canvas. And that's the scene that's going to manage displaying the list of coffees. And when the user taps on the coffee cell, we're going to show that.

We're also going to talk about how to use a delegate to relay that information back. Let's wire up a segue from the coffee cell to this table view controller. It's going to control drag and choose a scene, and establish a segue. So, once again, we've correctly added a navigation bar there, and we can give it a navigation title. Gonna call it Coffees.

Let's change the title. That's not what I wanted. Let's try this again. Hmm. Well, that looks like a bug. I'll take a look at that later. And we've got our coffees list. So we've got that segue. And what we really want to have happen is, when the user taps on that table view cell, we want to relay the coffee that he selected, or he or she selected, and pass that back to our add scene. So we're going to use a delegate for that.

Rob Marini, Joshua Pennington Let's hop over to the header file for the coffee scene and add a protocol that's going to define our delegate. All right, so I'm going to hop over to the header file for the coffee scene. And I'm going to add a protocol that defines our delegate.

I'm going to paste that in. And this is a really simple method. We simply relay back the coffee that the user selected. So let's add a forward declaration for our protocol. And let's add a property. This is just a really simple delegate. Rob Marini, Joshua Pennington And I'm going to hop over to the implementation file.

And now we're going to add the familiar TableViewDidSelectRowAtIndexPath method, so we can be informed whenever the TableView receives a tap on a particular row. And we're going to get the model object that represents that coffee, and we're going to relay it back to that delegate, using that property and that protocol we just defined.

And this really is the basis of how you'll do this for all of your applications. So let's scroll down and add our TableView method. Oh, whoops, first let's add our synthesize for our delegates, so the compiler can automatically add our accessor methods. And we'll add the method down here.

So, what this does is it asks the table views, the table view for its row, it's got it here as a parameter, and then it asks the core data model to get the model object for that. And we're gonna simply just call the delegate and pass that through.

All right, so now what we want to have happen is we want to set the delegate of this coffees list to the add scene, so that when the user taps on that, we can pass that object there and it can commit it to the core data model. So let's hop back over to the add scene view controllers implementation file.

And we need to declare that this class conforms to that delegate protocol we just established. So I'm going to put that in there. And now we need to implement that delegate method that tells us the user selected a coffee. I happen to have a property here already, selected coffee, which represents the coffee that the user selected. So I'm going to paste in that delegate method.

And this simply sets that method, and then it pops the view controller on the navigation controller, so that when the user taps on it, we automatically dismiss the coffees list. So that's pretty straightforward. So now what we need to do is we need to wire up that delegate property. From the coffees list to the ad scene, whenever the scene is being displayed, so when the user taps, we can get that call back.

So first, let's go over to the Storyboard and give that segue we created an identifier, so we can implement our prepare for segue method. All right, I'm going to select that, and I'm going to give it an identifier. I'm going to type in show coffees, that's a good name. And I'm going to hop back over to that file, so we can add our Prepare for Segway method.

I'm just going to add that there. And once again, we check the identifier of the segue to make sure that we are interacting in response to the correct segue firing, in case we add a second one in the future. And in this case, we access the destination view controller. That's the coffees list. And we set its delegate protocol back to the receiver. So I'm going to hit Build and Run, and let's take a look.

So we've got our list. I'm going to hit the Add button. And I can tap on the temperature field and give it some value. 203 is a good brewing temperature. And I'm going to tap the coffee cell. And when we do that, we have presented a table view with a list of coffees. And when I tap on one, It's going to slide back over, and you can see it's updated our label with the correct information. So that's how we pass information back from a scene that's already been presented. We use a delegate.

I'm going to hit Done, and it's added it to our core data model. So you can see here at the bottom, we have that brewing session that we just entered in. It's ready to be displayed using the Detail View Controller. So that's it for my demo right now.

And you can see that we were able to very quickly put together an application that would have taken a very long time to build if we had written it all in code. And we were able to use those key concepts that I talked about. We created scenes with segues connecting them. And then we were able to pass data to scenes as they were being displayed. And we were able to bring information back. So that was it for my demo. Can we go back to the slides, please? Thanks.

So once again, we used all these core principles in Storyboards to shuttle the data around and very quickly assemble our interface. So now Rob's going to come on stage, and he's going to talk to you about how you can interact with Storyboards at runtime, and how you can begin to integrate these into your applications today. Thank you.

So what do you guys think? So we think it's pretty great. So, as Josh said, my name is Rob, and today I am here to talk to you about the API for interacting with storyboards in your source files, and how to integrate storyboards into your applications today. So, let's start with the API. There are really three key parts to this. There's UI Storyboard, UI View Controller, and UI Storyboard Segway. Let's start by talking about UIStoryboard. And really, an instance of a UIStoryboard object is a runtime representation of everything that you've configured inside of your editor.

And the way you load one of these in your app is either by calling this method, StoryboardWithNameBundle, on UIStoryboard, and getting back an instance. And you would typically do this if you're trying to load some UI from the Storyboard that's not the first thing that the user is going to see. Alternatively, if your Storyboard does represent the starting point of your application's user interface from launch, you could specify the name of the file in your application's Info.plist using this key, UIMainStoryboardFile. This behaves the same way as it does for NIBs.

And when you do that, when your application launches, the UI application object just asks the Info.plist for the value of this key, and calls this exact code. It's everything that you would do, we just do it for you. Once you have a Storyboard, what do you do with it? Well, typically, you're going to be loading view controllers from your Storyboard. These are the scenes inside of our editor experience. And the two ways that you do this are by taking advantage of things that you've set up in the editor.

You can either load the initial view controller of the Storyboard, or you can set arbitrary identifiers on view controllers inside of the editor, and load them using instantiate view controller with identifier. A UIStoryboard, at the end of the day, is a series of NIBs. It's a series of NIBs. And some metadata that we can use at runtime to perform efficient loading and unloading.

Why am I bringing that up? Well, for you, this means that API that you're used to continues to work for doing your custom initialization and setup. You can use ViewDidLoad, AwakeFromNib, and Aniwa Coder to do things dynamically when your view controller is about to appear. So we have a UI storyboard, we have a view controller, now what do we do with them? In addition to everything else that your view controllers do, they perform a critical role in the passing of data throughout your application.

Josh introduced you to PrepareForSegue, which is your opportunity to load the view controller that's about to present user interface to your users, and set it up before it appears. A view controller also has a back pointer to the storyboard that it was loaded from. And what that means is that you can use that to load other arbitrary view controllers, and have them load your view controller. And this allows you to load your view controller at any point in your application. This allows for some really powerful user interfaces that adapt dynamically in response to what's going on around them. And besides interacting with and participating in segues, view controllers also can perform them.

You can set this up inside of Interface Builder, the way that we've shown you, by connecting actions inside of the canvas. But we've also added support in iOS 5 for gesture recognizers. So you can perform a segue in response to a multi-touch gesture. And in code, you can even perform these in response to things like device motion events, or even sound.

I don't know how to do it in response to sound, but I'm sure people in the audience do. What is a segue? Well... You'll probably be interacting with segues in two contexts. The first is as information for your prepare for segue method. And here, the thing that you care about is probably the view controller that's about to present UI to the user, and the identifier of the segue, so that way you can know right then what segue the user initiated, so you can perform the proper setup.

We also have a subclass of this in the frameworks, which is UI Storyboard Popover Segway. And just like it does everything that every other Segway does, but it also lets you get to the popover controller that's about to present the view controller. It's pretty handy. The other way that you'll interact with Storyboard Segways is by creating them yourself.

And here, the thing that's important to know is the view controller that performed you, the view controller whose UI you're responsible for loading, and some point in the middle at which you can execute your own transition, and take care of any relationships of the view controllers as they're about to appear. And that's the API.

It's pretty simple, and it's intentionally simple. It's really representative of a beautiful marriage between the tools and the frameworks to let you take advantage of things you can design visually and easily inside of the editor at runtime. Now let's talk about integrating Storyboards into your applications. So how many of you either have an app on the store today, or are in the process of writing one that you'd like to be on the store? No one.

So we would love it if you leave here today and start taking advantage of Storyboards immediately in your applications. And so we've built them from day one to be flexible and to be powerful. And if you're going to do this, there are sort of two approaches that you might take. The first is you can rebuild your entire UI from scratch. This isn't as crazy as it sounds. You get to get rid of a lot of code by moving to storyboards. And less code is less bugs.

Of course, if you don't want to do that, you can also adopt them incrementally, taking advantage of storyboards to describe new user interface for new features. And today, that's exactly what we're going to show you. Josh is a big fan of coffee. But I'm a big fan of food. Last year, I built this application on stage, and the reaction I got was, wow, it's great. I have a way to view my recipes now. But I want your recipes.

So today we're going to add some functionality to it. We're going to add a UI for sharing our recipes. What we're going to do is take our existing application, get some user interface defined in a storyboard, and present it to our users in a popover. This is actually a pretty typical case that you might be interested in. So let's get started. Going to go to my application for a second. And open in Xcode. You know, I think I want a bigger font. I'm getting a little old.

So, here we go. Now, What I'm going to do here is actually a little interesting. I'm told that social networking is quite popular, but I'm not very social myself. So I've asked some of my colleagues to put together the experience for sharing these recipes on a social network and using a web service that they've set up. So what I have here is a storyboard file, which represents the UI for doing this, and a static library that contains all the implementations for the view controllers and everything that's involved in doing that. I'm going to add that to my application.

And I will copy them. Great. So now, what I want to do is put a button in the toolbar that when you tap on it, presents a popover. This is something that if you've had any experience writing iPad applications, is pretty common. Going to go to the library. And find a bar button item, and I'll just drag it in. And I want it on the right side, so I'll add some space before it. There we go. I'm going to call it Share.

Now, as is typical with buttons inside of user interfaces that you design in Interface Builder, you probably want an outlet to the button and an action from it. So, I'm going to hide the utility area and open up the Assistant. So, as you can see, Xcode has helpfully shown me the files owner of this particular view. So, I'm just going to control drag from the button to the header, and I'll call this Share Button. And boom, I have an outlet.

Now, I want to set up an action. I'm going to go to the Navigate menu, and select Jump to Next Counterpart, and here's my implementation file. Now I'm going to control drag from the button into here, and set up an IB action. I'll call it Share Action. Now, typing on stage actually ends up being really hard, so I have some code that I'm just going to paste in here.

And what this does is we load a storyboard from this file that we dragged in. We get the initial view controller out of it. We take the sharing view controller defined by that workflow, hand it a recipe, and then present it in a popover. So let's build and run and see what we get.

and Ron, build and run. Here we go. I'm going to go to landscape. And select fillet of beef au poivre, because I could really go for a steak right now. And I'm going to share it. So I click the button, and here I have some UI that I didn't design, someone else did for me, and it's going to let me share my application with my recipe with the world. I'll select the share option, and as you can see, here's our recipe. And now we're going to publish it. Whoa, what just happened? Let's look at that again, 'cause I think it's pretty cool.

So, what we're seeing here is an example of a custom segue. As it turns out, I happen to have the source code that provided this UI for me. So I'm going to quit the simulator and go back to the finder, and go to that project. And here, we have the Storyboard. Pretty simple. And you'll notice that we have a segue here with a different icon than what we've seen before. Going to open up the utility area and take a look at it. You'll notice it's a custom Segway, and it has a custom class.

So let's take a look at that. And it's pretty simple. We have one method, perform. As I mentioned earlier, this is your chance to set up the relationships of the view controllers in transition, as well as to perform your visual transition. So here, I'm calling a C function, which someone who is a lot better at core animation than I am put together for me.

Transitioning through my navigation controller stack after some delay. If we take a look at that, you'll see here we're using an emitter layer, and just adjusting the values of the particles that it's drawing as we go. And that provided for that effect. And really, that's, you know, probably not a great idea to burn view controllers under your users.

You see what you can do just by writing relatively few lines of code in order to provide a custom visual feel as your users navigate through your application. So what did we just see? Well, you can begin adopting storyboards in your application without rewriting the entire thing, just loading one to present parts of your UI. And if you have things in your application that aren't well represented by the system transitions, you can define them in a custom segue. Maybe you have a view that pops out of a button, something like that.

And of course, what we've gone over today is what Storyboards are, and how you can create them and use them, both in new applications and existing applications, by taking advantage of our editor and our API. If you're interested in this, you can find out more about using Interface Builder in Xcode 4. It was a session yesterday.

If you were at Stumpy Experts last night, you can hop in the Wayback Machine and go there. Otherwise, they'll be on the videos. There's also a session that's being repeated tomorrow, What's New in Cocoa Touch, going over all the new APIs that we have available in iOS 5. And if custom segues are really your thing, there's a session on Core Animation Essentials. With that, thanks guys.