Welcome to What's New in Cocoa Touch. I'm glad to see everybody here so bright and early. It was a little early for me too. This is session 100. I'm going to be spending the next roughly an hour or so talking about some of the smaller things that we've added to UIKit, some of the larger features that we're putting into UIKit to support your applications and then some of the other APIs that have gone into other frameworks or talk about some new frameworks that are going to appear on the system. So let's get started.

We've added just a little tiny new control. If you were getting numeric input from your users before, you were probably doing something like throwing up a UI text field and trying to validate that input when the user typed in. You might have used a picker view and the user scrolling through to find a number that they want. This is a new control UI stepper.

It has a minimum and maximum value so you can limit your users to a specific range. It has a step value so you can choose how fast they move up through that range when they're hitting the plus and minus buttons. You can obviously pull the value out. There are some properties here that you can set for things like whether or not the control operates continuously, whether it's auto-repeating.

You don't have to do memory management on this just for the values, really. That's not necessary. And whether or not it wraps. So if you hit the minimum value on the way down, whether it pops back up to the maximum value. This is also sized really well to fit inside the default height for a UI table view cell.

So if you're putting a number of different places where your user's going to get numeric input in one of those tables, this is a great control to use. Here's our old friend, UI Alert View. We've seen some pretty amazing things that people have done in order to get input from UI Alert View.

So we thought we'd make this a little bit easier for you. In iOS 5.0, this is now UI alert view style default. It's what you get when you first create a UI alert view and you send the init with title, cancel buttons, message, that whole long selector. We now also have UI alert view style plain text input.

So if you have to ask your user something, this is a great way to do it. We've also given you UI Alert View style secure text input. So if you'd like to get a password-- This is how to do it. If you'd like to get login and password information, we have a style for that too.

So UIAlertViewStyle, login and password input, and we even go ahead and put a little placeholder text up there to guide your user. This is all defined in the UIAlertViewHeader, UIAlertViewStyles, there are four of them, the default, the secure text input, plain text input, and login and password input. And you'll initialize a UIAlertView and then send it the setAlertViewStyle message, pick one of these, and when you go and present it, it will come up with that style.

The text fielded index method is how you get at the text field that the user was typing into or the text fields that the user was typing into. That's a--there's only one index, index zero for the first two, secure text input and plain text input styles, and then there's a zero and one for login and password input. So UIAlertView has some easier ways perhaps to get user input.

In a previous version of iOS, we introduced the ability to plug your device into a screen, right, and get TV out and see that UI screen instance as an external screen to the device. But if you're displaying a bunch of content, right, you've got this great image that you want to display or you've got a movie maybe that you're playing out on that external screen, some televisions do this thing to you called over scanning and it kind of crops out bits of the content, right. And there are a couple of different ways you can handle this. You can try to scale your content, you can kind of guess at what's happening in the screen, but it would be a lot easier if we actually helped you guys out.

So, we're doing that. A quick refresher on UI screen though. UI screen has two really important properties. There's the bounds of the UI screen and there's the interface. So, for the main screen, the bounds in the application frame are usually the same, although we do inset it a little bit for things like the status bar and stuff like that. We expect that you'll keep your content in the application frame. That's actually the concept to keep in mind here. So, we're going to go ahead and inset that under certain circumstances when you plug in.

So, for a 720p screen when you plug in, if it's not doing any over scanning, The bounds and the application frame are the same across all possible options. So you can either scale the content, you'll be able to inset the bounds or inset the app frame when a screen is over scanning. For a 720p over scanning screen, If you tell us to scale, we'll go ahead and just throw the content up, the bounds in the application frame will be the same.

If you tell us to inset the bounds of the screen, we're going to take that 0, 0, 1280 by 720 bounds for the screen and we'll inset it about 5, between 5 and 10%, right? And if you've done a lot of media work with movies and things like that on televisions, this is the content safe area.

Right, so when you overscan, if it's going to stretch that content, it's going to stretch it off the screen. The content safe area is what's going to stay on the screen. Right, you also have the option to inset the app frame. So the bounds will stay the same. That may wind up going outside the television itself as the screen overscans, but the application frame is inset to the content safe area.

And that's the overscan compensation enum here. So UI overscan compensation scale, I'm not going to read the prefix there. Inset bounds or inset application frame. So this is your opportunity to make sure that, for instance, if you have your own closed captioning track or your own content that you're playing over a movie or over content on an external screen, you can keep that in the application frame and in the content safe area.

So there's a read write property, I'm sorry, read only property on, it's a read write property on UI screen. You tell us what to do when we discover that the screen is overscanning. Okay. Here we have a delightful iBook style app that only reads Lorem Ipsum text. But that slider at the bottom now can--you can hook that up to control the screen brightness of the device.

So you may find also that once you've messed around with the screen brightness and the user's taken it all the way down as far as they can go without the backlight going off, that it's still not quite dark enough for what you want to do. And we've also put in a software dimming system for that. So there are two properties now also on UIScreen. The brightness is a CG float. It runs from 0 to 1. You can run it down all the way if you want.

And the want software dimming flag here is how we're going to go further than what the hardware backlight allows. So if you want to be able to get a dimmer effect, kind of like the one that we do in iBooks, you can set this flag, and we'll go ahead and rescale. The brightness still goes from 0 to 1, but when you get to a certain point and the backlight can't go any further, UIKit will composite a view over your content and start tweaking the alpha on that to make it look dimmer than the hardware will allow.

And we'll scale. We'll scale this depending on what the hardware is doing. So if the hardware can actually go all the way down, you may not get this view. But the thing to bear in mind with want software dimming is there's a very real performance hit for this.

If you have lots of dynamic content or if you have lots of animations, if you turn this on, we're compositing a view over your content, so you may take a frame rate hit. So use this cautiously. If you use this for lots of static input or static content behind things.

So this is a UI scroll view and there are a number of places where we go ahead and tell you where the scroll view is going to land but if the user just goes ahead and scrolls, well, it kind of landed wherever we decided it was going to land which may not necessarily be quite where you wanted it.

So you probably wanted it to land exactly on a specific location, right? Your designer tells you to make sure that you've only got five UI table view cells up there, something like that. There is a new UI scroll view delegate method Here it is. Scroll view will end dragging with velocity and target content offset. This is where you can decide exactly where the UI scroll view is going to land when the user flicks it.

So when the user's finger comes up, your delegate gets sent this message. The velocity is in points per second and the target content offset comes in where we tell you this is where we're going to put it and you can fill that in out pointer in with a new CG point where you want it to land. So you'll be able to adjust the resting point of a UI scroll view.

This does change the physics of a scroll view, right? So one of the things that's pretty consistent across iOS and all the applications is if the user really flicks one of these scroll views, it comes to rest at sort of a known pace, right? So if you're going to use this, use it to come within a couple of pixels of a resting destination. If you bring the scroll view to a screeching halt, it's going to feel funny in your application, right? So you saw Scott demo the text system define mechanism that's now system wide.

And the short answer with this is if you can select it and we can find a definition, we'll display it in the UI. So this is built into the text system. So if you're using UI text field, if you're using UI text view, if you're using a web view to display content, your users will be able to select a word and get a definition anywhere in the system. There are a number of applications we've seen that actually aren't using the text system directly or probably striking your glyphs directly with core text and things like that.

If you're doing that and you want to be able to display definitions in your own applications, we have the UI reference library view controller. It looks like this on the phone and this on the iPad. It comes up in a popover. And the API for that is pretty straightforward. It looks like this.

You can init one of these with a term and the view controller that you get back is suitable for pushing on to a navigation controller. It's suitable for putting-- displaying modally. It's also got a dictionary has definition for term. And this is your opportunity to decide whether or not you're going to display UI for a particular definition.

Or if we can find a definition or if we can't, you can switch on this to figure out whether or not you're going to enable a button or show the UI itself. So here's a split view controller. Speaking of crazy things that we've seen. If you rotated a split view controller, you got this. What you might have wanted was this.

And so we're doing that in iOS 5 also. There's a UI split view controller delegate method. A split view controller should hide view controller in orientation. When you rotate the device, if you implement this delegate method, you'll get a ping back that tells you which split view controller is involved, whether it should hide a particular view controller, and in what orientation it should hide the view controller.

In 5.0, we're only calling this on that left-hand view controller right now. But there may be a time in the future when we wind up calling this on every view controller in the split view controller. But now you can keep that split view controller with both view controllers visible in portrait orientation.

There are a lot of places in your UI where you might want to be able to use an entire UI table view cell as a cut, copy, paste target. So rather than go through and try to work with the responder chain and use a text field or maybe a view over the entire table view cell, we're adding API to be able to use the entire cell as a menu target. So you'll be able to display menus for specific table view cells.

There are three new table view delegate methods. Table view should show menu for row at index path is where you decide whether or not the menu will appear. Table view can perform action for row at index path is basically the same thing as the corresponding UI responder method, right? This is your opportunity to decide whether or not a particular action should be performed for that table view cell. So if you can't cut or copy, you can return no from this.

And finally, Table view perform action for row at index is where you're told the table view and what action is being performed and which cell it's being performed on. So this is where you're actually going to go ahead and call, cut, copy, or paste on the particular table view cell. So these are all basically delegate methods that mirror the responder behavior but for UI table view cells.

We're also allowing you now to reuse cells with nibs, right? So if you have a table view cell that you've painstakingly laid out in Interface Builder and you'd like to be able to use that as with the table view itself, you can register that nib for the cell reuse identifier. So remember when the delegate gets called and says, okay, I don't have a table view cell for this, go create one.

Rather than getting the call to go create one, we will go ahead and automatically start creating table view cells out of that UI nib instance that you handed us. So this cuts back a little bit on some of the code that you have to write in order to use table view cells. Amen.

There is a UI Table View Changes Tips and Tricks talk that's Thursday in Nob Hill at 2 o'clock where we'll be talking about a number of other things like the ability to use static content in a table view. So if you had just a list of items to put into a table view, we've now written a bunch of code so that you don't have to.

You can just give us the list and we'll generate the table view data source for that. And a number of other nifty APIs like being able to move entire sections and cells at index paths and stuff like that. So if you're doing a lot of table view work, this will be a great talk to go to.

So you saw the new keyboard. This is the usual keyboard on the iPad, right? When it comes up, it's always pinned to the bottom. It always has the same height. But in iOS 5, we've introduced this new split keyboard. And there are two really important things about the split keyboard. The first is the user can move it anywhere. And the second is you probably want to avoid the keyboard now that it can show up in more places.

So we have two new notifications for this. They're in UI Window along with the old ones. There we go. UI keyboard will change frame notification and did change frame notification. These are now sent on any keyboard change. So this includes pairing your device with a Bluetooth keyboard. This includes when the user undocks the keyboard and splits it.

It also includes when the user is moving the keyboard around. So you can find out where the split keyboard is and actually change your content underneath it in order to avoid it, right? These are in screen coordinates by the way, so you'll probably have to do a transform to figure out what direction you need to move your content.

And we now have support in UIKit for animated images. This is pretty straightforward. It matches some other naming conventions we have. But animated image named and duration. So if you give us a name, like, say, image, we start looking for an image named image zero in all our supported formats, or image one in all our supported formats. And then we'll run up the numbers until we stop finding images.

We'll take all of those images together and put them into a single UI image that animates over a given duration. So it's just going to keep cycling that animation all the way through. You can also, if you've been generating your own images, you can use animated image with images, provide us an NSArray of images, and we'll go ahead and animate those also. So you may have generated a bunch of UI images for your UI, or the user's done something, you've collected all of those images, you're going to animate them over time. You can do that.

There are two read-only properties, NSArray images, and the duration, which is in this time interval. So if you do create one of these, you don't get to sort of just wedge an image there in the middle and have it show up in the animation. You'll have to recreate the animated image to get that to work.

We've also added some new API to do stretching and tiling of images. So we had some other stuff. You can also use content center and things like that. But we tried to make this as simple as possible with one API. So resizable image with cap insets allows you to specify a UI edge inset.

And then we'll make some decisions based on that as to how we will stretch or tile the images that you give us. Chris Parker All right. So you start with an existing image. You send that image, resizable image with cap insets. If you were to specify for this image a cap inset of 0101, remember that's top left, bottom right, we would take that middle section and stretch that as the image gets wider, right? So this basically allows you to create a three-part stretchable image.

If you were to do it for a larger image, right, that inset now specifies a bigger block. It's not a one pixel slice, it's a four pixel slice. If you were to resize this image now, we would take that middle section and tile it across rather than stretch it.

So if you've got images that your designers handed you and you're going to stretch all this stuff out, this is an easy way to do it. And we also allow you to create nine part images doing this as well. So if you're to specify insets of 1111, we'll take that.

The corners will be a static size. As you resize this image horizontally, the middle sections will get tiled. And if you resize it vertically, those middle sections across the center horizontally will get tiled. So constructing images that do this well is probably a good task for somebody who's really good at Photoshop. But this makes it really easy to be able to do those kinds of tilings for you.

And we also can do this with animated images as well. So if you have a series of these, you can do animated resizable image named, cap insets, duration and then as you resize it, we're going ahead and animating all of those images behind the scenes. Most of the places where you see UIKit API that takes a UI image, you can pass it one of these animated images as well, right? So that will work also.

Here is some boilerplate code. How many of you have written in code like this? Right? Oh, I hit a button and then I have to go find out what navigation controller I was in and then I will create a new UI view controller based on that and then I will push that UI view controller on to the navigation controller and there's probably thousands of instances of this in your own code right off the bat.

It would be great if you could go through and draw your application out and draw the workflow of your application out without having to write a bunch of that code. And the DevTools guys probably demoed this yesterday. I wasn't able to go to it unfortunately. They've developed a thing called storyboarding, right, where you lay out your application and the workflow of your application in Xcode and they'll drive the events from within the storyboard. In this case, we've got a navigation controller that's the root view controller. It has a table view, right, one of those static content table views that you can learn about in the UI table view talk.

And that next icon there is a segue. It's a transition from one view controller to another, right? So when you're participating in a storyboard, the storyboard is kind of a framework that drives the events of your application. You can find out what's happening in your storyboards because we've given you API for that.

There's a storyboard accessor that's a read-only accessor that tells you what storyboard is associated with your view controller, right? So when you fire up your storyboard-based app and you want to know what's going on in the storyboard, this is how you find out which storyboard you're associated with.

There are also two methods on UI view controller itself. Every segue in a storyboard has a segue identifier. It's an NSString. So if you want to drive one of these transitions yourself, you can do that. Perform segue with identifier sender. It's sort of a target action type thing. And then if a segue occurs, your view controller will get notified of it on this prepare for segue sender method. And this gives you the full UI storyboard segue object.

It's going to tell you all about the context of what's happening, right? Is it a UI navigation controller push? Is it a modal presentation? All of those things. So storyboards give you a really powerful way to be able to sketch out your application, but they don't tie you into it completely.

So you can hit a certain point in the workflow and decide that you're going to take over in code from there. And then you can always get back to the storyboard workflow. Maybe by using perform segue with identifier, right? So there's a good flexible point where you can use storyboards, but you're not completely committed to storyboards.

If the storyboard doesn't do something for you, you can get in and participate in that by writing code yourself. There is a storyboarding applica--talk introducing interface builder storyboarding here Wednesday at 11:30. It's a really, really slick technology and it will cut back on a bunch of that boilerplate code that you guys have been writing. So if you're interested, please go to that too.

Here's UISlider. It's not the sexiest UI class we have. But we get a lot of requests to be able to customize things. And customizing UIKit has not necessarily been some of the easiest code anyone's written. So what we've done in 5.0 is pushed a bunch of customization API all the way through all of our controls. So at the most basic, we've gone through and used tint color on almost every single control you can access in UIKit.

So that's in Slider's case, that's the tint color for both the minimum and maximum track and the thumb. For switches, the section that has on in it, right, you can tint that. So you'll be able to push tint color all the way through including things like your navigation bars and your toolbars and the toolbar items and all of the back buttons and things like that that are in your interface.

So if your designers come to you and says, hey, I've got this great color scheme, I want you to push it all the way through your application, you can now do that in UIKit. But we've gone further and we've also allowed you to put images in all of this stuff.

So you can specify your own track image, your own thumb image, you can specify your own images for UI navigation bars, you can specify your own images for toolbars, you can specify your own images for almost everything in UIKit itself. So there's a lot of new customization API on the individual instances. So hopefully that will cut back on some of the methods whistling we've been seeing in UIKit.

So the way you would configure an individual UI slider is by just sending it a message, right? UI slider, a slider, set minimum tracked in color, UI color, red color and that changes it to red. But if you wanted to do this for every single UI slider in your application, You could write a bunch of boilerplate code and wrap that up and make sure that you always call your code in order to get a UI slider. It's kind of a drag. We've introduced an idea of an appearance proxy into UIKit. So what you would do is send the appearance message to the class.

OK, you're a little early, but that's OK. You'd send the appearance message to the class, and then you'd send the same API that you would use to configure a single instance to the appearance proxy. Now every single UI slider you create comes out with that red tint color. The appearance proxy is new for iOS 5.0.

And it means that if you know how to configure one instance, you know how to configure all of them. Really simple. This is one of two methods in the entire UIAppearance.h header in the Appearance Proxy protocol. The other one you'll have to come to our appearance talk later.

We've gone through and also tagged all of the selectors that participate in this system with the UIAppearanceSelector tag. So this is your indication that you'll be able to send the Appearance Proxy for that particular class that setter and get that to layout. We're talking about all of this stuff tomorrow here in the Presidio at 2 o'clock right after lunch.

So if you're here for the--for Waves talk, just stay put, all right. You'll be able to learn more about all the stuff that we've put into the individual customizations as well as how to really fine tune the customization of your application. So. Here's iBooks. You guys have probably seen iBooks, right? This is the Objective-C programming language guide, the sending messages to nil section, a little bit of language esoterica. That's actually not the important part here. The important part is the page curl.

We've actually introduced UI page view controller to UIKit. And it does this. It turns out if you've ever written this-- this is a lot of math, right? So page view controller is a new class in UIKit and I have a demo of this that I'd like to show you.

So let's cut over here to the demo system. There we go. Andromeda Galaxy is alive and well. The really slick thing about this demo actually is you guys all have it if you're installing the beta because the demo is pretty much a new project and you ask for a page based application. And we'll call this pager demo. We'll make it universal. There's the use storyboard check mark. We're not going to use that today. But we'll throw this up on the desktop. And here it is. And you know what? I'm just going to run this on the iPad simulator.

In portrait mode, January, a good month, but we're not in that. If I just run over to the side of the simulator here and just click, you see that page effect. If I just start mousing and dragging here-- And you'll notice too, this is actually putting, I don't know if you can see that at the top, let me grab a different part here. If I start really bending it, you'll see that May here shows up on the back of this page, right? You can actually see the back of the page put through on portrait mode.

You can see that other part. If I rotate, I can kick it into a two up mode. And so we've got May and June here. And instead of seeing the back of the previous page, what you'll see is the next view controller in sequence. There's July, right? Automatically.

We're not in two up mode on the phone, but does this. So there's some interesting things about the pager demo. And again, this is the template that you get for creating a page based application in Xcode. We've organized this in a fairly specific way. There's both a delegate and a data source. And the data source is just a thing that feeds view controllers into the page view controller. So it works very similar to the UI table view code. So let's kick back to the slides.

as if by magic. You initialize one of these if you haven't created it in the Xcode template, you can initialize one with--in it with transition style navigation orientation options. The transition style right now, there's one. It's this page view controller with the pagey bendy pages. The navigation orientation is what direction is the tear happening? Is it happening like a book? Is it happening like a calendar? Right? So you can go up and down as well as left and right and the options, there's a dictionary there that you can pass in.

This is all in the UI table view--page view controller dot h header. It has a delegate and a data source. There are two very different things that these do. The delegate tells you things like, did the page view controller finish animating, what the previous view controllers were on the screen and whether or not a transition completed.

So this is whether or not they actually made it all the way through the animation or whether it flipped back to the old orientations. And on rotation, you get a page view controller spine location for interface orientation. And this is a very descriptive API, so I couldn't fit everything on the slide here.

But spine location is where does that split happen, right? Is the binding, you can think of it as the binding of a book, right? Is the binding at the bottom, in the middle or at the top horizontally or at the right, middle or left edge vertically? So you can, this is how when you rotate, you can switch into the one up mode or you can go two up, even vertically and things like that. The data source is even simpler. Two methods. We need you to tell us the view controller before a view controller, depending on which way they're going, and the view controller after a view controller.

So if you're in one up mode, you'd get one call for this probably for, you know, view controller after the one that's on the screen. If you're in two up mode, you'll get two calls. One for the one that's after the rightmost one and then the one that's after that. So that we can take those two, lay them out and do the effect when you open the book or turn that page to be able to put them up.

We're also talking a lot about view controllers. The page view controller is very slick, but, um, When we first came out with the iPhone SDK, all we had was the phone. And when you were creating a UI view controller, we really encourage you to write your view controllers to take over the entire screen and to manage screenfuls of information.

Well, that was great, except that then we came out with this device with a bigger screen, and the tendency was to want to manage sections of the screen with individual UI view controllers. So this view hierarchy has two views. They're controlled by view controllers. The one on the index zero for the split view controller is a navigation controller. It has in it a table view controller. The one on the left at index one is a custom view controller. We wrote it. It shows need information.

That hierarchy looks a little bit like this. And in sort of all of our previous UIKit development, the containers were mostly written by us, right? So you had a split view controller that managed two sections of the screen. You had a navigation controller that would manage entire sections of the screen and it kept track of its children and it sent the rotation callbacks and things like that to the child view controllers.

You guys mostly filled in the leaf nodes. Things like your custom view controllers, the table view controller that you subclass in order to put your own data into and things like that. In iOS 5.0, we are opening up the API so that you can write your own container view classes, view controller classes.

So writing a container is actually pretty straightforward. We've made public the parent-child relationship between view controllers. So there's add child view controller and remove from parent view controller. These are kind of special. You should treat these methods effectively as sort of protected methods on UI view controller. Your subclass will call these directly to be able to add the children in, right? So you might have, you know, some split view replacement that you're writing or something like that and you've got a set view controllers method.

It takes an array of UI view controllers. That method would call these, right, to add the view controllers in. Once you've added a child view controller, we take care of automatically forwarding the rotation callbacks and all of the view will appear and view did appear and all of those callbacks to your children for you.

So you can also get the array of child view controllers. This is just an accessor so you can manage that array. And there's also API now for doing better transitions between view controllers, right? So transition from view controller to view controller, duration, options, animations, completion. You put your animations in there, completion block. This is the new transition API. It's very easy to use. Well, it's a good thing we have code completion, There is an implementing UI view controller container containment talk today at 1015. It's in the marina right next door.

So if you're writing view controller containers or if you think you need to write view controller containers, this is the talk to go to. We're going to go into incredible detail on everything that you can do to really manage entire trees of view controllers that are going to manage sections of the screen.

The other thing they'll do is show you a lot more about UI page view controller as well. So there are a lot of things that you can do with it. It's a very powerful API that you can use to get really great effects in your application. So go next door, 1015, to see that.

Working with documents. You saw the iCloud demos. UI document, if you've used NSDocument on the desktop, UI document is very similar. It uses the same more modern approach that we've been introducing on the desktop. You can initialize one with the URL. You can get back the file URL and you can return a localized name to your users. If you're managing undo yourself in a UI document subclass, you can set your own NSUndo manager. for that. This is a great way just to manage documents within your application. We do a lot of the heavy lifting for you. You'll probably override these four methods.

Open and close with completion handler. We're making a fairly strong statement here about making sure that the user's interaction with your application is never blocked. If you're going off and you're loading something from the network or you're reading a huge document off of disk, if you're doing that on a main thread, you've only got five seconds before the watchdog comes along and says, no more. You're done. So the open and close will happen on a background thread automatically. And when it's done, you'll get a callback on the completion handler.

Load from contents of type error and contents for type are your opportunity to read and write your content. So load from contents of type error is where you're handed an NSData or a file wrapper, and that's your opportunity to create your document. Contents for type error. Is where the system is asking you for your data, either an NSData or an NS file wrapper, so that you can write that out to disk. It also has a number of different ways of working with errors.

On iOS, there are a couple of cases where your user might be able to interact with the device, and then suddenly they can't. They get a phone call, they hit the home button, things like that. Handle error user interaction permitted is where we tell you, hey, something went wrong. Here's the error. The error is localized. It has localized recovery suggestions and things like that.

It's the same NSError that you've worked with from Foundation before. User interaction permitted. If this is yes, that means that there's actually, your app is still running, the user can still tap the screen, and you can get information from them about what they might want to do with the error that happened.

Finished handling error recovered is your opportunity to tell the UI document system, hey, that error you gave me a few minutes ago, yeah, I handled that. It's good. I got this. If you weren't able to recover, then we go back and go into the automatic fallback. That's the fallback behavior for UI document itself. User interaction no longer permitted for error. You may have gotten a handle error user interaction permitted yes earlier.

If the user gets a call, if the user hit the home button while that error was happening, if the user gets, you know, an alert--if an alert pops up, they can't interact with your application anymore. This is your opportunity to squirrel all that data away so that when the user does come back to your application, you can try and recover with them at the same time. So that if they restart your app, you've got something that means that the user hasn't lost their data.

There are a bunch of different states that UI document moves through. State normal, closed, in conflict is interesting. I won't tell you why yet. Saving error and editing disabled. There are a bunch of different states this moves through. The in conflict one is there for iCloud storage. One of the big reasons that we've published UI document is that if you're overriding those four methods and you tell us that this is an iCloud document, we're going to take care of all of the heavy lifting of handling, notifying the cloud storage system that it's there and moving that document around from device to device for your users automatically.

So if you override those four methods and kick this document into cloud storage mode, you're done. Your app now supports iCloud storage. should be a great feature for your users. The Document State Accessor just is your opportunity to go back when you get the UI Document State Change notification and find out what happened.

There is a storing documents in iCloud using iOS 5 talk here Wednesday at 3:15 where we will go over all of this stuff as well as some demos and things like that. So please come by. If you're going to be using iCloud and you have documents that your users are going to want on every single one of their devices, and the short answer is your users probably want your documents on every single one of their devices, you should come see this talk.

The Assets Library now has access for adding group albums. So if you're going to tack on a new photo or create a new photo album for your users, you can do that with the Add Assets Group Album with Name API and the result block. And you can also now add assets to an asset group yourself.

Right, so if you've got a photo app or something like that where you're working with the AL Asset Library, you can now do some of these nifty things. Write modified image data to saved photos album, metadata completion block. This is your opportunity to take an existing AL asset and modify it somehow and put a modified copy of that asset right into the saved photos album.

And set image data metadata completion block. You'll actually be able to replace that data in the album. GameKit. Scott talked a little bit about GameKit on stage yesterday. There's now default leaderboard support in GameKit and for player photos as well so you can find out who's been killing you online.

And turn-based multiplayer games. The essential game technologies for iOS part one is happening right now so if you're here, you're not seeing that talk. But it is being repeated later in the week so you'll be able to go see the part one. You should look on your schedules for that. Part two is in the mission Tuesday at 10:15. If you're doing anything with GameKit, this will be a great session to go to to add turn-based multiplayer games to your application.

Core Data, there's a lot of new stuff in Core Data both on the desktop and on iOS. There's compound index support for entities, incremental stores, store specific migrations and they are doing a lot of work also to support iCloud storage on Core Data databases. So there's a lot of stuff here. If you're a Core Data client, the iOS talk is in the mission Tuesday at 3.15. You can go see that. There's also, if you're programming for the desktop, a desktop talk as well.

Newsstand Kit. New framework in iOS 5 supports newspaper and magazine subscriptions. This is some of the stuff that Scott talked about on stage yesterday also. There is a newsstand library per application. So if you manage magazines or newspaper subscriptions, you get a library for your application and this is the API that's going to allow you to manage the issues in your application as well as downloading new issues, including downloading content that has multiple parts.

So you might have a big HTML document and all of the assets that go along with that HTML document. And also all of the API that you need to touch off your background downloading. So when the user goes to sleep and puts their iPad down and they wake up the next morning and you want to get that content, it's already there. All of the API to do that is in Newsstand Kit. And there's a building newsstand apps talk in the marina at 4.30. So that's a great talk to go to for newsstand options. Twitter integration. There's a Twitter integration talk here Thursday at 2.

The big hitter here is we take care of all the authorization for you. There's a new accounts framework on iOS which works in conjunction with the Twitter framework. So you'll be able to do Twitter integration into your application right off the bat. So you can come see that.

Core Image on iOS. How many of you actually do image effects in your application? If you've been doing that on the desktop, this should be very familiar to you. All of the filters, vectors and colors and things like that are all available to you in iOS now. Also, new detectors.

For instance, the face detection algorithm is built into iOS. You have access to that. The image orientation stuff, so you can find all--what orientation the image might be in if you don't have that information off the camera. Edge detection, all that stuff now you can do right on the device.

Using Core Image on iOS and Mac OS X in the mission Thursday at 2:00 if you're doing any kind of great effects with your application, this is where you want to be. And finally, GLKit is a new framework on iOS 5. If you're doing OpenGL stuff, our examples on the website and one of the templates just takes an OpenGL view and puts it right into the window.

OpenGL, the GL Kit guys have put together an Objective-C framework that really lowers the barrier to using OpenGL in your application. There are two big hitter classes in here, GLKView and GLKViewController. The view controller is really interesting because if you make that the root view controller of your application and you rotate the device, it will go through and put the appropriate OpenGL transform onto that GLK view and rotate it for you automatically. So if you've ever been playing a game and you got the game center sheet that came up upside down because the game was handling its translations on its own, this can help out. So there's a lot of built-in logic that helps OpenGL work with UIKit.

Advances in OpenGL ES for iOS 5 in the mission Wednesday at 2 o'clock. So if you're using OpenGL, please take a look at this talk. There are also a couple of related iOS sessions for UIKit. There's a talk on iOS printing if you're doing printing in your application in Russian Hill Tuesday at 3:15 and there's a polishing your app tips and tricks talk at--in mission Tuesday at 2.

And there's a polishing your app tips and tricks talk at--in mission Tuesday at 2. And there's a polishing your app tips and tricks talk at--in mission Tuesday at 2. And there--there's a lot of really great performance and responsiveness information in that--in that second talk there. So if you're going to be--you're really looking to make sure that your app functions really well and is very responsive, please go to this talk. We'll talk about instruments and everything else you can do to debug your stuff.

More information, Bill Dudney, Applications Frameworks Evangelist extraordinaire. You've probably seen him running around. He's also doing a graphics and drawing talk this week. So if you're doing any graphics by hand, you should go see that. Documentation of Dev Center and the developer forums. Please come see us. We're here all week. So thank you very much for coming. Enjoy.