Good morning. Good morning. Welcome to What's New in Cocoa. My name is Ali Ozer. I'm the manager of the Cocoa Frameworks team at Apple. So today, we're going to talk about the changes in AppKit and Foundation since Snow Leopard. And there's a ton of changes. And we're going to provide pointers to other talks. And there's a lot of other talks to be pointed at.

Now, one important point. This is not What's New in Cocoa Touch. What's New in Cocoa Touch was at 9:00 AM this morning. So if you're here a little late, sorry about that. I guess you should not have had that one last drink last night. But you can enjoy this talk. And What's New in Cocoa Touch is repeated Thursday afternoon at 4:30, I believe.

OK, so here are the topics we're going to cover today. Some of them you saw yesterday, and many others which you have not seen yesterday. And with that, let's get started. Oh, and by the way, one note. Everything we're talking about, pretty much everything we're talking about today is in Lion. It's new in Lion. And there are very few things that actually are in Snowlip, and I will point those out. But these are all new material.

OK, so autosave and versions. So what's the problem we're trying to solve here with autosave and versions? Well, one problem is that users have to explicitly save documents. You create a new document, you have to at some point bring out the save panel and put it somewhere in your file system. In addition, you have to continue to save regularly. That Command-S tick that some of us have and some people don't have, we look over their shoulders, we get worried because they haven't saved all day. So you need to save regularly so that you don't lose your changes. In addition, sometimes you're forced to save at inopportune times. You just want to shut down your machine, you have to go ahead and save all these untitled documents or documents with changes. The system doesn't install and it wants you to restart and so on. So these are all things where the system is forcing you to save and you maybe don't want to. So the solution, as you heard about yesterday, is to eliminate the need to save explicitly. We will save documents automatically and always. And that's in quotes and I'll explain that later. and we're also going to save in place. Now, note that this is something that we've done in a number of other apps. Stickies does it. Mail does it with Compose Windows. Apps like Aperture do it. In addition, many apps on iOS actually save automatically. You don't ever hit save in many of those apps. However, the situation on Mac OS X is a little more complex because users have a lot of control, and they're used to it. Think about the case where the user has a 2010 budget file, and they want to create the 2011 budget file.

Most users would just go ahead-- not most users, but some users would go ahead and make changes to their 2010 budget file and do a save as at the end and save the 2011 budget file. But with an oil saving model, as you're making changes to your 2010 budget file, you'll be overriding your 2010 budget file. And unless your intent was to cook the books, that's not what you want to be doing. So that's something that we need to worry about.

We want to make it easier to avoid unintentional changes. We want to make it clear when a document's being changed. And we also want to notice when the document should perhaps not be changed. In addition, if the user makes an unintentional change, they should be able to get back to their original document. They should be able to revert changes, even if it is a few days later. And let me show you a demo on how we address some of these issues.

So here we have our line desktop. And here I have my 2010 budget file. Now note that I want to edit this 2010 budget file. And I want to create the 2011 budget. So I'm going to go ahead here and start typing. Note that the moment I type, we get this alert that tells me that this document is locked because I haven't made any changes to it recently. And it's telling me whether I should unlock, meaning I should go change it, or make a copy. Now in this case, I want to create a 2011 budget file. So I go ahead and say duplicate. So this is one way in which we protect you against unintentional edits. Now, note that the change was reverted in the original file, but it was carried over to the second file. Now, I can go ahead then and save this document.

instance, as let's say 2011 budget. So now one other thing I want to show you, let's say we're editing this file and I go ahead and make a change. Now at this point you get a badge here in the title bar. I hope you can see that. It says edited. Now this edited badge is our new way of telling you that this document has changes. Note that we are no longer using the little black dot in in the corner of your window watching everything you do, telling you you have to save. We're no longer using that. That's still reserved for non-autosave applications. But in this new world, we're just telling you that your document has changes and make you aware of it. In fact, at this point, if I quit TextEdit and if I go back and rerun it, note that the document comes back with the edited batch still there. Until I explicitly save or close the window, those changes are unconfirmed, but they are being saved. In fact, I can show you. For instance, I can come here and make some other update. And if I go to Finder, and if I quick look this document, you'll see that my changes are actually there. They are being saved to the document.

Now, OK, let's say that this-- I didn't do this. And instead, I went to my 2010 budget, and I actually did make a change. And then I said unlock. I wasn't thinking. So now I'm editing the 2010 budget file. And later-- and let's say I close the document, I open it. And later, I notice my mistake.

Well, that's when the versions UI comes in. And with the versions browser, I can actually go ahead and back in time and get back to my document as it existed, even if it is many, many days, in fact, months ago. And here I would choose the right version. I would simply say restore, and the document will come back to life.

If you want this for your applications, it turns out it's fairly easy if you're an NSDocument-based application. And we highly recommend that document-based applications use NSDocument if possible. NSDocument provides autosave inversions right out of the box. And all you have to do is override this one method in your subclass of NSDocument. Auto saves in place, return yes. Now, we don't do this automatically because some applications have sophisticated behaviors that does need to be tested. So once you do this, you know, don't just put the app on the app store. You might want to test a bit. In addition, there's a few other considerations. For instance, you might want to look at sporting asynchronous saving. That will make your saves faster, and it will make them work more seamlessly. So as the user is interacting with the document, they don't notice the saves happening every 30 seconds or every minute.

You really don't want to interrupt the user's workflow. In addition, you can customize versions UI, and you also have a mechanism for identifying discardable changes. These are small changes that can be thrown away without fuss if, for some reason, document can't be saved, for instance. Now, to hear more about these and autosave and versions in general, we have a whole talk this afternoon at 3:15 in Pacific Heights. I encourage you to attend that.

Now, one important part of autosave is file coordination. And file coordination is a new mechanism for locking in notification that's available on iOS and on Mac OS X. File coordination enables serialization of document accesses. This is the classic problem of somebody's reading a file, somebody's writing a file. Let's make sure that's done in a serialized, consistent way so the file isn't messed up. And this is important on Mac OS X even more now because you have mechanisms like iCloud, which can be changing the file out from under the application because the file was changed elsewhere and it just got synced because that device wasn't turned on, for instance. Another thing file coordination helps you with is making sure documents on disk are up to date. Earlier I said documents are saved always. Well, that's not true.

They're not saved after every key press. The power guys wouldn't like us very much if we did that. So what we do is we save documents on demand. For instance, if you drag a document-- if you're typing in "pages" and you grab that document in Finder and drag it into a mail message, you want to make sure what the user sees is what ends up in the mail message. You don't want the previous version to end up in the mail message. And although we do some tricks like we save as soon as "pages" is deactivated, we save as soon as there's a pause, the user can still very quickly drag that document. In fact, they can drag the document without even deactivating the app they're in. in. So the file coordination provides a mechanism for mail to say, I want this file and I want the latest version, and that causes Page to explicitly save at that instant. This is done with two sets of new APIs. There's a file coordinator class, which is what you use to do coordinated accesses to files, and the file presenter protocol, which is what file presenters, things that edit and view files, use. And this is a mechanism for hearing about coordinated accesses. Now, NSDocument implements NSFilePresenter, so you actually don't have to worry about it if you're using NSDocument.

And taking advantage of file coordination, this afternoon at 4:30, we'll go into more depth here. But I just want to give you a taste of this new file coordination mechanism with just a quick example. Let's say you're an app like Mail, and you import user files. And you want to make sure you get the latest version, and you get it in a coordinated fashion. Here's the code you might write. You create a coordinator instance. And then you call this method coordinateReadingItemAtURL options error and by accessor. And this is the method that a reader uses. And the options of zero indicates give me the latest version.

And then this block. This block will be called once the file has been all pre-deed up for you and saved. And during this block, you have exclusive read access to the file. So nobody will be writing that file, and the file has been up to date. So you do whatever you want to do in this block. Read the file. Do it as quickly as possible. And here we read it into a data. And then outside of the block, we process that data as needed and take care of it. So this is a simple, straightforward use of file coordinator that you might consider in your applications.

Now at this point, I want to say something quick about NS File Wrapper. This is actually not a new class in Lion. It's actually been with us since 10.0. But I just want to mention it. It's a good class for managing file wrappers. Sorry, file packages. Let me use the right terminology here. File packages, for those of you-- many of you probably know, but file packages are folders that look like single documents to the user.

For instance, txt.rtfd documents are file packages. If you do a show package contents, you will see that a file package might contain txt.rtf, which is the main text of it. And then the various attachments like graphics, spreadsheets, and movie are all represented as separate files. Well, why do we do this? One, it's a lot better to store files in their natural state, a movie as a movie file, a spreadsheet as a numbers file. And two, this is a very good format for making incremental saves fast. And so file wrappers are great for doing fast, asynchronous autosaves. The only file that gets saved here is the text.rtf.

Everything else is just efficiently hardlink copied on or whatever we can do, because they're not changing. Now good news about FileWrapper is that now it's in foundation. It moved down from AppKit. And it's also available on iOS. In fact, it was available on iOS 4.0. So you can use FileWrapper and this FileWrapper in a lot more applications if you need to. So if you have flexibility with your document formats, please consider a file wrapper.

OK, now let's move on to resume, the state restoration, also known as state restoration, which is another major topic. The goal with resume is to make restart, shut down, and log out seamless. We want to eliminate the need to save changes. And you saw that, how we do that with autosave. We also want to eliminate need to recreate state. If the user shuts down their machine and the next day turns it back on, it should come back exactly as they left it. One of the gold standards here is that if the user, of course, allowed it, and the machine did an install in the middle of the night and it restarted in the morning, the user cannot even tell that the machine rebooted. That's one of the gold standards you should always think about. Are we achieving that? Now we're also using the same technology to make quit preserve state, which is a user option. So when apps are quit and restarted, they can also restore state if the user chooses to do so.

Now, how do we do this? Well, on login, we relaunch applications that were running. I mean, that's one of the main things we do. And this is not opt-in. All applications are relaunched. And apps can opt out of being relaunched, but that's something that very few apps should do, if any. An example might be an installer app that just caused an install. It restarted your machine. Maybe it has no need to come back. So it can dynamically say, I don't need to come back.

We also want to provide mechanisms for apps to save and restore state. It's not just enough to relaunch applications. We want to make sure applications come back exactly as the user left it. Now, this is automatic for some cases. We know how to reopen document windows in S document-based applications.

We know how to bring back windows of single window applications. But there are a number of cases which we can't do. And there are also a lot of custom controls that only you know how to save and restore state. So we provide some APIs for customization here. Now, you can hear a lot of depth about this in the resume and automatic termination talk. That's Thursday morning at 9:00 AM. But again, I just want to give you a taste of what this looks like.

So here's an example of how to save and restore custom state. Let's say you have an UI element with a selected item property, an integer. In your setSelectedItem method, you would go ahead and call this method invalidateRestorableState. This is an NSResponder method. You would call it to indicate that your state changed. This is very fast. You can call it as much as you want whenever your state changes. As a result of calling this, at some point in the future, your object will be called with encodeRestorableState, and you'll be given a coder. And you use keyed archiving to write the changed state into that. And you just write the incremental state.

You don't write your whole state, just whatever changed. In this case, we're using encodeInteger to write our selected item. And later, when needed, when your application is relaunched or the machine is restarted, restoreStateWithCoder is called. And here, you will use the codeIntegerForKey to read back that integer and set that as your selected item. So this is pretty straightforward.

If you're familiar with coding and keyed archiving, and you maybe implement keyed archiving, this looks pretty familiar. So you can just do this. There's actually even an easier way. If your properties are KVC and KVO compliant, you can just implement this class method. Tell us what properties you want us to deal with. We will observe them, we'll persist them, and we'll automatically restore them when needed, and you don't have to write any more code. And you can use these two mechanisms in a mixed fashion. Use this for some properties, use the other for other properties. So it's fairly straightforward. where the bar is pretty low for adopting this feature.

Okay, so with that, let's switch over to our next topic, automatic termination. So what's the problem here? Now, automatic termination, you didn't hear much about yesterday. And so what's the problem we're trying to solve with this, and I'll explain what automatic termination is. Automatic termination is-- the problem is that users need to explicitly quit applications. Some of you are very careful quitters. You will quit your applications as soon as you're done, just so that the machine runs at full maximal efficiency. Or if you're running a game, you know you must quit all your apps. Then there are other users who never quit applications. You can recognize them by the fact that they have 80 items in their dock. They've just been running for a month. And they just never quit them. They just close windows. And that's fine. The problem, of course, is the system doesn't have any leverage into such applications. The system cannot kill the applications that are not being used. Those applications still are using some resources maybe. Maybe they're paged out and they're occupying all this room on disk. So the system has very little leverage to deal with such applications. So this is the problem we're trying to solve here.

Now, so what we're doing here is we're enabling applications to declare that their process can be killed. And more generally, what we're doing is separating the lifetime of applications from the lifetime of processes. An application that looks like it's running, for instance, may no longer have a process under some circumstances.

And applications should only do this if it can be done without the user noticing. Now note that this mechanism of killing processes in the background is on iOS, and it works very well. However, the situation on iOS is a little simpler than Mac OS X. On iOS, you're looking at one application at any given time, and maybe there are some background tasks, like music player running, but most of the applications are out of sight, out of mind. On Mac OS X, even though you're not using, let's say you have 50 applications running, even though you're not using 49 of them, their windows might still be on the screen visible to you. And maybe they're even updating some state in the menu bar or the dock icon and so on. So we have to deal with a few more issues here. So what I mean by application should do this only if it can be done without user noticing is-- an example there is, for instance, app has no visible windows. Because if an app has a visible window and the process is killed and the window goes away, the user will be like, hey, what happened to that window? Similarly, if the app is doing background activity, like checking mail, if you kill the process and the mail icon, the mail doc badge stops updating, hey, I'm not getting any mail. And one other condition for this to be adopted is that apps sports resume. Now, if the app has no windows visible at all and it gets killed, that's maybe a simple case. But if the app has windows and the user hid it and we killed it, when the app is brought back to life, it better sport resume so that it can restore the user state exactly as the user left it. User doesn't want to find themselves back in page one of their 100-page document that they were reading, for instance. So the resume and automatic termination talk Thursday morning will go into a lot more depth here. But I do want to give a quick demo to make this discussion more concrete. Back to demo machine, please. Thank you. OK. So first, I'm going to launch Activity Monitor.

And I'm going to search for text edit, and it's not running. I'm also going to run terminal. After all, we are a developer conference. We're not afraid of it. So with terminal and activity monitor, now I'm going to go ahead and open my 2010 budget file I had before. So you can see the document here, and you can see that text edit is running. I'm going to go ahead and hide the text edit.

OK, so Techset has no visible windows. It's not doing any background activity. I'm going to go type. I'm going to cause a memory pressure on this machine. And here's how you do it. System library, core services, TalAgent. One important point. This is pronounced TalAgent, not Taligent. And you can ask us in the labs what TAL stands for. So I'm going to cause a memory pressure. This is a tool that's available to you. And the moment I did that, note that text had vanished from the activity monitor. The process has been killed. But note that the blue dot is still down here, if you can see it. It still looks like it's running. In fact, if I do Command-Tab, it also looks like it's running. And if I were to select it, it does come back to life as if it had never been quit. So this is one aspect of automatic termination. Now another aspect of automatic termination is if I close the last window in an application, You can see it's still running, and it's still in the menu bar up here. But if I switch apps, the app quits. You can see that the app quit. This is a new sort of UI paradigm. You close the last window in an app and you leave it, the app quits, and this is something that your apps opt into. However, note that although it looks like the app quit, it is actually still running. If I were to go click back on it, it comes back to life and we just use the same process. So that's sort of equivalent to getting a much faster relaunch time.

OK, so now I want to talk a bit about iCloud Sport. You heard about iCloud yesterday. Two important things about iCloud are there are two categories of things you can save in the cloud, documents and configuration data. And documents are big documents. You saw an example of what I worked yesterday. And configuration data is stuff like high scores, what page are you in a book, and so on. So much smaller amounts of data, not images, et cetera.

So we have two talks. One talk in this room right after this one, iCloud Storage Overview, that will give you an overview. And later, the Auto Save and Versions talk will also go into a good amount of depth about iCloud and show you how to make an application iCloud aware. But let me just show you some of the APIs we have. We've added APIs in this file manager. Set ubiquitous item at URL. This is the API with which you'd make a file move into the cloud. When a file is made ubiquitous, it's in the cloud.

File Manager also has a bunch more APIs, such as explicitly causing a download of a file in the cloud or explicitly evicting from the local machine. That's not equivalent to removing the file. That's just equivalent to getting rid of that local copy of that file. So these are ways your application might explicitly control that local storage. NSMetadataQuery, which you might know is the class which does spotlight queries on Mac OS X, it has been extended to do searches for documents in the cloud. And you would use this scope.

ubiquitous document scope. And this URL has been extended with a few more attributes. For instance, you can ask whether an item is ubiquitous. You can ask whether it's being downloaded, what percentage downloaded. There are also APIs for uploading. There's also a property that lets you find out whether a document has-- a file has conflicts, meaning changes were found in more than two devices, and the system had to resolve it one way.

And your application can go ahead and do a more sophisticated job merging changes. There are APIs for that, a class called NSFileVersion that you can use for this. And finally, I want to talk about NSU because this key value store, if you're familiar with NSUser default, it's very familiar. This is the class you would use for storing configuration data, so small amounts of data in the cloud. There are definite limits to how much you can store. So this is mostly, again, for small amounts of data, high scores, et cetera.

So with that, let's shift gears and talk a bit about AutoLayout. So AutoLayout is something we wanted to do for a long time. Springs and struts have been great, but they have their limitations. And we've had this vision of doing something great for AutoLayout for a long time. And I'm really glad, I'm really happy to say that we've done something great here. And I hope you like it. AutoLayout is a new view layout system in Cocoa, and it's constraint-based. What do I mean by that? Well, let's say you have two buttons.

And you want to express the layout of these buttons in various ways. For instance, you can say that button one is 12 points to the left of button two. You could say they have the same baseline. You could say button one is at least 80 points wide. You could say button one is standard Aqua spacing right from the edge of its container. You can actually go ahead and say all these things, if you want. And the system will just figure out what the best layout is as various things change, like as the width of the button changes, as the standard Aqua spacing changes, and so on.

So let me just show you how you would do this. And I'm going to show you three ways. The first one is just code, you know, bear down to the metal code. NSLayoutConstraint is the one and only class we've added for auto layout. And to say button1 is 12 points to the left of button2, here's the code you would write. You would create an NSLayoutConstraint instance, and you would effectively say button1's right attribute is equal to button2's left attribute minus 12. Okay? And then you would call this method called add constraint and add the constraint to a appropriate super view, basically any super view of all the views involved. So this is great, but it's really not the kind of code you want to be writing for doing layout. It gets old quick. The second way to do it is, again, to use layout constraint, but this other method, which lets you specify constraints using ASCII art.

So this thing says that button 1, and the brackets represent objects or view elements, button 1 is 12 points to the left of button 2. You can also abbreviate it a bit, and this says it's standard ALCOA spacing away from button 2. So this gets you a little farther. You still are writing code, but it's a lot more visual. And the third way to do this, and this is, of course, the best way, is to use Interface Builder. And if you saw the DevTools kickoff yesterday, you saw Max's demo, here guides become persistent constraints. So those visual guidelines you see in Interface Builder, once you start using constraints, become actual constraints. And they're each independently inspectable objects that you can add, delete, inspect, change, and so on. So it's a lot, it's a much higher level of programming. And with that, here's an example of what the standard Cocoa Alert Panel looks like with constraints. And I think you saw this yesterday, but when you run it in English, this is the way it looks.

You can run it in German. It'll get wider. And if you run it in a right to left language like Arabic, it actually correctly relays out the elements in the window, assuming you specify the constraints appropriately. And you get the correct Arabic layout. There is a whole talk about Cocoa layout. It's right after this in Marina. I really strongly encourage you to attend it. It's great stuff. So with that, let's move to Aqua.

And here we're just going to briefly touch upon a few topics. Just Aqua itself, full screen, scrolling, multi-image dragging, a new object that has popover, some exciting changes in table view, and resolution independence. So first, Aqua. Just briefly here, you might have noticed that Aqua has changed. It's, of course, changing all along, but the changes in Lion maybe are a little more obvious. Aqua is now-- the controls are subtler. They're maybe more muted, a little more transparent. Here's what Snow Leopard looked like. And here's what Lion looks like. Again, Snow Leopard, Lion. It's a bit less lickable. Maybe that's not a bad thing. And in addition, we now have engraved text on controls. If you look closely at title bars, toolbar items, sidebar items, buttons, et cetera, you will see that the text actually has this engraving effect that you can get. It's fairly automatic in some cases.

And in inactive windows, we now do a much better and much more consistent treatment of enabled controls in active windows. For instance, in this case here, you can tell which controls are still enabled and which controls are disabled. And it gives you a much more subdued, muted look, which doesn't distract you away from your active windows. Now you can hear about these and other Aqua Changes at the full screen Aqua Changes talk, which is tomorrow morning at 10.15.

Full screen, Craig demonstrated full screen yesterday. And it's a new mode for working. big user feature in Lion. And the goal here is to allow the user to use as much of the screen as possible and take most advantage of that 11 or 13-inch display they might have. And the other goal is to reduce distractions. Let's say you're working on your great presentation or your next great app or your manifesto or whatever. You don't want to be watching that mail icon telling you got eight new messages and the clock ticking away and the battery insisting you're at 88% charge. You want to just hide that stuff and concentrate on your content. But you still want access to them, so the access is still as easy as moving your mouse to the top or bottom. In addition, full screen also gives you easy access to other apps. You're not in solitary confinement where you're in this mode, you can't get out. You just have to use mission control or just simply swipe left and right and get out into other apps. So it's both distraction-free but also very easy to get back to other things. To enable full screen, it's not enabled by default for your applications. To enable it, you specify which applications-- I'm sorry, which windows in your application you would like to go to full screen. You simply call this method on this window to specify which windows can go into full screen. Or better yet, you can use Interface Builder, and in the window inspector, just change the full screen mode of your window to primary window or auxiliary window as appropriate. After you do this, you would also go ahead and add a menu them to your app, enter full screen.

And you can also think about customizing the size of the window when in full screen, what the animation looks like going into full screen, and what the layout looks like in full screen. Some apps, like for instance, Preview, has done an exemplary job of how to use full screen. So they had to write some extra code there, but they do a very good job of utilizing full screen. The full screen Aqua Changes talk, which is tomorrow morning, will go into more depth here.

So scrolling changes, you've again heard about some of these yesterday. We now do inverted scrolling and soon we will stop calling it inverted, I think. But it's effectively where you're moving the content rather than the scroll bar. Elastic scrolling where your content bounces off the edges, sort of like rubber banding. Fluid swipes where, you know, that gives you the ability to scroll, scroll, and then have The scrolls convert to swipes if you're at the end of the page. Preview and Safari make use of this.

You might have seen the demo yesterday. And finally, overlay scrollers, which, again, I hope you've seen already. Overlay scrollers are scrollers which appear when needed, and they don't take space away from content. Here is a web page with a scroll with the Aqua snow leopard scrollers. They're beautiful, lickable, but they do take away space, and visually they can get distracting.

With overlay scrollers, you get this much more muted look that doesn't take away much space. They're also somewhat transparent. And of course, when you're not using them, they go away. So this gives you more of your content and less distraction. Now you can go to scrolling, swiping, dragging, now with more animation, which will talk about the various APIs your applications can use to customize or opt into these features.

Multi-image dragging is new APIs to give you more control over dragging multiple items. And you can have customizable look for this dragging and customizable flocking behaviors. You might have seen this in Action and Finder, and let me show you a quick movie. Here are two Finder windows and a TextEdit window. So we're dragging three items from the top window. There we go. You can see that they change depending on the content they're on. In the TextEdit window, you just see the image. And once they're dropped, things just arrange and everything animates into place. You can actually try this in Finder today if you'd like. There are three new classes here. and there's two formalized protocols. These used to be informal protocols. Now they're formalized that help you achieve a lot of these new behaviors and you can customize them in many ways.

The scrolling talk tomorrow, scrolling, swiping, dragging tomorrow afternoon at 3.15 will go into more depth here. And this popover is a pop-up window for transient content. If you used or programmed the iPad, you've undoubtedly seen or you used popovers. So here's what a popover might look like. Here's a regular window. The user hits the Start button. And here a popover comes up. In this case, it's including a date picker. The user chooses the date they want, and the popover just goes away. It's very transient. It's sort of like a popup menu, except you can have any view as its content, not limited to menu items. So it can host any view. And if your application allows it, popovers can also be detached by the user. They can actually grab that and move it aside. Now, there's a talk for popovers as well. Fullscreen and AquaChanges talk tomorrow morning will cover popovers in more depth.

So next topic, view-based table views. As you know, table views and outline views host cells. And whenever you want to put something in a table view, you have to create a cell version. And this is the main reason why we had cell versions of various controls we have. Well, now they can host NSViews. This, of course, gives you a lot more flexibility. You can create complex elements. You don't have to worry about making them into cells. Various interactions such as drag and drop work much more naturally. So this is a great, very good change. And there are two new classes, NSTableRowView, which is the main class that makes this happen, and NSTableCellView, which you can use if appropriate.

Now, TableView has other changes. They're now much more animated. With view-based TableViews, animations are pretty much automatic, but you can even animate the cell-based TableViews if you use a few of the new APIs we provided. TableView sports multi-image dragging out of the box and also allows floating group rows, which allow you to create new style sidebars with the rows that sort of move with the sidebar and stop. There's a talk for TableView, view-based TableView, Thursday morning. And you can hear our resident world champion marathon unicyclist, Corbin Dunn, give you demos and examples of TableView.

Just a quick note about resolution independence and architecture update. Resolution independence, we've extended the model we had, the device-independent quartz model, to screens. What this means is that Screen size and window frames are now in points. If you've used resolution independence before, you probably know that window coordinates were provided as-- or specified as pixels. Well, now they're specified as points.

What this change means is that a lot more applications are now compatible with resolution independence without any changes. And the good news is any changes you might have made for resolution independence still are very applicable and, of course, continue to work. And our goal here remains the same. we still want Cocoa applications to opt in or not opt in. We want them to automatically work with resolution-dependence, of course, and only in cases where things aren't working, we will opt them out.

Another simplifying factor is that display is now configured for 2x resolution, which also simplifies things. You don't have to worry about non-integral values anymore. And you would enable this through Quartz debug today if you want to play with it. In Quartz debug, there's a UI resolution panel. You would check this checkbox, enable high DPI modes. And once you do that, both in system preferences in the display prefs pane and in the displays menu, you start getting these additional resolutions. For instance, here, this is what a 24-inch cinema display would look like. I'm sorry, 27-inch.

It's 2560 by 1440, but in high DPI, it's effectively 1280 by 720. So the screen resolutions are actually specified in points once you do this. You can hear more about resolution independence at the Fullscreen Aqua Changes talk still tomorrow morning. OK, so with that, I'd like to invite Aki Inoue on stage to talk about some of the Cocoa text changes.

Thank you, Ali. Good morning. I'm Aki Inoue from Cocoa Group, or simply the text guy. It's mind-boggling to see so many new features, right? Well, it's the same with the Cocoa Tech System. The Lion Tech System is packed with exciting new features. Let's get started with Text Finder. The Text Finder is a new set of API providing extended text searching capability and UI. In addition to the existing Find panel, it now supports the Find bar you're familiar with, Xcode and Safari.

And it's designed with incremental search in mind from start. The text finder has built-in advanced search options, including pattern matchings from white space to as sophisticated as email address. Clicker. And of course, all of these new functionalities are covered by the tech system out of the box. In addition to that, we generalized the TextFinder API so that works not only with NSX View, but also with any client adopting a protocol from this system.

As I mentioned, all the functionality of the Text Finder is supported by the text system. For example, it's easy. to enable find bar for text view in your applications. Sending set uses find bar with ES switches the text finder UI from find panel to find bar. Of course, you can do so using the Xcode.

Underneath the tech system integration, we have a controller class and two protocols. This text finder, the controller class orchestrates all the text searching capabilities. And Inspector Bar. Inspector Bar is a new UI element, giving direct access to pages like text formatting options right in your document window. Many of these options used to be only available through auxiliary windows, such as FontPano. It's integrated into the Window Title Bar so that it gives you applications more modern look and makes them full screen savvy. There are many new improvements provided. font menus, popovers for color settings, context menu for text tabs, so on and so forth. And it replaces all the existing functionalities provided by the text rule accessory view.

You can enable the Inspector Bar using setUsersInspectorBar. This is a new NS6 Vue API. And enabling Inspector Bar automatically disables the existing Lula text accessory view. Again, You can use the Xcode to change the setting too. Vertical text. Thank you. The Cocoa tech system now supports one of the most advanced typographic features right out of the box. It supports both displaying and writing.

For Lion, we are focusing to East Asian text layout, including Chinese, Japanese, and Korean. It's top to bottom and right to left, meaning the text flows from top to bottom and the lines from-- right to left. Note that the lines are rotated 90 degrees, but the characters for Shizuke languages are still displayed upright.

We designed these functionalities based on the model view controller design pattern, just like the rest of the tech system, so that it gives us an open-ended architecture, flexible enough for future improvements and customizability for your applications. For example, it's very easy to have multi-layout orientation documents in your applications. You can have a text container, a vertical text container, followed by a horizontal one in a single layout manager.

Changing the layout orientation is straightforward. Set layout orientation. New NSXView API that takes either NSXLayoutOrientation horizontal or NSXLayoutOrientation vertical. The users are allowed to change this setting using the standard TextView context menu too. Not bad. What if I find this property can affect some other NSX view properties, such as bounce rotation or resize direction settings? And also, if appropriate, it might affect the enclosing scroll view settings, too.

Now then, let's take a look at those new features in action. The machine, please. Thank you. OK, let's open the text edit document. This is a new text edit with brand new look. You can change-- From families, from size. Color, pretty neat. This is the Inspector Bar. And next, Text Finder. open the Inspector bar using the standard find menu item.

As I mentioned before, the incremental search is right built into the system. And also, the find indication is also integrated into the NS Text Finder protocol. Other improvement is the search wrap around indication is also built in. Let's open the standard search menu, and it contains various advanced search options. We have some search pattern built into the system. And let's select email address. And it correctly selects email address in your documents. Now let's open new document. And resize so that you can see. And let's change to Japanese input. KORE WA YOKO GAKI DESU. It says this is horizontal writing. Let's go to Format Menu and select Vertical. And,. It says, Vertical Writing. OK, let's go back to the slide.

Other text system enhancements. The text system can now quick look attachments right out of the box. And can display color emoji glyphs. And we enhanced the dictionary content display. and many, many more. So for the complete list of the Cocoa Tech system enhancements, please refer to the active release notes. And now let's get it back to my manager, Ali Ozer. Thank you.

Thank you, Aki. OK, so now we're going to cover a few remaining topics that we couldn't fit elsewhere in the talk. And first one, very important, automatic reference counting. Hopefully you heard about this and saw demos yesterday during the developer tools kickoff. Here, you're letting the compiler do the dirty work of calling retain, release, and auto-release. Note that this works great online. It works great with Cocoa applications in 10.7. And as announced yesterday, this also is available for 10.6 applications. However, under 10.6, the zeroing weak references are not available. That's just one caveat there.

Now, here's one great item with Arc, with automatic reference counting. Arc code can interoperate with manual reference counted code. So you don't have to convert your whole application. You can convert half your application. If your application uses plugins, those plugins don't have to be converted. They will work with your Arc code as is. So that's one great thing about Arc, that the transition can be incremental, if you'd like. One other thing to note about Arc is that we are not changing the treatment of outlets, delegates, targets. Arc is not garbage collection. Arc does not detect and break cycles like garbage collection would. So you still have to be careful when you create your graphs of objects to specify which relationships are strong and which relationships are weak. And once you've done that, you know, Arc takes care of the rest. However, outlets, delegates, targets, they should continue to be weak by default so that programs don't leak. Now there's a talk for this, Introduction to Automatic Reference Counting, this afternoon at 4:30. There's also an advanced talk later in the week. I think it's on Friday.

Core Data has a lot of exciting changes in Lion. And its persistent document now has autosave support out of the box and also has iCloud support out of the box. Core Data now has support for ordered too many relationships. Yeah, it was a-- a lot of you asked for that. And there's also new concurrency APIs and new incremental store APIs. And there's also new modeling tools for Core Data in Xcode 4. We have two talks for Core Data. There's an iOS one this afternoon, and there's a Mac OS Core Data talk Thursday at 11:30.

Now with that, I just want to give a mini parade of some of the remaining features that I didn't have time to talk about. So let's get the parade started. There is a new class, NSJSON serialization. Good. This class lets you read and write JSON files. It's very fast, and the API is modeled after property-less serialization, so it should be pretty familiar. We have this new class. This is the love child of NSRA and NSSet. As you can imagine, this class, NSOrderedSet, is used for ordered relationships and core data, and it's generally usable.

We have a bunch of new keys in NSURL for additional file and volume properties. For instance, you can ask questions like, is this volume ejectable and so on. So a lot more of the APIs for which you have to go to lower, a lot more of the questions for which you have to go to a lower level are now available for you in NSURL. Distribute object now has support for keyed archiving. It used to be only the old style archiving, so you can use keyed archiving now. Key value observers, the remove method now takes a context argument which lets you remove observances a lot more exactly by specifying the context you provided at the time you added it. One person likes it. They got bitten by that.

There's a lot of string handling improvements. The new classes NSRegularExpression and StataDetector, these were added to iOS 4, and now they're available online as well. And another new class, NSLinguisticTagger. You can hear about these string handling changes in the advanced text processing talk, which is Thursday afternoon at 3:15.

And last here, but not least, we have some week-based calendar improvements in NS Calendar. We also have a talk about calendars, performing calendar calculations Wednesday at 4:30. Turns out the world of calendars and handling dates and times is-- Very deep, sophisticated, and just amazing. So I encourage you to attend this talk and find out all about the intricacies of dealing with calendars properly. Tomorrow morning-- tomorrow afternoon at 4:30. Now a mini parade of AppKit enhancements. There's Apple Push notifications, which lets you badge your Doc items of your applications.

We have much more Finder-like Open Save Panels. If you use Open Save Panels in Lion, you notice that they're almost the same as Finder Windows. That's because they share the exact same underlying frameworks now. So they're very similar in behavior. Windows now animate when opening and closing by default, and you can customize these behaviors. There's support for application sandboxing. You heard about sandboxing yesterday.

Classes like NSDocument and Open and Save Panels do a lot of work beneath the covers to make sure that your application can access the documents and files that the user wanted your application to access and nothing more. So there's a lot of work to make sure that those things work seamlessly.

A document-based app needs to be able to open its documents. It needs to be able to open its recent documents. It needs to be able to open all its versions and so on, while not letting bad code touch any other files that the user might have. So there's a lot of changes underneath the covers there.

We have better debugging of exceptions, a new facility for debugging exceptions. If you set this user default, it will cause an alert to be popped up whenever your application raises an exception, showing you the backtrace that raised the exception. So this will allow you to catch exceptions right when they occur. I mean, as you know, in Cocoa, we use exceptions for programming errors, and this will allow you to catch programming errors a lot earlier. So we definitely encourage you to set this default during the development phase of your application and just run with it. It's harmless otherwise. Otherwise.

And again, last but not least, accessibility. One big thing with accessibility, of course, is that all these features that we've been showing you-- versions UI, all the other changes, full screen, et cetera-- these are all accessible. So we have to keep accessibility going and making sure the system remains accessible as all these new features are added. And then we also have a talk, Design Patterns to Simplify Mac Accessibility, Thursday afternoon at 3:15, where we'll talk about some of the line changes. We'll also give you some overview about accessibility. And I would recommend if there's one accessibility talk you go to at WWDC, I recommend it be this one. There's a little bonus too in this talk.

OK, so a summary. There's many user and developer features in 10.7. And some of them are automatic, and some of them are opt-in. Auto save, resume, automatic termination. Of course, iCloud, huge new feature. Full screen, again, many applications can benefit from this. Gestures, many ways to use gestures, swipes and multi image dragging, so on. And auto layout, an amazing new feature for making sure Your layouts are a lot more easily localizable, a lot more flexible, and so on. We encourage you to take a look at these and all the other features and adopt them in your applications. And there's tons more. You can read about these in our release notes, which our release notes will never win a beauty contest, those of you who've read it. But they're chock full of good information. We usually focus on content rather than beauty with them. But we have release notes for AppKit and Foundation. You can search our header files if you'd like to read header files, you can search for 10 under bar 7. We have available macros and also deprecated macros for dear departed APIs that you should not be using anymore. And of course, documentation. A lot of the things we talked about have been documented, and you can get a lot more in-depth information by reading the appropriate documentation.

Bill Dutney is our evangelist. Email him if you have a question or just like to chat. Documentation, here's where you can get to documentation. Of course, developer forums are also available to you. Now I want to give you sort of a recap of related sessions and also point you at the labs. Today, we have three talks. The one right after this, Cocoa AutoLayout. In this afternoon, AutoSave Inversions and Taking Advantage of File Coordination. Tomorrow, we have full-screen Aqua changes in the morning, and then the scrolling talk in the afternoon and the calendar talk also in the afternoon. And on Thursday, we have Resume Automatic Termination, View-Based Table View, What's New in Core Data, Advanced Text Processing, and Accessibility Talks throughout the day. And with that, I thank you.