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.

Okay, 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 aren't installed up, 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 down 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-- 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. Sticky 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 2010 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 autosaving 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 is being changed, and we also want to notice when a 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 Lion 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. Okay. 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 the red, the eye of Sauron 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, you know, 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 badge still there.

Until I explicitly save or close the window those changes are like unconfirmed, but they are being saved. In fact, I can sort of show you, for instance, I can come here and type, you know, 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, okay, 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, you know, 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 NS Document-based application. We highly recommend that document-based applications use NS Document, if possible. NS Document provides autosave and versions right out of the box, and all you have to do is override this one method in your subclass of NS Document. 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 supporting 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 Auto Save 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. 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.

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 NSFileWrapper. 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, file wrapper--I'm sorry, file packages, let me use the right terminology here. File packages for those of you--I mean, those of--many of you probably know, but file packages are folders that look like single documents to the user.

For instance, text.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. You know, the only file that gets saved here is the txt.rtf. Everything else is just efficiently hardlink copied on or whatever we can do because they're not changing. Now, good news about file wrapper 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 file wrapper and this file wrapper in a lot more applications if you need to. So if you have flexibility with your document formats, please consider file wrappers. Thank you.

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, shutdown, and logout seamless. We want to eliminate the need to save changes, and you saw how we do that with Auto Save. We also want to eliminate the 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. 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 code integer for key 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. 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 I mean, 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 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 applications 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 the heck? 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 dock 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 hit it and we killed it, when the app is brought back to life, it better sports resume so that it can restore the user state exactly as the user left it. The 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, sort of to make this discussion more concrete. Aki, back to demo machine, please. Thank you. Okay. So, first I'm going to launch Activity Monitor.

And I'm going to search for TextEdit 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 ActivityMonitor, 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 TextEdit is running. Now I'm going to go ahead and hide TextEdit.

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 quits. 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.

NS Metadata Query, 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 Documents scope. NSURL 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 NS File version that you can use for this. And finally, I want to talk about NS Ubiquitous Key Value Store. This, if you're familiar with NS User 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, etc.

So with that, let's shift gears and talk a bit about Auto Layout. So Auto Layout 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 Auto Layout 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. Auto Layout 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, bare down to the metal code. NSLayoutConstraint is the one and only class we've added for AutoLayout. 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 addConstraint and add the constraint to an 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 Aqua spacing away from button 2. So this gets you a little farther. You still are writing code, but it's a lot more visual.

Aki Inoue, Ali Ozer 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. Aki Inoue, Ali Ozer 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, you know, it's a much higher level of programming. Aki Inoue, Ali Ozer And with that, here's an example of what you can do. Aki Inoue, Ali Ozer And with that, here's an example of what you can do. 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, etc., you will see that the text is not as clear as it used to be. 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 and 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.

You know, let's say you're working on your great presentation or your next great app or your manifesto or whatever. You know, 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 know, 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 know, 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 item 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 Akua 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 are 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 come with the 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 they're visually they can get distracting. With overlay scrollers you get this much more mute. 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 in 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. 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. You know, it's very transient. It's sort of like a pop-up menu, except you can have any view as its content, not just 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. Full-screen and Aqua changes 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, you know, whenever you want to put something in a table, 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 NS views. 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, NS table row view, which is the main class that makes this happen, and NS table cell view, which you can use if you're--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 independence, 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 2560x1440, but in high DPI, it's effectively 1280x720. So the screen resolutions are actually specified in points once you do this. You can hear more about resolution independence at the Full-screen Aqua Changes talk still tomorrow morning. With that, I'd like to invite Akie 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 Text Finder 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 FindVar for text view in your applications. Sending set uses FindBar with ES switches the TextFinder UI from FindPanel to FindBar. Of course, you can do so using the Xcode.

Underneath the tech system integration, we have a controller class and two protocols. This is 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 Mew 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 NSX-View API duct takes either NSX layout orientation horizontal or NSX layout orientation 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--

Color, pretty neat. This is the Inspector Bar. And next, Text Finder. opened 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. Another improvement is the search wrap around in Kishon is also built in. Let's open the standard search menu and it contains various advanced search options. We have some search patterns built into the system. And let's select email address and it correctly selects email address in your documents.

Now let's open a new document. And resize so that you can see. And let's change to Japanese input. Kore wa yokogaki desu. It says this is horizontal writing. Let's go to Format Menu and select Vertical. And say, . It says, Vertical Writing. OK, let's go back to the slide.

Other tech system enhancements. The tech system can now quick-click attachments right out of blocks. 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, Akki. Okay, 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 Auto Save 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.

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 NS-array and NS-set. As you can imagine, this class, NS-ordered-set, 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.

DistributeObject now has support for keyed archiving. It used to be only the old-style archiving, so you can use keyed archiving now. KeyValueObservers, 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 are a lot of string handling improvements. The new classes NS Regular Expression and Stata Detector, these were added to iOS 4, and now they're available in Lion as well, and another new class, NS Linguistic Tagger. You can hear about these string handling changes in the Advanced Text Processing talk, which is Thursday afternoon at 3:15.

Last 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 afternoon at 4:30. Now a mini parade of AppKit enhancements. There's Apple Push notifications, which let you badge your dock 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 NS Document 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.

You know, 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, you know, 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.

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 Lion 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.

Okay, 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. You know, 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, you know, 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. You know, 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, you know, 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 the 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 Auto Layout.

In this afternoon, Auto Save and Versions 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 and 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.