Good afternoon. Welcome to Cocoa Today.

My name is Ali Ozer, I'm the manager of the Cocoa Frameworks Team at Apple. So today we have a pretty packed agenda. The bulk of the talk is about what's new in Leopard, and the highlights of what we've added to Leopard.

Before but that I am just going spend a few minutes talking about what Cocoa is. Especially for those of you who are new to the platform or new to Cocoa. And then at the end we're going to spend a few minutes talking about best practices in creating your Leopard application.

So what is Cocoa? Cocoa is the term we use for the object-oriented frameworks for developing fuel featured applications on Mac OS X. And when we say Cocoa, we often refer to the three-core Cocoa frameworks, Foundation Kit, which is the non UI layer of Cocoa. Core Data, which is the data model and persistency layer, and AppKit, which is the UI layer of Cocoa.

Now Cocoa sits in the system next to Carbon and Java, which are the application frameworks. Above this, of course, are applications, and below this layer are Darwin, and of course the graphics layer. Quartz, OpenGL, Core Animation, and QuickTime, and so on. Now this is -- if there is one thing that embodies a philosophy of Cocoa, it is this; imple things simple, complex things possible. If you've been to WWDC before you've probably heard this.

You might have read it places. But this is basically how we design Cocoa. Try to make simple, obvious things that all applications have to do simple, but also enable things, complex things that you want to do in your applications. And we're going to go and give examples of this throughout the talk today.

Now one thing this doesn't mean is that Cocoa is simple. What do I mean by that? Cocoa is not something you're going to learn from a quick reference card. You know, sometimes people think oh, I'll go to WWDC and afterwards I'll write applications that evening or something. And that's definitely not the case. With Cocoa, there are a number of things to learn. You're going to learn the APIs, the program interfaces, the conventions, the best practices, and Objective-C. And I am actually going to talk about these at various points during the talk today.

But once you learn Cocoa, once you've, you know, learned all these things I showed you, you're actually enabled to do much more, be much more productive with much less code and effort. With Cocoa, the philosophy is we write the common code, you write the things that distinguish your app. And of course the less code you write, the less code you have to debug, the less code you have to maintain, and more of your functionality your leveraging.

Now, sometimes people see demos of Cocoa, you know, somebody gets on stage, puts together a calculator app or a temperature converter app, or a recipe app -- and you know, the app is nice and simple, and looks great. And doesn't require any code. And you know, folks get the impression Cocoa is great. But it's for simple applications.

And that's not quite true. There are many, many applications out there, many powerful and sophisticated applications. Some of these are from Apple. And many of those are from third parties like yourselves. And there are literally hundreds of applications out there. And the good news about these apps, you know, many of these apps, is that they are not only powerful and sophisticated, they're a joy to use.

Many of these are applications, you just want to, you know, bring up and do things in. And you want to get your friends and family to use them. And there's, you know , they're not only consistent, UI powerful, and also a lot of attention to detail. In fact, let me -- let me show an example of that.

Here's the icon for Coda, from Panic. An application that was released two months ago. And I was looking at this icon -- yeah. It's a great app. It's a bug development app. I was looking at this and I noticed that they actually have a 5, 12 by 5 icon in their app wrapper. And this is what we've been telling people to do as a forward-looking move for resolution independence.

And I was looking at this, I was looking at it a little bit more, and I noticed in the stem -- I don't know if you can see that. Let me zoom just a little more. There are those little hairs on the stem. And those are called try cones, I think. If I'm pronouncing it correctly. But there's so much detail in here. And this is just so today, on the screen.

You know, you can see that. But some day in your super-high resolution display you'll be able to count the hairs on that leaf. So that's great attention to detail there. Okay. So let me spend a few minutes talking about what makes Cocoa powerful. Well, as I mentioned, it's object-oriented classes. And it's just -- not just any object-oriented classes, but well-designed object-oriented classes.

And there's a growing set of powerful libraries. I already mentioned AppKit, Core Data, and Foundation as the core of Cocoa. But there's a number of other frameworks that are on the system and that let you access the back-ends of the applications we ship, such as Address Book, iChat, Calendar Store, and of course this graphics capabilities, the input methods Disc Recording and so on. There's a lot of frameworks on the system that are -- plugged into Cocoa well, and that you can use in your applications. And these use Cocoa conventions, which are all very consistent. I am going to talk about this right now.

When I say consistent conventions, I mean that all these APIs that are Cocoa compatible use the same nuts and bolts. The common currency of Cocoa applications is NS strings. For instance, if you have character strings you're communicating between layers, it's almost always an NS string. It's not a (Inaudible) or anything else. It's an NS string. Similarly, NS arrays, NS datas, NS URL, NS View. These are the common currencies. So we can take these APIs and plug them into each other very easily.

And there's a small number of mechanisms and conventions. Here I've listed, you know, five bullet points worth of them. And once you learn these you pretty much become familiar with 90-95 percent of the paradigms used in Cocoa APIs. You know, when you approach a new Cocoa API you will see, oh, this uses delegation. That's great. Oh, and this is KVO compliant. That's great.

And object ownership memory management rules, the last one on that list, as an example. We've had these rules for ever since Cocoa's been around. And as we move into the world of Garbage Collection, it turns out the rules are totally consistent with garbage collection. So there's no change there. And if anything, of course, memory management rules get simpler. So again, you learn this small number of mechanisms, conventions, and you are familiar with a lot of Cocoa APIs.

Objective-C is a super-set of C. It's native, and C compatible calling conventions. What this means is the way arguments are placed on the stack under different architectures and et cetera, is the same for C and Objective-C. And this, of course, means you can cross-call into C back and forth no problems. There's great C++ integration, even better in Leopard. And Objective-C is also very dynamic. It's got this great runtime system which can introspect. You can ask questions about methods, classes, et cetera, and using that dynamic functionality, it's a bridge to other languages like Ruby and Python.

Cocoa is not an isolated box. It's not -- all this power doesn't come at the price of having an environment which is self-contained and can't interact with other pieces. Since it uses C calling conventions, it can easily call into APIs such as POSIX. You can download pretty much any open source package from any open source UNIX package and integrate it into your Cocoa application no problem. And it also interacts with Carbon.

Before Leopard, the interaction was at the lower levels, and also at the window layer. And in Leopard we now have an HI Cocoa view type, in HI Toolbox, which let's you incorporate Cocoa views into Carbon applications. I am not going to talk much more about this, but there is a session Thursday afternoon, Session 145 where you can hear the HI Toolbox team talk about this new technology.

Cocoa is native Mac OS X. Cocoa is not a cross-platform environment that's been ported to Mac OS X, and that repeatedly has to be ported over and over to keep pace with Mac OS X. Cocoa and Mac OS X are very well integrated. And as a result Cocoa provides native -- you know, absolute, great support for Mac OS X features, such as Aqua, accessibility, printing, all these features are defined by Cocoa for the environment, basically.

And finally, what makes Cocoa powerful are the tools. As you heard yesterday, there's a new version of Interface Builder, IB 3. Now interface builder is the user interface design tool, but it's much more than just a user interface design tool. It not only let's you lay out windows views controls, it also let's you create the relationships between these -- object relationships between them.

It lets you save these out, archive these out, to files which are read back at the runtime. So those objects are brought back to life. And this is very powerful. You can create a lot of your -- the logic -- that would normally have required glue code in IB visually by connecting these objects together.

It's a very integral part of Cocoa application development. Sometimes people ask how can I create my UI without using IB. And you know, that's possible. It's totally possible to write dozens or hundreds of lines of code to sort of establish all that. But you know, you really wouldn't want to. It's just -- IB is a great time-safer, and it's an integral part of the development environment.

Xcode is, of course, the IDE. The development environment. It not only does project management, it has features such as syntax coloring, code folding, refactoring, data modelling and so on. And also the Compiler and the debug tools. An important point here is that all of these features are Objective-C enabled. So when you're looking at your Cocoa program, when you're looking for your Objective-C program you're actually doing this in terms much Objective-C methods, Objective-C back traces, Objective-C objects.

And in the tools area we have extra -- Xray now. Which is sort of the new uber-tool for all our new performance tools. Xray allows you to look at a bunch of performance -- let's you do performance measurements simultaneously on your application. Again, all of these measurements it does, it does it in a way which is Objective-C compatible. It knows about Objective-C.

So again, when you see reports about what's going on, what objects are being allocated, it's all in terms of Objective-C objects and back traces, and methods it applies to your program. Okay. So with that little background to Cocoa, I am now going to talk about what's new in Leopard.

Now if you were here last year, you already heard a lot of stuff we covered at a lot of stuff that we added to Leopard already. But since then we've added a lot of new stuff. Now a lot of this stuff is in the Release Notes. And a bunch of it's also been documented.

Today we're sort of going to be unfair. We're only going could cover some of the highlights and some of the exemplary items, you know. We're not going to go into detail about everything we've added into Leopard because there is just way too much. But we will cover the highlights.

So we're going to do it in five areas. The first one is definitely where the bulk is. We're going to talk about UI followed by the other areas of Cocoa. So yesterday you heard about this from both Steve's talk and also Scott Forstall's talk in State of the Union. We have a new window up here. And so basically there's one look and feel for title and tool bars.

And there's no more metal. Now we used to have this textured background style. Which indicated that a window should be metal. It now simply indicates whether the title tool bar gradient continues down the window. So the way the gradient continues is there is a light to -- sort of a darker gradient at the top. Then there is a solid body, which will grow.

And then in addition there is another gradient from that solid color to a darker color at the bottom. So this is what you get if you use textured windows. There's content in that window, those gradients will be adjusted. And there are ways to tweak that. I am not going to talk more about textures windows, because in general we want you to use non-textured windows. But this is just to show you how a textured window behaves.

Now examples of non textured windows, for instance, your common text document window is an example of a non textured window. Another example is preferences and preview. There's a solid color in the background of non textured windows that you can place Aqua controls on. And here's another example of a non textured window. The Font Book application. Now at this point, though, you might be saying, hey, there's a gradient border at the bottom. Doesn't this make this is a textured window? And the answer is no.

This is a lighter gradient -- in fact this gradient is sort of similar to the gradient at the top. We put a lighter grade in at the bottom as a way to enable black text to be easily visible on that area. So you would use this gradient if you want to put controls or text as a -- sort of an alternate bottom bar.

Analogous to the tool bar on your window. So how do you enable this? There's an API which let's you set the content border thickness for an edge. For non textured windows, the only edge that is valid for today is the bottom edge. So we would go ahead and specify this.

And when you do that, that's where you, you know, this is the bottom content border you would be specifying. And then you would go in and put your custom controls in there. Now the other kind of window style is this HUD, that's Heads Up Display windows. Scott also went into this yesterday. They can be borderless. Or they can be titled. And they are, of course, partially transparent.

Now heads up display windows are not the general replacement for panels. You shouldn't be replacing every panel in your application with a Heads Up Display. You would use them where the transparency is useful. For instance, full screen applications. And they are mostly for transient usages. Like non modal panel, non -- such as the font panel, color panel, the user might bring up and leave it up there for a while. But if they just want to bring up something, tweak it, and dismiss it, maybe a HUD window is appropriate.

And it's also a convenient alternate access to existing functionality. An example here is Xray. Yeah, Xray has a big window where you have all your controls. But if you minimize your Xray window, it turns into a HUD window that's on top of whatever you're trying to -- whatever you're trying to measure.

So here's what a HUD window looks like in preview screen mode. It's giving you slideshow capabilities. And here's another example. The HUD windows in iPhoto. Now you will see three HUD windows at the top. And then there's one more HUD window at the bottom. I hope you can see this all the way at the bottom. But one thing to note about this HUD window is that there is a pop up and a slider in this HUD window.

Now, these are HUD -- what we call HUD style controls. And we don't yet have support for this in the AppKit in Leopard. As you will notice, the other HUD windows in here don't use controls, they basically just use text items or images, whatever. These are all things that can be easily done. But if you wish to put controls like this in your HUD windows, you're sort of on your own. And either you can put Aqua controls or maybe avoid those controls in HUD windows all together.

So resolution dependence. If I were to put up one picture to define resolution dependence, it would be this. Basically goes to show ability to draw standard controls and other drawing at -- in the resolution-dependent matter. In this case they're being drawn at 8x. And we have now enabled this resolution-dependent drawing so that the same resolution drawing code path is used for 1x, 2x, whatever you've chosen. So this is the way things would look like before in 8x, and this is the way they look after. So before; after. So there is -- there is a difference there.

Now here's a little fun fact for you. Don't tell anyone. But I am just going -- just between us. If you hold down Command Control Option 3, your front-most app will switch back and forth to using resolution dependence drawing and non resolution dependence drawing. This little debugging aid we added in there.

And you can actually see some sort of a difference even at 1x, between the resolution dependent and the non resolution dependent drawing. So you can play with this right now. Show you the debugging aid to see how it might be effecting your applications, if at all. It's something we intend to remove for the final release. Assuming we don't forget.

They have a size, a conical size they have, that they use. But if you wish to draw them at any other size, they will accommodate you and look pretty, like this. Now the way you access these images is with the API we had for years. NS Image image named. You would say NS Image image named. Network. Now, a word of warning here. You look at this beautiful network image and you might be tempted. For instance, you might say I'm writing a fantasy game and I really need a gray, magical orb.

The network image looks great. So you would say, my gray magic orb is now the network image. The word of warning is this. In the next release we might decide to represent network, we're going to start using, say, a coaxial cable. So suddenly your wizards in the fancy game are walking around with a bag of coaxial cables, which is not quite what you wanted.

So this is a no-no. Typically when you're using these images, please use them, you know, just look at the name, see what the name defines, look at the documentation and use them just for that purpose. Don't misuse them, otherwise you might be surprised in the next release. The intent here is these images are there to give you a common look and feel across all applications.

Now another set of resolution and NS Images are these template images, and you can recognize these because they have the word template at the end of the name. Now these are monochromatic by default. I believe they are gray if you try to draw them as is. However, the intent here is that you would put them -- these in NS cells, and then you would set the background style, or you would put them in standard cells like button cells, and the right thing would happen.

For instance. If you add template image into a gradient button, this is the way it looks. It actually has a little bit of embossing in there. I don't know if you can see it. So depending on the context, these images about be processed by NS Cell, and appear in an appropriate map. And you can go ahead and use a cell, a pretty vanilla cell, to draw these in your own contexts if you wish. Now here's one more thing to notice.

The last two images to go right and right-facing triangle are the same. Here we wanted -- you know, the temptation here might be too great. Because let's say you need a right-facing triangle. If we don't provide that, you might have used the go right image to do that. Again, to remove the temptation of using the go right image in place of triangle, we're providing both. Currently, they have to be the same image.

But in the next release, if the go right image changes to -- for instance a sign post or a finger pointing right, the triangle will not change. So use the appropriate one. There are two talks which will go into more -- which will give you a lot of information on drawing and images and cells. And those are tomorrow morning at 9, the customs controls for Cocoa talk. And then at 10:30, the Cocoa drawing techniques talk.

Accessory views and alerts. This is something that you've asked for a lot. And we finally have it in Leopard. Basically, alerts are simple to use. You just -- one line and then you can put up an alert panel, with, you know, cancel, install, okay, whatever your buttons are. But if you want to customize it, it was fairly difficult to do before.

Now we have a way to do that and as you might except, the API parallels the other API in panels to do this. Set accessory view accessory. That's it. You create your own custom view in IB, you know, IB is the usual way to do it. And then you would give it to the alert panel and bingo, you get your accessory panel. Now, one common usage of this is the check box. So refreshen check box. Do not show me this again.

And we make this even simpler by providing this API, set show expression button. If you say yes to this, you automatically get a check box with that default text on there. And if you wish, you can ask for the suppression button, which is the check box, and changes title or initial state. And of course when the panel is dismissed, ask for the current state. Now again, a word of warning from before.

This is meant for a suppression check box. And in the future we might change the way it looks, the way it behaves. Maybe it's not even going to be a check box any more. Do not use this for any purposes other than a check box. If you use a check box which is not a suppression check box, just go ahead and add your own accessory view.

dock tile. In Leopard we now have this new class that enables the customized drawing into the dockk. So let me bring up a dock. Oh, wait, first of all. This is how you get an instance of dock tile. You could -- you would ask the application object for its dock tile object. Similarly, you can do the same thing for a window. So let me bring up a dock now. So here's your dock. An example of this is here. The -- the little badge on the Mail icon indicating that you have seven unread messages.

The API said badge label. You just pass this string. Preferably a small string. Enables you to put that string right into that little red star there. And this is something Mail uses, iChat uses, and something your application can use as well to indicate there's some pending activity that you need to look at. Another kind of customization is this icon here.

Now these are mini windows, minimized windows. And they're typically badged with the application icon that they belong to. But if for some reason you do not want that application icon on there because you're doing some other custom drawing, you can disable that by calling set show application badge. Default is yes. So you would say no.

And the final customization is perhaps the most interesting. For instance, iCal is showing the current date. Xcode is showing progress of the build. Activity viewers is showing the CPU usage. And finally on your GPS-enabled Powerbook or MacBook Pro, Safari's showing where north is. Actually that -- yes, we didn't release that yet.

But anyway --

Split view customizations. You know, split view is a class that doesn't get much respect. But if you look in your apps they're everywhere. They are a lot of split views. And then in recent releases, you know, in Leopard, there are actually many, many kinds of split views appearing in applications. Not just the standard bar with a dimple in it.

For instance, in Mail this area here is a 1-pixel wide split view. However, since the user cannot click on a 1-pixel wide area, the cursor changes as the user gets near it. So this is an example of a new kind of split bar. And now we're enabling this with the set divider style API. You can specify thin as a way to get this new thinner look. And the default is thick.

You can also get the color of this divider. The color depends on what kind of divider bar you've set. Or you can override this to change the color if you wish. And one other way to customize things is to change the effective area. For instance, if you decide you want your cursor to change, to split to be effective, some pixels on this side but not on this side you can change direct where it's effected. Now one other customization that you can see here is the ability to put little dragging areas in addition to the splitter bar.

I don't know if you can see it at the bottom there. The Mail window. And this is done by another delegate method, which let's you specify the additional effect of dragging area. And you just, you know, return a rectangle here. And then you go ahead and put your custom control or your standard button in there to do that, the dragging.

One other split view feature is auto saving. If you're familiar with auto saving feature in NS window, it saves the -- well, one person likes it. Thank you. So it lets you save the window's position automatically to user defaults. Then you can now do this with the exact same API. Set, auto, save name.

And split -- the split view will save the positions of bars and also whether they are collapsed or not out in the defaults. And this is also not only accessible through the simple API, but in Interface Builder in the split view inspector you can go ahead and just type in the name you wish. Very, very simple to use.

Menu item. Now this is something we talked about last time. But it's such a great little feature, I definitely wanted to talk about it now as well. It let's you customize menu item drawing. And not let's you customize it. It let's you handle events. This includes mouse and keyboard events. And can also animate.

So here's an example where we put sliders into a menu. You know, not that this is a great UI here, but this is something you can do. The API is again extremely simple. You just add a view. You set the view that corresponds to the mean you item and Cocoa does the rest for you. And of course those views could have controls, target action, bindings, whatever you want. All the power of Cocoa is available to you in that view.

Collection view. This is a new class. It had made an appearance at the last WWDC. It was known then as Grid View, but it went -- underwent a name change. Collection View is simply described as NS matrix per views. For those of you who are familiar with NS Matrix, it's basically our collection, our UI class that shows grid of cells. But now we can do this for views. And Collection View is actually a lot more powerful. I'm going -- I'll explain that now.

An example of Collection View is in Interface Builder. The library in interface builder is actually the collection view. So as objects are deleted, removed, sorted, et cetera, these things animate and that's some of the features that Collection View provides. Another great feature of Collection View is that it's fully driven via bindings. It can be fully competent Interface Builder with zero lines of code. Now let me explain the architecture of collection view a bit. Just to short of make this a little bit more concrete.

Here we have a collection view. Typically, the contents for a collection view comes from -- comes by binding the content to an array controller. Or you can actually assign an array to this content. So anyway, you bind it to an array controller. The content comes from there. Then there is a prototype.

A collection view item class -- that's your item prototype -- and that in turn points to a view. You design the view in Interface Builder. This is the view that's going to appear in the collection view. Now when that view object is added, the item and the view are automatically replicated.

So let me show you that. We're going to add a new object array to the array controller. This causes a new collection item to be created. It's represented object points to the newly added object. And the view is replicated and added to the collection view. Now let's add in that second object, and the same thing happens. A second view appears. And the third one will do the same thing.

Now one final piece of this puzzle is that the values in the UI elements in the view -- so these guys up here -- the values in here -- shows there can be arbitrary views in here. Text fields, sliders, whatever. These are bound to the corresponding items represented object. Now of course represented objects are here. So this is all automatic. Just by specifying these connections in interface builder this collection view will respond to addition, removal of objects. And if you change the sorting in the array controller the collection view will respond and so on.

Now -- talking about animation, let's talk about animation support we've added to Cocoa. You've seen this yesterday. There's great animation capabilities in Leopard. And we bring this to NS Views and NS Windows, and in fact any Cocoa object in general if you wish to add it. The way this works is that to animate a property, let's take a view as an example -- to animate a property in NS View instead of just setting the value of that property in the view, you talk to the view's animator to set the same property.

Now the view's animator is a proxy. It acts like the view for most purposes, but if you tell it to set the value of an animatable property, it will animate that property. So if you set the frame in the Animator, the view will actually animate from its old location to the new location. And size. Now there's a reasonable set of default settings. Most of the time you don't even have to change these default settings. You can just go ahead with this and, you know, reasonable animations will occur. So that's -- that's simple as it can get.

Now so far one thing I haven't talked about is Core Animation. Because it turns out that this feature in view can work without Core Animation. However, for sophisticated animations, highly performing animations, you will probably want to enable Core Animation. And you do that by turning on layer backing for views. In the API for that is settle once layer. So you tell a view set wants layer yes. This enables layer backing for that view and all its sub views. This is also possible to do in Interface Builder.

We are checking this wants layer box in the Inspector. Now what this does, it turns on layer backing as I mentioned. It enables per view alpha, shadow, and also filters. What this means is you get fancy visual effects and high performance animation. So if you have large areas animating, many objects animating, and the standard animation view doesn't do it for you, definitely enable Core Animation-based animations. And this also enables additional features such as hosting of Cocoa controls and NS OpenGL views.

Before, if you wanted to put a button on top of an OpenGL view you would have to create a child window and so on and manage that. And that was definitely in the realm of complex is possible. Well now it's simple things simple. You just put those things on top of OpenGL view.

Now the session in this room after me is Cocoa Animation. Building Animated Cocoa User Interfaces. And James Dempsey will be talking to you about -- more about these features. And just one more thing, again, between all of us here, I think I saw a guitar back stage. So for those of you who know James --

View Controller is a new class. It's basically NS Window Controller for views. Now it turns out nobody really asked for this class.

However, whenever we look at your sample code or we looked at various code people have been writing, it was clear that people needed this class. Because people would use a windows controller to control views. And that's sort of an abuse of NS Window Controller. It's useful for plug-in architectures where dynamic sets of views are, you know, are being swapped in and out and so on.

It's also useful it turns out for incorporating Cocoa views into Carbon windows. In conjunction with that HI Cocoa as I mentioned. You basically create your view hierarchy, have it controlled by NS View Controller, and put that into your HI Cocoa view. And there is a sample for this that you can download from your attendee site.

Now, just like an NS Window Controller, a View Controller manages top level objects. And it also confronts the NS Cell through informal protocol. Which means if a user types in the text field and closes the window without hitting tab or return, it will manage the discarding or committing of that value, for instance. And these are the highlights of the methods in View Controller. There's a represented object, you can set and get that. There's a title. It turns out many of the context for View Controllers are used. The title is useful. And then there's finally the view that's being controlled.

The -- you can either -- this normally comes from IB. But you can also override this to change the view that is being controlled. Now this view control discussion might be a little abstract for some of you, you know, maybe hard to visualize what this is useful for. So let me give a concrete example.

The Print Panel, the Print Dialogue, it used to have -- it has a set accessory view where you can customize the behavior of adding your accessory view. In Leopard we've now enabled customizing it further by adding this method, Add Accessory Controller. And this can be called multiple times to add multiple accessory views. And the argument here is a View Controller.

You sub class View Controller and you supply it here. We've also provided this protocol, Print Panel Accessorizing to tell you what methods you need to implement on top of anything else you might need. Here's what that protocol looks like. It's got two methods. One of them is required and one of them is optional. I'll talk about optional methods shortly.

But basically you implement a sub class of View Controller and implement the required method, and optionally, the other method and then you're good to go. And then the thing here is that the represented object of each controller is settle to the NS Print info object. Print info object is the object that maintains the print settings so it's a reasonable represented object and it lets your accessory views basically change the settings in there. Now let me give an example of this to make it even more concrete.

Now you might know of TextEdit. TextEdit is the word processor, the simple word processor that was shipped with Mac OS X. And the sources are available, by the way, on your systems if you want to look at this later. Here's what the Print Panel for TextEdit looks like. Now one major feature here is the inclusion of the print preview, which is pretty much automatic for Cocoa applications under -- under some sort of consensus. But there you go. It's the print -- it's a live preview of the document that's being printed.

Now, let's put that aside. Because I want to talk about the accessory view. TextEdit adds this one sample accessory view that just has this one check box. Print header and footer. And when the user checks that check box what happens is the headers and footers appear in the corners of the page. And this happens live. And that's what that API I just showed you -- the Print Panel accessory thing -- tries to enable.

So here is what the sub class of View Controller would look like. There are two methods. Set page numbering, and page numbering. No need to look at the code here. The point is that these are KVC compliant. In addition, we implement that method in protocol key paths for values effecting preview. And return to key page numbers. So what this means is that when the page numbering -- the value for page numbering, the preview is automatically displayed. So that's what this enables.

Okay. Speaking of TextEdit, now we should talk about text system features. And there are a number of great features in the text system in Leopard. Non contiguous layout. This enables multimegabyte documents to be opened by the Cocoa text system much faster and much more efficiently. It's doing a much better job now with huge documents. We now support new document formats. The Open document format, and the Microsoft Office Open XML Format.

And these can be both read and written. In addition, there's grammar checking, smart quotes, link detection, and a number of other features. Now some of these features are reflected in Interface Builder Inspector. You can actually enable, for instance, automatic quote substitution where, you know, non-fancy quotes convert to fancy quotes. But if you're in the context of Xcode, for instance, that's something you might want to disable.

Otherwise the compiler wouldn't be happy with you. I am not going to talk more about the text system features, but there is a talk, Customizing the Cocoa Text System, tomorrow afternoon where Doug Davidson and Aki Inoue will talk about these features, and also in general how to customize the text system. Okay. Now that was the big UI part of our talk. Now let's get to Core Data. What new in Core Data.

So persistent store API. This enables your -- you to have -- you to use custom stores in your applications. There's an abstract base class, NS persistent store, but typically you would sub class its somewhat abstract class, NS atomic store. And there are five methods you need to override, and here they are.

So by doing this you can have your own file formats. And there is an example you can download. I believe it's called HTML store. Which let's you -- which shows you how to use an HTML file as a store for your Core Data -- for your Core data managed data.

We have other changes in NS Fetch Request. Now Fetch Request allows much finer grain than performance tested fetches. And there are these methods that let you control exactly how objects are loaded or not loaded. Include sub entities, include property values, only return objects that are false. These are all yes by default, but you can tweak the behavior depending on how much stuff you want to load in.

There's an example called Go Fetch which shows these in action as well. I mention these examples because if you're interested more in the Core Data sessions -- well, you missed them all. Because they were this morning and one's going on right now. So the examples are -- examples are the only thing you can look at.

One other performance aid here is Manage Object context, which has this new method this let's you -- returns the number of objects that would be fetched for a Fetch Request without actually returning them. And if all you need is a number of objects and not the objects themselves, this is a huge performance win.

Finally the big -- other big Core Data feature is the version of migration API. Typically -- you know, as you know, the Core Data stores are very much -- are very tied to the model that's defined for them. So whenever you change your model, of course the store no longer works. This new API, there's a mapping model class which let's you define how a mapping -- how a model maps from one version to the other.

And of course this let's you control, you know, when writing the stores for those different models. Using the NS migration manager class you can actually get a -- you can actually migrate a model up, or even in fact down. You down grade to a previous version. And you control the set runtime.

And Xcode also has tools to let you define these mapping models. So you're actually doing it in Xcode. You don't have to do it in code. Okay. So with that, let's move on to non UI. Which, of course, means mostly foundation stuff at this point. You heard about this yesterday. The new NS Operation class.

This class represents an encapsulated task. And when I say task, I don't mean NS task. You know, the kernel task. It's more than an operation, some -- some encapsulated piece of thing to do. This enables specifying dependencies in terms of other operations, priorities, and whether these things can execute concurrently. Meaning they can be run on separate threads against each other.

Now NS Operation's partly abstract. You would typically sub class NS Operation and specify what operation needs to be done. However, we do supply a concrete sub class NS Invocation operation, where it can supply a target and selector, or NS indication, as though we define a concrete operation. Now, one other helper classes here, the Operation Queue, and Operation Queue performs NS Operations in the background. You create your operations, you put them in the queue, and they will be executed automatically in the background.

Now my default Operation Queue does the right thing. And Simon Patience talked about this a bit yesterday. But you know, NS Operation might start executing operations concurrently based on how many CPUs are in your machine. But if some of those operations got blocked due to IO, then NS Operation Queue might choose to start with more operations. You know, this is the kind of smarts that would be very hard for you to control. Because this really involves knowledge of the kernel inside. So it's fairly powerful stuff.

We've also done some threading improvements, which are worth mentioning right now of the we have less and faster locking throughout. For instance, at synchronize is now much faster. And retain and release are also much faster in the face of contention. You know, when there are multiple threads trying to do things, these things could slow down a bit. But now they are much faster. Similarly, Objective-C 2.0 properties -- not similar, but along the lines of threading improvements -- properties are atomic by default.

What this means is if one thread is setting a property and another thread is getting that property, you will never get a corrupt value back. It does the orderly thing in the right context. And if it's returning multiword values like NS ref, you will never get half a ref back. That's what atomic means. Now, one important thing.

This doesn't imply high level synchronization. If you need high level synchronization of your object you still have to lock your objects at a higher level. For instance, if you ask an array for the number of items and you start enumerating those items, the array might change between those calls. So in those cases you need to have your own -- own synchronization around -- around your beta structures, or around your code.

Now there are also new NS object methods to improve threading. And I will just show you one could whet your appetite. This is basically the lazy man's method. Perform selector in background. So this creates a thread and executes it. So it's a way for your thread to just execute this elsewhere, and I don't want to be blocked, I don't want to hear about it.

Just execute it. It's fairly straight forward. There are a few other methods like this, and you can go to these two talks Thursday morning, Partitioning Your Cocoa Application, or the Performance and Boosting Response and Performance. A glorious title. You can go to these two talks and hear more about NS Operations threading improvements and much more.

Three new classes. NS hash table map, table pointer array. These correspond to or they're analogous to NS Set, NS Dictionary, and NS Array. What these classes do is they're customizable. You can put objects or non objects in these classes. They can have different copy retain behaviors, and one interesting behavior they have is the ability to do zeroing weak references.

This is very interesting for Garbage Collection, because when an object gets garbage collected, any references, any weak references to those objects in these collections are automatically cleared out, which is very good for Garbage Collection purposes. And something that will be very hard for you to do correctly. Because there are a lot of raised conditions involved in that. Now, again, this is a case for simple usage is simple. You create a hash table by, for instance , you can create it by hash table with weak objects. This means create me a hash table where objects are not retained.

And the garbage collected in mind, which means the objects, you know, this reference, does not cause object to not be garbage collected. Or if you want a more sophisticated set up, you go ahead and create an instance of pointer functions. You create pointer functions. You can then set -- oops, sorry.

Twitchy finger there. Let's go for it. Okay. You can set the echo function and the hash function, for instance. Or there's a number of other functions you can set and create your hash table from these pointer functions. And this says to customize these collections any which way you want.

Okay. Scripting. I am not going to say much about scripting except we have a bunch of new features. Some new features to enable scripting to -- the scripting abilities of your application to grow with plug-ins. There's support for these hidden attributes an sib elements, which let's you support all their deprecated APIs So basically enable you to have old scripts continuing running while you present the new API to new script developers. And finally, much better error sensing and reporting. There is a talk for Cocoa scripting that's tomorrow afternoon at this time. Not this room, but this time. Where you can hear Mark Piccirelli talk about these improvements.

So 64-bit. You heard about this yesterday. Leopard enables Cocoa applications that are 64-bit throughout. And by this I don't mean -- I just -- I don't mean just -- you can compile your app at 64-bit. But they can actually manage 64-bits worth of data. Because some of the classes like -- or most of the classes like string, array, the text system, are actually also capable of dealing more than 32 bits worth o2f data.

Now to enable this, we've added three new types, NS Integer, NS UInteger. These replace Int and unsigned int, respectively. And CG float, which replaces graphical and related float quantities in the APIs. Now really, there's only three new types. But you know, it's really a huge API change. Because hundreds of methods in the API have been effected. Where Int now becomes NS integer, unsigned int becomes NSU Integer and so on.

But you know, when you look at the definition, you see that for 64-bit, these are defined as longs, or doubles, which means they're 64-bit quantitdies. But for 32-bit they're defined as their previous definition. So really, although the declarations themselves have changed, API is not changing. 32-bit applications totally binary incompatible. Exactly the same as before. Now let me show you what the API looks like with these changes. For instance, NS Array used to have an account method that returns unsigned Int. Now returns NS U integer. Object Index now takes NS View integer.

The line spacing and paragraph style used to be a float. Now it's a CG float. And of course, in 64-bit this is a double. Which means you get much better precision. And the basic types, like NS point, NS size, are now in terms of CG floats. This means that direct basic type are also in terms of CG floats. It's in terms of points and sizes.

Now you know, if you take your Cocoa application and you compile for 64-bit, you might get a few warnings, you might not get anything, no warnings, and might seem to run. However, if you're still content to use Ints and unsigned Ints and floats in your program, there might be a lot of hidden bugs in there. Things will crash, maybe mysteriously later. In addition, of course, your program might not be able to process 64-bit quantities as effectively as you might want. So we have this conversion script that will convert your Objective-C source code to use these new source types.

Typically, you would run this conversion script and then depending on the size of your app you might spend a few quality minutes or hours or maybe days in file merge, looking at the discs, or maybe using Xcode's new Snapshot feature, looking at the discs and fixing them up one by one.

And most of the time, most of the changes will be, you know, along the same lines so it should be pretty quick to get through. This script -- running this script is -- and its effects are described in the 64-bit transition guide, which is available. You can get to it from your Xcode documentation.

Oh, and worth mentioning, Friday morning at 9 a.m. we have an Adopting 64-bit Programming Talk, where Matthew Formica will talk about just -- just give you an overview of 64-bit and talk about the various API changes and so on. And that's Friday morning. Okay. So now let's talk about Objective-C.

So Garbage Collection is a big new feature. Now the biggest -- the most important thing about Garbage Collection, you've probably -- if you've come to WWDC the last few years you're heard about Garbage Collection. There was talk of Garbage Collection in the air. And now it's real. And that's the important thing. It's real enough tomorrow Xcode to use Garbage Collection. So you probably heard this yesterday, but Xcode is a garbage collected app.

Now Garbage Collection is easy to get started with. You just enable it within Xcode. So if you bring up the build inspector, you can go ahead and check that check box to enable Garbage Collection for your application. Now, one thing about Garbage Collection is that it's best for new applications. It's not the kind of thing that you should go take your big application, you know, that's already running, already debugged, and change it to use Garbage Collection. We do not recommend that. Instead, you know, if you're selling a new project it's a good thing to consider.

Now of course, if you're a big existing application that had a lot of memory problems and crashed every few minutes and leaked all over the place, maybe it is a good idea. But anyway -- now one more app that Garbage Collection turns out to be good for is BlastApp. Now, I don't know how many of you know about BlastApp. Oh, there's one person. BlastApp is this retro looking helicopter game. I mean, it's really retro. It was retro the day it was written, like, 20 years ago. And still is retro.

But it was written as an Objective-C app for back in the day. And it was converted to Cocoa Java. And recently it was converted back to Objective-C. Now one thing that happened when it got converted to Java is all the retains and releases got dropped. Of course had it got converted back to Objective-C, the last thing, you know, somebody wants to do is put all the retains and releases back in. So instead we just checked some check box and some Garbage Collection works great. So there's another example of something that works -- I mean, that's what Garbage Collection's very good for.

There is a GC -- in depth GC talk Friday afternoon at 3:30. You can hear more about that. Okay. Exceptions. We now have a unified exception model that unifies the exception models of C++ and Objective-C now one thing to note here is that this is 64-bit only. However, it is source compatible with 32.

Now in general, and I didn't mention this earlier. But in general, we want you to have one source base for 32 and 64-bit. d We don't want you to have to maintain two different source bases for those two. Now in this case, the exception code you write for 32-bit will be source compatible with 64-bit except it will have different behaviors in some cases. Probably the biggest difference in behavior is the fact that under 64-bit with this new unified exception model it's much cheaper to enter NS during or at try block.

However, it's more expensive to raise or to throw an exception. Now this of course is in sync with Cocoa's exception handling guidelines. Cocoa's exception handling guidelines state that, you know, we don't use exceptions for normal program flow. We don't use exceptions for regularly expected errors. But they are used for unexpected errors or programming errors and such.

Now also let me talk a bit about properties. I am not going to go into too much detail in properties, but properties provide new syntax for declaring properties, and synthesizing accessors. Now properties are really great at eliminating tons of code. For instance, here we have three property declarations, and they have their time and At Interface.

And at the bottom is the implementation file, where just putting one At Synthesize, we're able to synthesize the getters and setters for those properties. And not only are these -- getters and setters do what you might expect, as I mentioned earlier, they are atomic and they do the right thing for different types. They handle the memory management rules and they're okay, they work for Garbage Collection or not, depending on how your app is built. So it's very powerful stuff.

So one question at this point is that, you know, let's say that you open up NS View dot H. And you saw that there was absolutely zero use of At Properties. So the question you might have is why doesn't Apple use the At Properties syntax if this stuff is so great? Well, it turns out we do use it.

There are some of our APIs, especially in the newer frameworks and the newer classes that do use the properties syntax. For instance, Image Kit uses property, and most of it is APIs. And really, the bottom line is all of our APIs should be using this. And you know, it just hasn't happened yet.

That's just where we are. Now of course the good news is that property syntax isn't all that magically different. It does let you get meta data about those properties, but other than that, the property and non property declarations are equivalent. For instance, just because NS View did not use a property, doesn't mean in your sub class of NS View you can't use At Property. You can go ahead and do that.

In fact, there is a new dot syntax, and you know, we don't talk too much about that yesterday, I am not going talk too much about it now. But the new dot syntax allows you to get properties by using dot syntax. That turns out to be orthogonal properties, where you can use the dot syntax to get properties that are not declared using At Property. You know, you can say my view dot bounds. Although bounds is not declared using At Property.

Or my view dot window dot title, or my view dot once there equals yes. So these will work. So there are the two features that are orthogonal. So turns out this is not a big issue right now. And over time we should just switch that properties in our header files of course, and I encourage you to do the same.

Fast animation. You heard about this yesterday the syntax is great. You know, this reads much better than any of the previous alternatives we had. This not only turns out to look better, it's also much faster than reading one by one because it does its work in batches. So it's really a win, win situation here.

Now you can tell which classes implement fast animation by looking at which ones implement this fast animation protocol. For instance, NS Array, implements NS Fast Enumeration. And since there's a protocol for this stuff you can actually implement fast animation in your own classes by implementing the fast animation protocol. There is just one method you have to implement.

Optional methods and protocols. I showed you an example of this earlier where we had the Print Panel accessorizing protocol. So what this means is that for an object to be conforming to a protocol is just needs to implement the methods that are valid. It can optionally implement the optional methods.

This puts a little bit of a burden on the caller, or the caller has to be response to selector to see if the object responds to those optional methods. Now, what are the benefits of this? Well, one benefit is now you can add methods to a protocol in a later release.

Without this feature, if we publish the protocol and your objects implemented this protocol, and if we added two new methods to that protocol later, your object would suddenly be non conforming. You know, it would be in this situation where, hey -- so we would have to maybe invent a new protocol or create additional protocol and so on. So this enables us to get around it by added those methods as optional.

Another benefit is that this enables using protocol for declaring delegate methods. Now if you're familiar with delegate methods in Cocoa, they're often declared as informal protocols NS objects. But with these optional methods and protocols, we intend to convert all our delegate methods to actually be protocols with optional methods.

Here's an example that actually has been added in Leopard for the new path control in the path cell classes. These -- this is a -- here's a delegate -- here's a protocol defining a delegate method. And the two methods in there are optional. Since typically delegate methods are optional. And so all the methods in this protocol are optional.

And again, you know, you might be asking why isn't this done everywhere. Well, it just hasn't happened yet. Okay. Now Objective-C has support for GC attributes. This is not something -- I don't think they talked about any yesterday. But it's actually a pretty powerful new feature. These GCC attributes enable decorating declarations with meta data. And they actually look God awful. There's an example. What this -- what this horrendous yellow thing says is that the first argument of this function is a print out-like argument.

So that any percent Ds, percent Ss, whatever in there, should be paired with, you know, arguments in the rest of the functional. So it's fairly powerful. However, this attribute syntax is gnarly. We go ahead and create macros to cover this up a bit in many of the cases.

And let me show you some of the other usage scenarios. For instance, availability and deprecations. As lenient as a new method we've added, and it's got this declaration available in 10.5 and later. This is -- also the Compiler will pay attention to this. If you are compiling against 10.4 it will warn you.

The C string method. Famously deprecated a long time ago, it now has a declaration on it. If you try to use it, we'll give you a warning. Another usage case here is putting sample requirements. A common pitfall in Cocoa applications is, like, saying NS Array with objects, which takes a list of objects and you forget to put the nil is in. We now have this declaration at the end which causes the Compiler to warn you if you forget to put the nil.

And again -- yes, it is a nice thing. ( Applause ) >> And again, if you look at this declaration you will see it in terms of these attribute things. But we try to hide a mess. Using advantaged OBGCO features. That's Thursday afternoon. Right before we all go get drunk. But anyway -- Thursday afternoon.

And at least it's now in this area. We don't go all the way to Apple any more for this. But anyway -- this talk will go not only into this feature, but also go exceptions, protocols, and a bunch of other things I just talked about. Okay, and here's my absolute favorite feature in Leopard. Non ASCII and constant NS traits.

This will work everywhere. It's great. And by the way, programs using this will work all the way back to -- theoretically, they will work back to 10.2, but there are many other reasons applications won't work back to 10.2, so anyway, the runtime knows about this. Another way to represent this is with example -- for example, is with UTF8 strings.

This is even less readable than the other format. But of course the most desirable way to represent this is by actually typing those characters as you see in the third example. With that, you know, funny little infamous snow man there. Now to do the third form you really, really must trust your editor not to lose the encoding of your file.

And Xcode does a great job of this. It knows the end coding of your file. But for instance if you ever open that file in some other lesser editor and save it, it might ruin your files. So this is something that, you know, to do this you must be brave and trust your tools. But if you can do it, it's of course great. Now one thing here though.

This feature doesn't mean you can now take all the localized string calls in your application and dump them. You still need to localize all the strings which are shown to the user, of course, by using macros like NS Localized String and so on. But now you can actually use real double quotes, fancy quotes, long dashes, in the strings you're localizing. So that's the feature you're getting here.

Thank you.

Okay. Now just very quickly, we're just going to put up slides of other changes. Not even talk about them. We have several new controls. Rule Editor and Predicate Editor are great. They give you the same kind of UI that you see in Mail and Finder for creating search rules.

Path Control. Again. If you're showing paths in your applications, if you're getting paths from the users, path control is an object you should look at. We have a bunch of other new classes. Dictionary controller for bindings, we have a great new tracking area class which gives much finer control over tracking areas.

And other significant changes. There's tons more. You should really look through the release notes to see what these are. Table out line view. Much better keyboard handling, for instance. Open panel, save panel. If you've seen it, it's got the Finder like side bar, it supports icons and so on.

A lot of changes. Many other changes throughout the -- throughout Foundation, Core Data and AppKit. And of course all the other frameworks as well. Okay. So, with that, let's talk a bit about best practices. And this is -- these are mostly best practices as you write your application for Leopard.

So one best practice is use properties. Just single handedly, properties feature will help eliminate dozens, hundreds of lines of source code. And this is typically the kind of source code that suffers from copy-paste errors. Because you write your set-get methods, and then you copy, paste them and you forget to change one thing. And there are tools out there -- I mean there are tools out there that help you write your accessors and properties will eliminate all that work.

For a new application, consider Garbage Collection. Now I talked earlier about why you would consider this for a new application. But there's one reason why Garbage Collection might not be appropriate yet. For an app to run garbage collected, all the frameworks it depends on, all the libraries it depends on must be garbage collected. That includes all the plug-ins that might load.

That's not a problem for Apple frameworks. But if you're using some third party frameworks which are not yet garbage collected you might want to -- you might want to consider that maybe evangelize to get those frameworks also to convert to Garbage Collection. But anyway, that's something -- you know, make sure all your dependencies are available in a garbage-collected form.

Be 64-bit ready. Now you might not think you want to ship a 64-bit app yet, and you don't need to. You know, there are some reasons to shipped 64-bit apps, but many applications don't yet -- aren't yet there. But it's important to be 64-bit ready. Instead of using Ints and unsigned Ints, use NS integers. CG floats. Once in a while compile your app for 64-bit and see what warnings there are.

And you know, if you do those things your app will probably be 64-bit ready thde day you want to ship it. And you can even -- if you're shipping your application for Tiger you can make it 64-bit ready even there. All you have to do is define -- when I say it's going to be 64-bit ready, I'm saying your app which is 64-bit for Leopard will still run on Tiger.

All you have to do is define NS integer, U integer, and CG float using those simple definitions I showed earlier. That way your app can still compile on Tiger, and on Leopard it can compile as 64-bit. d Use multiple processors effectively. Clearly, as you heard yesterday, that is the direction.

You know, instead of adding more CPU cycles we're adding cores. And having an application that can take advantage of mean, that means your application will benefit from increasing the number of cores. Use NS Operations. Think about how your applications can be made more thread safe and so on.

Take advantage of new features. Now, some of the features I've shown you require one line, some require zero lines, some require two lines. There's one that requires half a line. So you know, sometimes enabling new features is very little work. You can go in and enable non contiguous layouts in the text system.

And unless you're doing something very sophisticated, it will probably require no more changes to your application. You can, for instance, enable auto saving in this document. That literally requires only one or two lines, and suddenly there's a brand new feature in your application. An ability to save your documents automatically. So if your app or the system crashes, you know, they're there.

And you know, you can do these even if your app still needs to run on Tiger. You can do something like response a selector, continue set -- contiguous set, contiguous set needs continuous layout. And if it's not there you know you're on Tiger and you just don't call it. So it's possible to use these dynamic determinations.

Avoid deprecated APIs. Now that we've started deprecating them it's easier for you to find them. Not all of them have been deprecated yet. But anyway, you know, just if you see deprecated APIs, don't use them. Use the suggested replacements instead. And please don't use private or undeclared APIs. This always ends in tears.

Either for you, or for us, or for the user. You know, as we work hard to try to wrap Leopard up. The biggest problems we run into are applications which have used private, undeclared functionality. Therefore they are breaking our assumptions on how our objects are being used. It's -- it's really a big problem. And gets bigger, of course, as there's more APIs to choose from.

And finally, start with the highest level of abstraction. And this is an important enough point that I'm just going to talk a little bit more about it. Just give examples first. An example is use NS View instead of Core Animation. If you want to animate things in your Cocoa application to view later, start by using NS View. Turn on layer backing. See how well that suits your needs. If you find that doesn't suit your needs, you need much more control, that's the time to go to Core Animation and, you know, start doing more advanced things.

Now of course the reason for this is, in NS View you get all sorts of features like event handling, tool tips, tracking areas, training, accessibility -- the moment you drop down to Core Animation and start doing your own drawing, you know, you have to consider these other features. Do you have to enable them, and if so how are you going to do it. So there's a lot of stuff NS View does for you.

Another example here is use NS types instead of CG types, or CF types or other lower level types whenever you can. For instance, NS font is FCG font. S C array instead of CF array and so on. And what are the reasons for these? Well, one thing is this thing we call impedence matching. If you have an NS font it will work with Cocoa APIs much better. If you have a CG font you will have to convert it to an NS font at some point.

So you are paying that cost. You are constantly going through this conversion process. In addition, using NS types -- NS types are a lot more Garbage Collection friendly. The moment you start using CF types, some of the retain release behaviors are different in the garbage collected world for CF types. And you've got to worry about the bridging between those objects.

Another example here -- another thing I mean, is use higher level functionality. If you have some algorithm, you know, for dealing with C strings, like Cons Care Star (Phonetic), or Point, or Plus Plus, the first inclination might be to convert the character index. NS string character index. That's often the wrong approach because it exposes you to the -- some of the dirty, undersides of Unicode where -- you know, Unicode's very complicated because in the end. It supports a lot of things, but there are sometimes multiple characters need to come together to represent one character. You know, what the user might think of as a character.

And so on. There are surrogate pairs and all this stuff. So instead of using character with index and deal with these issues yourself, use higher level functionality like has prefix, arrange in string, and so on. NS string has a whole set of rich functionality that can help you here. Similarly, instead of using objects that index and NS Array, used enumeration facilities, like make objects perform selector, or the four in.

This -- if you use those array nodes you're trying to enumerate and can optimize the access patterns while you're using object at index, the array doesn't notice. One final example here is NS document. You know, NS document does a great job of saving files on different file systems, handling the meta data, handling it with all the quirks, doing appropriate back up copies, auto saving and the whole -- and I don't envy them on the work NS document has to do, it's just a lot of work. And if you have to replicate them in your own applications, you know, you could be a lot more productive by letting NS document handle that, and you concentrate on the things, of course, that differentiate your application.

By the way, on NS document one thing to mention is TextEdit. The word processor now using NS document in Leopard so it could be a good showcase for what it is. Okay, so why do you want to do all this? Well, this way you know, we can change implementation on their issue, we can improve it, we speed it up, we add more features, and now this document can do more things for you , for instance.

And so on. And therefore you will be leveraging us. So, you know, so we're providing the foundation for you to build upon. And you know, we enable you to ship innovative applications. Concentrate on the things that you want to ship. That's why you should always start with the highest level abstraction that you can. So that's that.

Please, for more information you can contact Deric Horn. The application's Framework Evangelist. He's down here in the front row right now of the we have the usually attendee site with a lot of documentation and sample programs, and the reminder that we have source codes to applications like TextEdit and Sketch and many more available on your machine and developer examples folder.