My name is Joshua Pennington, and I'm an engineer on the Interface Builder team. And today, we're going to talk about how you can adopt Storyboards in your app. We're going to cover a couple topics today. I'm going to start out by giving you a quick overview of Storyboards. Then my colleague Tony is going to come up here and talk about how you can adopt Storyboards in applications that use CoderZibs. And then I'm going to finish by talking about some great new features for Storyboards in iOS 6.

Let's start with the basics. This is a Storyboard. And a Storyboard allows you to view your app's entire user interface in one place. And you can also view the transitions between the parts of your application, so you can very quickly get an overview of the application just by glancing at it.

Joshua Pennington, Tony Ricciardi And there are two main concepts in a Storyboard. The first concept is that of a Scene. A Scene is a view controller. And it can represent the entire screen in your app or just one major component area, like a split view pane in a split view controller on iPad. Joshua Pennington, Tony Ricciardi And you can drag in views. You can select things and resize them. You can inspect their attributes in the inspector. So all of the normal interface builder affordances are present here.

Joshua Pennington, Tony Ricciardi And this is where you're going to spend most of your time flushing out the UI of your application. So that's the first concept, a Scene. Joshua Pennington, Tony Ricciardi The second concept is that of a Segway. A Segway defines navigation in your Storyboard. Shows you how to get from point A to B. Joshua Pennington, Tony Ricciardi And you create a Segway by picking an event source, like a button or a table view cell, and then choosing the Scene that you would like to transition to.

Now, another important concept in an application is passing information around. I have this list of events, and when the user taps on one of the events, I want it to display a map view controller that shows the event. In defining this navigation in the Storyboard as a breeze, we just create a segue from the cell to the scene that we want to display.

When this Segway runs, what we want to do is pass some information along so we can know what to display. We've got a method for that. Prepare for Segway. This is a method on UI View Controller, and it's intended to be overridden. We'll give it a call on the Source View Controller, and you can write code here that will take effect whenever the Segway fires.

Joshua Pennington, Tony Ricciardi So, whenever the Segway runs, we'll call that method, and you can pass along any information that you need to display in the Destination View Controller. Joshua Pennington, Tony Ricciardi So, let's take a look at what this looks like inside of an application. Joshua Pennington, Tony Ricciardi All right, so let's open that up.

Let's go into full screen mode. And here in my Storyboard, I have three scenes. The first scene is a navigation controller. This is a standard UIKit object that manages a stack of view controllers that have been presented, and then also manages the transition between these scenes with a nice push animation.

It also draws the nav bar at the top that gives us a title and a back button. The second scene is a list of events. And I'm using a table view for this. And so at runtime, I have some code that looks in a database and it makes a number of copies of this prototype cell that I've defined. We'll talk more about table views in a bit. And the last scene I have is a map view controller. And you'll notice if I zoom in here, You can zoom in on storyboards and double tap to zoom back in.

In the left, I have a Segway connecting the Navigation Controller to the list of events. This is a type of a Segway called a Relationship Segway. And it simply defines the root view controller property on the Navigation Controller. And so this kind of just bootstraps the process. So when the Navigation Controller is displayed, the scene comes along with it.

The second segue connects the list of events to the map view controller. And this segue is linked up to that table view cell, so whenever it's tapped, we slide across to the map. What I'd like to do is add a second scene that's going to display information about the event. I want to display the details about it. And I'd like this segue to be triggered when the user taps on the little blue arrow on the side of it, like the phone application.

Joshua Pennington, Tony Ricciardi So I'm going to create a new scene. And I create a scene just by dragging a view controller from the library and dropping it on the canvas, like this. So I'm just going to give us a little bit of room here and drag out a new table view controller.

I can create a Segway by control-dragging from the TableView cell and choosing this scene. You can see here that it's presented a list, and there's two sections in this list. The first one says "Selection Segway," and it has a number of Segway types below that. And this is called the "trigger." So this would let me create a Segway that's going to be fired when a normal tap takes place on the TableView cell.

And we've already got one of these wired up to the Event Map Controller. The second section says "Accessory Action." And this is what's going to happen whenever the user taps on the Accessory Action area. And we want to create one of those. So I'm going to choose a new Push Segway.

So you can see that we now have a segue that's going from that table view cell to the scene that we just created. And we also still have that normal selection segue wired up to the map view controller. So let's customize this scene that we created. I'm going to give it a title. I'm just going to call it Details.

And I have a table view below that. And table views come in two flavors. We have a prototype-based table view, which is where you have one or more prototype cells that you assign identifiers to. And then at runtime, you write code that asks for copies of these cells, which you then customize with the information. And this is fantastic for things like news feeds or emails, where you have a dynamic number of items that you'd like to display.

The second type of table view is called a static table view. And a static table view allows you to define the data set entirely in IB. So for things like menus where you may already know exactly how many things you'd like to display, this works out great. It also works out great if you have, you know, something like details for an event. I already know I have two rows I'd like to display. So I'm going to use a static table view for this. And I can change this table view to static by clicking on it. And in the attributes inspector, changing its content from dynamic prototypes to static cells.

I can select a cell and hit delete. I can also command click on this other cell and select both of them. I actually selected its parent there. Let me try that again. All right. And TableView cells have a number of built-in styles. I'm going to choose the right detail style so we can get two nice columns with information. And I'm going to select these labels on the right, or on the left actually, and type in some information. I'm going to call this author name. And for the second row, this is going to display the date.

And while I'm at it, I think that the style would look better if it was set to grouped, so I'm going to change that as well.

So now when this controller is created, it's going to be an instance of that subclass. So we've got this segue that hooks up to this controller, and the controller knows how to display an event. We just need to give it an event now. So we're going to use that method that we talked about a bit ago called prepareForSegue.

And prepareForSegue is going to run on that list of events whenever this segue is initiated. So we're going to put some code there that's going to pass this event model object along. And whenever you write a prepareForSegue implementation, you're going to look for identifiers on the segues. And the identifier is just a string, so we're going to assign one to the segue. And segues are just like any other object in IB. You can select one.

In the Inspector, assign attributes. I'm going to call this "Show Details." And if I hop over to the subclass for the Events View Controller, I can implement Prepare for Segway. I'm going to use the jump bar to move over to that file. And you can see that I already have an implementation of prepare for segue here that finds the event that goes along with the cell that was selected and sends that to the map. I'm going to paste in another fragment that does the same thing but for the show detail segue.

So once again, this just looks at the list of events, finds the correct one, and sets that on a property on the destination view controller. Let's hit Build and Run and see what we have. Okay, so we've got a list of events, and when I tap on one of the events, a map is displayed showing the event's location.

I can hit the back button and go back to the list. And if I tap on the detailed disclosure button on the right-hand side, that second segue is fired. We load the information and customize it for the event that was selected. Joshua Pennington, Tony Ricciardi So you can see that we were very quickly able to create a UI for our application using these two main concepts, and using that prepare for segue method as a glue to pass some information along. And this is the basis of how you'll build any application using a Storyboard. So, I'm going to invite Tony up, and he's going to talk about how you can mix Storyboards with existing applications that are using code or ZIP files. Tony? Thanks, Joshua.

Good afternoon. My name is Tony Ricciaardi, and I'm also an engineer on the Interface Builder team. In the app Joshua just showed you, the UI was implemented entirely within a single Storyboard document, and that document served as the entry point to the application. Now I'd like to show you a few ways you can integrate Storyboards into your app when you'd prefer to implement certain parts of your UI and code.

First, I'll show you how you can combine views from Storyboards with views implemented in code. And then I'll show you a couple ways you can customize transitions between scenes in your Storyboard using code. Let's start with an example. This is my game. It's called Dungeon Plunder. It's a retro role-playing game that I've implemented entirely in code using OpenGL.

In this game, you explore this dungeon and you collect treasure and you fight monsters that you encounter along the way. And today, I'd like to add a new feature to this game that lets me browse through my character's inventory and see all the items I've collected in this dungeon.

I'd really like to implement this inventory screen using a new feature of UIKit called Collection View. A Collection View is like a table view in that it manages a collection of cells and also gives you a lot of freedom with how you can layout those cells. In this case, I'd like to use a two-dimensional grid layout like this.

In Xcode, we're making it very easy to design collection views in Storyboards with Interface Builder. And so I'd like a way to implement this new inventory screen with a Storyboard and then wire it up to the rest of my app without going back and reimplementing all my old UI code. So I can do that using the Storyboard API.

First, there's a class method on UIStoryboard called StoryboardWithNameBundle. And that just lets me load a Storyboard document at any point in code. And then I can call a method on that Storyboard called Instantiate Initial View Controller. And that gives me a copy of the initial view controller of that Storyboard. The initial view controller is the entry point into the Storyboard, and it's generally the root scene in your scene graph. And that view controller I get back is indistinguishable at runtime from any other view controller that I would create in code normally.

So now I'm going to show you a demo where I integrate that new feature into my app using a Storyboard. Okay, so this is my Xcode project. And you can see I've already added that Storyboard to my project. But I haven't yet wired it up to the rest of my app. And before I do that, I just want to hit Build and Run. So let me quit the simulator. I'll just hit Build and Run so you can see what that currently does before I make any changes. I need to do a clean build.

So in this Storyboard, I have three scenes. On the left, I have my navigation controller, which controls the navigation stack.

So that's all already been implemented, and I just want to wire it up. So I'm going to go over to my AppDelegate file. And now we're in Application Did Finish Launching with Options. And in here, I just create the view controllers for my tabs and add them to this array of view controllers managed by the tab bar controller.

So I'm going to paste in a couple lines of code. And these lines just use the API I discussed. The first line loads the Storyboard document, and the second line creates a copy of the initial view controller. Now all I have to do is add that view controller to this array, and I'll hit Build and Run. And you can see I have that third tab.

I can tap on a cell and see the details using that detail screen. So as I mentioned before, I really wanted to have this inventory screen laid out using a two-dimensional grid instead of this single column that I have here with a table view. So to do that, I'm going to go back to my project and swap out the table view with a collection view.

First thing I'll do is delete the table view controller. And I'll open the library and drag out a collection view controller. So collection views in Interface Builder are very similar to table views. They have this notion of a prototype cell, which is this square you see up here.

That's going to show an image of my item. So I'll just drag out an image view and add it to the cell.

At runtime when I create copies of this cell, I need a way to reference that image view. And I can do that by creating a custom subclass of UICollectionViewCell that has an outlet to an image view. I've already done that, and I'll just show you that class really quickly.

So that's all we have here is a subclass of UI Collection ViewCell that has an outlet to an ImageView. So now I'm going to go back to my Storyboard. I'll open up the outline so I can select the cell, and I'm going to give it that custom class.

Now I can wire up the outlet by control dragging from the cell over to the image view. I also need some code to actually go and create the copies at runtime, and that is all implemented in my custom subclass of UI Collection View Controller. Let's look at that code.

So this method here is part of the UI Collection View Data Source Protocol. It's called Collection View Cell for Item at Index Path. And all I do in this method is create a copy of my prototype, which I reference using a reuse identifier, which I call inventory cell. And then I just set the image of that cell.

So I'm going to go back to Interface Builder and give the cell this reuse identifier so that I can refer to it at runtime. So the cell's already selected. I'll just go to the attribute inspector and call it inventory cell. I'm also going to need to give this CollectionViewController a custom subclass so that that data source method gets called.

Now I want to add a header view to this collection view that shows up above each section of items and just says what kind of items are in that section, like weapons, armor, potions. And I'm going to do that the same way I designed the cell. So in Interface Builder, we also have the notion of a prototype section header view for collection views that use a flow layout, which gives you that two-dimensional grid. Joshua Pennington, Tony Ricciardi So I can select the collection view and go to the attributes inspector and give it a section header. I'm just going to add a label to that header view.

I'll give it some white text so we can see it, and I'll make it a little bigger. And now I'm going to do the same thing I did for this cell. I have a custom subclass. UI Collection Reusable View, which just has an outlet to a label. And I'm going to go and set that as the custom class of my header view.

Now I can control drag from the header view over to the label and wire up that outlet. If we take another look at my data source, my collection view controller, you'll see I have this other method here. I'm going to show you a tutorial called Collection View, View for Supplementary Element of Kind at IndexPath, which creates copies of that prototype header view I created. And I reference it using this reuse identifier inventory header.

So I'll go back and give that reuse identifier to the header view. Now I need to wire up some segues. I want to make this Collection View Controller the root view controller of my Navigation Controller, so I'll drag out a Relationship Segway. And you can see when I do that, I get a nav bar, which I can give a title. I'll call it inventory.

I also want to make a push segue from the cell to the detail screen, so that when the user taps on the cell, they see those details. So I'll select the cell and drag out a push

In this code, all I do is set the title and image and the attributes that's going to show up in that detail screen. So I need to go back and give this identifier to that segue. I'll just select the segue and call it item detail.

Okay, now I'll hit Build and Run. And let's take another look at the inventory screen. You can see now I've swapped out the table view for the collection view, but I still have all the same data show up. And I can tap on a cell and see the details for that item.

There's just one more thing I'd like to add to this inventory screen. I'd really like a way to know where I found this item in the dungeon. Down the line, I might be running low on potions and I need to find some more. And it might be useful to know where I found this potion so I can go look in the same area. So I'd like a button that shows up on this screen that I can tap and it'll take me back over to this map screen and show me where I found that item. So let's go add that.

I mentioned earlier that that map view was implemented in code. So I need a way to wire up a segue from my detail screen over to that map view controller while having it load its view from code rather than from the Storyboard. Well, it's actually very easy to do that.

If I set the custom class of a view controller in my Storyboard and that custom class overrides load view, then at runtime when I reach that scene, I'm going to execute that load view method, which loads the view from code.

This first scene will represent the Game View Controller. This will represent the Map View Controller. And I'm going to wire up a third relationship segue here for the Inventory View Controller.

So let's zoom in on the GameViewController. As I mentioned, I already override LoadView in my GameViewController class, so I just need to set the custom class of this ViewController. And I can just delete this view since it won't be loaded from the Storyboard anyway. So now what we have here is a scene with a view controller but no view in the Storyboard. I'm also going to customize its tab bar item. I'll give it an image. There we go. And I'll do the same thing for the map view controller. Delete its root view and give it a custom class. And I'll customize its tab bar item.

Now I want to add that button from this detail screen over to my map view controller. Let's zoom in on the detail screen and I'll add a button and I'll call it location found. I'll wire up a segue from the button over here, make it a push segue. I'll rearrange these scenes a little bit.

So now I need to go back and delete that code that previously created the tab bar controller and those two other view controllers, and then load the tab bar controller from the Storyboard instead. So let's go back to the AppDelegate file. I'm just going to select all this code and delete it. Then paste in two lines. The first one loads the Storyboard and the second one sets the tab bar controller as the initial view controller of the Storyboard. I'm going to hit build and run now.

And you can see I have the same functionality I had before, but now these view controllers are being loaded from the Storyboard instead of using that code I had previously. So you can see my map screen that shows me my character's location, and I can tap on an item and reuse that same scene in the Storyboard, create a separate copy using that segue. And now this shows, now using that to prepare for segue method on my detail view controller, I passed along the location of the item.

So in that example, I showed you how I could combine views. I could integrate this Storyboard, this new feature for the Storyboard into my app while still using my views that I implemented in code. And I could also load those code-based views from the Storyboard, which let me visualize the entire flow of my application without reimplementing the UI for those old features. Now I'm going to show you a few ways you can use code to customize transitions between scenes.

Let's say I wanted to add a game over screen to my app. I wanted to present this view when my character's life total went down to zero. Normally, you would create a segue by dragging out a connection from the triggering UI element, like a button, over to the destination scene. But in this case, there's no UI element that's going to trigger the segue. I want it triggered by custom logic, when I know that my character's life total goes down to zero.

So I need to create what we call a manual segue, and I do that by dragging out from the ViewController's icon in the dock over to the destination scene. And then in code, at the appropriate time, I can trigger the segue by calling a method on UIViewController called performSegueWithIdentifier. And that identifier is just a string constant. I give the segue an interface builder.

Now let's say that you have a scene in your Storyboard that represents an error handling view, and you want to present this whenever there's a problem communicating with the server. Your app might have 300 different places where you talk to the server, and you need a way to present this screen from an arbitrary line of code where you might not have a reference to a view controller and be able to call perform segue with identifier.

So you need a way to jump to this scene without a segue. You can do that by giving the view controller an identifier in the Storyboard, And then calling a method on UI Storyboard called InstantiateViewControllerWithIdentifier. And that just lets you hop to any scene in your graph without using a segue.

So before Josh comes back up here, I just want to recap a few of the techniques I showed you for integrating Storyboards into your app while implementing custom behavior and code. First, you can mix views from Storyboards with views from code, either by loading a Storyboard from code or by having your view controllers in your Storyboard load their views from code.

I also showed you a couple ways you can customize transitions, either by triggering segues manually using perform segue with identifier, or by jumping directly to scenes using instantiate view controller with identifier. Now Josh is going to come back up here and talk about some cool new features we're adding to Storyboards in iOS 6. Josh.

Thanks, Tony. Thank you, Tony. So, let's talk about some of the new features in iOS 6 for Storyboards. We've got a couple new ways that you can use Storyboards in your apps. And let's talk about View Controllers. So View Controllers are an essential part of any app, and they're also that first important concept seen in a Storyboard.

And they're sometimes used in isolation. You might have one for an entire screen worth of content, and you'll use something like a navigation controller or a tab bar controller to manage the display of them. However, sometimes you want to display a view controller inside of a view controller. So if you wanted to do this in some applications, you might use it for something like you've got Chrome around the edge of a navigation controller.

So you can use view controller containment APIs added in iOS files. to achieve this. If you wanted to do this today, you would assign an identifier to a scene. You'd write a bunch of code to make a copy of it and use the containment APIs to install it inside of another view controller.

But you have to write a lot of code for this, and you don't get to position the view in Interface Builder. So today, with iOS 6, you can create embed segues. You just drop in a container view and wire up an embed segue. And when your view controller loads, you automatically have another view controller inside of it. And that's it. There's no code for this. Thanks.

I'm pretty excited about this too. So let's hop over and take a look at this. And I've got this app I wrote earlier for looking at information about the gross domestic product. I'm an economics nerd, so I like this stuff. And I've got three scenes in my Storyboard. I've got a nav controller. You guys all know about that. I've got a list of states. And on the right-hand side, I've got a detail view controller. This is a pretty standard master detail app.

And what I'd like to do is have a map on that very last scene. But I have this map view controller that I always use in my projects because it knows how to do stuff like display a highlight region and display annotations and a bunch of other complex stuff that I don't want to duplicate in every single view controller. And I want to use this view controller inside of that other one. So I'm going to use the new embed segue to take care of that.

And let's take a look at that subclass I'm talking about. So I've got a pretty straightforward class here. I've got two properties. I've got an outlet to a map view, so we can wire up a map view. And I've got another property that specifies the highlight region.

And this just takes an object that conforms to a protocol that has some basic points to outline the shape. So I'm going to go back to Interface Builder and add a map view, and we'll wire that up. So let's hop back over to the Storyboard using the jump bar. And I'm going to drag in a map view.

I'm going to hook up that map view outlet. And so now we've got a view controller that, if I hit Build and Run, would be embedded inside of that container view controller. What I'd like to do is pass that highlight region along. So I'm going to give that segue an identifier and then implement prepare for segue on the detail scene so I can pass that information along. So I'm going to click on the segue and type in embed map controller and hop over to the subclass for the detail view controller and paste in a bit of code that I wrote.

And what this does is it looks for the identifier and it passes along the detail item that I'm inspecting as the highlight region. And so this is just a model object that represents the state and it conforms to that protocol. So I'm going to hit build and run and we can take a look at this in action.

So you can see that I have a list of states, and when I tap on one, the map view controller is installed and displays the highlight region. So we're able to very quickly have a view controller inside of another view controller and not have to write a single line of code except for that for customizing it. So I'm going to hop back over to the slides.

I've got this application here, and it has a couple scenes that the user can navigate through to create an account. And when they're done, they have the option to hit Done and dismiss the form sheet, or hit Reset and go back to the beginning of the sheet to re-enter in their account details. In my Storyboard, it looks like this. I've got a scene that presents a navigation controller and a form sheet.

And so we do this by adding unwind actions, which are a new type of Ivy action, to your view controller subclasses. And these serve the purpose of declaring points of interest for you to roll back to in your application. So you'd add an unwind action like done or reset to your view controller subclasses.

And then we display these as destinations in Xcode when you go to create a segue. Joshua Pennington, Tony Ricciardi And so we do this by adding unwind actions, which are a new type of Ivy action, to your view controller subclasses. And then we display these as destinations in Xcode when you go to create a segue.

And whenever you connect to that, we'll display a list of unwind actions. So in the case of reset, I would connect to that and choose reset. So now we have an unwind segue. And when that unwind segue fires, the first thing that we're going to do is find the destination. So we'll walk up the chain of presented items until we find a match.

At which point, we'll call prepare for segue in the source. So in the case of the example, the confirmation view controller will receive prepare for segue. Then the destination's unwind action will be ran, so it gets a chance to prepare for the segue. And then we actually trigger the navigation. So in the case of a modal view controller, we'd call dismissModalViewController, and it would go away.

So let's talk a bit about the search order. There's a little bit to it besides just walking up the chain. So when the reset button fires, we're going to start by asking the source view controller if it would like to handle the unwind action. And we have a new method on UIViewController called canPerformUnwindSegueAction. And by default, this does the right thing. So it just looks at the receiver and checks to see if it has implemented the method. So in this case, if it had a method called reset, this would return yes, and we'd declare it as the destination.

If you're doing something special, like if you have a social network app that has three view controllers that all have the same unwind action, and you've presented them in a row, you can use the information that we supply in this method to disambiguate and return the appropriate result. But for the primary case, you don't have to do anything here. So in the case of the confirmation sheet, it doesn't implement reset. So we know that this is not the destination. At this point, we're going to step up to the parent view controller.

That's the navigation controller in this app. And it has a responsibility to search through its presented controllers to find a match for the unwind action. So we're going to click on View Controller for this. And if you're using the built-in UIKit containers like UI Navigation Controller, you don't have to do anything here. It just does the right thing. If you are creating a custom container that uses the view controller containment APIs, you'll want to override this and search your child view controllers until you find a match.

So, Navigation Controller is going to search the controllers that it's presented. It checks the next controller, which doesn't implement reset, so it returns no. We then try the next one, which has a method called reset. So we're going to pick this as the destination. So at this point, we need to actually get an object to perform the navigation.

If you're using the built-in kit provided controllers, this method is already implemented, so you don't have to think about it. If you're creating a custom container, you'll want to override this to return an object that will perform the appropriate navigation. So whatever type of transition is appropriate for your custom container will be taken care of here.

So the Navigation Controller chooses to return an object that we'll call PopToViewControllerAnimated. And at this point, we'll call PrepareForSegue on the SourceViewController so it can fix up any state. We then call the Unwind action on the destination so it can customize. And then we perform the navigation, which causes, in this case, Pop the View Controller to be called.

We'd do a similar search for the done unwind action whenever that happens, except that we'd go one more hop up the chain until we found a match. So, that's the theory. Let's go look in the app and see how it actually happens. Okay, so I've got a project here. Here we go.

So I'm going to go to the reset controller and paste in a bit of code.

With Unwind Actions, there's just two pieces that we care about. We care that their return type is IB Action and that the argument is typed UI Storyboard Segway. We look for these in Xcode to add them to the list. And whenever your Unwind Action fires, you can do whatever you want in there.

You can pull information back from the Segway because you have access to the source or the place that you're unwinding from. And you can also fix up any state on the controller. In the case of reset, I'm going to reset some fields that the user has entered in so they can start over again. So let's add another Unwind Action to the very first controller. This is what's going to happen when the Done Action fires.

And we do a little bit more here. What we do is we access the destination view controller of the source view controller. And that is the confirmation sheet. And when I wrote this app, I made a property on the confirmation sheet that wraps up the account information that the user's entered in. So I'm just going to pull that back and use it in the app.

And I also update UI to show a success view so the user gets a bit of feedback. So we have these unwind actions so we can find places to unwind to at runtime. So let's go back to the Storyboard and add unwind segues that target these actions. I'm going to go back over here.

Go to the Storyboard. And I can create the unwind segue by Control-dragging to the exit icon. And you can see that it's populated that list with the unwind actions that we created earlier. So I'm going to choose Reset for this one. Then I'm going to do the same for the Done unwind action.

So now, when I hit Build and Run, we can take a look and see what we get. So I've got this app here and when I hit add an account, I can step through the sheet here and fill out the information. And when I hit reset, We slide back to that first controller. So it walked up the chain of controllers until it found something that implemented a reset. And then we ran the reset action, and it reset any information that was present. So let's go back and do the same thing for the done action.