I'm Deric Horn. I'm the Application Technologies Evangelist. And usually when I tell people my title, the next question is what is an evangelist? So let me try and give you the quick run down. Basically as an evangelist, there's a small group of us that try to promote the adoption of our key technologies. So we work directly with developers and largely with developers like you that might be new to the platform, coming to the platform or that just want more help or questions with certain technologies and APIs.

And in addition to that, I'm also the Mac OS X Essentials track manager here at WWDC. So essentially responsible for the Mac OS X essentials track that you see here and was involved with a lot of the content, going to endless rehearsals, sample code, creating those head starts that you saw.

So hopefully today I'll be able to kind of give you some good insight as to the cool new sessions that you're going to want to see to help further your application.

So before I really get started here though, I'd like to know how many of you out there are here for the first time at WWDC. Oh excellent.

Okay, so this is a great crowd. So I expect this is the perfect crowd for me. And always, you'll see my email a few times. Feel free to email me and I can always help you get in touch with the right people or help you with your issues in particular. So over the last six years, we've had five releases of Mac OS X and Mac OS X server.

And each one increases in power and capability, stability as well as security. And our upcoming release, Mac OS X Leopard, our sixth release I think is really a culmination of a lot of time. This is really the release that I think I'm most proud of. I mean, it's just the release that just seems like all of our technologies, are all coming together. You see a lot more of these pervasive technologies across the system, a lot of collaborative technologies and so forth.

I had lunch with a developer today, Wil Shipley and he mentioned that this release is the one that is really the developers' release. It has so many features for developers. In his words, it'll make your application 10000 times better than it already is. So hopefully we'll go over a number of those technologies today.

And really the way we're working this session is we have two sessions in a row, part one which is the first hour and then part two which will be the second hour. And each part is divided into two sections. And in the first section we'll have Larry Coopet come up on stage and talk a little bit about the overall Mac OS X architecture, some issues with building your application on Mac OS X, as well as some, as well as some cross platform techniques, some things that you should be aware of, how to deal with strings across both platforms, Mac OS X and for instance Windows and so forth.

And then I get to come back up on stage and Steve had his top ten list this morning and I have my top ten list of killer new development technologies that you'll want to take advantage of. And these are technologies that I think are really give you a big bang for the buck. What I call kind of these deep APIs. In that you just write a few lines of code and you get to incorporate the whole new technology into your application and really add a lot of value to your applications.

And in the second hour, we'll talk a little bit more about graphics. Mac has and continues to be the platform of choice for creative, creative engineers or creative folks. One of the reasons why is we have a whole new track this year, the content and media track. So we'll have Babak Mahbod come up, come up on stage and talk about our graphics and multimedia frameworks as well as imaging and OpenGL and so forth and then we'll wrap that up with Matt Henderson coming up on stage, talking about our development tools, Xcode, our IDE, Interface Builder, what we use to layout the user interface as well as embed some logic into that user interface design. And then the new features in our Leopard development tools.

So at this time, I'd like to welcome Larry Coopet on stage.

Thank you.

- Thanks Derek.

Like Derek said, I want to talk to you guys about coming to Mac OS X and its implications for developers. A little bit about me.

Most recently I was at Alias Wave Front where I did, I was a project lead for Maya coming to the Mac from Windows. And in another lifetime ago, and Apple is still blaming me for this one. I was the lead on Photoshop to Windows from the Mac. So I've got a broad base of multi platform experience. And we're going to kind of hit the 50000 foot level and make sure you guys come to the labs if you guys have specific questions this week. And so for people who are familiar with OS X, this might be a rehash.

So let's get started. One of the things that, oh I want to talk about the agenda. So what, first of all the things I want to talk about are what are the major code components you're going to be dealing with? What are the localization issues because you know OS X has a great story for this. Model view controller which you're going to hear a lot this week if you're new to the Mac. And a bit about Cocoa and then I'm going to run through a development, quick, quick development demo.

So one thing I want to stress is you already know this stuff. You know people come to the Mac, they see Cocoa, they see square brackets and all this and they get a little nervous. You already know this stuff. So these are very familiar concepts. Applications, shared code, DLLs, you know resources, localization, and you know settings and preferences across invocations.

So first of all, let's talk about applications in shared code. What are they on the Mac? How do they work? Well, I want to talk about some structural differences. One is you know now modern applications in DLLs are much more complex, right? It's just not your, your DLL, you EXE just floating in space. So on the Mac this week you're going to hear about things like four way binaries and universal binaries.

So what are these? And how does Apple solve this? So universal binaries or four way binaries are simply two or more binaries stored together in the Mach-O executable format. Okay, the interesting thing about this is that the Mach-O format stores this information and then Mac OS X knows how to load these separate binaries on the fly depending on the current architecture. And what's really interesting about this is there's absolutely no thunking, there's no intermediate code.

And just like Steve said this morning with 32 and 64-bit, you build these things, it just goes. Only your code is duplicated, right? Resources, HTML content that are stored inside your application bundle are not duplicated. So you do, people say oh my application is going to be three times as big. That's not what happens.

So there is some issues that you'll bump into. And in byte swapping, this is not an issue for any high level APIs you'll be using for, on the system for loading images or string data things like that. It will be an issue if you've got proprietary file formats and you want them to support both Intel and Power PC architectures.

There's tons of swapping macros and, and function calls for doing this on the fly. And its important to remember when you see Xcode these are trivial to build. In fact they release and you select your release configuration, you get end way binaries. And for all you 64-bit people, please remember that our compiler is LP64 not P64 d so this can cause a problems for some people coming from Windows.

So back to applications of shared code. What's the other issue we have to resolve? We have more than just code. As I mentioned, we've got HTML pages, resources, you have helper apps that you want to launch. Now you're going to learn about QuickLook and Spotlight plug-ins. Where the heck does all this stuff go? So this has been in Mac OS X since the first version. We have a thing called a bundle.

Okay? Bundles are just formalized directories. They're just well formed directory structures. And the idea that while the formalization of the structure is so that the system can recognize these components quickly. Okay, it hides the complexity from the user, right. You don't have this spewing of content all over the place. Common bundles are application frameworks. You can see this a lot and a framework is a DLL. Okay? That's wrapped inside a bundle folder.

All of your necessary subcomponents go inside your framework, okay? And what, so let me just show you a little bit. ( Period of silence ) Hang on a second. ( Period of silence ) Okay, so I'll show you. This is how you do it. This is the application. And I want you to see the, the contents there and what's important, a couple of things. There's my dot exe.

Stored inside that folder. Okay? Then I also have, you'll be seeing this a lot in both DLL, in your frameworks and in your applications. Your going to see info dot P list. This is an XML file that tells the system about your application. It's just, and we call them P lists or property lists. It's just XML. Meta data. Frameworks, that's where your DLLs go. Okay? You'll see the iTunes has two private frameworks there and at utilities and at iPod updater. Those are my DLLs that are private to my application.

And then of course my resources folder, which we'll talk about a little more later. So what are the benefits for the bundle? Obviously you know you've got all these components. Now I keep them together in one, one thing, all right? And the cool thing is, folders are already part of the system, right? I don't have to do anything, just a little bit of code in the system to recognize bundles and what type of bundles.

Easy versioning, you'll talk about that in the labs. And of course you're avoiding your DLL confusion. Right, and so the other thing drag and drop installs. Apple recommends drag and drop installs where possible forever. Now since it's just a folder basically, boom, I drag it on. And yep, documents can be bundles as well. In fact Xcode projects are simply document bundles.

So next I want to talk about the next big part of most applications and frameworks, is resources. Okay? Again more and more complex resources, how do we sort this out? And what are the localization issues? Well, again as you saw in iTunes, resource, resources are just put inside a folder inside your bundle. Now your bundle could be both an application bundle and a framework bundle.

Don't forget that. So they're just files stored in the proper location, no more resource compiler, no more deciphering these Arcadian formats. So and the cool thing in both inside OS, Mac OS X is that I have really, really high level functions for doing this. We had some arguments during, when we were putting the slides together. We were going I can do that in one line.

You don't need two lines of code there. So this is what's interesting. Its very high level and you can see for you know I've got an image loader and, and that's code taken out of the sample I wrote that works, okay? So that's it. And so let's talk about, about resource localization a little bit.

What you have inside your resources folder is you'll have the ISO standard naming convection and you'll have the English lproj , the French lproj, I'll show in the demo later. And these are just subfolders that hold your localized data, okay? Now this, I want to stress here one thing, absolutely zero code has to be written to support arbitrary languages, okay? You localize your content, not code.

System finds and loads proper resource bundle based on your current you know language settings. Okay? And there's fall back support which is very interesting. If the resource isn't localized, it goes through that chain inside the system and says, okay, I can't find French. The next one language you've got chosen, these that are chosen is English. It will find the English resource and all the way up the chain so on and so on.

As Derek said, I wanted to talk a little bit about strings. This is where developers kind of get caught sometimes in the Mac. Strings first of all are stored as Unicode text files. Okay? And they are just stored as key value pairs, very simple. It's all Unicode all the time on the Mac, okay? So I told developers if I see lots of char starred declarations in their code, you're probably going to have problems unless you know implicitly that this is all UTF 8 encoded. If its not you're going to really have some issues.

One thing I like to talk about is STL strings are 32-bit or W char T is 32 bits on the Mac, freaks some people out. But you really need to write like 2 bottleneck routines to solve this problem when you're reading and writing your own, your own data text files Mac high level APIs for loading strings does not have this issue and don't forget about bomb characters if you're like I said writing your own file formats.

The third part is your settings and preferences and storing state across invocation, okay. Where does the information go? How do I handle multiple users? Again, our setting and preference system is just based on XML. They're just Unicode text XML files. The interesting thing is they're stored per application and you can kind of take control of that and change that a little bit. But you only care about your info. You're not writing into a registry where you can scrag someone else's data. These P list files are not utilized by the system, only by your application.

Okay? And the APIs are again as you can see are key value paired. My little example there, again I load the standard default mechanism and I literally say give me this Boolean for this key. I'm done. You can make these as complex as you want. I can store arrays of dictionaries and dictionaries of arrays and all this. And that's, its, there's one function called the store this out.

And you can store these in different domains. The Mac has the concept of domains similar to Windows. And so I can say I want this stored for the current user, all users of the machines, anyone on this system, so on and so on. So the next thing I want to talk about is model view controller. Hopefully you guys have heard of this paradigm and you're going to hear it over and over again this week.

And what is it? Obviously the model, I kinda like to use engine view controller, right, but the model is your intellectual property. This is your code. The view is what you know the view, users view into your data set and the controller is the view that ties all these together. And why is this important. Okay, for coming from other platforms, this is really critical, right, for you guys to reuse and share your code.

You really want to uncouple the platform specific code from the platform neutral object. Obvious, but its amazing how many people still don't do that. And what's really critical is you see with Mac OS X and Leopard the idea of what my view will be changes dramatically right and you guys are, have probably bumped into that with dot net. So whether it's an HTML view because I can write code that can be uses a plug-in inside Safari, things like that. I don't know where my code might live.

Language changes of course you know coming from C Sharp to Objective-C. And you know these widely divergent tool kits like Windows Presentation framework, Core Animation. And it's really important when you separate that code to leverage the system, right? I want to do my work in my engine code and let the system take care of all that other thing which is you know what Derek talked about in Leopard. You really, really want to take advantage of that. Of course, this lets you share you code more effectively.

So what should you be doing? Okay. You need to take ownership of your code. People always say, oh you know this is complex. You're like yeah, of course its complex, right? But you need to factor this and start thinking about how your code breaks down into these models and not worry about the view so much right now.

Please remove view dependency. I have all these developers say, oh I just have a check box on screen. I, I load up my code and I set the state once and I'm done. MVC that breaks, right? You have to store your application state inside your controller or inside your model code.

You do not want to because I had a guy this morning say yep, I took some code and I wrote some AppleScript behavior for it, it broke because they were storing the UI, the application state and the UI guess what, you don't have a UI when you're being called from somebody's AppleScripts.

Avoid intermediate representations. I cannot tell you how many times I have had developers come and say oh, I load this and I have this cross platform code and I convert the thing to a C string and then I try and load the file. I'm like, what? You've blown away the whole Unicode thing and, and they have this intermediate representation. Don't do it. It's better to wrap the high level system objects, right? And again take advantage of what the system offers. Let the system do the work for you.

A real quick thing about you're going to see this slide all week, in fact you probably already seen it a couple times today. What I want to say is what's cool about Mac OS X is you're free to pick from any of these layers, drop down into BSD and Darwin if you want, pop back up into your Cocoa, Java code. It's really, really cool that we don't have a lot of limitations you know that you see on other systems.

This, you're free to mix and match. And I think that I need to stress that too. Don't, you know people talk about Objective-C Cocoa. Remember, as Matt will point out later, our tools are all kind of language agnostic. C, C++, Objective-C, Java, you can mix and match wherever you want.

So on to Objective-C. It's a superset of C, Matt's going to go more into this later. It, as an old traditional long time C and C++ developer, I have to tell you that I'm really, really enjoying Objective-C. And it's, I've just gotten into it in the last 10 months. And I, I can tell you that it's really incredible. And the idea that it's heavily introspected so that facilitates all these things like delegation that you'll hear over and over again and all this introspection allows the dynamic runtime binding. Okay? Its really dynamically bond up by name.

Okay? And Cocoa, you know Cocoa is the equivalent, is you know our dot net equivalent. It's built on, its Objective-C code and it's, you know there's thousands of mannerisms in this frameworks. And that's why I tell people, use it. Take advantage of the system and just do what's important for your application. Don't do the heavy lifting. The NS prefix, people say what's that? It's NeXTSTEP legacy. So that's the kind of the 50000 foot overview and I just wanted to do a, a quick demo. Demo please.

So what I want to start out with here, one thing that people bump into more a lot when they're bringing their MVC layer over right. I have my DLLs. I want to bring those over to the Mac and integrate them with my application. So I'm going to start here with a simple, this is my little test framework code. And all it does is oh, let's see.

Let's build it and run it. I put this together. There's absolutely no code behind this right now. This is a typically entry point for Cocoa application. You see there's absolutely no other code in here. I've got some resources. I've got my standard linked in frameworks. That's it. So let's run that. Comes up behind here and this is my nib, my resource file and I've got a button and a text field in there. So I want to show you how I can integrate a straight C++ non Cocoa, there's no, into this application.

So here I've got my simple C++ framework. I've got a simple string class that actually kinda mimics C string if you've seen this on MFC. Called TX string. All straight C++. Okay? And I'm going to build that.

And then I'm going to integrate that into my test framework here. So let's bring up the folder.

And this, you're going to see this a lot this week. So I'm going to integrate my two Cocoa files and I want to share my Cocoa header here.

This is a typical controller class. I've got a text field I bar and I've got a, an action that I'm going to tie to.

So I'm going to open my nib. I'm going to drag in an object. So a couple points I want to point, I'm going very fast, but you're going to see more of this. So what Xcode is doing is telling Interface Builder to parse all the source in my code right now. And what's interesting is if I go back to Xcode and look at my controller class, I've called it AA simple controller.

Now I've just added a dumb object to Interface Builder. I'm going to get info about that. And I'm going to tell it I want it to be an AA simple controller. Xcode has actually told Interface Builder to parse this. It's parsed my headers. It knows already knows about my code. That's the difference. This is not a new I wizard, okay. Interface Builder is integral to building your code. It knows about your code. Again, Cocoa introspection, right.

So I'm going to tie that to that. Here's my little window that I put together from my little tool palette over here. And this is standard behavior. I'm going to drag, don't worry too much about the details. But I'm going to drag from my button to my object.

And guess what, hey it sees the action. Set string on some action. I click just like that. Now my object needs to know about the text field so it can set that data. I controlled right from that to that. And I set the outlet, my text field. Okay. So now I've got my, I save my nib.

And I build and everything great. But I wanted to do something. So now I've set this up ahead of time so not to bore you guys too much. And I'm going to say I want to use this framework that I've built, okay. And so I'm going to turn that on and then.

Okay, very clean. And then I need to go back here to my framework and make sure that's built. Go up here.

And I'm going to drag my framework into my high level code here.

Okay. And then I gotta do one more step. Remember that this is going to build an application bundle. Okay and I, so you're seeing parts of Xcode if you haven't seen before, I'm going to add a copy files phase. New build phase. Copy files. And I'm going to tell it to put it in my frameworks bundle. Which is my, where my DLLs go. And I simple drag that down into there. Now when I build and run.

Now what this code has done, let me go to my simple framework here. In the controller, when I get the action, it literally calls into string from key which is a function I put in my simple C++ object here. And there it is. String from key. So I'm calling into the DLL directly from my framework. So it's a straight C++ being called from Cocoa, absolutely no problem. Now one interesting thing about localization.

Okay. So one, one more minute here. So I'm going to go into my resources here and there's the string that you say. This is the English version of my string. Okay? Here's how easy, I'm not going to change one line of code. I'm going to get info about this string and I'm going to tell it make this file localizable. You see that the little spin out appears here. I'm going to go back and say I want to add a localization. I'm going to make it French. I'm done with that. Hopefully this will work. Then I'm going to say this is the le.

French version of my string, right. Okay. Now what I want to point out is let's quit that. I haven't touched any code right. So now I have to clean this and actually there's a bug currently in, in Xcode and the pre, in the beta, so let's delete the framework as well. And then clean my target here.

Rebuild my project. And hopefully this will work. Oh, I need to bring up the System Preferences so I can change my language. And then build my application that uses my framework. And let's run it. ( Period of silence ) All right, I still get the English version, cool. So let's quit.

Go to international. Change my language to French. Again, no code, hopefully this will still work. ( Period of silence ) All right, zero code. Okay. Only content changes. And it's really that simple whether its image data, HTML content, the system finds it for you. So and I wanted to show you the finished product here. If you go to my products here. And oh, sorry.

And let's reveal this in the finder and if I right click on this, show package contents. Hey, does that look familiar? There's my frameworks, there's my DLL. And there's any and if I go into my resources folder, hey, French and English. Again, I've had to do nothing except change my resource content.

Okay. And, and that's how easy it can be. And once you get these systems set up and lets just, so there's my test framework. And there's the resources that are for that actual application. Okay? That's it. Slides please.

Oop.

And now Derek's going to come up and hit you with some even neater stuff.

Yeah. Thank you Larry.

So as you can see, the goal isn't trying to create an application that's going to be the less common denominator across all the OSs. The goal is really to take advantage of whatever OS that you're writing for and give the best user experience for whatever platform you're going to deliver that application on. And the way Larry suggests of writing a Cocoa front end which bundles our latest technologies and then having a common backend, the C++ engine is really the way to go if you're going to go this cross platform route.

So now I get to tell you about what I think are probably the five killer technologies in Mac OS X. I'll start off by just giving you kind of a brief overview so you can just kind of wet your palette with it and see if you want to learn more through, throughout the rest of the week.

Before I can talk about these killer new technologies, I have to talk about Cocoa itself. Cocoa is our object oriented class library. It's our object oriented framework. And what I would have to say the single neatest thing about Cocoa is the ability that it just follows these common coding conventions and styles.

Really meaning, once you start to learn a couple of these conventions, it makes it so easy to go away and grab and grasp this whole new technologies, add them into your application with a few lines of code and things just work. Most of the time people compare developing applications in Cocoa like building a house with Legos. You take this technology over here and you just fit it right on.

Works great. Over the last year, we've been working a lot on the infrastructure of Cocoa. The whole thing is now 64-bit clean from the top all the way down through the bottom. In Tiger we have the BSD layer that's 64-bit clean and now we've brought that up through the application class libraries. Cocoa is also resolution independent. That means if you were to write and application in Cocoa that used our common user interface design, Interface Builder and so forth, automatically your application is going to scale with resolution independence.

Also in Cocoa for the last year we've introduced a number of new controls. Typically developers love new controls because it means you get a whole lot of functionality developed by the experts back in Cupertino and you get that for free. Some of the new controls here are for instance predicate editor which you see up here.

And this is similar to what you might see in your mail for filtering out your spam for instance. We have a new collections view which used to be called the grid view. By taking advantage of these new controllers, you also get the latest functionality in there too. These are available in Leopard. So both of these views come like pre bundled with animation in them.

Core data is also part of what I would call Cocoa. In general CoreData I think at the highest level you can think of this as almost embedding a database into your application. We've stored the backend in either binary, XML or SQL light format. And the biggest improvement, well I don't want to say the biggest, but one of the improvements since Tiger that we've made in CoreData is its now somewhere between 5 and 20 times faster , depending on the operation you want to make. Tomorrow we have a session at 2 o'clock in the Presidio, that's upstairs, Cocoa today that will give you a rough idea of what we've been doing in Cocoa in the last year at 2 o'clock like I said tomorrow.

I can't really talk about Cocoa though without talking a little bit about Objective-C. Larry mentioned a little bit about it. And I just wanted to mention Objective-C 2 point 0. One of the main goals of writing Objective-C 2 point 0 is to make it so you guys have to write less code. And by doing that we added garage collection. A lot of modern languages now a days include garage collection. So this means if you have an existing Java app, should make it that much easier to bring your Java app over towards Cocoa.

We also added properties. Properties are, let me see how I can describe this. It's a way of maybe sticking on attributes onto instance variables. This might be one way of thinking about it. So you can say I want to access this instance variable by reference. When you do that, it will automatically synthesize you accessor routines. You're getters and your setters to access this instance variable. So if you have a FU, it might generate that set FU type routine for you.

Now based on that attribute is how it will automatically synthesize those accessors. So it'll either do a deep copy, copying the contents of that pointer or maybe a shallow copy and just point the, copy the pointer across. That's one of the functions of properties. The other one is changing that bracket notation to more of a standard dot notation that people are familiar with, as you can see on the slide up here.

And lastly we wanted to improve performance as you may have seen this morning. One of the ways that we improve performance in the language is by making it not only easier to read through things like this fast iteration, but its also faster. As the, as the name implies.

So that's a little bit about Objective-C. Overall, I think you know throughout the industry I think that for a number of years software developers were looking at making developers more productive by you know adding more and more enhancements to these gigantic class libraries. Things like MFC. But I think over the last five years or so there's been a trend to also go ahead and improve the languages in themselves. And that's when we start to see things like C Sharp and Ruby and Objective-C 2 point 0 come to life.

So now on with my top favorite technologies in Leopard and Mac OS X in general. Animation has got to be hands down the technology that developers are clamoring for. This is the technology that's when developers see decide that the next version of their products are going to be targeted toward Leopard only. And it's really amazing the way that it's implemented.

We have a lot of things, for instance, no animation loops or timers. No frame by frame drawing and automatic retargeting. To kind of put this in perceptive, in the past I have written some of the functionality for instance where I would show a palette window on screen. And as I mouse over that pout window it'd come to the front, be completely opaque. And as I move my mouse away, it would fade out.

Just doing simple things like this currently really involves you chaining up your timers, you say fire a timer ten times a second and at the same time change that alpha of that window. But that really involves keeping almost like a state machine, which direction was I going in? I'm fading out.

How much alpha have I already applied? How much is left? Once the user puts that mouse right in there, what do I have to do now? I have to think about retargeting. What state am I in? Which direction do I go in? That involves writing quite a substantial amount of fragile code with your timers and all. Now we handle all this for you. It really gets dropped down to about half of a line of code to implement this type of thing through animation.

And it really allows you to take your application user experience to the next level. Its not, its not a means of adding eye candy to your application. It really allows you to provide something that's more intuitive to our users. At this point I also wanted to mention that we have coding head starts. We developed 19 of these for this conference. We have one called the Core Animation head start which includes a video, a read me as well as tutorials and sample code.

We have two sessions covering animation and they occur tomorrow in Presidio immediately following that Cocoa today session. And they start off at the view level describing how to add an animation of the view level and then the one at 5 pm will talk more about the underlying Core Animation engine.

So I'm going to go ahead and talk a little bit more about animation while I'm up here. In general I think that there's four types of animation you can add to your applications. We'll start off with the easiest. The easiest way is to have to write absolutely no code at all and start integrating animation into your application.

Then we have the ability to animate these built in view and with the properties. So every view and every window has certain properties associated with it. We know its size, the rectangle that it makes, we know its origin. We know the amount of alpha applied to that. That has other properties as well. For instance maybe the rotation of that view.

Then we also have the ability to animate custom view properties. So if currently your creating your own view, lets say you're creating add volume knob for your application. And you want to animate that knob going from you know volume one on the dial all the way up to volume 10. You want that knob to slowly turn up there. This is what I mean about adding animation to your custom view properties.

You can't just tell a normal view set volume to 10. It doesn't understand what this concept of volume is. This is your own view. So you know how you're going to want to turn that volume up. And if you think about this, this also allows you to hook in to things that aren't only visual. So while you're animating this control, you can also be setting the output level of your speakers. So now you're animating non visual properties as well.

And fourth, and this is probably the most complex and this is the ability to use the underlying Core Animation engine directly from your, from your Cocoa application to get that fully immersive user interface. The things like what we have in Front Row or Time Machine. You can now create your own UI And you can do this all, starting at the Cocoa level and then dive down as deep as you need to go.

So lets talk about the easiest way first, the ability to add animation into your applications without having to write any code. There's a couple ways to do this. One of them is the new Interface Builder 3 allows you to add these transition effects into your application. So as you design your user interface in Interface Builder, it allows you to set transition effects.

So for instance if I have a tab window and I want to switch from one tab to the next tab, maybe I don't want to just pop in the new view. Maybe I wanted to do a page scroll effect or dissolve to the next one, or slide in.

You can now add all of these transition effects directly in Interface Builder. And in fact you could probably add a whole bunch of them because it not only does some standard ones, it does anything that core image transition effects support. So as new transition effects get added to your system, you can now add these directly to your user interface.

Next, the ability to animate these built in view and window properties. So what we see up here is a simple call to set the frame of a view, that basically means set the origin and set the size of this view. So how would we, how would you go about adding animation to this API? I mean, for me the obviously solution is stick on an extra parameter, say whether or not it's animatable. Okay? Yes or no.

That's a, that's a solution. That's one that I thought of, but that has a side effect of now double the number of APIs you have. You have all the existing APIs and you have to double them and stick on an extra parameter. So what we came up with was something quite really elegant solution. This is the half line of code that I was talking about. We can now ask the view for its animator proxy. And then send that message to the animator proxy itself.

Anything that gets sent to this animator will automatically animate over time. We have built in defaults. I believe it's a quarter second to do the animation. And we have this kind of ease in, ease out time curve, so your animation will start slow, speed up and then slow down at the end.

And probably the most elegant thing about this animator concept, or this animator proxy is messages that you send to the animator that it doesn't understand, for instance if we want to change the title of one of our views, there's no clear way to animate the changing of the text. So when it doesn't understand that message set title, it'll go ahead and forward it on to the view itself.

So this becomes very powerful if you already have your existing layout code where you were passing in views to change the layout. You now passing in the animator, it will then go ahead and animate all those transitions. Anything it doesn't understand will still get handled appropriately. So at this time I'd like to show off a couple of demos from the Core Animation coding head start. If we can go to demo machine please?

Okay. First thing I'm going to show off is this picture spinner demo.

Go ahead and launch the project and we'll build and run it. So what we have here is a small application which is going to, let me bring this up, which is going to apply certain effects to our image here. We'll go ahead and drag and drop an image on this window.

I go ahead and maybe change the alpha value, the rotation, the size, the origin and we'll hit start.

This is the effect that you're going to get through Core Animation by adding in, by adding in just normal visual effects in here. I think currently today if you were to do these types of things, it would have an animation time of zero here. As you hit start, it just flashes into place.

By changing this duration time over here, you can now start to get a better user experience for, for our user. It'll slowly start to slide into perspective. So users can kind of keep contact with that image and see how it's changing.

The other thing I wanted to show you here is the actual code to this application.

There we go. The actual code to this application, the entire application is really only this one method here. It's a very small method. And you can see that by using the built in Cocoa framework, you get all that other functionality for free. You get the ability to do, to accept drag and drop, to display the, the entire menuing Windows and so forth. This is the whole bulk of our application here. The only change that we really had to make is actually, let me see what's going on here. I think I maybe already had one of those running. Quit.

Okay. Let me just change one thing. I'm sorry. Okay that's still fading out. The only change that we had to make to get this to work is actually the send messages to the animator itself. I think I've got a little inconsistency here with the version that I'm showing and the version I'm actually running though.

But, if we can go back to slides please.

So now we talked a little bit about how to get animation for free and how to animate those built in properties. Now I'd like to talk a little bit more about those more advanced concepts. Those adding animation to your own custom views and, and calling down to Core Animation directly. If we could go back over to demo.

First we'll start off with a sample that we put together on the coding head starts. And this is a custom view. This is a speedometer here. So if you have your own custom view that's a speedometer, you might want it to change the speed from 70 to lets make it go 100 miles an hour and we're going to do this over one second.

When we hit draw, you can see that needle smoothly go over to 100. This particular sample has a number of other animation effects built in as well. So we can go ahead and animate several different properties of this speedometer all at once for us. So that's the ability to add custom animation to your own custom views and it really boils down to only having to override one method called default animation for keying.

And the last animation demo I'd like to show you is one which calls down into Core Animation directly.

This is a small sample I wrote on a, I think on a plane ride from somewhere to Chicago. And the idea behind this is we take a regular view hierarchy, something which we design in Interface Builder and we're actually calling down into the Core Animation a matrix transformations directly from Core Animation.

We take this entire view hierarchy and it can now be rendered onto a layer and we can now animate it through Core Animation directly. And as you can see there are actually two different views. We might have our own application which is an address book. And this might be the read only view. We flip it around. We'll go ahead and take a snapshot.

See if this all works. Hey! There I am. Not a good picture.

But you can see by integrating an image kit into this application, it's really just a few more lines of code, I flip it around, and now I have my read only version here. So that's the idea of calling down Core Animation directly. And being integrated into your Cocoa view layer. Go back to slides please.

So that was Core Animation. Next I'd like to talk to you just a little bit about resolution independence. I think there's kind of a common misconception that the displays now a days have about 72 pixels per inch. But if we actually look at a chart, even back in 2001, we were up to 96 pixels per inch. And we just announced a few weeks ago the new MacBook Pros and they are coming in at about 133 pixels per inch.

So you can image that if we did nothing from our side and just kept on giving, giving you better and better display hardware. And you did nothing on your side in writing the applications, things are going to get smaller and smaller and smaller to the point of being unusable.

So one idea here is we can just go ahead and magnify what we see on this screen. And then you get kind of this pixilated look. You're not getting the full capabilities of that display hardware. We don't want a pixilated look, we want something that's going to be crisp and clear. You see the difference between this, this is the resolution independent version. Here's the kind of pixilated one that we might just get if we magnify it. The resolution independent version.

So really in your applications, to take advantage of resolution independence, there's very few things that you have to do. If you use our standard controls, you're going to get resolution independence built in for you for free. If you have your own custom art work, your own custom controls, your splash screens or so forth, I recommend that you save those images in what we call multi representation tip files or multi image tip files. That basically means your going to keep one representation at 72 pixels per inrch, another one maybe at 144 pixels per inch, and another one at 288, collapse them all together in the same file.

NS Image will automatically pull out the appropriate representation and then downsize it for you. So you're always going to get a crisp and clear look in your user interface. So you can image the time, depending on how good your eyes are, you might want to scale that user interface with any application. And this will allow it to agate at any resolution.

Or I can think of lots of other reasons why you want to do this, I just hooked up a Mac mini to TV at home. I can make the content of my, of my web pages nice and big so I can read the text, but I still can't read the tabs and the menus. Because it's too far away.

Next is Quick Look. You may have already seen quite a little, quite a bit about Quick Look today. Quick Look gives you the ability to provide quick, rich previews of your documents. We have Quick Look plug-ins built in for all the standard types that you might think of on the Internet. Things like JPEG, TIFs, PDFs, HTML files, even Excel files. But if you have an application which write proprietary content out to document files, it's crucial that you also deliver a Quick Look plug-in.

Now it's very easy to write a Quick Look plug in because you've already written the code. Basically all you're going to do is take that code that's going to read from that file and display that file into graphic context and separate that out into your own Quick Look plug-in. And then you get a great deal of functionality from this. Quick Look is used throughout the system. It's used in Time Machine. It's used in Finder. It's used in Spot Light. Quick Look plug-ins allow you to talk directly to iChat Theater.

If you have an open save panel or navigation save, or a navigation services panel, the way we used to generate previews has now changed to excepting Quick Look plug-ins. So if you provide that Quick Look plug-in, your users will automatically get this rich view of what you're looking for.

Here we see an implementation inside the Spotlight window. We see the picture we want, we hit the space bar, boom, you see a really quick look plug-in, you can see exactly what you want.

Again the Quick Look and Spotlight session is on Thursday at 3:30 in the Marina. Quartz Composer. Okay I really love Quartz Composer. Quartz Composer is a great way of mixing different types of media together. You can mix QuickTime with the mouse, with a graphics and so forth. And I really love it because you put it all together in these scenes without having to write any code. You simply take the output of what we call one patch, like maybe a mouse patch might output in its X and its Y coordinates.

And then you just hook that up to the input of another patch. And you start to hook these things up like Legos or wires and you generate these beautiful scenes. We might have an RSS feed as one of these and you might want to wrap that RSS feed onto a cube for instance and have the cube follow your mouse around the screen.

You can put together these giant compositions all without having to write any code. So you can really separate maybe what you do in code from what your motion or your graphic artist does though Quartz Composer. One of the new things that we added in Leopard is the ability to add your own patch.

So for instance, if you are writing a stock market application, you might want to create your own patch that can read Apple Stock Quote. And then you can link up the output of that text string to be rendered into an image and now this image is going to be rendered on one side of a cube which is spinning through space for instance. That would be the similar workflow that you're going to go through.

If you're a hardware vendor, you can also write a Quartz Composer patch to read from that hardware and then integrate the output from that through that whole workflow. It's very hard to explain, but we're seeing more and more place throughout the system where we're using Quartz Composer. Here's a little part where we're using it inside of the iMovie theme chooser. You can see all of the content that we're looking for is all rich, dynamic and a users content.

But it's so hard to, for me to describe what Quartz composer is, I think I have to show you really quickly. So we can go back over to demo

Whenever you install Mac OS X, you get your development tools for free. So if you look on the, on the root of my system, we'll go inside the developer folder. Inside of a folder called examples. And we're going to look down here for, there's tons of examples. Quartz Composer sample code. There's one over here called chart.

Chart, let's take a look at it. And we'll go ahead and take a look at the Quartz Composer composition first. This is what it looks like from the Quartz Composer application. We can see our separate patches here. And basically what we look at right now just seems to be the inside of a cube.

But you're going to notice over here someone now put some sample data here. If we link up this sample data into the input of our patch, it will now display a graph for us. So maybe in your application, you were thinking about creating a graph, but maybe you didn't think you'd have the time to create a 3D graph that looked so pretty or that you can change right here from Quartz Composer. If you look closely at this sample data.

Excuse me, the settings, you can see that the sample data, if you can read that far back is really just an array. Now like I said, one of the, probably the most beneficial thing about Cocoa is these similar coding conventions. So we can now start to export what we see in Quartz Composer three different ways. We can export it as a QuickTime movie. We can export it as a screen saver.

Both of these are not so exciting. But the third way we can export it is exactly as a Quartz Composer view. By exporting it as a view, our application can now supply this data dynamically at run time. So let me show you a little bit about how we're going to do that. We'll unhook this data. And as you see now, this little data dot here used to be dark gray and now it's white.

Whatever we want to publish, we'll publish through a concept called bindings and through out application we can help bind our new data to this value here. So we'll go ahead and publish this value. Published inputs, data, we can name it whatever we want, publish it as data. Save it. Quit this.

And open up our Xcode project. The first thing we'll do is take a look at what it actually looks like from Interface Builder. Inside of our resources folder we're going to have our nib file here. And if we look at the main window, this is what the user interface of our application is going to look like. We're going to have a table on the left which is going to supply data. And this black area here will be populated by that Quartz Composer view.

So now we'll go ahead and build and run this.

So the important thing to take away here is that if you are going to design something in your application, you might first want to see what Quartz Composer has to offer. You might want to add an RSS feed. Why not add one that's rich, full of graphics and see what we have there? Now all of this can actually be handled with, mutated live from our application and affect our Quartz Composer composition.

So for instance, I live in a, in a little town called Los Ghettos. And, and I think it's, I think it's a 10. So I can just put it up there like that. And you can see the actual text of our Quartz composer changes as well as the bar chart.

Back to slides please.

So that's Quartz Composer. The fifth technology I want to mention real quickly is iChat and iChat Theater. In iChat you may or may not have known that we have already in Tiger released a framework called the instant message framework.

And that framework allows you to get the status of your buddies, whether or not they're online, to get their address book so you can find out their phone number or other information. To get the picture that they use in their address book. All powerful things. But now in Leopard we're releasing iChat Theater.

And that gives you the ability to take your application data and then post it through the AV connection and share it with one of your buddies. So for instance, if I'm writing a keynote presentation and I want to show it off to my boss, the picture of myself shrinks down, I can now see that presentation live.

So this is pretty sophisticated. It's going to take your application data, use our H264 compressor, compress it and then throttle that across your bandwidth. And the resolution that's going to throttle across also gets determined by your network speed. So that can also change over time. You can get a high resolution picture going across as your network capability goes up. And it lowers all dynamically. So you get all this functionality.

Now how much code do you guys think you'd have to write to get this all working? Let me tell you, there was only three lines of code to get all these working. I can basically take any NS view hierarchy and then say iChat Theater, I want to share this with my buddy.

This is a, I think a very interesting concept, especially if you want to build community, if you're working on a game, a card game and you want to start making that multi player or share any of your, any of your content on one of your windows with someone else. This is great way to go. Again we have a theater, we have a session in Russian Hill on Tuesday at 1030 am.

But let me show you a little bit more about how this works. So we can go back to demo?

So this is the demo that I decided to put together right before the presentation, so the logistics people love me for scrambling around to find these iSight cameras. But what we're going to do now is we're going to take our existing application and we're going to go ahead and broadcast that Quartz Composer view across iChat Theater to one of our buddies.

so let me first see.

There we go.

So the first thing that I'm going to have to do from Xcode is the project that I have here works on Tiger 10.4, and I want to upgrade it, I want to make sure that its going to run on 10.5 only. Because iChat is 10.5 only technology.

So we simply go to the information, change this to Xcode 3 and change our target from 10.4 to 10.5.

That's the first step. Next thing we're going to want to do is every small application that you're going to see sample code for always has this controller class, remember that MVC model. And it's usually called app controller. We want to add a few extra things into our app controller.

The first thing we want to add is a shared reference to iChat Theater. We already have a reference to the view that's going to be our Quartz Composer view. So one we've just added an, an instance variable to our iChat Theater. And we want to add one more action. This is the method that we're going to call when we want to start broadcasting our content across to our buddies.

So that's about all we have to do. I'll do a little more housekeeping by adding in the header files up here, the instant messaging framework header files.

So this is the change to a header file that we need to do. Now let's go ahead and modify our user interface of our application so we can now add a button for iChat Theater.

Let's pop the window up here and we're going to go ahead and resize this in Interface Builder. And find the button we're looking for.

In this case I'm going to grab this square button over here. We'll move it up. That looks good. And let me resize this so it looks a little bit better.

You can see these blue lines help guide me so I'll just automatically snap to position to follow the user interface guidelines. Now this kind of a boring button. So what I'm going to do here is I'm going to go ahead and make it a little snazzier. I'm going to add an icon onto it.

So here is the icon I want to use. I stole this directly from the iChat application. And what we want to do now is add this iChat resource into our Xcode project. So we simply drop it into our resources folder here. It'll ask me if I want to copy it across. Sure.

Now one of the great new things about Leopard and our tools is that the integration between Interface Builder and Xcode has gotten so much better. So it seems like they're in constant communication. I can now simply click on this button, get my inspector window up.

Let me see which one is was. Image. When I clicked on image, it automatically sees now that I have an image in my application called iChat. I'll select that and now we have a nice little icon on there. The next thing we're going to want to do is when someone clicks on this button, we want it to actually call our method that we just added, that toggle iChat.

So in order to do that, we'll drag a connection from our button back to our app controller. And this is that new method that we added, toggle iChat Theater. It'll start the iChat Theater session when we click it once and stop it the next time.

So now we should be done with Interface Builder, let's go back to code.

So we've already added the method, toggle iChat theater and we've added the instance variable, this iChat, iChat Theater manager instance variable. So now let's go ahead and add, change our code to actually launch this session in iChat Theater.

First thing we're going to want to do is initialize that shared connection. So we'll find a routine called init. That looks like a pretty good place to do it.

Don't you guys just love how I just copy and paste codes? There's no way I could actually trust myself actually typing it on stage. So now what we've just done is initialize this connection to our iChat Theater, our instant messenger. And we want to go ahead and copy that one method across.

This is the toggle iChat Theater method. As you can see, the first time we start it, we'll hit the stopped method. So we'll go ahead and start the video right here. When it's already running, we'll fall into this state and stop the video from running. So I think that I have done everything I need to do.

Let's go ahead and build it. Actually I know I left out one stage, but that's half the fun, showing the errors. So we have an error here.

And basically the error is that it didn't find the framework that we're looking for. We added the headers that we need, but we don't have that actual library linked in yet. So the easiest way to add an extra library to link to directly from Interface Builder is to go ahead and control click on the frameworks folder, we'll hit add and existing framework. It'll open up the panel directly to the frameworks folder and all we have to do now is navigate down to the instant message framework.

Which is right here.

Now let's build it, okay. Excellent. So I'd like to ask Larry to come up on stage and help me out here a little bit. The way to use iChat Theater from your application, the first thing to do is launch iChat Theater, or excuse me, iChat.

And start a connection with one of your buddies. So in this case, I'll start a video connection with Larry.

Hi, are you going to talk to me Larry?

Back to Xcode, we'll go ahead and build and run our application. And now we'll simply click the button. And you can see that our iChat theater presentation has now changed. So my picture has been replaced with the content of my application. And this is all completely live.

I'm going to go ahead and change Los Altos and we'll go ahead and make Los Altos a 10 here. And it automatically updates from within iChat Theater and you can see the presentation that Larry gets on his side, he'll see a small picture of myself along with my application content. So we can go back to slides.

So that's really how easy it is to add iChat Theater into your applications. As you can see, it really just takes a few minutes to do this and adds, it could add some great value to your applications. So to wrap things up, I wanted to tell you about a few of the great resources that I use when developing on the Mac.

One of them, you're here, WWDC. This is like the Mecca. This is the place where you're going to get the latest and best information either through the presentation format that we have here or if you have individual questions, down in the labs downstairs, where you can work one on one with the engineers that actually write the technology.

And I also want to encourage you to enjoy the social aspect of WWDC. We have events going on in the evenings. Tonight we have the AD, ADC, ADC reception on the third floor. Tomorrow we have the events, stumps the experts and the ADA awards, Apple design awards. And on Thursday we have the bash up at Gwenna Gardens. So it gives you a great opportunity to meet other developers that are in the same boat as you, working on the same types of things as you.

Next is Cocoa Heads. Cocoa Heads is an independent developer group and they have organizations ranging from Toronto, Canada to Osaki to Quala Lampure. So if you go to Cocoaheads dot org, you might be able to find a Cocoa Heads meeting close to where you live or its very easy to start one up.

Or if you don't like either one of those and you just want to try one out, you can go this Wednesday at 7 o'clock in the Apple Store, not too far from here, we have a Cocoa Heads meeting and the theme is going Indy. So we have some of the you know prominent Independent Mac developers will come up and give some advice, both technical, marketing type advice on what it takes to, to go independent with your own company and writing software for the Mac.

There's, there's a saying that if you ask any Cocoa developer what they're favorite book is, they'll always name two books. And one of them is always Cocoa Programming for Mac OS X, writing by Aaron Hillegass. I talked to him about an hour ago, he's revving this book to, to work with Leopard. And he also is teaching at the Big Nerd Ranch. If any of you have heard about it, the Big Nerd Ranch is this immersive class, week long class where you can go to and learn all about Cocoa, just immerse yourself for one week over in Atlanta.

One of the neat things about the Mac OS X development in general is it has this great little ecosystem. There's a number of independent developers out there with their own blogs. And I usually use the site Cocoa blogs dot com which is kind of an aggregate. It'll take all these individual blogs, write a sentence about each of them and then post links to the, to the most influential or most interesting blogs. And lastly, developer dot apple dot com. This is the place where you're going to go to get all the information from Apple, whether it be information about conferences we're having, latest technical information, SDKs and so forth.