Video hosted by Apple at devimages-cdn.apple.com

Configure player

Close

WWDC Index does not host video files

If you have access to video files, you can configure a URL pattern to be used in a video player.

URL pattern

preview

Use any of these variables in your URL pattern, the pattern is stored in your browsers' local storage.

$id
ID of session: wwdc2006-101
$eventId
ID of event: wwdc2006
$eventContentId
ID of session without event part: 101
$eventShortId
Shortened ID of event: wwdc06
$year
Year of session: 2006
$extension
Extension of original filename: mov
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: ...

WWDC06 • Session 101

What's New in Cocoa

Application Technologies • 45:03

This talk provides an overview of new features and important changes introduced in the Cocoa frameworks in Leopard. Learn about the exciting developments in AppKit, Core Data, Foundation, and other related frameworks on Mac OS X, and get pointers to other sessions that cover the changes in more detail.

Speakers: Chris Parker, Doug Davidson

Unlisted on Apple Developer site

Downloads from Apple

SD Video (430 MB)

Transcript

This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.

Good morning. My name is Chris Parker. I work in the Cocoa frameworks team, and I'm glad you could all join me here at 9 in the morning for What's New in Cocoa. So let's get started. We have a number of new things going on. We've made a lot of changes for 64-bit and for resolution independence, so you heard Simon Patience and Peter Graffagnino talk about those yesterday.

We have a lot of new behaviors for existing API as usual, a bunch of new API and some new controls and things like that that we're going to show you today. So let's start with some discussion about 64-bit. Simon told everybody yesterday that in Tiger, all the lower level system libraries were 64-bit, and now in Leopard we're moving up. So the frameworks now are going to be 64-bit, and we've made some changes throughout Foundation and the kit to facilitate this.

So we've updated our collections in 64-bit. They can hold many more objects. We've added some new types and new methods to deal with the wider word size, and we've also provided some conversion scripts for you. So if you look around in your developer folder, you'll find some scripts to do some conversion of types and methods. You'll also find some verifier for NSCoders, so we're going to try and help you get your archiving right in both the 32-bit and the 64-bit world.

We've also removed some classes in the kit. And sometimes we'll have to do some work on the code, but we're going to try and help you get your archiving right in both the 32-bit and the 64-bit world. So we've pulled out NS Menu View. We've pulled out NS Movie and NS Movie View, and those have been deprecated in favor of the 64-bit stuff that's in QtKit.

QuickDraw, you saw yesterday, QuickDraw has been completely deprecated, so NS QuickDraw View is gone. And NS, the Simple Horizontal Typesetter, that's been deprecated for a little while. We're actually pulling that out of the kit in 64-bit as well. And the new typesetter APIs are what you should be looking at.

We've taken individual methods here and there out for 64-bit. We've taken advantage of this opportunity for binary compatibility to be able to pull some of that stuff out. So some deprecated methods are gone. We've also made a lot of changes for resolution independence. The work started in Tiger for developer testing, so when you fire up Quartz Debug in Leopard, you'll be able to see some new behaviors. Most of the standard controls now draw in high res, so when you scale your UI up at 1.5x or 2x, there'll be a nice crisp button.

There'll be good crisp text in the menus. And outlines for all the controls. We've worked on a lot of the standard images now are available in high resolution, so if you ask for a named image, you're going to get a nice big scalable image that will get displayed correctly. We've addressed a lot of the problems with non-integral scaling that we had.

Scrolling now works a whole lot better when you're scrolling in views. And some of the table view stuff has been fixed for row alignment in high resolution. So there are a lot of other changes here. They're all in the release notes. I could talk for a long time about this. But we do have a few other talks for you to go to for this. So right here in this room at 10:30, the Taking Advantage of Leopard features in Cocoa talk.

And in the marina later today is a 64-bit overview. And those two talks will cover a lot of the stuff in more detail here than I can here. So let's just get started right with the stuff in the app kit. You saw Peter Graffagnino talk about the cinematic experience. And part of that is using core animation. What we're doing is we're going to incorporate a lot of these core animation capabilities directly into the app kit.

So NSView subtrees can be automatically mirrored into the core animation layers. So if you've been looking at the core animation API on Leopard, you'll see that there's this idea of a layer that each view will have. And we're also adopting the implied animation model that's there. So you'll be able to do some very similar things where you set an attribute and just have it happen. This also means that we can add new appearance attributes to NSView.

So there will be some new things you can do with views. And it's all to make animation easier in Cocoa. So we don't like writing lots of code any more than you guys do. So we're going to try and compress down how much code everybody has to write to get really good eye-popping animations into this.

So the way you turn on the layers for a view is you call set wants layer yes. And that takes the entire view subtree and makes it core animation capable effectively. So we've introduced this idea of an animator proxy for the object. So before if you called set frame on a view, it would happen automatically. Now what you'll do is you'll ask for the view's animator and then call set frame on that. And that makes it happen using the core animation effects.

If you need to do longer durations than the default, or if you want to group multiple things into a single animation effect, you'll use an NSAnimationContext. This is a similar idea to an NSGraphicsContext. You begin a grouping, in the current context you set the duration, and then you do things like set the frame. And then when you call end grouping, that touches off the animation.

The new NSView properties, things like the layers are an obvious property, but this will include things like alpha value, the view, the shadows, compositing, origin, frame, the bounds, all of that stuff is all controllable by this new animator proxy idea. And again, I could talk for a long time, but we have a Cocoa Animation Techniques talk in Knob Hill on Wednesday.

And if you'd like to learn more about using the Core Animation stuff in Cocoa and how all this stuff works just by turning on the LayerKit stuff in Cocoa, that's where you should go. And I'm going to ask Doug Davidson to come up, and he's going to talk about some stuff that we've been working on for Cocoa Text.

Thank you, Chris. Let me just go over to the demo machine here. Now, from time to time over the last few years, people would come up to me and they'd say, "Now, the Cocoa Tech system is great, but why does it slow down so much when I try to load in my 50 megabyte log file?" I have to say, well, you know, it's not really designed for that. And some of them will say, so redesign it. That would take a long time. Well, for Leopard, we've had a long time.

And anything over a year is a long time for an OS release, don't you think? : Hello, everyone. I'm Chris Parker, and I'm going to talk about the new features in the Cocoa framework. This talk provides an overview of new features and important changes introduced in the Cocoa frameworks in Leopard.

Learn about the exciting developments in AppKit, Core Data, Foundation, and other related frameworks on Mac OS X, and get pointers to other sessions that cover the changes in more detail. Learn about the exciting developments in AppKit, Core Data, Foundation, and other related frameworks on Mac OS X, and get pointers to other sessions that cover the changes in more detail.

So let's go back to the slides. And let me talk about what we've done to make this possible. Well, first of all, we've rewritten a large chunk of the text system. More important for you, we've added a new option to NSLayoutManager called non-contiguous layout. What this does is it means that when it's turned on, any portion of the document can be laid out, regardless of whether previous portions have been laid out previously or not.

And as you can see, this does have significant performance benefits for large documents. However, this is an option. It's not on by default. You have to turn it on. The reason is that it also produces some significant behavioral changes to the NSLayoutManager APIs. Now, if you are using NSLayoutManager only indirectly, say via NSTextView, then you can probably just turn it on without any problems.

If you are using NSLayoutManager directly, however, you probably will have to do some work to modify your code in order to adopt this. For TextEdit, I think it was just a one-line change. When Xcode adopted this, they had to do significantly more work, but not too bad, I think.

Now along with this comes some new NSLayoutManager methods. Of course, there's a flag to turn it on or off. And because of these behavioral changes, we also have some new methods that allow you to explicitly specify and force glyph generation or layout for specific portions of the document.

We've also taken this opportunity to do some cleanup on our API to fill in some holes and add some new methods to make things simpler. For the details of the new methods and behavioral changes, go to the AppKit release notes and look at the NSLayoutManager header. It's all specified there.

So what else do we have for you? Well, as you know, the Cocoa Tech System imports and exports a variety of document formats, HTML, Word doc format, and so forth. There's been a lot of talk recently about some new document formats. So I'm pleased to be able to say that in Leopard, the Cocoa Tech System will import and export both the Oasis Open Document format used by OpenOffice 2 and the ECMA Office 2. There's also the Office Open XML format used by Office 2007.

The support for this is on the system that you've received. It is currently still somewhat preliminary. In the case of Office OpenXML, necessarily so because the standard is not yet finalized. And also there's an important caveat, and that is that the Office 2007 betas don't use a standard format, they use a non-standard variant. We can handle it, but anyway, the details for this are also in the release notes. You can take a look at that. And you can try this out in TextEdit, a system you have.

What else is on the system you've received? We have a number of smaller additions to the tech system APIs. A number of people have asked for more control over the spell checker, and in particular over the dotted underlined misspelling indicator, where it gets shown, and we've added that for you. We have a number of new methods for controlling temporary attributes on the layout manager.

And the layout manager has a new method to make it much easier to get access to insertion points in the text, in particular to get bulk access to many at once. And there are a number of other new bulk methods from the layout manager. Text views now have tool tips for links to automatically show the destination of the link. And a lot more. Take a look at the Reese notes again for details.

Chris Parker, Doug Davidson In addition, there are some new features that are not enabled on the C that you have that are planned for levered final. Among these are grammar checking to go along with spell checking, inline editing of images attached in text, courtesy of ImageKit, smart quotes, automatic conversion of straight quotes to curly quotes, and automatic detection of URLs and text conversion to links. All of these, of course, on an opt-in basis.

There is one more thing I want to mention that's not perhaps directly relevant to Cocoa, and that is that there is a new public framework in Leopard at the Carbon level called Core Text. This was private in Tiger, now public in Leopard. This is essentially a modern replacement for Atsui, and it provides very low-level line layout information. The Cocoa text system has been using it to get its low-level line information since Tiger.

Probably most of you will never need to use it because you have Cocoa APIs like NSLayoutManager to get this information. But if you've ever had occasion to use Atsui, you should take a look at Core Text. It's a lot easier to use. For starters, it's based on attributed strings, just like the Cocoa text system. And there is a talk on this, I believe it's on Thursday. And now I'd like to bring Chris back up to continue talking about AppKit.

Thank you, Doug. We've got some new controls and some new behaviors in the kit, and since Doug started out with a demo, I thought I would also. So, one of the things that we've been working on here, if I could have this demo machine, please, is... I'm trying to improve some of the things about the menuing system. So here I have just an application that you might whip together in Interface Builder.

It has a help menu. We see that the search menu is automatically in there. You know, the window menu, the normal stuff. Let me go down here to the application menu and if we look at this "What's This?" menu, we've made a few changes. You can now put arbitrary views in NS Menu items.

On the top here there's a garden variety text view. We have a button and an indeterminate progress indicator and a circular slider there at the far right. That spinning put any crazy view is a Qt, is a Quartz Composer composition. And this last view down here, well you can, oh, I moved away. There we go.

You can actually, I'm going to show you a little bit of a I played this for hours for a while. This was just great. So that's what we've done for menus. If I could have the slides back, please. I'm on NS Menu Item, and the way you do this is you basically set up your view the way you'd like and call setView on it.

There's no step three, right? It's create your view, call set view, you're done. Menu items with views don't do things like draw their title or state, so everything gets assigned to your view for drawing. You'll get mouse events and things like that normally, but you won't necessarily be able to get keyboard events, right? So we're tracking the menu for keyboard equivalents, but not directly in the view. So there are a few restrictions, but you should be able to play with it and figure out exactly what you'll be able to do.

Chris Parker, Doug Davidson We've added some new delegate methods to NS Menu also, so when you're mousing over the menus, you'll be able to get more information about what the user's doing. You'll get a delegate callback. Menu will open just before it pops open. Menu did close. It will highlight item as the user scrolls through it just before that highlight comes up on the menu item.

Chris Parker, Doug Davidson We've also introduced a new class called NS Rule Editor. So you've seen males rules filter. You set up slices that match various... Chris Parker, Doug Davidson Criteria, and then the rules are filtered here. We've added this directly to the kit. So it supports nesting of rules.

It's a delegate-based API, so you'll assign a delegate to it, and then this control will ask your delegate about what it should be displaying. Chris Parker, Doug Davidson It's also bindings compatible, so you should be able to just wire one of these things right up and bind to your controller object directly in IB.

Chris Parker, Doug Davidson If it's something that it can generate a predicate for, it will do so. So you can actually get NS predicates automatically out of this thing. Chris Parker, Doug Davidson And it's fully localizable, so all of the things that you see in a rule editor can be completely localized through a clever plist mechanism that we've set up. So this is what it looks like.

Chris Parker, Doug Davidson All right, so this particular one is a compound rule. Any of the following are true, and the name would contain an image, and the kind is of any image that's of type TIF. Chris Parker, Doug Davidson And this has the same plus and minus buttons on the far side, so you can add and remove slices, and you'll be able to completely configure this. Chris Parker, Doug Davidson So NS Rule Editor is now available for you in this. the kid.

So there's a special subclass to this. We figure that people are going to be doing a lot of things with filtering of, for instance, their core data applications and stuff like that. So we've added NSPredicateEditor as a special subclass of NSRuleEditor. So rows get populated directly from its object value, and the control's object value for a predicate editor is an NSPredicate.

So there's a helper class called NSPredicateEditorRowTemplate, and that maps between the elements of the predicate and the things that are displayed in the predicate editor. And this is completely configurable also programmatically or in Interface Builder. So if you've looked at the new Interface Builder, there's a control in the library there that's one of these rule editors. And it uses target action to talk about all the changes.

So this will go right up the responder chain, if you like, also. Chris Parker, Doug Davidson We've been spending a lot of time also on TableView and OutlineView. And there's some new features available in there. Type to select now. If you've got your TableView set up and you type.

You can type to select. The disabled state now works as the way you'd expect. There's also some new APIs for hit testing and tracking, so you'll get better control in the table view and the outline view of what's happening in your sliders and things like that, and a new full width look, and that looks like this. Right, so the full width look here goes all the way across.

You see that favorite things group is a full width cell that goes all the way across, and you don't see the check boxes and things like that. I typed to select Kosh here, and we've got some Other controls in there that we'll see what we can do with some API for those in a minute. You can control cell tracking now. So if you return a no from this method, outline view should track cell for table column item, that actually turns off tracking for that particular thing. If you return yes from this, now you can actually track independently of item selection.

And so the combination of this and some other API allows you to be able to grab a slider that's in a cell in a row, and it doesn't change the selection of the table view. So there's some behaviors here now that you can change without having to do too much subclassing. We've also added NSPathControl.

And this easily allows you to represent a path and its components. There are three different styles, the standard path style, the navbar style, and a popup style. And you can also filter the permitted types in this. And I actually have a demo of this also, if I could have the demo machine back here.

So here's the path control demo. And this is the pop-up flavor here, where if I click on the temperature converter menu, this pops up the regular demo. This is a list here of the path that it takes to get there. All of the display icons are correct. This will be localized into the user's system folders localization. You can choose different folders here.

You can turn this menu off if you like. The standard look is a little more interesting. You've probably seen this directly in the finder. As I resize this, the path elements shrink. And if I get it really small here and start mousing over these things, it will do the same animations.

So Navbar style, this may look familiar to you a little bit. It has the same look that the iTunes one does, right? So this has the same behaviors as I mouse over things. They expand. As I make it bigger, it resizes. And these are all set up to do things like drag elements out directly as a drag source, and they can also accept Oh, that wacky Mighty Mouse. You can also accept drags and just drag something into it and it automatically will grab the path from that. So that's the path control, the new path control in Leopard.

Again, I could spend a lot of time talking about this. We have another talk about it, Beyond Buttons and Sliders, right here tomorrow morning at 10:30, where a lot of these controls will be talked about and some other stuff in TableView and things like that. So please come by if you'd like to learn more about that.

We've added support for drawing gradients in the kit. So being able to have a color gradient with multiple color stops. These are linear or radial, so you can draw off a radius if you want. And it was colors at locations color space. So you give us an array of colors, and then locations is an array of CG floats from 0 to 1, 0.0 to 1.0, and those represent the inflection points for the color stops.

And you can draw linear gradients or radial gradients and that interesting one there is drawing Bezier Path Angle, and that looks like this. So if you've set up a Bezier Path with a bunch of disconnected elements, you can tell it to draw the gradient underneath it and it takes care of doing all that clipping for you. So some of the work you may have been doing to do this is now right in NSGradient.

So that's a really boring screenshot I know. So we've set up new stuff for tracking areas. So you may remember in Tiger we've got some ways to do mouse tracking. We've set up a new model for this, and this takes some of what we do today in Tracking Rects already and then adds some new properties to it. So initWithRectOptionsOwnerUserInfo, this guy will set up a tracking area for you and you can decide whether you want a tracking area for this or not. You can decide whether you want mouse entered and exited events or mouse moved events and also cursor updates.

And those are all passed in as options. You can also specify when the tracking area is active. Only when the app is the first responder or when it's a key window, when it's in the active app or if it's always tracking. And there's some additional behavior. You can start out inside and things like that, but the really big one is this invisible rect one.

And that will take care of... So you set up some tracking areas and you scroll those tracking areas off of your view using a scroll view. It will take care of automatically disabling those tracking areas for you. And then when they come back into the visible area, we'll re-enable them automatically. So all this code that you guys have been writing goes away.

We've also added full screen mode to NSView. So if you saw one of the demos yesterday, Andres, hit a button and the thing went into total full screen mode. That's this API: enter full screen mode with options, exit full screen mode with options and whether or not the view is in the full screen mode.

And you can set up animations for this to be able to do transitions from the windowed mode into full screen mode. You can opt into it for all settings and things like that. This is a really powerful but really simple API to get that kind of effect. And we're really happy to be able to add that also.

Andres' demo, you may have seen it with the picture browser using a thing called GridView. And there is a class in the kit now for that and that's bindings compatible. It uses NSViews and the NSView has a class called GridView. And it's a core animation behavior that we've seen for core animation. And this thing can be completely wired up in interface builder.

So you'll set up a small prototype view, wire it up to your controller, hook the thing up to the GridView, and it takes care of laying these things out and filling out each of those views as it draws them. And it also takes care of layout as you expand and contract.

We made a lot of changes for uniform type identifiers in the kit. So there's new support for NSDocument, NSDocumentController, the OpenPanel and SafePanel, Workspace, Pasteboard. All of these classes now have much better support for UTIs in Leopard. And there are some other sessions about this. Unfortunately, I don't have the information, but there's a lot of information, a lot of information in the release notes on this about how to use it and how the filtering works and things like that. And we're really encouraging people to use UTIs because they work really well with Spotlight and a bunch of other technologies on our system.

So we're going to move down now into Foundation, and with all of these new machines that are coming out with all kinds of processors, it's a little more interesting to be able to find out how many are in the machine. We've added to NSProcessInfo the processor count method, and you'll see this type NSUInteger.

This is a cover type for us. It's 32 bits and 32 bits and 64 bits in 64-bit, and this allows us to be able to write the same code in both 32-bit and 64-bit. This processor count method returns the number of processors that are in the machine. So in 64-bit, we had a lot of room for lots of processors to come up eventually. How many active processors? You can turn processors on and off.

Most of our users don't do this, but sometimes it's handy to be able to test things in a uniprocessor or multiprocessor environment, and that's the active processor count. So we've put those on NSProcessInfo. But with all of these processors that are now in the machine, we do want to help you guys take the best advantage. So we're adding some new methods to NSThread.

Some methods to find the main thread. This class method for isMainThread tells you whether or not the thread you're running in is the main thread. You can get a reference to the main thread. There's an instance method now that also tells you whether the instance you have is the main thread.

And you can set the stack size of the thread now. So if you need a thread with a much bigger stack size, you're able to do that just before you touch the thread execution off. And you can also initialize the thread without starting it. So sometimes it's handy to be able to initialize these things, but not touch the operation off until later. And that's what this init and initWithTargetSelectorObject do. And those help us do some other things.

You can control thread execution now. We've added some new API to tell you whether or not a thread is executing or whether it's finished, whether it's cancelled, and then cancelStart and main here. And these are some new methods to really try and help you parallelize what you're doing. So you override main to do most of your work. And then you guys will have to maintain the isExecuting and isFinished state.

Cancel is an advisory state. So what will happen is somebody will call cancel on your NSThread instance. And then your main will check to see whether or not cancel has been called. And then you can elect whether you're going to exit by returning or throwing an exception or however you're going to get out of this particular method.

This is not the same. If you're familiar with the POSIX PthreadCancellation idea, this is not the same as that. Right? You can't cancel a Pthread out from under us and expect things to work that way. So Foundation and Cocoa don't support the POSIX PthreadCancellation model. We now have a method to execute stuff on a specific thread. So earlier we introduced perform select our main thread.

This is now perform on any thread. So if you have a thread instance, you can tell it to do something. PerformSelectorOnThreadWithObject. So now PerformSelectorOnMainThread is really just a special case of this method for us. And we've also provided a convenience. You can run a single method in a background thread. So PerformSelectorOnBackgroundWithObject, that just fires off a thread, does the selector with that object, and ends. So you can fire off a thread really easily.

This is now perform on any thread. So if you have a thread instance, you can tell it to do something. PerformSelectorOnThreadWithObject. So now PerformSelectorOnMainThread is really just a special case of this method for us. And we've also provided a convenience. You can run a single method in a background thread. So PerformSelectorOnBackgroundWithObject, that just fires off a thread, does the selector with that object, and ends. So you can fire off a thread really easily.

And this operation talked about dependencies. So I'm going to talk about dependencies a little bit. You can add an operation as a dependency of another operation or remove it. You can find out what the dependencies are. There's some other state you can find out about whether or not it's ready.

An operation is ready if all of its dependencies have fired off and are done. And operations can have priorities. So you can set the priority on a particular operation. And then when you put it into an operation queue, the queue is going to take care of managing all those things automatically.

Right? So the NSOperationQueue is pretty simple. You just add an operation to it. And then it takes care of when it's got time, it's going to go off and fire off-- it might fire off a thread, it might not. It's going to just take care of executing all the operations that you put in it in priority order automatically.

So you can also cancel all the operations, hang around until the operations are finished, and change the concurrent operation count. So we try to pick a sane default based on what the machine configuration looks like. But if you discover through your own profiling that you need to change that, this is the API you'd use. So this gives you an easy way to be able to encapsulate all that threading stuff and really take advantage of the extra processors that are now in our machines.

Here is a multi-threading in Cocoa talk. So if you'd like to learn more about this, there will be some demos and more explanation about what's going on here tomorrow at 5:00 PM. So that'll be a good one to go to if you're having a lot of threading things going on in your application. We've added NS condition.

Well, sort of added. This is a Pthread style condition variable. So NSConditionLock has the test directly in the condition lock. This actually moves it outside the object. So you'll typically take the lock, hang around while the test is true, and then do your work and signal when you're done and unlock it. And this actually shows up in the headers in Leopard, but it's been around since 10.0. So you'll be able to use this in Tiger if you need to.

You'll notice that there have been a bunch of Objective-C changes, and you heard about properties and some other things, and we'll talk a little bit about those here, but some of the big hitters are the at-defs directive has been deprecated, so you won't be able to use at-defs to be able to get it to embed structure information right into your code. You'll have to interrogate that with the API.

PoseAs has been deprecated. The Objective-C runtime has provided some new API to do the kinds of things that people were doing with PoseAs, so this will not be available as a supported mechanism much longer. There's new garbage collection stuff. We'll talk a little bit about some of the garbage collection things that we've done in Foundation, and some new language features and runtime API. There are two Objective-C talks, one in Marina at 3.30 and then at 5 today, so if you'd like to learn more about that, please do.

Here's what we've been doing in Foundation and Cocoa, though. We've made a lot of additional enhancements for garbage collection in Cocoa, so if you'd like to try it out, you can just turn it on with -f object CGC, or you can just check the box in Xcode, right? So you'll be able to run your app's garbage collected on Leopard to try it out.

There is a class now called NSGarbageCollector, and if you need more information about what the collector is doing or being able to turn things on and off in your app while it's running, you can go here. So, let's go ahead and run it. So, this class method defaultCollector will return nil if you're not running garbage collected, and it will return a default instance of the collector if you are.

And you can turn collecting on and off, find out if it's actually running, you can collect if needed. You can also disable the collector on a per-pointer basis, so if you know you're getting - if you have particular semantics that you need to fake the collector out, you can do it with this API.

[Transcript missing]

You saw about properties, right? So here's a person object that's been declared with a number of different properties, a birthday, a first name, a last name, and a full name. This first property is by ref, so that's actually holding the direct pointer reference. If you call the setter, it will just replace the pointer directly. The second one here is a by copy. These are actually copied in and out, so the accessors that are synthesized will depend on what keyword you put there in that second slot there.

And this read-only property is one that really has no Ivar. It's sort of, it's set up, you would just return the concatenation of first name and last name, for instance. These are all strongly typed, and you can also specify your own getters and setters right here in the declaration so that if what the runtime is doing doesn't fit your needs or if you're retrofitting this into existing code, you can specify those. Those will get called automatically.

Enumeration, we've made some changes for enumeration, and one of the things that you saw was this one here, we have an array with an object enumerator, and we're doing something with it, and this all condenses down to this. So for item in some array. This actually is much faster, it turns out, and your objects can participate in this.

It doesn't just have to be Foundation built-in collections that do this. If you go ahead and look at nsinumerator.h, you'll see this protocol, NSFastEnumeration. This count by enumerating with state objects count allows you to be able to fill in the enumeration state. The Objective-C enumeration behavior will kick in, and this reduces enumeration overhead significantly.

So before, while we were calling next object, or behind the scenes, you were calling object at index. This gets us down to less than one method call per object. So if you've been seeing in your code where your enumeration is taking some time, and you're spending a lot of time on object-c message send, this can get you out of it. It turns out this is much, much faster. So if you have a Tiger machine around, you might want to compare it. It might be a little fun.

Now that we have four-way universal binaries and a bunch of different architectures to have to code for, we've added some code to NSBundle to be able to get some more information about what's happening. So you can pre-flight a bundle, and this means that the bundle machinery is going to go and look at that bundle and do everything right up until linking that bundle into your executable, and tell you whether or not something looks like it's able to be loaded or not. And this is pre-flight and return error, returns an NSError by reference.

And the same thing for loading a bundle, except that'll actually go ahead and load it. You can get better errors back now. So you might have a PowerPC application, and somebody's written an i3d6 plugin for your app, and you won't be able to load that in, right? So you want to be able to put a meaningful error in front of your user that says, oh, you know, I can't load this because it's not the right type for this computer. You should get a new version of the plugin or something like that. And those errors are all in foundationerrors.h. And, you know, not loadable. Architecture mismatch, that kind of thing.

So these are a good way to be able to get good errors in front of your users for bundle situations. What architectures are in a bundle? This just returns an NSArray. Executable architectures returns an NSArray. And we've predefined some NSNumbers here for the different architecture types. So you can find out what's actually in that bundle without having to go through and use the DL open APIs and things like that and try to walk the Mach headers. We'll just do all that work for you.

There are some new changes to NSPredicate. The contains in between predicate operators are new ways to do comparisons in your predicates. And there's also an optimization for evaluating a predicate multiple times. So if you have a single predicate that you keep evaluating with a bunch of different variable substitutions, you do multiple different things, you can use this method evaluate with object substitution variables, and that's going to take care of caching everything it can to make your predicate evaluation much faster.

Chris Parker, Doug Davidson NSExpression also, new expression types. There's a subquery expression, which allows you to not have to multiply evaluate an expression in order to get an answer. The aggregate expression type, unions, intersections, minus. These all let Core Data generate lots better SQL. So if you can adopt some of these, you may actually get better performance out of your Core Data app.

And there's also one for using your own functions for predicate evaluation. So you provide a function to the NSFunction expression type, and you can actually do that. You can actually set up your own function for it to return yes or no for the predicate stuff. So that allows you some flexibility in We've made some changes to copy behavior in collections. In Tiger, immutable collections performed a deep copy. We got some bugs on this and people noticed it.

It's a problem because items in a collection may not conform to the NS copying protocol. So what happens? You try to copy one of these things and an exception gets thrown and nuts, now you're out of luck. In Leopard, all the immutable collections now shallow copy by default. So this is a little more performant and, oh, you filed that bug.

We've put in a link check, and we do this a lot. We've put in a link check for Tiger applications to get Tiger behavior, so we're not going to surprise any of your apps that are running on Leopard that were compiled on Tiger, hopefully. But we do want to make sure that this gets noticed because it may change some things. If you were relying on code like this to get a deep copy, that's not going to happen anymore, unfortunately.

NSArray deep copy, some array copy with zone null, now is going to do a shallow copy when you relink your code on Leopard. There's an easy way to fix this, though. If you call init with array copy items yes, that works on both Tiger and Leopard the same way. So this is a drop-in replacement for that if you were expecting deep copy behavior.

So that's the collections copy behavior stuff. We've also made some changes for enumeration. So for id item in some mutable array, using the new for loop syntax, we go through and find out if some item is equal to another item, and then we remove it from some mutable array.

So we're enumerating the same mutable collection that we're removing things from. We're mutating and enumerating the same collection. I was going to have Malcolm read this because apparently he wrote this line, but it's not safe to modify a mutable collection while enumerating through it. Some enumerators may currently allow enumeration of collections modified, but this behavior is not guaranteed to be supported in the future.

Future is now. For code linked on Leopard, this will throw an exception. Part of the fast enumeration stuff that we did allows us to be able to detect this condition. So this actually helped us find some relatively tricky bugs. So they may be running around in your code as well. If you relink your code on Leopard and you're doing this, it will throw. So this is much safer now. And if your objects are participating in the fast enumeration stuff, it is vitally important that they don't do any modifications themselves either.

The way to fix this, fortunately, it's simple. Array copy. Just make a copy of the mutable array, enumerate that, and then modify the original. Pretty easy to get out of. Sometimes you do this and you find that some other code was jumping off and then coming back and modifying the original. So it may not be quite as obvious as this, but it works out to be pretty easy to chase down. There are a number of other frameworks that have Objective-C APIs, and they work very well with Cocoa.

Core animation you heard about. This is what's being used to produce all those nice cinematic experiences that Peter's talking about in his graphics in the State of the Union address. It's part of Quartz Core, so if you're already linking Quartz Core, you've got this available to you already. And this is the underlying machinery for NSVU animation.

So just like Cortex, if you need to drop down to that because you have really specialized needs, you can drop down to Core animation, but hopefully you won't have to. Hopefully we've done all of the heavy lifting for you for NSVUs. And this takes care of all the hardware and things like that and handles text and timings, but we do all that too.

ImageKit now is a sub-framework of Quartz, and that actually includes the image browsing and choosing stuff, and image filtering and image filter choosing. So the effects that you see in things like PhotoBooth where it displays a bunch of images and it applies each filter and sequence, that's what this API does. And this also provides support for things like slideshows and image editing. So this will do some very basic image editing right in your The new publish and subscribe framework is a new public framework in Leopard, and this is a high-level RSS abstraction.

This is the stuff that Safari and Mail are using to do their parsing. And publication over the local network, and you can subscribe to things, and this will take care of making sure you know when things are updated and stuff like that. There's also a new Calendar Store API. So if you've been dying to get access to iCal's calendar information, they're providing it now in Leopard.

And this provides access to all the account appointments and to-dos and things like that, and attendees for meetings that's tied in with your address book. Different kinds of events, one-shot events, recurring events, alarms, all that stuff. So you can get direct access to that information from Calendar Store.

Core Data has been doing a lot of work on this. Chris Parker, Doug Davidson They've done a lot of work in the last year, and they've introduced APIs to do schema evolution. So as your data set changes... Hopefully you've specified enough information, but it will automatically migrate those files over. A new Atomic Store API, you'll be able to write your own Atomic Stores for Core Data to use.

So if you have your custom format, you want to use HTML to store your stuff, whatever it is, as long as you can read it in and write it out in a single thing, new Atomic Store API. New Predicates and Expressions, we talked about those a little earlier. Some improved fetching options and better performance.

If you want to hear more about these, there are three Core Data sessions, and it looks like they're all right here. Today at 5, tomorrow at 9, and tomorrow at 2. So if you're doing a Core Data app, you should probably come to that also. You also saw some of the new things in Interface Builder 3 during the demo. The new document view has been improved. There's that new inspector window with the library, the connections heads-up display, and a new plugin API.

And the big hitter, I think, if you write your own controls and things like that, it's much easier to write plugins now that participate in Interface Builder and just drag them in and out and set up your own palettes and things like that right in IB. So two IB sessions, Integrating Custom Views with Interface Builder. That's in the Marina, Friday at 9, and Interface Builder Techniques, Wednesday at 5. So if you are interested in writing your own controls and having to participate in Interface Builder, here's the talk to go to. We have a lot more information.

Sit up here and talk all week. God, I hope not. Derek Horn is our Application Frameworks Evangelist. You can reach him at Derek at Apple.com. There's a lot of documentation and sample code, things like that, other resources. Our release notes, obviously, on the DVD. And we will be in the AppKit Lab Thursday at 2. That's downstairs. I think it's on that side of the building. And to answer questions, if you bring your code by, we can take a look at that. work through stuff.