Hello, everybody, and welcome to session 302, Introduction to Xcode. I hope that was the glitch for the evening with the bad batteries in the clicker. That's me. And, all right. We have a full packed program, and we'll be going a little bit more in depth from what you've seen yesterday in session 300. Let's talk about what does it take today to be a modern IDE.

First of all, you have to have a streamlined workflow. These days, your projects are huge. You have tons of resources, many hundreds, thousands of source files, et cetera. And you need to be able to focus really quickly on what it is that you're working on right now, and be able to manage and navigate all those files really efficiently.

You also need a powerful editor. That goes without saying. You have to be able to go through your long files, find your methods, navigate through all that source code, maybe group files together, which you're working on, just having a small working set. You need a fast and flexible build system. Fast goes without saying, because your product is so big.

But it also has to be flexible. You have to be able to customize it, what to do with a C++ file, what to do with a Nib file, etc. So you need to be able to make it just right for you. You need to have quick documentation access.

OS X is really powerful. It has really powerful APIs, Cocoa and Carbon. All together they have numerous thousands of API calls, and you have to have an access to documentation of those API calls really in an efficient way. And it should be integrated with the UI and profiling tools.

Code that you're writing is just part of the story, right? You're also doing the user interface design. Maybe it's not you who's doing the design, maybe there's somebody else doing it, but you better integrate, so when you add in your resource file, it gets reflected in your IDE. Then profiling, you wrote your app, it's finally working, it's not crashing, but it's kind of slow, so you need to profile. It would be good if the profiling tools knew about the source code and vice versa.

So finally, source control management. Chances are that if you're writing a large application, you need to write it on your own. So there's a large team of you, maybe there's a dozen, maybe there's a hundred of people, and you need to integrate with different people together through the source control management. And the last-- I don't think the batteries are quite there.

The last thing that you need is API awareness in the debugger. Source-level debugging goes without saying, but it will be really nice if you had direct display of your own personal data types, as well, in the debugger. So now let's have a quick look at Xcode. Here we can see we do have a streamlined workflow. As Steve Naroff showed yesterday, in 300, you have really quick access to all of your data and all of your files. You do have a powerful editor. It features code completion.

Today, we will show you how it really works. You have access to your methods, to individual methods, to files by groups, etc., You do have a fast and flexible build system. Today, we will not go quite in-depth on that. There's session 303 in 24 hours right here, so you can see more detail about that there.

You have quick access to documentation. Apple's previous tools were actually pretty good at integrating the documentation, but we have made it much, much more efficient even than what we had so far. We're now using the Safari rendering engine, as you saw maybe in the previous session, and that makes rendering of documentation much, much faster and prettier. And it is integrated with UI and profiling tools. We will see some demos of that later today.

It is integrated with source control management. Xcode features integration with CVS, and also with Perforce. This screenshot is not necessarily the most indicative of that. And we do have API awareness in the debugger. Again, main is not the best place to show. But it gets even better. These were the of courses.

Speed is really important. So we have taken great care of improving many little things which add up to a big picture. First, we added Zero Link, which basically eliminates the need for linking altogether during the development cycle. We have added Fix and Continue, which eliminates the need to stop and relaunch your application while debugging. We have an annotated source editor, so that any compiler errors or warnings are visible right in the editor as you're there. You don't need to have an extra panel pop up and click between windows if you choose not to do that.

We have CodeSense, which is our way of code completion, but it's actually more than that, and more on that later. We have parallel and distributed builds. You saw a demo of that yesterday, using all those beautiful Xsers over there. It works even without Xsers. It works with just your neighbor's computer, or when you're at home with your wife's computer. We do have predictive compilation that kicks off the compiler in the background, while you're still typing. and... So when you add it all together, it actually adds up to something that's really, really fast. All of those little things put together are something very fast.

So let's have a closer look at all those things. This was just very superficial. Now the project window, as you saw before, on the left side you have an outline view of groups. You have static and dynamic groups. Static groups you create the way you want them to be. And dynamic groups-- we also call them sometimes smart groups-- are generated and maintained for you by Xcode. You can have files filtered or kept together by type, by file name. You also have smart groups for find results, for errors, et cetera.

You can do searching and filtering on any of those groups. So you can search on special variable name, and then you can filter just in which files you want to look at them furthermore. This is very important when you do a batch find, or maybe even a batch replace, and you find yourself in a lot of trouble. You need to narrow down the search.

You have an optional integrated editor. You can use the main project window for text editing as well. So that eliminates the need for having many windows, which is especially helpful when using a 12-inch PowerBook, for instance. And you have inspectors with search fields. We'll see more of that in the demo, but it allows you to search and find compiler settings, for instance, very quickly.

The Xcode editor is the other very important, it's the key part where you're probably going to spend the most time, because you're writing source. It allows you to apply sources to the application which is running, as it is running from within the editor. You don't even have to open the debugger window. You can do it right away from the editor. It features CodeSense.

Again, that's code completion and more. The errors are shown in source code, and we'll see that in the demo. You have quick access to documentation through command clicks, option clicks, and through other means. And you, of course, do have customizable key bindings. You can set up your own key bindings. You can set up, we have pre-canned Emacs, CodeWarrior, MPW, and other key bindings.

Now CodeSense, I mentioned it a few times before. Xcode stays completely aware of your source code. It parses your code in the background, and as you make changes to it, it knows what you're doing. So it offers you code-sensitive, context-sensitive code completion. It also allows you to do class browsing. Yesterday in a demo, you saw briefly search on symbols. You can search just on definitions, on many other things. And we'll see that later today in the demo. And there's going to be more coming based on this technology of CodeSense in a future release of CodeSense.

What's important about it is it works for code in progress. It doesn't have to be compiled. So as you're typing new code, and even if it has bugs in it, like you forgot some curly brace somewhere, it will still work. And that's very powerful. Yet it uses the same parser, or very close to the same parser as the compiler. So it's taking the same path as your compiled code, which is also very important when you do if-defs. Works for C, C++, Objective-C, and Objective-C++. And we will be adding Java support for that in Panther GM.

Now the inspectors. In Xcode, we have added a new set of inspectors with a consistent user interface, very simple interface. It allows you to inspect target dependencies. To set compiler options on a clear text way, which is very user-friendly, and to view documentation for your compiler settings and linker settings, etc.

It allows you to set up the build rules, as I said, those are the rules, what to do with a C file, what to do with a Nib file, etc. You can add your own rules, you can change the rules that we ship. Project settings, which are more global settings, like where to build, where to put the intermediate stuff.

CodeSense settings, which is Inspector, which needs to be properly applied when you actually want to use it. And source code settings, that would be indentation, tab stops, filing codings, or using UTF-8, or using just plain Mac OS Roman. And I talked a lot, I would like to invite Matt Firlik, senior engineer on the Xcode team, and he's going to show us the workflow in Xcode. So Matt, what do you have for us? Thank you, Stan.

We haven't done anything yet, so hold on. So we're going to talk about some of the workflow issues. One of the complex parts about workflow is that we all spend a great deal of time with workflow every day. We move between files, debugging, documentation, a whole gamut of things. But the complexity comes in that we all do it just a little bit differently.

Some people like their windows in certain places, certain sizes, certain keystrokes. The important thing to note about Xcode is that instead of trying to provide a single idiomatic approach to workflow, instead we take the approach of providing flexible and customizable options for navigation and organization of your projects, so that it works as you expect it, but works for everyone. So let's take a look at it. We're going to take a look at a Carbon example today, one that actually ships on the system. It's called ClockView.

So it always shows you an amalgam of that. This becomes extremely useful, as Stan mentioned before, when we do something like find. For example, if I was going to bring up the Batch Find panel, I can actually go ahead and type in the string OS. I want to find where this string exists within every single file in my project.

Click on Find, and it's going to go ahead and show me that list in the detail group. Same idea, same metaphor that we used before, but it's showing me find results. And in this case, the status shows me I have 218 selected. What if I did that again, and looked for, in this case, HIView.

I have 32 in this case. If I go ahead and select both of these together, you can see that-- maybe some of you can't see, but it does really say 250 up there. And if I go ahead and type in main.cp, there is every instance of those two strings in main.cp, which makes it very useful and very quick and easy to get at the content you want by looking at things in groups.

We can also, as Stan said, do the same thing for your project symbols. The information from this comes from the persistent symbol index, as Stan mentioned before. And these are all the symbols that is in this particular application. The number up here says a little under 11,000. I can actually go through and look for all of the methods that look for bounds. And I can see all the implementations of those. Making it really quick and easy to go and find the content you're looking for to go straight to it.

So we've talked a little bit about organization. Let's talk about navigation. How do I actually get to content? How do I work with it? This is one of those things that starts to become a little bit personal about editors. Where does your editor go? So in some cases, people like editors to be all in one window. So we have this button up here, which allows you to pull up the embedded editor and look at your content. So I can go back to my sources, taking out the little item up here in my filter, click on a file, and it shows up in line.

So I can go ahead and take a look at my file using the built-in functionality of the editor. I can scroll down to something that I want to create to edit. Or I can use the function pop-up, which lists all the functions in this particular class, and jump to something that I want to work with. As I select more and more files, each file is put into the particular view, and I can go ahead and work on it.

But as you see, it takes up a lot of screen. And some people may want a larger detail view. So in some cases, you may want to have an external editor. So as one of the main idioms in Xcode is double-clicking brings up an external editor. So I'll go ahead and double-click on a file. And there's my main.cp. I can go ahead and actually double-click on the rest of these.

And I can bring up external editors for all of them, which then brings up the very important question, how many windows is too many? In this case, I have three open, which starts to kind of clutter my screen real estate. So there's an actual nice little customization here, where in the upper right-hand corner of the editor is something called the editing mode.

For those of you who can see this icon, it looks like there's three windows paned one in front of the other. If I go ahead and click that, it becomes a single pane that now every time I double-click on a file, it's opened in that editor. So it's always open in one external editor, giving you the ability to work in the way you might like.

However, once I have this external editor open, I have to keep going back and forth to get more and more files. And it kind of destroys the flexibility of having this separate window to edit things. So much as I said double-clicking on something would open up a particular file in the external editor, I could actually double-click on a folder. In this case, it actually opens the first item in that folder. But I can go ahead and click-- I can go ahead and drag the groups and see the groups on the left.

So now you can start thinking of editors as collections of things that you want to work on, bringing up possibly more than one, but still having the flexibility to either click on the file or just go ahead and drag into the editor and go ahead and work on it. This, of course, works the same for the project, where I can click there.

And now I have the entire contents of my project in one external editor, which then allows me to go back and use a feature that we affectionately call MetroMore, which is to double-click on these column headers. And I can get some more workspace back. So now I can start looking at more and more windows without having to resort to using expose or something to see all the windows to give you a little bit more functionality.

So once we've edited, or actually, let me take that back. Once we've gone to a particular file, let's talk about things that we would want to edit. So I can go down and let's scroll down to the bottom here of this particular class. I have a method here, hi set visible.

Let's just say, for whatever sake, as I was developing with this, I didn't actually put that in. And I knew that I needed to put something here. If I weren't familiar with some of the APIs, or I needed more information, what I would like to do is use some of the other assets that Xcode has to provide this information for me.

One way of doing that is to go to the documentation window which provides me a list of all the information that I can look at based on a particular topic, like Carbon, so I can scroll down through the topics. Or I could actually use the nice little API search to go ahead and type in something, like hiviewset, find the function I want, click on it, and see the documentation. Very quick way to get to information about things that you use or you want to use.

However, in some cases, going to the documentation might take a little bit of time if you're not sure exactly what you might need. This is where some things like CodeSense comes in mind. You might want to go back to the Symbol Smart Group and do some filtering looking for a particular method.

You might also want to bring up the class browser that we ship that also has the same information showing you the hierarchy of the information in your classes. I can go through and click on a particular method, actually see the definitions, go ahead and look at those and use one of those in my particular implementation, which is great for reference information.

But when you're in the midst of developing code, what you really want is you want that information at your fingertips. You figure Xcode already knows about it. I'm not really sure what I want yet, but why can't you just give it to me? Well, as Stan has pointed out, we actually have.

So what we do is provide as one of the features of CodeSense is code completion. It's the ability to figure out contextually where you are with some information about potentially what you want to give you that information. So I'm just going to start typing here. I'm going to type hi, and I'm going to go ahead and hit the completion key.

What it's going to do is it's actually going to go ahead and take that information, take that prefix, take contextually where I am, and go and try and figure out what it should provide. In this case, it went back and pulled out all the list of functions that start with hi. Actually, let me go ahead and move my window over here a little bit so that I can show this to you a little more easily.

You'll see that there's a nice little scroller here. I can actually scroll through this extremely long list of elements, which gets me closer to what I want. But I'm looking for more information. So I could actually just go ahead and keep typing. I could actually just type hiview. And you'll see that the list actually starts to filter itself down.

I can back up and type a. And see in this case, there are only four elements that match. I could type b and c some more. But in this case, what I'm really looking for is-- and Dan Brunner, and Dan Lebowitz, are the founders of the Google Cloud Platform.

The first step is to create a new application, and the second step is to create a new application. and use code completion. Very, very quick and easy to go and get the information you want right in line. So, there are a number of-- Thank you. It's important to note that there are a number of preferences and configurations to a number of functionality pieces within Xcode.

Typically, to go ahead and edit some of those, you would go to the Preferences and pull up the Preferences panel. In this case, for the code completion, Code Sense, they're all under the Navigation Preferences, and you could set it up so that it automatically pops up when you dereference a pointer, when you type a period, and also filter if it's case sensitive when it brings up information.

You can also go to the Preferences and set key bindings, an extremely useful feature for mapping your keyboard to exactly the functionality you want. In some cases, with code completion, people want escape. Some people want F5. Some people want different keystrokes. And we give you the ability to take code completion and all the other functionalities and map them to the key sets that you're most familiar with. When you want to go and edit things that aren't particular to the application itself instead of key bindings, you want to look at things for information on files, I can actually navigate to a file and bring up the inspector.

In most cases, when you want to edit something, the Inspector is where you're going to go. And the Inspector is a context-sensitive way of looking at different aspects of your project. In this case, I'm looking at the general information for the main.cp file. But I should actually go ahead and click up on the project.

And now I'm looking at the information on the project, build styles and other aspects. So when you want to go ahead and edit information, you're going to do so with the Inspectors. So that's just a quick overview of some of the workflow aspects. You'll see more about the Inspectors with the compiling and debugging in later sessions in this demonstration. Thank you.

Thanks Matt for the very good demo. Now, let's move on. There's way more to come. Okay, so now I've written your source code. It's all beautifully completed. You read the documentation on exactly what the app will be doing. Now we need to build it. We need the build system for that.

Xcode has a fully integrated build system that's into the IDE. What does it mean? Well, it's not using or relying on external tools such as Make or Jam or Ant or things like that. It just knows the state of your project. It knows which files you have touched, which headers maybe you have touched. So it has a fast dependency analysis.

It knows that when you change a header, it needs to recompile also this set of source files. And that's immediately reflected in the user interface. You have an up-to-date status. You have also error annotation, which was mentioned before, but it's also shown in the main project window when there's a new project. There's a compiler error or warning.

And you have an optional access to see all the gory details. That is usually hidden away from you. But if you need to, if you're really debugging a bizarre error that it just says build failed because of something that you would expect would be working, well, maybe it just ran out of space or something even more cryptic happened. So you can access those gory details.

The compiler under the hood of Xcode is based on GCC 3.3. We took it from the open source community, but then at Apple, we have added a lot of special enhancements to the compiler. That compiler, from its own, is very fast in generating code. It also generates very efficient code, so not only your compile time is fast, but also what your customers will care about, the runtime of your application, is very, very quick.

PCH, precompiled headers. This is something that actually GCC doesn't have. We have added that. That's an Apple add-on. So that even the C++ people who were complaining about the lack of precompiled headers, so far we now have something that will suit everybody's needs. And finally, we have added support for inline assembly exactly in the Code Warrior style. So you can take your Code Warrior style C file with embedded assembly and compile it right away. We have added many other switches that are to handle progmas, but it's in more detail than is suitable for this session.

and the rest of the team. We also have a new application called Precompiled Headers. This is something new that we added to GCC 3.3. It's a brand new mechanism that works for all languages. It works for C, C++, Objective-C, and the Safari people with C++. And there's going to be more coming with Panther. This is just a pre-release, so the PCH mechanism, you might find cases where it's maybe not quite mature, but we are working on more and getting things more automated.

Now, predictive compilation, that's another step to cut down the compile time. It primes the pump. Most compiles are not, they're also just syntax checks, right? You're trying, did I forget a curly brace somewhere? But even when you're doing turnaround debugging, then you just go somewhere to the code, you change something, and even if you know exactly it's this one character, the time that it takes you to say, command S to save and command B to build, during that time, you know, when you're really fast, it's maybe half a second. Well, during that time, the compiler was already running, and it's ahead of you.

So it cuts down the turnaround time. So it starts the compiler as soon as you start editing something, and it goes through all of your pounding clues, and pre-processes, pre-compiles that. And when you say, actually save and build, it will do just the rest, which is usually 1% of the work.

Then comes the build, something we demoed yesterday, and this is really not the most mainstream feature, definitely not the most mainstream feature yet. This is something more for thrill seekers at this very moment. It takes care of, it takes advantage of rendezvous. It will discover other computers on the net that have the same Xcode version installed, and it will try to distribute the builds to that computer if the user on that computer has allowed that. It creates completely self-contained jobs, so even if you don't have the same headers installed there, or even if there's a little bit of a mismatch, you don't have to have a mapped network file system, for instance. The compiled job is completely self-contained.

And the pre-compiling happens on your machine, and then it gets passed once to that server, but it happens only once. So if you compile more than one file, you actually have a great speed benefit. The greatest speed benefit is around four machines. It really varies on the kind of code that you're using. It really varies on the kind of code that you're using. You don't really need that set of Xservs unless you have a huge build production. Like at Apple, we have built an integration where we built all of OS X.

And when you have large apps, maybe like Maya, having that would make sense. What it requires is a really fast network, 100 megabits or gigabit. With 10 megabit or over airport, you will not see any benefits. So now I would like to invite Anders Bertolud, who's the lead Xcode engineer, to show us a little bit about the build system. Thanks, Stan.

So Matt showed you some of the great features we have for navigating and for editing source code. So I'm going to go ahead and show you how to build it and some of the workflow we have there. So I'm going to open the same project that Matt used. This is the Carbon example ClockView.

And what I'm going to do is to actually show the embedded editor here. So I'll go ahead and open that. And I'm going to select one of the files here called the ClockView.cp. And this is where a lot of the code in this little program is. So what I'm going to do now is just to build and we'll see what happens. Whoa, it had some errors.

Okay. That wasn't expected. So let's go and select the errors and warnings group. As you notice, on the left side, there is now the errors and warnings smart group that shows you any files in your code that have problems last time you compiled them. In this case, we see that there were a couple of errors and some warnings. Okay. You'll also notice that there is an icon in the margin here.

And in fact, if I go back up here, you'll see both the warnings and errors are shown here. I can actually, if I'm looking at just the source code, let's say I'm working in this mode, I can actually just click on this error here and then it will show me what the problem was up in the status field. So what I'm going to do here is to actually show you a third way as well. We do have a warnings and errors panel that, as Stan mentioned, you almost don't have to use.

This is only if there's something really weird that's going on. You can actually see exactly what the build system was trying to do, in this case, trying to compile this file. If you want the real details of what was going on, you can actually select entries up here and it will go down and show you the transcript, including all the command lines. But 97% of the time, you don't need to see that.

So what we're going to do here is I'm going to fix a couple of these errors. This one is just a warning, so I'll just go ahead and delete this one. We've checked that this is okay and everything's fine. In this case, we see that there was actually an error.

Let's see, if I go and click on this, we just had a misspelling, so I'll just enter the I back in there. I click on this one. We see, actually, we need to pass .x. So these were just a couple of warnings that we put into the code here.

I'll go ahead and build again, and it asks me if I want to save. So we've already built, and there's still one error. In this case, this appears to be a macro that we haven't defined. So what I'm going to do here is to just select this and just copy it. And in this case, we want to go to the inspector. So I click open the targets group. This is the target that defines how to build this app called ClockView. I hit the inspector icon, and, again, we can just go to the build.

So I'm going to go to the build settings here and define it. So this is a preprocessor macro that needs to be defined. Now, there are a lot of settings here, and I'm not quite sure which one I want to set, but I know it has something to do with preprocessor symbols.

So I'm just going to type preprocessor. Oh, look there, preprocessor macros. So I can just enter the value in here. I'm just going to paste this. We'll define that as zero. And then one other thing of note is you can actually search here, as you noticed. And if you need to see a description, you can just pull up a text field down here, and you can see more information about the particular option.

And this, if I don't filter anything, it just shows the most common settings that 90% of the time you'll need to use. Things like optimization, preprocessor flags, things like that. If you don't see the setting that you want here, odds are that it's still supported. It's just you need to open the drawer. So opening the drawer reveals the different languages that are being used in this project.

And you can actually disclose this to go down and set particular categories. So let's say I want to change some options about linking. I'll just select this. And, of course, the filtering works here as well. The current setting smart group is a special one that shows everything that's specifically set in this target is different from the default values.

So now to find my preprocessor macro, I'm actually just going to build this again. And we see that build succeeded this time. And one last thing I want to note is you can actually do single file compile. By default, it's bound to Command K, because that's what a lot of people are used to. But you can, of course, bind that to anything you want. You can also show the assembly code or the preprocessed source for any of the source files you're working on. So with that, I will hand back to Stan. Thanks.

Thank you, Anders. There's going to be a much more detailed session about it in 24 hours, session 303, right here, so if you want to know more. Okay, now I've built your application, and contrary to your expectations, it's not quite flawless. There are bugs. So, the favorite of everybody, debugging. We found out from feedback from all of you, from own experience and common sense, that the debug cycle is very important, so we try to squish it as much as we can. We have a very efficient debug cycle in Xcode.

First of all, the debugger itself features a context-sensitive data display. With data view summaries, we have formatters for all Carbon, Cocoa data types, and as well as some other data types. And you can create your own formatters for your custom data types. You can do really simple ones, which are like simple string formatters, similar to printf. Or if you're displaying something really bizarre, you can actually write bundles that the IDE will load, and it will display your own data types. You can, of course, now break on C++ exceptions.

Yes. Another way to reduce the turnaround time is how to get to the debugger in the first place. Zero link. We are adding this feature, which basically does away with linking, because linking is time consuming. Usually, most of the time, you're adding just one file, maybe two, but not your over 1,500 files in Finder, right? So you do just away with linking, and it makes the turnaround time go dramatically down. It loads the object files as they are needed as the application is launched. So this is a very efficient way, but not necessarily suitable for final deployment of the application.

And then finally, we have Fix and Continue, which completely reduces the turnaround time to around three seconds. It allows you to dynamically modify your application as it is running in place. It's suitable mainly for logic bugs, places where you put the wrong variable, you're running over an array, things like that, infinite loops.

Or my favorite, trial and error code. I mean, for instance, I can't never get coordinate transforms right. I mean, even if it's something like this is scaled by that, or the coordinates are rotated, I just can't get it right. And for that, fixing continues is very, very useful. And for UI layout, for instance, as well.

What Fix and Continue really excels at is when you're making changes within functions, changing constants, add and modify local variables, maybe call functions, or even write new functions. So you can do all of those things. Fix and Continue is not so suitable for changing, or actually doesn't work with things that have global effect, like changing headers, or changing globals.

Obviously, when you modify just one file to reference a new global variable, all the other ones, they don't know about it, right? So you would have to quit and rebuild the application for that. Or call signatures. It works pretty well with Objective-C, but it does not work so well with the other ones. And there will be a dedicated debugging session that will be talking great length about Fix and Continue.

And the other debugging kind of tools that we have integrated with our performance. Your application is now maybe running, it's not crashing, but it's still kind of slow. And we ship a bunch of apps, such as Sampler, Malloc Debug, Object Alloc, and Thread Viewer. Those are profiling applications both for speed and for memory usage.

Because when you're leaking memory, that's not a good user experience as well. Now, Xcode is integrated to a certain degree with those applications, the first step. So that Xcode can call them as your debug media, and then those applications message back to Xcode about selections that you make, so that they show you actually the code that causes all those memory leaks or spends a lot of time.

There will be a dedicated session about this. This is session number 305. And I would recommend that you go there. Now, this time I would invite Chris Friesen on the stage. But that guy, he worked so hard, he actually is homesick. And so Anders picked up his demo just this morning. Welcome, Anders, again. ANDERS FEJS: Thank you. Unfortunately, Chris couldn't be here. So I'll get to demo his really cool features instead. So I'm again going to open the ClockView example here.

And so you've seen it being edited, and you've seen Matt show off some of the navigation features. You've seen us build it, but you actually haven't seen it run yet. So let's do that now. I'm going to go to one of our pop-down toolbar buttons-- actually, this one-- and I'm going to say build and debug first of all.

And we'll get the clock view up here. And it looks kind of odd. It has a dark gray background. So we're going to fix that. So I'm going to minimize this and pull this over here. I just want to open up the embedded editor again. I'm going to go down to my clock view source code here and go through this here. I know that there is some place in here where the shade is being set. And so what I'm going to do is I'm actually going to go down and find the fill shade equals statement. And if I can type it right, we'll go to it.

So there are a couple of parts to this here. I see that there's a fairly dark color here. I'm just going to go ahead and change this. And I'm going to save the file. And then you notice the check mark appears here. This is the build system paying attention in the background and says, oh, I need to compile this file now because you changed it.

So there's also a tape dispenser. So let me just go ahead and click on that. And we notice that it's compiling the clock view. And it's going back into the app here. And it's actually changed the code on the fly. So the clock continues running, but now we have a nice white background.

But you may notice there's something odd going on here. I'll make it larger so you can see. It says that this is quarter past 4:00 in the morning. Apparently, we have a logic bug. So let's try to find where that might be. Let's go ahead and search for the string AM here.

And we see that it's right here. So let me actually go ahead and look at this. And we say, ooh, greater than 12. That's not good. It should be less than or equal to. So let's go ahead and change that to less than or equal to. I just make the clock a little bit smaller here in the background. And let's go ahead and save the file, and we'll fix and continue that again. So now it changes to PM. So we fixed the logic error.

So as you can see, this saves a lot of time. If it takes a long time after you start your app to get to the part where the problem occurs, you can save yourself a lot of time here. So, so far we've just changed a constant, we've changed some logic. Let's call it function. So this white background here is kind of boring, so I'm going to go ahead and search for the fill shade again.

And this time, I just want to go ahead and type something here. Let's see, that changes over time. So let me go ahead and get a random value here. So I'm calling a function in the library. And let's see, maybe I'll compile that. And then, whoop, we had the error again. Okay, parse error before the parentheses. So we'll fix that.

will do the fix again. So now we see that every second, it picks a new shade of gray. So we're calling a function in our code now. All fix and continue. So, um,

And also you see here a summary of the event for the event ref in this case.

So what I'm going to do here is to step a couple of lines here, and I'm going to step down to line 205 here. And you notice that root changed here. It was invalid before. We highlight the change value in red. This indicates that it changed in the previous step. And we show a summary for that as well.

So, that's kind of cool. One of the things I'm going to do now is to, I'm going to go down, and there's another breakpoint here. I'm going to go ahead and enable this breakpoint. I'm going to resume the debugger. I could do this in either. As you notice, I go back to the text editor here, or the debug window. I could actually edit and see the source code in either one. It doesn't really matter. I'm going to continue here, and now it stopped at the breakpoint I just set.

So this is where we assign a rectangle variable. I'm just going to go ahead and step over this. And first let me go down to QBounds. It's here. It has garbage values, just on the stack now. Just going to step over this. And notice that it formats the rectangle coordinates according to the Carbon definition of a rectangle.

But this is just four numbers. This is kind of confusing. What if I wanted to edit this myself? Well, let's say I wanted to put in labels. I can actually see here that if I double click on it, I go to the definition of this formatter. And I can just edit it in place. I can see the left is equal to this value. The top is equal to that value. The right is equal to that value. And then I go, actually, that was the bottom.

and then I say R equals. Now when I hit return, it actually formats the string according to the definition that I typed in. So you can reference any arbitrary subfields of a structure that way. And this definition is now stored for me per user in this project, so you can customize it to your liking.

So these are just two of the features that the debugger provides. We have Fix and Continue, which of course lets you get back up into your app again without having to restart it. Great for logic errors, changes sort of within the curly braces of a logic of a function.

And the other really powerful feature are the custom data formatters. So depending on whether you're using Carbon or Cocoa, it automatically load in custom data formatters. And as you saw, you can define your own or modify the ones that we provided for you. So that's all I wanted to show today. There are more sessions on debugging and on the build system as well. Thanks, Stan. Thanks, Anders.

Now, that's just part of what it takes to create an application. This is just the code and the debugging. However, there's also the other part, that's the user-visible part, that's user interface. And so it is my pleasure to introduce to you Mr. Eric Seymour, who is the lead engineer on Interface Builder. And he's going to give you an introduction to IB. Great.

Thanks, Stan. OK, so, so far you've been listening and dealing with code issues related to your projects. And of course, it's very, very important, but obviously a big aspect of your projects are user interfaces. And at Apple, we build interfaces with a tool called Interface Builder. And I think for those of you who haven't seen it, a couple of slides just to let you know what this thing is are important.

So what is Interface Builder? Well, Interface Builder, or IB, is Apple's way, or is Apple's tool for building Aqua-compliant user interfaces. And of course, it supports Carbon and Cocoa, and of course, works with Xcode. Now, just to be clear, Interface Builder is a graphical tool. You drag things off of a palette, drop them onto Windows, resize them, set properties, and perhaps most importantly, establish relationships, drag connections between things, sometimes, and perhaps most importantly, between things in your interface and in your own source code. Very, very important.

So where does Interface Builder fit in the grand scheme of things? Well, Xcode manages all these resources in your project, especially source code. And you've been hearing over the last couple of days all sorts of techniques for reducing the amount of time you need to spend in your source code, right? Reduce your compile loop, reduce the amount of time it takes to go find something, make changes.

Well, Interface Builder perhaps is the best example of this, because Interface Builder does not actually generate source code as the artifact of your interface. It produces archives of your interface objects. So it's not creating source code that you would then have to compile and build into your application. It's just another resource managed by Xcode, compiled or built in the build process, just simply copied into the final product of the application.

So, what's new for Carbon with Interface Builder? Well, you heard that HIView is the future of Carbon, and Interface Builder is constantly evolving to support that notion. You'll notice right out of the gate that we support several new HIView-based objects, HIImageView, Search, Field, ScrollView, and more. And also, and it's not written down here, but we now support embedding in custom controls.

Of course, we also support all of the new interesting features of Panther, including many controls and other important things, such as new metrics and such. and then control properties. This is a new feature that I like to spend a few minutes on in Carbon support, and what this allows us to do is add ad hoc data values to our controls right in a nib file. So to do that, I'm actually going to demo.

And I'm going to quit this application because I need to restart. So for this application, I also am going to use ClockView, standard shipped example for Carbon. And let's just run this thing real quickly here. So I'm just going to run this app. OK, ClockView, pretty straightforward, pretty boring. I need to add a feature to this. So the feature that I've added is I want an image to show up in the background of this clock.

So as any good developer, I have a few options of how I'm going to do this. Well, clearly, I'm going to write code to do it because this is a custom control. But how do I make it--how do I manifest it in the interface? How do I trigger its inclusion in the interface? Well, one way to do it is to write more code, compile it into the app.

Another way is to write some code and perhaps leverage fix and continue to maybe speed up that process. But another way is to abstract the inclusion of the actual image, the triggering of that image into my nib file. And so I'm going to do that right now. I'll-- With the application and I'm going to bring up Interface Builder.

And here is the nib file, so to speak, the file that contains my user interface for Clock View. And this view right here represents the custom control that is the Clock View. And I'm going to bring up the inspector for this. And in the control inspector-- for those of you who may be familiar with the control inspector in the past, you'll notice this new table view at the bottom. And this is a place that I can associate ad hoc data properties right to this control. So at runtime, I can pull them out and do something interesting.

So I'm going to add a new property to this. I'm going to give it a creator code of my app and call this image, and it's a Unicode string. And I happen to have an image in my project already included called Panther. And I'll just save my nib file, hide interface builder, and quick build.

And all that did is-- Copy the Nib file into place, no recompiled code, image in the background of my clock. Now, this is important because this, This is important because this gives me the ability to be more than just a viewed editor in Interface Builder. It gives me the ability to take attributes that I've coded into my custom view and make them available at a level where somebody doesn't actually have to write code to do it. So, for example, if I go back into Interface Builder, say I want to have another one of these, I could duplicate this or drag it off the palette, basically just create another custom view. And this one I'm going to change. I'll stick another image in there.

I'll add a new property to this, and this one's going to be rotate. This happens to be a float value. Now, this editor gives us the ability to set the actual type of the data that I can retrieve when I get that property. This is a Boolean, and I'm going to call that true, to resize my window, and I'm going to save. Hide Interface Builder. Quick Compile and Run, and two objects, slightly different data in the nib file, but effectively, I've repurposed that object without writing any new code. Okay.

So let's go back to the main screen. All right, there's my demo. All right, so let's talk about Cocoa for a few moments. So of course, in Cocoa, we're supporting, just like with Carbon, all the Panther controls and sizes and interesting features. One of those, of course, is a brand new feature called the Controller Layer Support.

As hopefully most of you saw yesterday, there was a, we're supporting WebKit. and for those of you who may be familiar with Interface Builder of the past, we're trying to satisfy a long requested feature, and that's adding data cell support to table columns. So you can just drag them off your pallet, drop them on top of your column, and you have your cell. And we've also revamped the Connections Inspector.

So, to demo this, I actually want to focus, I only have so much time, and I want to focus on one very important feature, and that's the controller layer. Now, Yesterday, hopefully most of you saw the example where we built a web browser without writing any code. And we didn't just build a web browser. Then after we were done building the basics, which is the old IB demo of target action, we polished it.

We made it really clean. And hopefully you recognize that typically to make an application really clean, you've got to write code. You have to take advantage of more than you can do with just wiring up a few connections. And we did this with this new feature called the Controller Layer.

Now, I'm going to deviate from that demo. I'm not actually going to show that to you, because I think it's important to show the raw materials of what the Controller Layer is giving you inside Interface Builder. So to do that, let's quit out of this, and quit Xcode, and just go into IB.

And let's get rid of this, because I don't need it anymore. I'm going to create a new application here, and I'm going to do the staple of Interface Builder demos, just to start. And that's the slider text field demo. So I can hear the yawns. Everybody's seen this before. but this is an important moment in the history of IB.

So there's my slider. Oh, and by the way, let's just pop a new feature here. Let's just make that a mini slider, just so that I can demo yet a new feature. And I'm going to make my text field really large. Another thing that's worth noting is we've reorganized a lot of the palettes and the inspectors to accommodate for new features. Hopefully you find them more streamlined, and we appreciate feedback.

So, when I'm doing this, what I need to do is establish a connection between this slider and this text field. I'd like, when my slider moves, I'd like the value in my text field to change. Okay? So, I do that by dragging a connection in Interface Builder, and when I do that, Interface Builder gives me a list of all of the possible things that that text field can do when it receives a message.

So, I'm going to choose "Take Double Value From." Now, by the way, I just want to point out another little feature that we've added to Interface Builder. We've added type-ahead support. So, if this list were really long, I could just start typing keys. "P", "Take Value From", and it'll jump around. This is especially important, for instance, if you target first responder, and you've got to scroll and find the thing that you want to deal with.

Okay, so let's make sure that I have that connection, take float value from, test our interface, right. So now, when I'm moving my slider, now it's a mini-control, it's harder to hit, I change my value. Okay, so this is kind of interesting, right? Many of you have seen this, but the reality is, that text field has a whole lot more capability than just showing a value.

Right, and we take advantage of that today in our interfaces. We have colors, we have sizes, we enable items, we disable items, sometimes we hide them, right. And so, what do we do? We go to code. Now, what I'd like to do is unwire this, and here, we'll disconnect that. And now I'd like to use the controller layer to solve this problem for us. So, to do that, I need a controller. And so we have a new palette here, it's the controller palette. And I'm going to use the most basic controller we have.

Which is an object controller. And you can think of this like a traffic cop, like a, well I was going to say traffic cop. You can think of this like a traffic cop. It basically is going to look at all the pieces of our interface, and it's going to monitor this, when it sees a change there, it's going to change a value there.

It's going to do all the right things for us, so that we don't have to write that code. Okay. So, I have my controller. Now, I need to make some bindings to this controller, so that this actually does something interesting. So, I'm going to go to a brand new inspector in interface.

And it's a very important one, so we put it right under attributes, it's called bindings. And the bindings inspector is interface builder's window into all those other properties you had to go to code for in the past. Okay, so on my slider, which I have selected now, I could enable it or hide it, it has max and min value, and it also has value. And I'm going to choose my object controller, which I just created, and I'm going to bind to a key called number. Just an arbitrary key.

And then I'm going to go to my text field. Note that it has a much longer list of things that you can do with the text field. It's just a more interesting widget. And I'm going to choose my object controller, and I'm going to bind to the same value. Number.

But I'm going to do something more here. I'm going to close my value, and I'm going to go to font size. And I'm going to go to my object controller, and I'm going to bind font size to that exact same value. Okay? And when I test my interface now, not only is my value changing, but my font size is changing as well. Now, this is the new slider text field for Interface Builder and this is what I meant when this is kind of a groundbreaking step for Interface Builder.

Because for years, we've been asked how come I can't have more than one action or how come I can't have more than one target. And the reality is that that's the wrong way to solve this problem. The right way to solve this problem is to have a controller, one of them, be the controller for all of these pieces. And all you have to do to that controller is give it its--give it the rule list, the roster. Okay, here's what you need to do controller. You need to monitor this thing and that thing and these things over here.

And oh, by the way, it would be really great if you could persist this data in my data model too. And so controllers also have implied depending on the controller type, the ability to persist that data in the user defaults database or perhaps another database. I'm just using a raw object controller here so it doesn't actually have persistence but I could have used the user defaults controller. So that's what I wanted to show you for Cocoa and I have lost my clicker which must be over here. Now, there's one more thing.

And that's compatibility checking. So, we're on our fourth major release of Mac OS X, and that means that there are all these features trickled into releases month after month, year after year, and you have to support them. And we recognize that we need to make it easier on you to support these features reliably.

So, what we have done in Interface Builder is add better compatibility checking support. So, basically, select the format you want your Nib to be in, tell it what the target platform is, the oldest target platform, and watch for errors. And Interface Builder will warn you when it thinks you're about to do something wrong.

For example, if you are targeting Mac OS 10.1 as your oldest target platform, perhaps you shouldn't pull a spinning progress indicator in because that wasn't supported on X.1, and it just won't work. In fact, that's a data loss one, so you won't even be able to save your Nib. So that's all I have to talk about today. Thank you.

Thank you, Eric. That was a very interesting demo. There will be more on that. Summary. Xcode gives you a very efficient workflow. It's fast in all respects. It's fast at building, at debugging, and also helps you to be fast on your end through profiling. We want you to use it.

Install it both on Jaguar and Panther. In your package, there should be two CDs, one for Panther, one for Jaguar. 99% of all features are available on Jaguar, all of them on Panther. And please do send us feedback. The product can be only as good as you help us make it by giving us feedback.

So to start with feedback, who to contact? Godfrey DiGiorgi. There are mailing lists. There is an Xcode specific mailing list at the very bottom. We do read this. Heck, our vice president has said that he will be reading that email. So,

and the roadmap. Session 303, increasing productivity, 24 hours here. There's a special session about GCC. There's a session about performance tuning with the performance tools. There's a special session about Carbon with Xcode. And there will be the feedback session where you can give us a earful of feedback. And finally, debugging on Mac OS X after the feedback session.