So my name is Chuck Pisula, and just like everybody else here from Apple today, I'm here to help you. And in particular, I'm here to help you learn about Cocoa. So, let's give you an idea, again, what Cocoa is. It's an advanced object-oriented framework designed from the ground up using objects and many powerful object-oriented methodologies.

It provides you a full feature set for doing application development, and it integrates well with other system components. It's not a standalone component. You can use any of the POSIX APIs or, as you heard Scott say earlier, actually integrate with parts of Carbon, like the print panels actually comes up through Carbon. And it's used by many important Mac OS X applications. System Preferences was written in Cocoa, the Mail application, Project Builder.

Let me set the stage for what you're going to learn today. My goal is to tell you what makes Cocoa unique. By doing so, we're going to talk about some of the important classes in Cocoa. We can't talk about all of them. There's a lot. And we're going to discuss some of the main concepts and features, in particular those that make Cocoa unique and powerful. Above all, I want you to learn that Cocoa is powerful, easy to use, and can make you more productive.

Cocoa is powerful. It's an object-oriented framework designed from the ground up, using objects and those object-oriented methodologies. You'll notice some of these slides are similar to earlier slides you saw today. I'll have to learn next year not to do them so early so that they can't be reused by people before me.

So they're designed for extensibility, again, like Scott said, so that you, the developer, can make changes without a lot of effort. And we use a dynamic runtime system that makes many things easy to do that you might not even consider doing with other frameworks. It's easy to use because we have consistent APIs and conventions, again, in Objective-C and Java.

And again, those of you who are not familiar with Objective-C shouldn't be frightened. It's something that, it's a small extension to the ANSI C-based language to support things like objects and messaging. And if you're familiar with object-oriented programming and the C-based language, you should be able to learn it in a day or two.

Now, we also have brought up this line count thing many times. So one measure of productivity is line count. It's not the only one, but it's a measure of productivity. So what can Cocoa give you for free? Well, in fact, with no lines of code, you can actually have a reasonable text editor.

Now, I know most of you out here are not in the business of writing text editors, but what this means is that this is an example of what Cocoa can give you for free. And the idea here is that although you're not writing text editors, you want to get lots of stuff for free so that you don't have to reinvent the wheel.

This means you get more time to work on features which make your product unique and helps you sell your product. So at this time, I'd like to bring Doug Davidson up on stage. He's going to show you how to write a no-line text editor and sort of show off what you get for free in Cocoa. Doug? Good afternoon, everyone. I'm here to show you how easy it is to get started writing great applications with Cocoa. So we're going to write a Cocoa application from scratch right now. So let's fire up Project Builder and get started.

This will be a Cocoa document-based application, something along the lines of simple text. And we'll let Project Builder create a project for us. Now, the main thing we get with this project is a couple of interface definition files. So let's take a look at those in Interface Builder.

The first one has a window for us where we can put the contents of our document. With Handy, your document content is here. Since this is going to be a text editor, Well, the thing that I want to put in here is a text view. So I'll just drag one in off the palette. And I'll position it the way I want.

I want to size it the way I want. And I want it to grow when my window grows. For that, I have to set a couple of springs. And let's take a look at the attributes our text view might have. We've already got-- it's editable. That's good. Multiple fonts allowed. That's also good. How about graphics? That would also be nice.

And undo. That's useful. And the other one has our main menu. Let's also take a look at that. Here's our main menu. Now, since this is a text editor, I think I would like to have a text menu. So I'll add that and a font menu. Let's see. Let's try building it. This is always a moment of truth. Built. That's good. Let's see if we can run it straight from Project Builder. And here is our application. What did we get? We got a document window, or maybe two or three, that we can type into.

Let me make that a little bigger for you. That's better. And this has a lot of the standard text type features that you might expect, like copy and paste or drag and drop.

Or we can drag in inline images. Let me make that a little bigger.

Built right in. And we also have a ruler with some various formatting options.

And there's one more thing. You notice this little close button up here has a document dirty indicator in it. That means that our application has automatically noticed that we edited this document. And if we try to close it, it will ask us if we want to save changes. And it will bring up a save panel, a little one or maybe a big one, whatever we like. You can try to save.

Oops, didn't save the document. What's missing here? We didn't write any code. We forgot to add any code. Well, at this point, I have to admit that Cocoa can't do absolutely everything for you. You would have to write a little code to be able to open or save documents. But with an additional less than 20 lines of code, This text editor would be able to open and save documents in a variety of formats, and we would have a full working text editor. Now back to you, Chuck.

Thank you very much, Doug. Now, again, the point of the demo was not to show you that you can write a text editor real easy. Well, you can, but most of you aren't going to be doing that. The point was to show you that you get... Lots for free in Cocoa.

And if you're like me, you like getting stuff for free. Like Will Shipley was up here earlier saying, you don't enjoy writing stuff that's been done hundreds of times. You want to do new, unique stuff that's going to make your product really cool. And that's what Cocoa allows you to do.

So let's talk about some more, I guess, more realistic applications, like some of the stuff you guys are going to be writing. We have the mail application on Mac OS X. It was written in about 75,000 lines of code. Again, you see this probably rehashed a couple times now, but I just want to reiterate it because it's so important to understand that you get compact code size and still lots of functionality. So of those 75,000 lines of code, 15,000 are actually comments.

So that leaves us with about 60,000 lines of code. Of that, 40,000 are written in reusable frameworks. Now this means that they're not specific to mail. We're actually reusing them throughout Apple so that we write it one time and multiple applications get to use it. That leaves only 20,000 lines of code for this mail application that are specific only to that mail application.

Many of you are familiar with OmniWeb. OmniWeb is a full-featured Cocoa application. It's a web browser, and it was written in 300,000 lines of code. Now, at first, this might sound like a lot, but I've been told by the OmniWeb folks, who are generous enough to give me the line counts, that 120,000 lines of code are there only to support about five various plugins, like Flash and so on.

So that leaves us with half the code only to support a couple of plugins that we're in C. That leaves about 170,000 lines of Cocoa code. Of that, 140,000 of them are written as reusable frameworks. So you're noticing a theme here, where typically in Cocoa, you're able to write your code, some of it factored out into reusable frameworks.

Now, Omni actually posts this on your website. You can go and check out the code yourselves. And they address things like networking, the web, HTML, and some custom controls that they're on. So that leaves, for a full-featured web browser, only 36,000 lines of code. Again, very compact, yet full-featured.

Okay, so let's leave, that's a bit of the motivation as to why you might be interested in checking out Cocoa. Let's talk about where Cocoa fits. You've seen this many times. You've seen at the lowest level is the cherry-flavored Darwin pill. Above that, we have maybe lime-flavored graphics of Quartz, OpenGL, and QuickTime. And then, like Scott talked about, we have many programming environments, one of which is Cocoa, its own tasty little component.

So Cocoa, in a little bit of detail, it's actually divided up into two layers. We have the foundation, which is typically non-UI classes, and the app kit, which are the UI classes. And the app kit gains its graphic capabilities from application service, which, again, is Quartz, QuickTime, and OpenGL.

Cocoa is full-featured. There's a lot of classes here. In fact, there are 220 or so classes. So we don't have time to talk about all today. Some of you have already picked these up. If you go to Hall 2, there's these references that you can use. I guess they're cheat sheets.

Just try and hide them conspicuously on tests. So again, we're not going to have time to talk about all this today, and I just want to point out what some of the stuff that we're not addressing today are. Cocoa is, again, broken up into the foundation and app kit layers.

APCAD addresses things like windows and views, graphics and imaging, events and system interaction, a number of classes for text handling, which were shown off in the earlier demo. Then in the foundation level, we have classes for basic storage and collections, abstractions for dealing with file input and output, for dealing with operating system mechanisms, such as processes and threading, and networking and communication, and then some others.

Okay, so let's dive into the foundation now in detail. At the root of the foundation is a class called NSObject. In fact, you'll notice that all classes in Cocoa start with the letters NS. Brief history lesson: this actually stands for "Next Step" because Cocoa was a Next Step technology. So maybe this is a lesson for including company names in your APIs. I don't know.

Foundation, again, is below the UI level, and it provides basic classes for storage and collections, operating system abstractions to make dealing with the operating system easier, and our core support for internationalization and localization. And while I talk about the Foundation, I'm also going to touch on some topics which are important at that level, in particular, memory management and the concept of mutability.

So, we have basic storage and collection classes for things like values, NSStrings, which store Unicode strings, NSData for storing a bag of bytes, collections that you're typically used to from CS-type classes, you know, arrays, dictionaries, and sets. And what's important about these are that they have very consistent APIs, and they can be written to files as property lists. Now, let me explain property lists a little bit, because we've only been talking about XML, not property lists.

Now, property lists are basically a simple object graph that we use when we write out the files. And these are defined using, the format is defined using XML. In fact, if you're interested, the DTT is on the system. Now, property lists are a deal as a small, flexible data store. And for that reason, as has been mentioned a couple times now, they're used throughout Cocoa and Mac OS X for things like user preferences and configuration files.

Now, we also have abstractions for dealing with the operating system. And I use the term "abstraction" a lot today, and I want to define what I mean by that. By abstraction, I mean we have a higher-level interface to gaining access to this functionality. It doesn't mean that the functionality is any less powerful. It just means that it's easier to use.

Now, we have abstractions for dealing with the operating system, such as threads and locks. For doing file input and output, things like NSURL, or NSFileHandle, for dealing with files. We also have classes that help you do networking, communication, and for accessing system information. Now, there's lots of classes and functionality here, but if your needs are exceptional, you can always use any system-level framework or POSIX APIs, for instance, so that, again, Cocoa is not a standalone product. You can use it with other components in the system.

Internationalization is very important in Mac OS X. Obviously, we're able to ship seven languages simultaneously. The way we're able to do this in the Cocoa frameworks is through our support for Unicode data, which is in NSString. Now those of you who are used to using the Carbon APIs may have heard of CFString. NSString is a very, very similar class. It's basically just a small shim on top of CFString.

So NSString stores Unicode data, which means it can support any language that Unicode can. And for that reason, we use it throughout our APIs instead of basically char stars. Now typically, localizing your application involves more than just converting strings. You also want to convert your images, so a stop sign in the US might not make sense when you're running in some other language or some other country.

So you need to localize things like images and, in fact, your UI. So NSBundle provides our support for that. NSBundle is just a resource loading mechanism that knows how to rummage around your app packaging system and find the appropriate resources for the user's currently selected language. It's also just a general resource loading mechanism, but for localization, this is what you'd use it for.

Okay, so that covers some of the basic classes and functionality at the foundation level. Now I want to talk about some of the concepts that apply at the foundation level. Memory management is important. Cocoa does not use automatic garbage collection. However, it uses something just as simple and easy to understand. It uses reference counting. So the basic idea is here that when you send an object a retain message, that adds a reference to the object. When you send it a release, that decrements the reference to an object. When the reference hits zero, the object will get deallocated.

Now, the basic rules of our memory management is simple. By convention, only creation methods return objects that have a retain on it. All other methods return objects that temporarily don't have any references. If you want to keep that object around, you send it a retain. When you're done with it, send it a release. And again, once it has no references, it goes away.

Immutability is also a very useful and important concept at the foundation level. Many classes in the foundation are mutable classes, which means that they can be modified. Or we have some that are immutable, meaning that they can't be modified. So why do we have a distinction? There's a couple reasons.

Immutable objects can't be modified, which means it's safe to pass them around. I can pass you an immutable array safely if I know you can't add objects to it. I might need to know that it's not changing, which means I can also return immutable arrays from my API to external clients and safely know that they won't be modified.

Immutable classes could also have more efficient algorithms. If I know an array is not going to change, I might be able to do something more efficient in my implementation. However, the drawback, of course, is, well, they can't be modified. Not much use to pass around arrays that you can't add things to.

So, for that reason, we also have mutable objects. And for that reason, lots of classes at the foundation level come in both flavors. So, we have NSStrings and NSMutableString. And, in fact, you'll notice the same things, you know, similar classes at the core foundation level. Mutable classes and non-mutable classes.

So, it's a concept that we use throughout Mac OS X. Okay, so that covers non-UI functionality. I, myself, am a graphics guy. I love doing graphics. And we're all Mac programmers here. Who likes to do great graphics? Okay, everybody's third. Okay, so the app kit again is where we have our UI level layer and our graphics.

It provides the infrastructure for drawing and handling events, and also provides many of the components that you're going to use off the shelf in your application. We have basic controls like buttons and check boxes, advanced controls like the toolbar, and we also have standard dialogues like color panel, save panel, open panels, and we have many advanced Aqua features such as drawers and transparent sheets. And again, as you saw earlier today, Cocoa features a very sophisticated text system.

So here's a diagram showing some of the classes that I'm going to touch on today. Again, only about five of those 220. I'm going to start by talking about NS Application. Because everybody's writing application, so everybody has exactly one instance of NS Application. Now, NS Application is important because it manages your connection with the Windows Server.

It'll set up the connection, and when the Windows Server receives events, it'll dispatch them to the application, who then will appropriately forward them off to whoever needs to get them. NS Application is also important because it gives you hooks to customizing typical application behavior. So, for instance, if you need to customize and do something special in application termination, there's hooks for you to customize that behavior.

Okay, everybody has an application, so they got an NS application. Everybody also typically will have Windows. And then Window is the guy who reserves screen real estate and provides you a place to put your topmost view. Ennis Window is also the guy who Application will forward events off to, and then it will figure out, based on the event, who needs to receive that.

So clicks go to the view under the mouse, key events go to whichever view currently wants to receive keyboard events. Through some of the magic that you heard Scott talk about, we can dispatch these keyboard events off to dynamically figure out what object wants to handle keyboard events. And again, Ennis Window is where you'll find our support for advanced features such as drawers and transparent sheets.

NSView is where you're going to do your drawing. NSView handles lots of details that you don't want to handle. So some of you might really enjoy this stuff, but typically most people don't want to worry about managing the view hierarchy, worrying about coordinate system transformations, view to screen transforms, or worrying about clipping. It's all done for you in Cocoa. Also, NSView provides basic UI functionality that you're used to having around, like, drag and drop, context-sensitive menus, and help tags.

Again, off the shelf, there are many instances of NSView that you can just use in your application, such as NSTextView, which you saw Doug use earlier, or NSMovieView, which plays QuickTime movies, and there's a number of other views. Now, if you want to make your own view that does your own whiz-bang, custom, really cool drawing, all you need to do is subclass NSView and override the methods that you're interested in. So if you want to draw, which you're all going to do, you override drawRect. If you want to handle mouse-down events, you override mouse-down. Any other event that you want to handle, you just override that method in order to handle it.

NSView is where you do your drawing, and Cocoa provides you lots of options for drawing. In particular, we have NS Bezier Path, which allows you to do path-based drawing. Lots of things that you're familiar with with path-based drawing, such as curve to point, stroke fill, set a dash pattern.

NSImage is our class that provides an abstraction over images. So we support images like TIFF, JPEG, bitmaps, anything else that you typically would expect QuickTime to support. And the nice thing here is that it's an abstraction on images, so we can add support for new images, in fact, which we have in the past, like PDF, and your application gets that new functionality without even knowing that it existed previously.

We also have the ability to draw strings. So strings know how to draw themselves. A class I haven't mentioned yet is NSAttributedString. That's our abstraction on styled text. We also have abstractions for colors and fonts. And again, in the past we've added functionality for things like pattern colors or true type fonts. And we've done this without changing the API in those classes, so clients have been able to pick up new functionality without having any idea that it would have existed at some point in the future.

And if you need to do your own graphics transforms, we have NS Affine Transformation. Now, there's lots of options for drawing, but if your needs are exceptional, you can always use Quartz drawing. Again, Cocoa is not an isolated component. It can use other components in the system. Sony CG functions can be used. At this point, I'd like to bring Doug back up on stage. He's going to give you a demo on how to actually subclass NSVU, how to draw, and how to handle events.

Doug? Thanks, Chuck. OK. Now, this time, I promise we're actually going to see some code. So what we're going to do right now is what might be the beginnings of an image editor, perhaps. We'll draw an image, and we'll allow the user to click and drag to make a rectangle selection. So I've already created the project for us. And here in Interface Builder, instead of a text view, I put in a custom view and set it to be my custom subclass of NSView.

Back in Project Builder, let's take a look. I've added a few lines already to the implementation of my custom subclass. Actually, just two methods. For demo purposes, I have hard-coded a specific image. Now, really, the only interesting line In this code so far is this one. And this is in our draw rect, our custom draw rect method.

And what this line says is that we want to draw the entire image in our entire bounds. And that by itself is enough to draw the image. But we also want to do the click and drag selection thing. So let's add some lines. First of all, I'm going to add a couple of instance variables to keep track of where the user has clicked and dragged.

Keep track of the start point where the user started, click, and the end point where they drag to. And next, what I need to do... is add just a couple of methods to keep track of those things. So first of all, I have my mouse down method. That's going to be called automatically when the user clicks. And all that this method does is to set both the start point and the end point to the location of that mouse click in our view coordinates. And then we say that we need to read Redisplayed. And then we have another method, mouse dragged.

Which will be automatically called when the user drags. And all that does is to set the endpoint, just the endpoint, to, again, to the location the mouse was dragged to in the view's coordinates. Now, given these two points, it's fairly straightforward to compute the rectangle that they determine, and I have a little function that does that, too. It's about as long as the rest of the code in this app, actually. I'm going to insert that.

The final thing we need to do is actually draw that selection rectangle. So let me get that. I'm going to add that to our draw rect. And what this says is that if the start point and the end point are not the same, then we set an appropriate color, in this case red.

and create a Bezier path. In this case, the path is just a rect, being the rect determined by those points, and stroke it. Simple enough. Let's see if it builds. Let's try running it. Now, here's our application. It draws the image that I've hard-coded. Notice again it scales nicely, automatically, no code needed for that. And I click and drag, there's my selection.

Thank you again, Doug. OK, so now I've talked about NS Application, NS Window, and NS View. And the attentive ones in the audience have noticed I've skipped one class. That's everyone, right? NS Responder is the common superclass of all these classes I've already talked about. And the reason is they all share some similar functionality. In particular, all NS Responders can receive events. And again, events in Cocoa arrive as methods. So if you're interested in keyboard events, your subclass of NS Responder will override the key down event -- key down method, excuse me.

NS Responder also introduces another important concept called the Responder Chain. And every subclass of NS Responder can be in this Responder Chain. Now, the Responder Chain works like this. Every window knows who its first responder is. Every responder knows who its next responder is, and so on down the line. And so this forms a responder chain. What will happen is, when events come into the system, they get dispatched, typically, to the first responder. If it doesn't want to handle it, it gets passed down the responder chain until it finds someone that wants to handle it.

So typically, you're probably not interested in knowing about actual very low-level events like mouse clicks or key-down events. You're really concerned with, was this button clicked, or was the slider manipulated, things like that. This is where NSControl comes into play. As you can see, NSControl is a subclass of NSResponder and NSView, which means it inherits lots of functionality from these classes. However, NSControl has some important differences.

NS Control is defined as something that's typically triggered or activated by user action. Again, button clicks on a button, a click on a button. Examples would be NS Button, NS Text Field, or more advanced controls even like Outline Views. Now, again, I said it inherits lots of functionality, but it also has some important differences. Every control has a target object and an action method.

I'm going to get into this in detail in a little bit, so let me just leave that for now. Controls also have values that can be queried, so I might need to know that the slider's current value is 0.5, or that a text field's current string is something or other.

Also, since controls are typically things that I can click on, I need to be able to enable them and disable them. So control has support for that. Target action is a very important concept in Cocoa, and this is what makes some of that magic that Scott Forstall was talking about earlier possible.

The idea here is that when a control is triggered, it has a target that is going to tell I was triggered. So the target object is the guy that gets sent an action method. In Cocoa, targets can be nil, and when the target's nil, the message will go to the first responder.

And again, if the first responder doesn't implement that action method, it goes down the chain until it finds someone that wants it. So, this is how cut is implemented in Cocoa, typically. When the user clicks and drags down to the cut menu item, we haven't actually hard-coded in a target. The target's nil. And so what will happen is, the frontmost window, its first responder will get a cut message. If it doesn't actually implement cut, it'll go down the chain until it finds your custom view, which implements the cut message.

So again, you can imagine how much gory detail and management you'd have to do if you had to actually manage who the current target was and keep track of what window's in front. That's all taken care of you through the beauty of the first responder chain and target action.

At this point, we'll bring Doug Davidson back up on stage, and he's going to show you how target action works in Cocoa. Thanks, Chuck. So this time, we're going to build on our previous example, and we're going to add an action method to our custom view. And to do that, we're going to pay a little closer attention to scaling.

So I'm going to add a few A little bit more code here. Now, first of all, I have one method, setScale. It will set the scale on our view to some float value. Now, in Cocoa, every view has two rectangle parameters. One is its frame, which determines it in the external coordinate system.

And the other is its bounds, which determines its size in the internal coordinate system. So to scale this view, all that we're doing is setting the frame size to be the size times the scale factor, and setting the bound size to be our original size, just the hard-coded size of the image, and again saying that we need redisplay.

And also, when we get loaded, we want to set the default scale to some value of 1. Now, our action method is this one. called Take Scale From. And what that does is to set our scale based on a value determined from the sender of the action method. In this case, we're going to have the sender of the action method be a slider. The value of the slider is just determined by the position of the slider. So the slider will tell the view what its scale should be.

Let's take a look at our interface in Interface Builder. Now we're going to take our view, and I want to group it into a scroll view so we make sure we can always see it. Let's make this window a little bigger. Move this thing around a bit. Now, here I'll get a slider, drag it on, position it the way I want it.

I've set some nice values for it. It goes from 0.5 to 1.5, and it starts at 1. Now I need to hook this up. Here's the magic of Interface Builder. I'm going to drag, saying that the target of my slider is my custom view, and the method it's called is takeScaleFrom. Now let's see if this will build.

And the slider tells the view how to take its scale. If it's too big, we can scroll around. We can still make our selection. And we're all set. Thank you very much. Let me assure you that Doug doesn't normally program using stickies. Some of the beauty of what you saw here was that because, again, Objective-C has very good introspection, Interface Builder knew that it has these methods that it can wire together.

So we've talked now a lot about classes and specific functionality. And although that's some of what makes Cocoa powerful, it's some of the concepts that we use in Cocoa which make it really unique and powerful. So I want to talk about, in particular, some design patterns that are used throughout Cocoa.

In particular, the notifications, sometimes referred to as the observer pattern, delegation, and the model view controller paradigm. Notifications are a way to broadcast happenings throughout an application or even to other applications. Those interested in knowing about a happening will register as an observer. Typically, in Cocoa, some of the things you can register as observers for are, "Tell me when a window will close," or "Tell me when a text did begin editing." However, you wouldn't expect notifications to be used for really low-level things like "Disc did spin," or something like that.

So observers have to register with somebody to say, hey, tell me when this event happens. That guy is the notification center. Notification center is sort of the glue that makes notifications work. What happens is, observers register with the notification center, telling them the name of the notification they're interested in and the object that they want to monitor. And also, they provide a method to be called when the notification is posted.

Now, you don't actually have to tell it what object you want to monitor. You can say, "The object I'm monitoring is nil." And when you do that, you say, "I want to monitor all objects for a particular notification." So I might want to know when any window in my application closed. I do this by specifying nil. Posters are the ones who post the notification. They post the name and any additional information which may be valuable. For instance, what window is closing.

Delegation is a powerful design pattern that allows one object to act on behalf of another. Typically, it's a way to provide you a way to customize an object's behavior without having to subclass. So, NS Application has a number of delegate methods. One called Applications Should Terminate and Applications Open File. So if I want to customize my applications termination, I provide a delegate who does some special work in Applications Should Terminate.

Okay, so at first, notification and delegation somewhat sound like similar concepts, and they are because you're sending messages when things happen. But they have some important differences. With delegation, there can only be one delegate per object. Much like with the Highlander, there can be only one. However, there can be many observers. And because of this, you'll notice that with our APIs, delegates typically receive should messages. They're allowed to affect behavior because there's only one. However, notification observers will receive will or did type messages. There's no way for you to affect it.

So let me give sort of a contrived example of making a U.S. law. In this example, the House makes the law, and we'll say the President's our delegate in this situation because he's allowed to veto the law when he's asked should the law pass. Now once the law finally passes, all of us out here as notification observers learn about it through the notification the law did pass. It did pass. We don't have any way to affect it. Of course, there's always voting, but we know sometimes that doesn't actually work in all places.

Okay, so another design pattern that we use throughout Cocoa and has already been mentioned a couple times is the model-view-controller paradigm. In this paradigm, the model stores the data. However, typically it's more than just a simple data store. It knows how to perform intelligent operations or business logic or things like that on the data. However, it's separate from the view. It doesn't know any particulars about any view that it's being displayed in. The view knows nothing about the data.

It just knows how to display typically some simple types, but it's separated from-- The Cocoa APIs are a powerful tool for creating full-featured desktop applications for Mac OS X. The Cocoa APIs include low-level utility, system interaction, internationalization, internet, and platform independence classes, as well as a rich set of user-interface components and a powerful and extensible text system. This session provides an overview of Cocoa APIs. So I'm going to talk a little bit more about it in the next couple slides, and I'll usually talk about it and just call it MVC.

Okay, so I'm going to hit on a number of application-level topics, some which MVC affect and some which are just application-level topics that you'll be interested in when you're developing your application. In particular, if you're writing a document sort of application, Cocoa has a wonderful document architecture that you'll be interested in knowing more about. Every application on Mac OS X should have undo support and be scriptable. And typically, you're going to want to be able to talk to the clipboard or have preferences in your application.

OK, document architecture. It provides you a number of standard features that you want to have in an application that works with documents. As you saw earlier in Doug's demo, we had a document-based application that ran open panels and save panels for us. We didn't write any code to do that. It also managed the document edited status.

Again, these are mundane things that you typically don't want to have to reinvent. Now, for you to make a document-based application, all you're going to have to do is provide routines that can load and store the data. Again, stuff that we didn't do in the earlier demo, but you provide the custom logic to do that.

Undo is very easy to do in Cocoa, and for that reason, every application should be undoable. In fact, every Cocoa application, as you heard before, already has undo support. In particular, the text system has built-in undo support. And if you need to add your own undo support, all you need to do is that when your model changes, you register an undo operation with the NSUndoManager. And again, since undo typically wants to be registered when your model changes, a good separation of your model and view will make undo easy for you to implement.

Scripting is also very easy to implement in Cocoa, and again, that means every application should be scriptable. Cocoa provides a lot for you already. We handle events from the Apple Script Standard Suite, such as Open Print and so on. The text system provides a number of the classes that you need in the text suite.

And if you need to add your own support for scripting, which you're all going to do, You don't have to do a lot of work. You have to edit a plist, which again is this XML-based file format, and you need to write a method or two. So it's very easy to do, and again, since scripting acts through interfaces through the model, a good separation of the model and the view makes scripting easy to implement.

Typically, your application also wants to have preferences. When you need to store preferences to disk or read them from disk, you can talk to the NSUserDefaults object. It stores preferences per user per application. It also allows you to access system preferences. So anything you see stored in the system prefs application, you can access through NSUserDefaults. And also, if you have a suite of applications, NSUserDefaults allows you to share preferences between them.

If you need to implement cut, copy, paste, or something similar, you need to talk to the clipboard or provided data, right? And its pasteboard is the object that gives that functionality. In particular, the data can be provided either immediately or in a lazy fashion. And of course, we all prefer to be lazy because if we have some huge data, we don't want to have to compute it if it's never needed.

And its pasteboard also has filtering services so that you can convert to the requested formats. And in fact, we provide conversion of Mac OS 9 types for you automatically. Okay, we covered a lot of stuff today. I made this thinking it might be earlier in the day. I guess it's actually time to eat.

What I'm hoping you take from the talk today is that Cocoa gives you lots of functionality. You don't have to reimplement mundane tasks that aren't interesting to you and don't add value to your product. You get to spend time working on features which will help sell your product. Cocoa has lots of powerful concepts. More than just the classes and the functionality of the classes, we have powerful concepts that we use which make Cocoa unique and powerful. And again, I love free stuff, and Cocoa gives you lots of it.

So it's day one, and we've got a lot of sessions left if you're interested in Cocoa. In particular, I would highly recommend going to the Using Cocoa talk. There will be lots of code demos there. We didn't show a lot today. We're going to show a lot more there. The Advanced Cocoa talk is actually for beginners to Cocoa and Cocoa experience folks, so everyone should feel free to attend to that. And if you have feedback, come to the feedback session on Friday.

There's also a couple more things you might be interested in. The project builder talk coming up, interface builder, and learning about things such as NSURL. Again, one of these foundation classes that I talked about. There's lots of documentation on your CD. The first thing I would recommend checking out if you're new to Cocoa is the concepts documentation, because that, again, is what I think makes Cocoa unique and really powerful.

There's lots of information elsewhere. There's your O'Reilly book that you can go grab. And actually, there's lots of Cocoa enthusiasts out on the net that provide things like mailing lists and fax and free frameworks. Again, Heather Hickman is your contact for anything Cocoa. There's a new Cocoa Development mailing list that if you're doing Cocoa Development, you should look into subscribing.