Good morning. This is session 363. You might be in the wrong place. Take a quick check. It's still okay to get up and leave. I won't be hurt. My name is Chris Parker. I work on the Cocoa frameworks team. And today I'm going to talk to you about what we've been doing in Cocoa for Snow Leopard. And that usually works out to be a whole bunch of API. I don't have Steve's cool thunk sound effect here. I couldn't get that in time for this talk. So just imagine that happening there.

We've been spending a lot of time in the Cocoa frameworks group working on a lot of the things that you heard Bertrand talk about in his talk on Monday. And that's going to include some things like better coverage in the kit and foundation on technologies that you would have had to go to other frameworks for. And all the slides that we talk about that, and we'll have this nifty little Cocoa icon in the upper corner there.

We also are looking at incorporating concurrency directly into the APIs in the Kit and in Foundation. And these will all take advantage of, you know, these multiprocessor machines that we've got with eight cores and the laptops with dual cores and stuff like that. We're also incorporating Sudden Termination directly into Foundation in the App Kit. So this is a technology that's going to allow users to speed up their log-out and shutdown process, as well as quit apps very quickly.

We're also spending a bunch of time looking at file system efficiency. There are a lot of different places you can go to get metadata about files in OS X, and we're looking at consolidating all of those into one API and also make sure that we're taking advantage of any work that anybody else has done in the course of doing file system work. So we're going to do some caching there as well.

And we're, of course, also going to talk about this guy here. If you were here for the previous talk, Blaine's What's New in Objective-C talk, this is the new syntax for declaring and using blocks in API. This is not the scale. It doesn't actually show up this large in your source code.

Let's get started with foundation. We're going to start off with blocks. Blocks are small snippets of code that capture the lexical scope. If you were here for Blaine's talk, you talked about being able to use local variables directly in the block that is in that scope. I'll show you some examples of that. They're inline, so you'll write them right in your code. They're also copyable.

Here's a new method. It's on NSDictionary. It's called Enumerate Keys and Objects Using Block. This is the method definition. There's the selector, and there's the entire declaration of the single parameter that this takes. It's a block. Here's how you know it's a block. This is just the little up caret. You may have seen it in other great operators like Bitwise Exclusive or. Its name is block. It returns nothing. This is a void return.

Block. And each time this block is invoked, there will be three parameters that are passed to this block. One will be the key. The other will be the value for that key, the object for that key, and this by reference Boolean called stop. And this is how you'll be able to stop the enumeration midstream.

So rather than have something where you had to write boilerplate to return a value to tell us when not to stop, you'll just set what stop points to to yes, and that will end that enumeration. So this is a pattern that you'll see throughout all of the enumerations.

enumeration code and iteration code and searching code that we have that are using blocks in foundation. So remember how we used to do enumeration of dictionaries, right? We have 4n in Leopard. It's the fast enumeration protocol. It allows you to iterate through the dictionary, and you'd have to write a 4n loop against your dictionary, and 4n only returns the keys. So you'd have to go through and call object for key for each item and use that.

So in a block, you would just use enumerate keys and objects using block, and there's the entire block, and this means that you get the key and object at the same time. So this is a little bit more expressive. It's a little nicer to use than having to make that additional message send each time.

We've also added some conveniences to other classes that take blocks. This one's on NSString. And this is a very common thing that people want to do. They want to enumerate the lines that are in a particular string. So you'd call components separated by string. You might pass it the backslash and the carriage return there, or the new line. And this winds up creating a whole new array that's populated by copies of those sub-strings in the array that have separated by line. And then you have to iterate over that.

What we do now is use enumerate lines using block. And each time through that block, you'll just get a new NSString that has just that line in it. This avoids the intermediate array. It's better for performance. And the kit's actually going to go ahead and do a much better job of figuring out what all the line endings are, right? Because there are a lot of different ways to break it up. This takes care of all of those.

: This is the first time I've seen these slides. I'm really sorry. One of the other things that you do is with NS attributed strings, right? A lot of people want to be able to go through the attributed string and figure out what attribute is in each range of the string.

And so you might call something like attribute at index with longest effective range in range. So you have to set up this method call and write a while loop that iterates through these things. Right? What we're going to do instead now is use enumerate attribute in range options using block.

And the block is right here. So what I've done here is renamed the key, the ID object to font so that it's a little more obvious what I'm doing. And this code just goes through, runs through all the attributes in the string and compares it to find out if the font size is less than 10. And if it is, we'll just go ahead and print it out. We can do other things with it as well.

This is a much easier way to be able to enumerate in NS attribute. So we're going to go ahead and print out the attribute in the string. And in order to also provide a wider range of API, we have two new methods that do this. One is the one that I just showed you, which is enumerate attributes in range options using block. That's the one on the bottom. And enumerate attributes in range options using block.

Each time through that block, you're going to get an NSDictionary that has the entire set of attributes that are applied to that string, to that substring in that range. It's a much faster way to be able to go through an entire string and get all of the attributes that are there. Blocks are letting us be a little more expressive and allow you guys to write less code in your applications. So it's nice for us.

It's nice for you. We're also adding API to allow sorting using blocks. This is the type definition of basically a named block here. The name is NS comparator. Each time the comparator block is invoked, it'll take two objects to compare. And you'll return an NS comparison result from that.

And there are sort options that you can pass to all of these things. The sort concurrent flag and the sort stable flag. So now with the block API, we have a stable sorting API in foundation, which is not a guarantee that we made before. So if you pass the sort stable flag, you'll get a sort that the results have the elements in their relative positions correctly. Those are NS sort options.

Also, that concurrent flag is interesting because in Bertrand's example, he had some dispatch call going on and things like that. And this basically reduces most of the concurrent API in foundation. So you can take the API in foundation for all of these kinds of sorts and selections to a bit flag that you pass into it.

So we'll take care of all the concurrency in the background. You'll use these things with sorted array using -- with options using comparator. And this -- for an array that's large enough, we actually go through, split it up into a bunch of different threads, let those threads do all the work.

We're also doing searching in Foundation now using blocks. Index of objects passing test and indexes of objects with options passing test. And you can pass a number of different options to this. Enumeration concurrent and enumeration reverse. If you want to do the enumeration backwards for the options, you can do that for indexes. This also applies to all of the enumerate objects using block APIs that are against NSArray and things like that.

The interesting thing about these blocks is that these are the ones that return a bool. And here, if the object or the index is being passed in, you'll do your test. And then you'll return a yes in order to get that object's index included in the NSIndexSet. This is a quick way to build up those index sets. You can write your test in line there and it's very expressive. : NSIndexSet now also does enumeration.

If you try to do 4N enumeration with an NSIndexSet, you can't. Enumerating an NSIndexSet is a little bit inconvenient. These are enumerate indexes using block and enumerate indexes with options using block, and these are a much easier way to actually run over each index in the NSIndexSet. You'll get the index of each object going through it.

Okay. I can slow down for a second. Sudden termination. What we're trying to do here is enable fast exit for applications and log out and shut down. We've all seen this where the user goes up to the Apple menu and they pull down shut down and you kind of sit there and twiddle your thumbs while an application does a bunch of work in order to quit.

The way you do this is by using NSProcessInfo API. An application launches, sudden termination is disabled. When the app knows that it's in a clean state, you'll call enable sudden termination. And this is how you signal to the operating system that you're ready to be killed. If you have data that's being saved and it hasn't made it out to disk yet, you should disable sudden termination.

Wait until that work happens. When you know the work has happened, re-enable sudden termination. We take care of a bunch of this for you. So if you're using set object for key and you just sort of take your hands off and you wait for the auto sync timer to come around and synchronize your NS user defaults out to disk, we'll disable sudden termination while those haven't been written. And we'll re-enable it when it does get set. So we're doing a bunch of the work. NSDocument does a bunch of work for you as well. So there may only be a few places in your code that you'll need to adopt this.

If you want to opt your app into it by default so that when it launches, it's clean right from the start, you'll use this NSSupportSuddenTermination key in your Info.plist, set the value to yes, will talk about this in session 425, Performance in Document-Centric Cocoa Applications. That's right here tomorrow at 5. Makes for a long day, but you should come see it. It'll be a good talk.

We also have now automatic cache management in Foundation via the NS Cache class. And this is something that works a lot like a dictionary. Objects that are put into the cache are indexed by keys. You'll do some search object for key request. That'll give the object back. There's some built-in policy, least recently used in frequency. There's also a cost factor that we're building into this as well as account limit. And these are sort of not hard limits. We'll get close to them and then we'll start taking some additional behavior.

Object for key and set object for key, obviously the main setters and getters for objects that you're going to put into the cache and remove from the cache. Remove object for key takes them out. Set object for key cost is how you associate a cost with a particular object. And that works in conjunction with the set total cost limit API. So you can set an upper bound for the cost.

And as soon as we hit that bound or go over it, again, it's not a hard limit. We'll start evicting items from the cache based on their cost. And the set count limit is the same thing. you probably want to know when something's going to get evicted from the cache.

There's also now at the low level a purgeable memory facility. The kernel has a way to be able to allocate a special kind of memory that if it's not in use, if you haven't indicated it's in use, then, well, it'll go ahead and rip it out from under you when there's memory pressure on the system.

Chris Parker We've implemented that as part of an NSMutableData subclass. It's a special kind of mutable data called purgeable data, and this takes care of managing this for you. So we'll do the allocations and things like that. And what we've done in order to make this discardable content idea abstract is we have now an NSDiscardableContent protocol, and these methods are for content management. It's how you'll indicate that you're still interested in the backing store of an object, and when you remove that interest, the backing store of the object may go away.

We also have an automatic management method. We also have an automatic management method. One of the other things that we noticed in working on Snow Leopard and other operating system releases is that there are places where we could be a lot more efficient in terms of our use of the file system.

: Thank you, Chris.

I'm going to start with a quick excerpt of all the properties that are available, and there are more of them that you can see in this URL.h. The effective icon key is the one that's displayed for the user, and the custom icon key is whether or not the user has pasted a new icon onto that resource. So it will be able to tell the difference between what's being displayed and whether the user has a preference for that icon.

We also have a new file URL type. File URLs are interesting because they're path-based, right? So volumes/users/chris_talk.rtf points to a specific file in my home directory, in that user's directory, and if I move that file, I'm not going to be able to locate it with this resource locator anymore.

We're introducing a new type of file URL called a file resource URL. And when I call file resource URL, I get something that looks like this. The format of this isn't important. What really is important is the behavior. And if you've done Carbon File Manager programming, this basically functions exactly like an FSREF.

So if the file moves on to the local disk someplace, we're going to track that. So here's a file in my home directory. I have this path-based URL. I call file resource URL on it. I get this nice different kind of URL. It's still a file URL. I can still pass this URL to things like NSData's init with contents of URL, any of the URL-taking methods that are in Foundation and the kit. But if I move that, one of these actually tracks the file when it moves. So now you'll be able to get this functionality right from NSURL and use it all the way up through the Foundation and AppKit stack.

is the talk about this today at 2:00 in North Beach, using file system APIs efficiently. Chris Lynn will talk about this. Keith will also explain about bookmarks, which are a new kind of data that we're using as basically the follow on to the alias manager for very rich aliasing experience also. So that's also being introduced today at 2:00.

As part of all this, we've been introducing new APIs in-- we introduced new APIs in Leopard that took URLs. We're actually doing a lot more of this now. We're adding more URL-based API to Foundation. So NSBundle grows a bunch of new NSURL methods that return these populated NSURLs.

URL for resource with extension, subdirectory, isBundleWithURL, all the different URL subfolders, things like that. And these are all things that you'll be able to use directly in the new Foundation APIs and the new Kit. So NSURL, also we've put a number of these on NSFileManager. So all the copy item at path, all the at path APIs are now at URL APIs.

So copy item at URL to URL error, move item, link item, and remove item, all of their delegate methods have been updated as well to hand you URLs to the delegate. And these will all be ways that we'll be able to take advantage of some of the data sharing that we can do with the NSURLs.

We've also enhanced property list parsing, some of the APIs there. So if you're working with an NSData, these two new methods on the property list serialization headers, data with property list format options error and property list with data options format error, those two methods allow you to switch back and forth between NSDatas and property list classes.

And the important thing here is the error parameter because we're going to put better errors in there to talk about what went wrong in parsing that plist and where. So whether something's not a plist type or if you have an XML plist, something's wrong with the XML, that kind of thing. And those are also suitable for presentation to the user. If you know something more about it, though, as usual, you should wrap those up and put a more descriptive error in yourself if you need to.

We've also done it for streams. So if you have a stream that the mark is sitting at the beginning of a property list data that you know in the protocol you're working with via the stream, you'll be able to write the property list to the stream or read the property list from the stream using these two new APIs. Write property list to stream format options error and property list with stream options format error. So those are a set of property list APIs that give you much better errors. So-- oh, yeah, there's that App Kit thing.

The Kit is getting a number of new methods and functionality that also incorporates some API that you would have had to go to other frameworks for. And we tried to be very careful about the API that we're drawing in. The first is being able to get at the finder labels right from NS Workspace. So you've seen this in the finder. The user has a bunch of labels that are set up with colors and text.

You'll call file labels or file label colors against the shared workspace instance. And you'll get that list. And if you register with NS Workspace's shared workspace instance, you can also get this notification about the fact that the file labels change. So if the user goes and tweaks those, you'll get the notification that says maybe you should go back and read that list again.

Workspace also can show query results. So something you would have had to go to HLTB for the Carbon UI Kit for. Show search results for query string. You give it a query string that's formatted the way Spotlight expects it, and this will tell the finder to go ahead and put that search window up and start doing that search. This is a nice little convenience method there.

There are also new notifications for NS Workspace. And these will be available at all times. At one time, you would have had to be the frontmost app for this. Now you can get them all the time. Did hide app, did unhide app, the activation and deactivation notifications. These work now for all running applications. This includes anything with a full UI or LSUI element applications and LS background only applications.

: I'm glad to see there are four of you who need that. There's now also desktop image support. So now right from NS Workspace you'll be able to set the desktop image URL for a given screen. Set desktop image URL for screen options error. Give us a URL that points in an image.

Which screen you want it on is the NS screen instance there. The options are things like, well, it's what you see in the desktop and screen saver control panel. When you set a desktop image you can choose whether it fills the screen or centers, things like that. You can also find out what the URL is, desktop image URL for screen and desktop image options for screen. So you'll know exactly how the user has their desktop set up if you want to change it.

We also now can vend information about other running applications. NS Workspace has this new method called running applications, and this includes all running applications again. So this is anything that checks in with the Windows Server and says, hey, I'm an app. So this will be LSUI element applications, LS background only applications. This is any Ruby Cocoa application that checks in, PyObjc, all of those things that actually make a point of working with the Windows Server to tell us that it's an app will report here.

That running applications method returns an NSArray. Each element in that NSArray is an instance of one of these things, which is an NS running application. And this is all stuff you probably would have had to go to another API for. The property declarations here are things like terminated. So if you have an instance of one and it ends, the terminated state will change to yes.

You may not be able to get information about it after that, but all of these things are available while the app is still running. Hidden, whether or not the app is hidden or active, the localized name of the app, launch date, the icon, what executable architecture is it, and this includes whether it's a 64-bit app, 32-bit app, translated app, things like that.

If you wanted to tell one of those applications to do something like hide or unhide, previously you would have had to roll up an Apple event and send that Apple event to the application and get it to do something. Now you can call hide or unhide directly on one of these instances, and that will just take care of it for you. You can tell it to terminate if you're feeling particularly vindictive toward another app.

You can also tell other apps to activate with options. So if you just call this with zero, it will bring the key and main windows front. There's also an option there to be able to bring all the windows of the app to the front. So there are some options there. You can look at those up in the header. So that's an NS running application.

Do I even have to present this slide? Somebody already knows what's coming. You may have seen this in mail. Somebody sends you an email and they send you an address and a website. Mail takes care of figuring out where the address is and it goes through and it nicely URLifies all the URLs and things like that.

If you've done this yourself, it's a lot of work. You go through and you have to find everything that looks like an address or looks like a URL. It's really frustrating. We're actually bringing this right into the App Kit in Snow Leopard. With a unified text checking API.

So in Leopard, we were doing spelling and grammar. Now we'll do dates, times, addresses, and phone numbers. We'll do URLs. We'll find your smart quotes and any of the smart dashes and things like that. Interesting text features. Text replacements. So if you've typed in something that we know that could be replaced by a nifty or Unicode glyph or something like that, we'll put that in and we'll also enable auto correction. So all of these things will be available in the text system in Snow Leopard.

How are they available? I hear you cry. NS Text Checking Results are basically the object that's going to wrap this up. So an NS Text Checking Result has two primary accessors. That's going to be the read-only property for the result type and the range. And that's the range in the string that you checked that contains that result type.

These nine are text type spelling, grammar, date, address, link. Link is the URL one. So once we autofind the URL, that'll be the link type. And it matches with the NS Attributed String attribute for that. Quotes, dashes, the replacement type, and the correction type. So whenever you get a text checking result, you'll be able to interrogate it for what kind of thing it is and where in the string that appeared.

If it's one of those other special types, like a grammar type or a date, we've put some conveniences on NS Text Checking Results to be able to just pull those things right out. So if we saw a date, you can call date on the NS Text Checking Result. You'll get a fully cooked NSDate. But if you call URL, you'll get a URL.

The address components one is interesting because addresses are fairly rich things, right? The address components accessor returns a dictionary. That dictionary contains all of these things if we found them. So the name, what the job title is, the organization, street, city, state, zip, country, and the phone number. So you get full information about all the addresses and things like that that are in.

A text checking result. One of the other really interesting things that text checking results come with, and this is the tenth result type, is this NS Orthography object. And NS Orthography objects describe what the script system and language is that are in use in the text. So when you ask us to check a string, we're also going to go ahead and figure out what that string looks like in terms of what the script system in use is and the language.

And the two primary accessors on that are the dominant script and the language map. And this is interesting because this is what's going to allow us to be able to do things like spell checking and stuff like that against sections of the text without having to switch your language.

NS Text Checking. These aren't hooked up yet in the seed. The API is there. But just to give you an idea of what will happen, you'll be able to toggle all of these automatic behaviors right on NS Text Views. So if you want these things to happen automatically in any of the NS Text Views that you've got in your code already, you can call something like set automatic data detection enabled. And we'll go ahead and search all the text that's in that text view automatically. And you can turn these things on and off individually.

So there's one for dashes and quotes and URLs if you want to just do certain subsets of those things. It's not turned on in the seed right now, so you can't play with this directly. But you can use this new API and a spell checker. And this is check string range types, options in spell document with tag, orthography word count. The big hitters here are the check string range. So obviously the string that you want to pass us and the range that you want to search in that string.

The types are a bit mask of what things you want to look for. So tell us that you're looking for URLs and addresses, and we'll only look for those things. The orthography is interesting. If you pass us a by reference pointer to an NS orthography object, we'll take the entire range of that and figure out what the dominant script and language are and return that in that top level NS orthography object.

will also return word count if you want it. The array that's returned here is an array of those NS text checking results. So each of those will have their own orthography information in them. So not only do you get an overall sense of the dominant language, but you'll be able to pick out all the languages in each individual text checking result.

In past years, NS Browser has maybe lagged a little bit behind the other collection viewers. and we're addressing that in Snow Leopard also. There's a new item-based set of delegate methods. And if your object, if your NS Browser data source delegate object implements these four methods, browser number of children of item, browser child of item, browser is leaf item, and browser object value for item.

If you implement those four things, you're going to get a very rich set of APIs that are available to you on NS Browser that allow you to change back and forth very easily between what's being shown in the browser and the model objects that are underneath it. So things like item and index path now will work if those methods are implemented. Index path for item, index path for column, current... is a parent for item. I need glasses.

Is leaf item and parent for items in column. All these methods work in conjunction with your data source delegate to be able to return those items. And it's much easier to switch back and forth with these. Selection index path and set selection index path, these APIs allow you to be able to set up exactly the path of things that are selected all the way down that NS Browser in one call. So this is also pretty easy to use. We're also offering header and preview views in NS Browser now. And this is the header things up over each column.

And if you've seen what the finder does when you click on a leaf item, it shows that view in the last column there. This is how you'll be able to do the same thing. And all you have to do is return us an NS View controller for a particular leaf item for either the preview view or that header view that goes up in the top there. So this will be a much easier way to be able to use NS Browser to show those kind of rich browsing experiences when people click on their leaf items.

A couple of other enhancements on NS Browser. Scroll row to visible of columns. So before you could bring a column in, now you can actually select a specific row and bring that in so that the user can see it without having to make any UI changes to figure out where their selection is in the browser. And the clicked column and clicked row methods work in conjunction with the NS Browser set menu API. So if you have a contextual menu, you'll be able to find out exactly which column and row was clicked on to determine that.

Doug Davidson will be giving a talk about all of this stuff and is polishing your Cocoa application talk. That's tomorrow right here. You don't have to stay in your seats until then. You can go and come back if you want. And he'll talk about all of this and a number of other things in his talk. I'm not even going to say anything right away. NS Event and NS Responder now do multi-touch gestures. So everything that's available now for the MacBook Air and the newer MacBooks, the trackpad events. This is magnify with event, rotate with event.

Swipe with event, begin gesture with event, and end gesture with event. And these are how you're going to be able to hook up in the event system all of those events into your application. So if you're working with swipes, typically, if you do a right swipe, you go forward in your browser history. This is how you do something like that.

So swipe with event. You get the NS event in it. You can check the delta X of the event. If it's greater than zero, it's a left swipe. If it's less than zero, it's a right swipe. So this will be how you can wire up your interface to be able to take advantage of those things. Thanks.

We have some new behavior in NS Drawing, and this is kind of interesting. NS Drawing lock focus used to go to an off-screen window where the image would be contained, and now we've stopped doing that. We're actually doing direct memory buffers with NS Image lock focus. So this is actually a good performance win for us because it means that we're not using the Windows Server to hold the window references for this. It does mean NS Cache image rep is deprecated. It's still there for compatibility, but the lock focus code is definitely going through a different buffering mechanism for that.

If you see any behavior changes on the seed, please let us know. And there's a bigger discussion of this in the App Kit release notes. So we'd really like to know if something goes south with this. We're also trying to make it easier to work with NS Image and CG Image refs.

There are a lot of places where the API takes a CG image ref or expects a CG image ref and maybe you've got the other thing in NSImage. In it with CG image size, this new API in Snow Leopard that pulls in a CG image ref, wraps it and makes it an appropriate NSImage. These next two methods work in conjunction with each other.

CG image for proposed rec context hints and best representation for rec contents hints. NSImage really tries to be a resolution independent drawing image representation and CG images are a little bit more pixel oriented. So this is how you'll be able to generate a CG image as if it were drawn in a particular rectangle. So this is an easy way to get a CG image out of an NSImage ref. A CG image ref out of an NSImage. There we go.

We now also have some more support for NS Cursors, new kinds of Cursors. Drag Link Cursor, the Drag Copy Cursor, Contextual Menu Cursors, and the Operation Not Allowed Cursor. That last one is the one where, you know, if you drag out of the finder into something else and the user's not allowed to make that drag, we'll put the little circle with a slash through it.

We've also introduced something you would have had to go to Quick Draw for previously. And Quick Draw would have required you to get the current system cursor. This actually gets you the current system cursor right away. It includes any, no matter what app has set the current system cursor, and no matter what that cursor looks like or whether or not it's hidden, this will give you the image and the hotspot for it right there.

And NSError. NSError is a class that actually lives in Foundation. That class allows you to produce user visible errors that are suitable for presentation right to the user. It contains a bunch of things. Here's one that I got at some point trying to open up that talk.rtf file.

I don't have the appropriate access privileges. It has the localized failure reason and the recovery suggestion. Now, if you add the NSHelpAnchorError key, we'll actually put the little help anchor right there in the presentation machinery for you. So that's very handy. NSDocument now supports the concurrent loading of documents.

This is a class method on this document that will be called repeatedly with each type of document that's being opened. Right? So this is interesting because if you return yes for this from a particular type, we'll go ahead and possibly schedule the opening of that document on a background thread.

And this is going to allow your application to stay much more responsive all the way through that process. So if you select, say, 50 documents, 49 of those documents are little 500K documents, and the 50th one is some 600 megabyte monstrosity that needs to load. We're not going to block the main thread loading that document. We'll do it in the background. The user can actually interact with all the other documents in the application and do their work.

And when that 600 meg document loads up, it'll come into the front and then you'll be able to work with that also. So we're trying to make sure that it's easy to write document-based applications. And we're trying to make sure that it's easy to write document-based applications that respond well and continue to respond well even under heavy opening load.

: NS File Wrapper now also has efficient saving support. So a lot of times you'll have an NS File Wrapper, you make two or three changes to files and there are 400 things in the wrapper. If you call write to URL options original contents URL error, that original contents URL is The pointer to where the original document is.

What we'll do is we will compare everything that changed and figure out that all we have to do is create a bunch of hard links to the new location on file systems that support it. And then we'll tear down the old one there. So it's a very efficient way to be able to write file wrapper changes to disk. Mark Picciarelli will talk about this in his performance in document-centric Cocoa applications. And that's also here in Russian Hill Thursday.

So We also have concurrent drawing support now in Snow Leopard. So NSWindow has a top-level call, allows current view drawing. That allows current view drawing tells the window that its contained views may be able to have their drawRect methods called in concurrency. So they may be called on different threads on the same time. NSView has a canDrawConcurrently method and a setCanDrawConcurrently method. And these things opt the NSViews into this draw and concurrent behavior. So Aliozer will be talking about this.

Cocoa performance techniques in the marina Thursday at 2. And this is a very good way to be able to get some extra drawing performance if you know that you can draw in background threads. I have a quick little demo here. If I could have demo one, please. Gosh, I hope this looks okay. Okay. Let me get this so you can actually see what's going on.

Pay no attention to this man behind the curtain. They always ask you, "What are you going to do when the demo goes wrong?" They never ask you, "What are you going to do when the machine doesn't display the way you think it should?" If I launch this, do you guys see that? Let's The code is bouncing. If I create a new project, no. All right, let's try this again.

You guys throw the fruit, I'm walking off stage. Yay! Thank you, sir. Boy, it's a good thing there are people who know computers around here. Well, now what else can go wrong? So I'm going to just fire up a new Cocoa application here. And I'll call this AppLister. And here we have our blank Cocoa project.

Let me create a new class here. I can't put instances of NSWorkspace in nibs, so I have to create a little controller object here. To create our AL controller, I'll use our new Objective C 2.0 property syntax here. To create a property, we'll make it a read-only property. This will return an NS workspace.

So all this does is when you call it, we call shared workspace and feed it back to you. And let's add some stuff to a nib. So here's our main menu and our window. Let's start throwing some stuff in here. We'll put a table view in.

Get this all nicely lined up. I like to have the spacing correct, so we'll make this so that it's all nicely resizable. And let's set up our object also. So I'll get an NSObject instance here. We'll throw it in. And here in the object inspector, I'm going to go ahead and set its class to be ALController.

Now, what I want to try and do is hook up to the NSWorkspace instance. So I'll use an NSArrayController here. to bring that in. What we'll do is we'll use Cocoa bindings and grab the content array. We'll bind that to the controller here, and the model key path will be workspace running applications.

And what else do I need to do here? Oh, let's make this look good. Let's get an image, an NSImage cell, and we'll assign that to this. : Thank you, Chris. I'm going to go ahead and start the session. I'm going to start the session with a quick summary of what we've done. The first thing we're going to do is we're going to go to the We build and go. And what we have now is, by binding to the NS running applications instance, our very own low budget activity monitor.

So if I launch TextEdit, it shows up. And if I quit Interface Builder, you see Interface Builder leave. If I quit TextEdit, the running applications instance is key value observable, as are the NS running application instances as well. So you'll be able to get some interesting notifications out of all of that.

The other thing I wanted to show you was the text checking APIs. And it sounds like-- I mentioned that a lot of this stuff was a lot of work to be able to go through and search through all of that text. And what I have here is just a little short demo of using the text checking APIs. And I threw this together in much the same way in Interface Builder. I just typed some text directly into the Interface Builder text view right in IB. So here's a bunch of text. There's a URL.

Oh, it's that thing where people send you mail your address. And a possible replacement text and just some grossly misspelled words. And if I hit Check Text here. This goes ahead and recognizes all of that. And we've also gone ahead and I've assigned some tool tips and things like that.

And here the tool tip over the little C that's been underlined is actually, it's hard to see up there, it's actually the little copyright symbol. And I can add some stuff to this, put a registered trademark thing there, hit check text again, and the tool tip has that. Chris Parker How much code did this wind up being? Oh, not much.

Here's where all the hard work really is. This is my text check-- check text method. Say that five times fast. I grab the Layout Manager to be able to do some attributed string, setting temporary attributes on the string. I grab the string out of the text view, clean up any attributes that might have been there, and then this is me doing-- well, actually, I'm sorry.

It's the text system doing all of the work for checking all the possible types in that text. So that one line of code gets everything. And here I've just used the for in statement to run over that array and just assign some different attributes depending on what the different text checking things are.

So it's a really, really easy way to be able to do all of this. So if you don't want to do it automatically in NSTextView, it's pretty much one line of code to find out what's in your text there using our text system. So-- Can I please have-- do I have the other one back now? I hope. All right. The slides are back. Yay. Core Data has also been busy. There's more than I can possibly talk about here, but let me hit the highlights. There's now Spotlight integration in Core Data, so you'll be able to do searchable records from your Core Data database.

So there's a support directory that will automatically get maintained when you opt into this. There's tool support to mark properties, so when you have properties inside your model, you can check off those properties to say index and spotlight, and it'll just take care of that. And it's got all the support for generating the SQL for all of that stuff.

Chris Parker There are also read-only properties now, which is a big performance opportunity for you. And the new fetch requests that do read-only properties support composites of function expressions, individual properties, key paths, the aggregate functions for sum, average, max, min, count, things like that. Chris Parker And there's also a way to be able to get distinct results out of your databases.

So this is a property fetch that allows you to go out and find out what's in your database without having to get every single object and then do the uniking, right? Chris Parker So if you were picking, oh, let me do something. Chris Parker So if you were picking, oh, let me do something.

And there's also support for lightweight migration. So automatic schema change support for simple model changes. If you tack on a new property for something, Cordato will go ahead and figure So there's also in-place migrations for SQL Lite data stores and tool support for also renaming your attributes, relationships, and entities. So all of that stuff is built right into Core Data.

The Core Data team will be talking about that today at 2 p.m., What's New in Core Data. There is a lot more than I could possibly fit in here. You know, we could talk for a few days on all of this stuff just by ourselves. One of the things that we are doing in the future, if you heard Blaine's talk, he touched on this.

In delegates and data sources, things that we did before Snow Leopard was define what the methods were by using what we called informal protocols, which was really just a fancy way for saying categories with a lot of documentation. So this is the NS TableView data source informal protocol. It has some required methods. It has some optional methods. And if you've ever mistyped one of those required methods and then sat there for a while and gone, why isn't my TableView working? That's where this can come in handy.

So we're going to go through the foundation and the app kit and define those as formal protocols using the @required keyword and the @optional keyword. And this will be a way that we'll also annotate the delegate and data source methods with those angle brackets indicating protocol adoption so that you'll be able to get some compiler and tool support out of making sure that you've got all of those methods spelled correctly or actually implemented that have to be required.

Ken Ferry, tomorrow morning, bright and early at 9:00 AM, will talk about Cocoa tips and tricks using Snow Leopard features effectively. This was actually labeled as Leopard features. No, we're actually going to talk about Snow Leopard features. Custom bindings, some interesting things you can do with obviously 2.0 properties and key value observing. He'll also talk a lot about some of the drawing stuff that you can do.

Leveraging Cocoa's layer-backed views, tomorrow morning in the mission at 10:30. Troy Stevens will talk about subpixel LCD anti-aliasing in the App Kit. Grouping and sequencing animations, getting things to happen in the right order. Switching between layer-backed and regular views. There are times to do it and times maybe not to do it, and he'll talk about that. Mapping view to layer geometry can be a little tricky. He'll have some tips for that and also some performance ideas in the Cocoa drawing system.

will be talking about Cocoa performance techniques. These are a bunch of things we haven't talked about before at WWDC. Multithreading atomicity and synchronization in the collections and your objects. Computational complexity. He will also talk in detail about the NSCache, NSPurgable data and NSDiscardable content API. So all the new caching and purging techniques that we're adopting in Cocoa in the AppKit and Foundation and also some drawing stuff.

Doug Davidson, right here in Russian Hill tomorrow at 3:30. We'll talk about polishing your Cocoa application. Once you get it working, there are a lot of things you can do to really make it shine. And 64-bit readiness. You heard Bertrand's talk about asking for plug-ins now to be 64 and 32-bit capable as well as the applications. So these are some things that you'll be able to learn about there.

Performance and responsiveness, security, localization and internationalization, usability and accessibility and scripting. I think Doug and James will probably be talking as fast as I was here. And tomorrow also performance and document-centric Cocoa applications. Our very own Mark Picciarelli will be talking about concurrent document opening, our NSURL usage everywhere in the Foundation and the App Kit.

Fast document saving with the new File Package API on File Wrapper. And all the sudden termination stuff and how adopting sudden termination can really help your app as well as the operating system as a whole. If you're just dying to meet us, we have two labs remaining. The Carbon to 64-bit Cocoa Lab in OS X Foundation's Lab B. As far as I can tell, that's a fancy name for that back left corner when you walk in.

And we also have a Cocoa Open Lab tomorrow at 2:00. I'm sorry, tomorrow at 12:00. That's in London. And we have a Cocoa Open Lab tomorrow at 2:00. I'm sorry, tomorrow at 12:00. Lab C, which is a fancy name for the other back corner. So please come and ask us questions there.

For more information, you can write to Mr. Derek Horn, who is our Application Frameworks evangelist. And also we're going to be updating the AppKit and Foundation release notes as we add new things. So please keep an eye out on those. And now we have time for some Q&A.