Good morning. Welcome to Using Xcode: Source Control Management, Debugging, Editing, and Refactoring. My name is Andrew Pontious. I am one of the managers of the Xcode IDE. The goals for today's session are as follows. We're going to show you how Xcode can help you do your job better and be more productive at your everyday tasks. We're going to cover all the major areas of Xcode functionality, everything except the build system. For that, you'll want to go to Understanding the Xcode Project Management and Build System at 3:30 today in this room, Marina.

This session is going to cover a lot of cool Xcode functionality, but it's not an introductory session. We're going to assume that you understand the concepts behind debugging and SCM and programming. And while some of the features we talk about today are new in Xcode 3.1, the rest are already available to you in Xcode 3.0, which shipped with Mac OS 10.5 Leopard in the fall of last year.

So how are we going to achieve these goals? Well, we're going to start in the same way that you would, with SCM. Now, with our sample project, we're going to be showing you how Xcode works with Subversion. But Xcode also supports CVS and Perforce. Then we're going to run our application and show you how Xcode's debugger can help you analyze the behavior of your application at runtime and even change that behavior dynamically. Finally, we're going to add some new functionality to our application using the features of the Xcode text editor and Xcode's automated refactoring tools. So, let's get started.

with SCM. Now, there are five Xcode SCM features we'll be showing you today. One will be showing you how to set up Xcode so that it can configure your projects to use SCM automatically. This feature is new in Xcode 3.1. Two, we're going to show you how to import your project into an existing SCM repository.

Then we're going to show you how to check that project right back out in order to make changes to it. Four, we're going to show you how to use Xcode's user interface to see the history of individual files in your project. And five, we're going to show you how useful Xcode's SCM comparison window can be in your programming. Get started with the demo. Helping me out today is Justin Garau.

Now, the project that we're going to be using for our demos today is called Cocoa Slides. Cocoa Slides is a project that shows you how to use the new core animation APIs that were introduced with Mac OS 10.5 Webber. You can get Cocoa Slides for yourself by going to developer.apple.com and searching on Cocoa Slides. Now what we've done is we've taken the project and we've modified it, both removing some functionality and adding some new capabilities. All of that history, all of those changes, are recorded in our Subversion Repository.

Now, let's say we didn't know about Xcode's killer SCM support. So what we did was we checked out this project using Subversion's command line tools. But now that we've heard about Xcode support, we would like to enable SCM support in our project as easily and painlessly as possible. So let's open Xcode and do that right now.

Now, we'd like to go to the SCM portion of Xcode's preferences, and we can do that by going to the SCM menu and choosing Configure SCM Repositories. This brings us to the Repositories tab of the preferences. As you can see, right now it's empty, but we'll change that. So we'll go to the Options tab.

And we'll go down to the bottom. There's a new checkbox there in Xcode 3.1, configure SCM automatically. So we're gonna check that. So it's an opt-in feature of Xcode 3.1, but I encourage you all to opt in yourselves. So click the OK button. And now let's go find our project in the Finder and open it.

So Xcode does a number of things for you now. It starts by offering to create a repository configuration for us, so let's click the Create button. Then Xcode opens the project, but it also opens our Preferences window, so let's go back to that. You can see that now there is a repository configuration for the repository that we checked out our project from.

Because this is a Subversion Repository, the most important field in the configuration is the URL field. This is the same URL you would use to get at that project from the command line tools. Now, if we were entering this URL manually, after you were done typing it in, you would press the Tab key, and Xcode would automatically fill out the rest of the fields for you. In this case, it's filled in the Scheme field and the Path field. Now, the green circle at the bottom tells you that Xcode can connect to this repository successfully.

Now, you might be thinking to yourself, well, this is great if I already have something checked into my repository, but what if I'm just starting out? What if my repository is empty? We can help you with that, too. Now, the Preferences window that we're seeing here allows us to add, remove, and edit repository configurations. But if we'd like to actually perform some SCM operations, we need to go to a different window. So let's close this one, and we'll go to the Repositories window, which is also available from the SCM menu.

As you can see, now our repository shows up in the Repositories window, and our CocoaSlides directory is there and it's selected. So we'd actually like to operate on the top level of this repository, which means we have to deselect this folder. So we can do that by command-clicking on it.

And then, importing something new into our repository is as easy as clicking the import button in the toolbar. So, we'd like to import, let's say, the Sketch project, which is available from the examples directory of your developer tool's installation. And so you can see it's in examples, appkit, sketch. So once we've selected the directory we'd like to import, we can type in a comment that will go along with the import operation, and click the Import button.

See, Xcode tells us when we're done. Now, we could do all of this without resorting to needing to know any command line commands or options. It's all just very simple from within Xcode. And now let's do it again by checking out the project. Again, there's a check-out button. And let's put this in the same place where we checked out our Cocoa Slides project.

Now here's the next thing that Xcode does for us. Xcode will scan the top level directory of our checkout and see if there are any Xcode projects in it. And if there are, it goes ahead and allows us to open it directly. Let's go ahead and open the project.

The second thing Xcode does is it makes visible the SCM column in the Groups and Files tree. The SCM column is how you can see the SCM status of all of your files in your project. For the third thing, we want to double-click the top-level node of the Groups and Files tree. This brings up the Project Info window. We'll go to the General tab, and you can see at the bottom, the SCM Repository project setting has been set for us to our repository.

So we can close Sketch and we'll go back to Cocoa Slides. Now, you're seeing Cocoa Slides for the first time, so you may be asking yourself what sort of changes have been made to it. And Xcode can help with that. So let's select one of our files. Let's go to maincontroller.h. And we'll bring up the SCM history for the file by going again to the SCM menu and choosing Get SCM Info. This brings up the File Info window and switches to the SCM tab.

Now, the type's a little small here, but you can see that there are three check-ins that have been made for this file. And the two later ones involve removing APIs. So we'd like to see some of that. So let's select the first entry there, which is the initial import, and the first removal of APIs. And then click the Compare button.

This brings up Xcode's SCM comparison window. So the revision one is on the left-hand side, revision six is on the right-hand side. And you can see that as advertised, there have been five APIs that have been removed. So in the middle column, there are arrows. So let's click on one of those. And you can see that here we're given some choices. The first choice is to choose the left-hand side. So let's do that.

And you can see this shows you another property of the comparison window, which is that the right-hand side, in addition to just showing what revision six is, also shows the results of our choices. The right-hand side is a merge view. So let's try it again. Let's go to the third arrow, flip that over.

And now we'd like to save the results of our choices. To do that, let's go to the File menu. And you can see that the option available to us here is Save a Copy As. So why is it called that? It's called that because we're not actually looking at the file that we checked out. We're looking at versions of the file that came from the repository.

So now we could go ahead and save this particular version of the file over top of the version we checked out. But that might clobber any changes that we've made there. So let's call it something new. Let's call it a main controller merge.h. said that all of our choices are saved and we can use those choices later on in our programming. So this shows you some of the features of Xcode's SCM support. We can go back to the slides. Switch to the slides.

Now that we've shown you our SCM support, we're going to go ahead and run our application and show you the debugger. And to do that, I'm going to bring up Chris Friesen. Thank you. Hi, my name's Christopher Friesen. I'm manager of the debugger team. Now that we've checked out our source code from SCM, we're going to see how we can use the mini-debugger, data tips, and breakpoint actions to not only explore how our application works, but also investigate some changes that we might want to make later to the actual source code. And then at the end, we'll look at some debugger display options.

The mini-debugger is a small window that floats above other windows, including your application. And this allows you to interact with Xcode's debugger without your application deactivating. You can then use data tips to view variable values, as well as the debugger strip to switch between threads and stack frames.

In its running mode, it's condensed down into a small window that's nearly actual size if you're in the back of the room. On the left is a stop button that will stop the execution of your program, pause button that will drop you into the debugger, then a button that will take you to Xcode's project window, and finally a button to activate and deactivate your enabled breakpoints. Once you click pause, this is now the pause mode. It expands to show you your source code, and you can interact with it there.

Now, data tips let you view variable values directly in your source code. You simply hover over a variable value with the cursor, and then a window pops up to show you the actual value. So here we've hovered over self. It's got a little red box around it. And then the data tip comes up, and then you can automatically navigate down into elements of that variable.

You can also select some text in your source code. Hovering over that will give you a little evaluate icon. It's a little blue circle with an eye in it. It's kind of hard to see in this particular slide. Clicking on that will then evaluate this expression in the debugger, and then we see the result here in a data tip.

The data tips also have a contextual menu, highlighted here. This will allow you to print descriptions of Objective-C objects, open that particular variable in a separate window, or view that variable in the memory viewer. We also give you step-in controls as data tips. So if you hover over a method at the current PC, you'll get a step-in icon you can click on, and that'll step into that method. If you hover over the beginning of the line, you get a step-over icon to step over.

Hovering over a line away from the PC will give you a continue to here, and Hovering Over the Declaration of the Method will let you step out of that current method. So these are quick ways to navigate through your code without having to go to the top of the window to the step-in controls. Now every project has its own breakpoints window.

On the left-hand side are groups of different breakpoints. For instance, you have the project breakpoints, which are breakpoints for the current project. and Global Breakpoints. Breakpoints that you put into this group will then follow you to any other project that you open later. Xcode also includes breakpoints from other projects that you currently have open.

If you don't wish to include them, then unselect the checkbox next to them. On the right-hand side is the detail view that then reflects the breakpoint selected on the left. This first column discloses the breakpoint actions. The next column gives you little icons to differentiate between symbolic breakpoints and file and line breakpoints.

Then the breakpoints column gives you the name of the symbolic breakpoint. You can double click that to edit the value to change it to a different symbolic breakpoint. And then for file and line breakpoints, it gives you the current method or function name as well as the line number. Then you have a column for enabling and disabling the breakpoint.

Then the location tells you which shared library or module that that breakpoint is set in. You can also set a breakpoint condition. This will determine whether or not the debugger will stop at that particular breakpoint. There's also an ignore count. So if you want to skip this particular breakpoint five times, you'd enter five.

Then we have the Auto-Continue column. Selecting this will cause all the breakpoint actions for the current breakpoint to execute, and then Xcode will automatically continue without coming forward. Then we have a hit count that can show you how many times this particular breakpoint's been hit. And finally, a comment so you can remind yourself which breakpoint actions you've set on this particular breakpoint.

As I mentioned earlier, breakpoint conditions are an expression that if they evaluate to true, the debugger will then stop at that breakpoint. Now, when you enter your breakpoint conditions, you want to make sure that you cast them so the debugger understands what the values are. So, you want something more like this.

For some reason your breakpoint conditions aren't working, you should stop the debugger in that area of code and then test out your expression in Xcode's debugger console. Now, the various breakpoint actions you can do include things like managing your GDB breakpoint commands. You can also log variable values as well as expressions, play sounds, run Apple scripts and shell scripts, chain multiple commands together, and then auto-continue as I mentioned earlier.

You can also create your own custom groups over on the left-hand side. Simply use the contextual menu to choose Add Groups, and then you can name it whatever you like and drag your breakpoints in. You can also use the contextual menu to enable and disable whole groups all at once. Now there's a special group. If you create a group called template breakpoints and drag breakpoints into that group, the actions on those breakpoints will be available for built-in breakpoint actions, which we'll show you in a minute.

Built-in breakpoint actions are available in the contextual menu of the gutter in your source view. Control-clicking there will bring up a menu, then select built-in breakpoints, and then you get the built-in ones that we have there, things like log the stack and continue, play a sound, and then there's a divider followed by any breakpoints that you've put into a group called template breakpoints.

and finally the debugger display options. This is available under the run menu. Here you can control whether or not the data tips are enabled or disabled and whether or not you want to use the step controls. You can also choose to have source and disassembly viewed in the debugger window side by side or disassembly only. Now let's bring up Antonio Proios who will run our demo for us. Here we are in our source code, and we're going to click Build and Go to launch the application.

And you can see that we've changed Cocoa Slides to now have a maximized window. We've also altered it so that it automatically cycles between the different layouts. Now let's click on one of the slides to see what the application does. Image is lines, blue dot jpeg. It's now added a graphic effect and spoken the name of the actual image inside the slide. That was actually a breakpoint action which occurred.

So as you can see, breakpoint actions, when they autocontinue, don't actually bring Xcode forward. So you can explore what your application's doing by using them. Now let's explore actually changing the color of that particular slide to really make it stand out, because right now it's kind of difficult to see which one's been selected. So let's Command-Tab back to Xcode.

and we'll set a breakpoint in slide viewcarrier.m in drawrect. and we should also go and turn on use the mini-debugger. Since this is an application that has a very large window, and we'd like to be able to interact with the debugger without hiding most of the application. So now I'll switch back to Cocoa Slides. We'll click on a slide.

Images, lines, graphite.jpg. So now we've stopped. The mini-debugger's expanded. At the very top of the window, we see that the debugger strip is available, so we can switch to different threads. On the far right is a pop-up for the stack where we can choose different stack frames. And then in the middle, we have controls for activating and deactivating the breakpoints, continuing, and our other step controls.

Next to that, we have a jump to Xcode's debugger window or debugger console. Back in the source code, we can hover over self to bring up a data tip. And then hovering over the disclosure area will automatically turn that open, and we can drill down and even see some of our data formatters.

Now if we go back to the code, say we want to step into self-bounce, but we've broken back before it. We can actually drag the PC arrow back and that moves the program counter. Dragging the PCRO doesn't actually execute any code. So now, if we hover over bounds, we'll get the step-in data tip. Clicking that, we'll step into the code. And then we can use the data tips again to step over. Hovering over bounds, the beginning of the line, we get the step out.

And now we can continue stepping using the debugger strip at the top of the window. We can step along. We see that it's setting a color for the slide, and we can hover over G. Let's try changing that value to one. So we'll single click on it, change the value, hit Tab, chose red to show that the values changed.

Now if we continue, the mini-debugger gets out of our way so we can see what's happening in the application, and we see that we've chosen a nice green. And this is all without changing any of the source code. So we can explore different options until we come down to the right color that we want and then make those changes in the sources.

The top of the window in the menu debugger on the right-hand side is the Activate and Deactivate Breakpoints button. Clicking that will deactivate all of the enabled breakpoints. Now when we click on a slide, Our breakpoint action, which speaks the name of the slide, doesn't execute because it's been disabled. And you can enable it again.

and click on a slide. Image is Jaguar Aqua blue dot JPEG. Now let's switch back to Xcode. And close the menu debugger. In here we have the main debugger window. And we can go up to the run menu and the display options. and choose Vertical Layout. This will place the variables on the left-hand side underneath the stack, so you can actually make that taller if you wish. There you go. So if you have lots of variables and you want to be able to see more of them without digging into your source code, some people like this option, especially on bigger monitors. All right. So let's go to the breakpoints window.

Now if we control click on the top of the table column, we'll get a contextual menu, and we can see we can choose which items we actually want to disclose. Now hit count and comments are disabled by default, so you'll have to enable those yourself if you want to see them. So now we can show how the hit count increases by enabling one of our breakpoints, the CycleLayout breakpoint. And now when we continue, we'll see that that increments every time the layout changes.

All right, let's stop executing Cocoa Slides. Now let's go to our breakpoint, which was playing the sound. will disclose it, the breakpoint actions. And here you can see we've chosen the log breakpoint action. There's some static text at the beginning.

And over on the right-hand side of that window, we can also choose to log that instead of speaking it if we so choose.

And those log comments will go to Xcode's debugger console. On the left-hand side of the window, for the project breakpoints, we can control-click to bring up a contextual menu, and we can group enable or disable them. So if we disable them, we see over on the right, all the breakpoints have disabled.

And finally, our template breakpoints. You see that we've added a group called template breakpoints. And if we select the breakpoint over on the right-hand side and disclose its breakpoint actions, It doesn't currently have a breakpoint action, so let's add one. And let's make it a log. and Alex Fischer, and the rest of the team. Thank you.

Change the comment to "Plays sound." Now if we go back to our source code, Now when we control click in the gutter, we got the contextual menu. We can select built-in breakpoints. And then down at the bottom, we see our new template breakpoint is available to us, play sound.

Thank you very much. Let's switch back to the slides. So now that we've looked at how to debug our application and investigate behaviors, we're going to see how we can use the editing and refactoring tools in Xcode to actually go make changes to the source. And to do that, we bring up Dave Ewing. Thanks, Chris.

So I'm Dave Ewing. I'm an engineer on the Xcode team, and I'm talking about editing and refactoring. We're going to talk about what's new in the latest versions of Xcode and talk about getting the most out of the editor. The editor in Xcode 3.0 actually went through a major overhaul, and there's quite a few new features.

I'm just going to highlight a few of them here. So first there's code folding. So with code folding, you can hide blocks of your code by clicking over on the gutter on the left. We call that the code folding ribbon. It shows you the area that it will fold, and then clicking on it folds it away.

We also added a new feature to Code Completion called inline code completion. So with inline code completion, we actually show you as you type the best suggestion for what you might want to complete. Now we've had code completion for a long time, so this is just a new way to get a quicker access to it. So here, if I type an I, it shows me that init is the most likely thing. I hit tab, it completes that. Hit W, it says that init with array is the most likely thing, and I go ahead and hit tab to finish completing that.

In Xcode, we have a database of index symbols we call the CodeSense index. In 3.0, we added the ability to show variables, symbols that the index knows right in the editor with different colors. So here we have an instance variable called root URL, and it's shown in a kind of bluish, grayish, greenish there to show that it's an instance variable. Here we have NSMutableArray, which is a system class, and it's shown in a shade of purple. So, of course, you can customize what colors you want for all these different symbol types, and we have a number of built-in sets that you can choose from for coloring.

Also in 3.0, we added the Research Assistant. So the Research Assistant is a floating panel that comes up and follows the context, your editing context. So as you move around, as the insertion point moves through the code, it will look at whatever symbol is there and look it up in the documentation. If there's documentation for it, it'll show you right in the Research Assistant.

So in there, it shows you where the symbol is defined, what header file. It'll have links to the documentation, links to documentation for related API, links to example source code. It'll even show you the availability of that symbol, so what version of the operating system it first appeared in, and maybe if it's been deprecated.

Finally, I want to talk about user scripts in Xcode. So we've had a scripts menu in Xcode for many years now. It was always kind of difficult to add new scripts to the menu. So at the bottom of the scripts menu, there's now a new command called Edit User Scripts, and it brings up this panel here. On the left-hand side, there's a representation of what the menu looks like.

And on the right-hand side, there's a view in which you can edit that script. So here, it's a little hard to see, but I'm looking at one of the built-in commands called Convert Spaces to Tabs, and you can see that it's just implemented with a born shell script on the right.

One of the interesting things about this is in order to convert spaces to tabs, it needs to know how many space characters correspond to a tab stop. And it does that by asking Xcode via AppleScript what that conversion should be. So you can look at all those examples. All of the built-in scripts are there for you to look at. So what's new in Xcode 3.1? Well, we've got some more good stuff for you here, too.

So there's a new property list editor. The property list editor lets you do structured editing of property list data files. New in 3.1 is the ability to show the keys and values in a human-readable form. So for, let's say, Info.plist files, you no longer need to remember the name.

Is it CFBundle something? It actually shows you those names in line, and it will complete the names as you type so that it knows about the valid keys for an Info.plist. It also is, there's also definitions in there for some of the settings files on the iPhone, in the iPhone SDK.

Also new in 3.1 are tokenized placeholders that are used when doing code completion and text macros. So in this little window here, I've inserted a text macro for a for loop. And in this for loop, there's an array that needs to be filled in. So there's a placeholder there that's represented as a token and some other statements for filling out the rest of the loop. So you can click directly on that placeholder and just start typing and it will fill in that area for you.

Then there's edit all in scope. So this is a new menu item under the edit menu. Surprise, surprise. So what it does is that when you select a word in your file, it will look for other occurrences of that word in the current context and allow you to edit them all at the same time. So as you start typing, it will change all of the occurrences at once.

Finally, there's Open Quickly. So Open Quickly now brings up a nice window that gives you a list of all the available options for what you type in the filter field above. You can see here that I've typed Browser W, and it shows that there's a source file and a header file. There's also an interface builder nib file. But there's also a method and a class that match. So double-clicking on those rows or navigating with the arrow keys and hitting return we'll let you go directly to those locations.

Okay, so let's talk a little bit about getting around in Xcode quickly. First, at the top of every editor view, there's this bar that we call the file navigator. So in the file navigator, there's a number of pop-up menus. I'm sure you guys, if you've used Xcode, you already are using this.

There's a file pop-up for all the open files. There's the function pop-up. There's also a pop-up for breakpoints and bookmarks in the current file. The class pop-up, which shows you the superclasses and subclasses. There's the included files pop-up, which show you what files are included by this file, and what files this includes.

And so all of those actually can be accessed with the keyboard. You don't have to use the mouse to get to these things. By default, we attach key bindings for the file and function pop-ups, control one and control two. You can assign key bindings yourself for many of these. of the other ones, for all of the other ones.

Okay, so jumping to a definition. Well, there's a menu command to jump to a definition. There's also a menu command to look up the current text in the documentation. But you can get to this quickly with the mouse by just command double-clicking on a word. So command double-click does a jump to definition. Here I've command double-clicked on init with URL, and it brings up a little pop-up if there's more than one occurrence of that symbol, and then you can choose which one you want to go to. Option double click does a similar thing, but goes to the documentation window.

The function pop-up is normally sorted by the order of the symbols in the file. If you hold down the Option key while you bring it up, it will sort it alphabetically. You can actually change the default behavior if you prefer one or the other in the Xcode preferences. And then Option key will give you the other search option when you use it.

Let's talk a little bit about customizing the editor. So CodeSense, I showed you the new inline code completion. Well, you can turn that off if you like in the preferences, but you can still have access to the other code completion commands. There's the next completion command, which cycles through a list of the most likely completions. So you--it's accessible with a control period, and when you hit control period, it will just go through the most likely options. And then, of course, there's the pop-up list for code completion, which you can get to by hitting the escape key.

Key bindings. Key bindings is one of the coolest things in Xcode, actually, I think. So you can assign key bindings for anything, any key bindings for anything in the menu, or anything in the text editor. Now, it turns out that there aren't key bindings assigned to a lot of the commands that are available, and if these are commands that you like, then this is the place to go. And if there's a command you wish we had, you can look in the key bindings and see if it's there. There are quite a few gems in there.

And speaking of gems, we have text macros. So the text macros are actually, there's quite a few of them that are available via code completion. So whenever that particular macro is appropriate for the context in the editor, it will show up in the completion list. But it's also available in the menu. Now it's kind of deep inside this hierarchical menu, but the reason it's there is so that you can assign key bindings to them.

So probably even the people in the front row can't see what I've selected here, but there's a parenthesized selection menu item. And that's bound to an option paren here. So you can just, any selection in the editor, make a selection, hit option paren, and you've just added parens around it.

So now let's talk a little bit about refactoring. So refactoring is modifying your code while preserving its behavior. So by itself, that's not particularly interesting, but when you're going to make a change to your code, often you need to restructure it some. So it's done in preparation for making changes. Programmers aren't always good at it. We make mistakes, typing errors, what have you. But computers are better at it. They're faster and more accurate. So this is what the refactoring window looks like in Xcode.

At the top, we see where we've specified the refactoring. In this case, I'm doing a rename of an instance variable. In the middle of the pane, there's a list of files that will be changed by this refactoring, and when you click on one of those files, it shows you the comparison view, the same view that you saw earlier with source code management.

We support quite a few refactorings in Xcode. It's interesting, like, the rename refactoring is cool because we don't just rename something if it appears in source files or header files. Say it's a method, you know, an IB action, for instance, or a class that also shows up in an interface builder file. We go ahead and rename those in the interface builder file as well.

If it's a class that matches the name of the source file, we can rename the source file. And of course, if that source file's under source code control, we tell the source code management system to rename it as well. With that, I'm going to show you some of these features in action. So let's go over to the demo machine.

Okay, so I'm going to make a change to this project. Right now, it brings up 20 or so slides that are sitting inside the /library/desktop/pictures folder. I happen to know that there are more pictures in there. There are subdirectories underneath that that also contain more pictures. So I want to change the code. So that it recurses down into those subdirectories. And this code isn't actually very familiar to me. So how do I do that? Well, first, I'm gonna start by looking up desktop pictures. So I'm gonna do a find in project.

We've done another find here, so I'm going to search for desktop pictures. Ah, that's probably good enough. And we can see that there's an occurrence here in maincontroller.m. So here we're creating a new browser window controller and passing it that path. So that sounds interesting. So let's look at browser window controller. To do that, I'm going to bring up Open Quickly.

So here's that list I showed you a little bit earlier. Shows the header and source file. It also shows the class declaration. I think I want to go to the source file, so let's go ahead and do that. Okay, well, there's a big header here at the top. Actually, we have the code folding ribbon hidden here. I'm going to go ahead and fold where I am. So hide that comment out of the way. We can see there's a path method, the initializer here, and it's setting an instance variable to that path.

Well, that sounds sort of interesting. I guess I want to follow where that path is. I'm going to go ahead and hide away some more of these, all the methods and functions here, and see what we have in this file. So none of these look particularly interesting. Let's look at setup.

I'm going to go ahead and double-click on that to open it up. And we can see the first line of code in here. We're creating an asset collection and passing it a URL that's built with that path. So that actually looks interesting. Let's go ahead and command double-click on asset collection. And it takes me to that class definition.

I think we have a trend here. It's now putting that into an instance variable. So we need to follow that around. We can go to the function pop-up and see if there's anything interesting here. Well, there's a refresh method. I'll go ahead and go down to that. I have been in this code before. I actually know where the things are.

But this is a general idea. So here in this method here, the first line is calling find asset files in root URL. Now that sounds actually really interesting for what I'm about to do. So I'm going to go ahead and command double click on that method. And we can see it actually just takes me down further into that file.

So, what does this method do? Well, it takes that URL and actually pulls the path right back out of it. It creates a mutable array, and it's gonna put stuff in that mutable array, it returns that. So we have a file manager here. It's getting the directory contents at that path, and then it's just looping through all of those asset files and adding them to the array.

So, as I said before, I want to recurse through that whole directory hierarchy. So in order to do that, I actually want to do that in a different method. I don't want to do that here. So I'm going to create a new method out of this, and to do that, whoops, To do that, I'm going to control clip, bring up the context menu here, and choose Refactor.

So it knows that the most likely thing I'm going to want to do with this kind of code is extract it. Go ahead and zoom this out. So it's analyzing the file right now to figure out what parameters need to be passed in and what should get returned.

Well, nothing should get returned in this case. And it gives you a default name for the method, which is not particularly interesting, extracted method, and passes it asset files. Well, I want to name this method find assets or find files in directory, so I'm going to go ahead and cut that out. I'm going to go over here and type find assets.

And go ahead and paste that back in and say in directory colon and get rid of this stuff on the end. Okay, so now I have the new signature for my method. I'll go ahead and preview it. And there's some changes here down below we can look at, but let's go ahead and apply it. Little easier to see this new method in line in the editor. Okay, so I've created a new method. Cool.

So now I want to go and recurse into the subdirectories. So inside this loop, I'm going to add an else statement. Now that's fine, I could just keep typing, but it turns out there's code completion for this. We have a text macro, so I'm going to go ahead and say next completion.

and it inserts a block for the else. And, okay, so I want to call this method recursively. But the method actually hasn't yet been discovered by our code sense index. So when we save a file, that's when our index goes and indexes. So I'm gonna save that so that code completion can know about this. And then I'm gonna go ahead and say self find assets. And let's go ahead and bring up the completion list. I'll hit the escape key. So it knows that I have find assets in directory, the method that I'm in.

So I'm going to go ahead and complete. I'll just go ahead and hit Control period to fill that out. Now I can click on the placeholder token here, or there's also under the Edit menu, Select Next Placeholder. Well, I'll go ahead and do Select Next Placeholder, Control slash, and it takes me right over to that placeholder. And I want to pass it root path.

Well, no, I don't want to pass it root path. I want to pass it a new path that's a subdirectory. So I'm going to create a new variable, path, - We'll go up here and create an NSString, and I'm gonna complete that out, star path, and assign it to be, let's see, I want it to be the root path, root path, we'll go ahead and complete that. And I want it to be string by append, well, let's go ahead and bring up the list.

Oh. Thank you. So it's string by appending path component. Where'd my cursor go? There it is. And we'll pass it the file name. semicolon. Okay, that's good, but root path, I don't really like the name of that variable. I'm not just starting from the root. I'm actually, you know, recursing down in.

So let's go ahead and change the name of that variable. And I'm going to use edit all in scope, command control T. And you can see that it's highlighted up at the top in the signature for the method and in this call here. It's highlighted that all at once. And I just want to call it directory. So as I type, it changes it in all places. If you move outside, it's done.

Okay, so let's see. There's one other thing I need to do here. So I'm now storing the file names into this mutable array, but I actually want to store the full path. So I'm going to change that to be path. That's good. Now where we used it, I also need to change how it's used, and that was back up in the refresh method that we looked at before. So if we look at here, we can see that it's... Creating a URL out of that file name.

And I just want to create, well, a plain file URL. So let's see, I'll double click on that. Select to there, and let's say, so file URL, and I don't remember if that's the, you know, file URL with path, that's what I want, and I want to pass it the file name.

Go ahead and complete that out. Okay, I'm gonna hit save and let's go and run it. and see if I've got any more files. Ooh, it built, excellent. Doesn't always work that way. All right, we got a lot more files. Woo-hoo! Okay, that's it. So with that, I'm gonna take you back to Andrew. Let's give him the clicker. And he'll take us out.

Thank you, Dave. Okay, so what are some of the things that we've shown you today? Well, we've shown you how to use Xcode's SCM support to perform SCM operations directly within the IDE. We've shown you how to use Xcode's debugger and its data tips to debug your application from directly within your text editor. And we've shown you how to use the features of the text editor and Xcode's automated refactoring tools to add functionality to your application quickly and easily.

Here we want to talk about some related sessions you can also go to. So now there was the Xcode for Visual Studio and Eclipse developers. That was yesterday, but you'll be able to see that on video later on. There's also understanding the Xcode project management and build system, which we mentioned before. That is today in this room, Marina. There's also debugging and profiling your iPhone application, and that's tomorrow in the Presidio at 10.30 a.m.

In addition, we would encourage you to go to the labs today. There are three Xcode developer tools labs. One is today at 2 p.m. in OS X Foundations Lab C. There's another one tomorrow at 3.30 in Lab A. And then there's an iPhone lab on Friday in iPhone Lab A. So we encourage you to go to those, but you can also go to any of our open hours labs, and there will be engineers there. to answer your questions.