Home > Articles > Home & Office Computing > Mac OS X

  • Print
  • + Share This
This chapter is from the book

Using the Navigator

The starting point for this exploration is the navigator pane at the left of the workspace window. You show or hide it with the leftmost View button, as pointed out in Figure 1.3. At the top of the navigator is a selector bar. The seven items in it control which navigator is displayed. You can use commands in the Navigators submenu of the View menu or keyboard equivalents instead of the selector bar if you want.

If you want to hide the navigator, use the leftmost View button or the View > Navigators > Hide Navigator command (inline.jpg–0).

The next sections explain the navigators, their keyboard equivalents, and what they do.

Project inline.jpg–1

Figure 1.4 shows the project navigator. When you have first created a new project, it will very likely look like this. At the top of the navigator is a single item with a disclosure triangle to its left.

Click the disclosure triangle, and the single project item opens revealing its files and groups, as you see in Figure 1.5.

Figure 1.5 also demonstrates another feature of Xcode: the parts of the workspace window know about one another. When you click the project icon at the top of the navigator, the editor area of the workspace window shows information about the project, as you can see in Figures 1.4 and 1.5.

Figure 1.4

Figure 1.4 The project is shown in a collapsed form in the navigator right after you have created it.

Figure 1.5

Figure 1.5 You can expand groups in the project navigator.

Click one of the files in the project, and it appears in the editor area shown in Figure 1.6.

Figure 1.6

Figure 1.6 Click a file to edit it.

Clicking a file opens it in the editor area no matter what kind of file it is. Figure 1.7 shows an interface file (a nib file) in the editor area. Note that new projects for iOS have the option to use storyboards instead of nib files; for older projects and on Mac OS, nibs remain the standards.

  • Learn more about storyboards in Hour 14, “Working with Storyboards and Swapping Views.”

Figure 1.8 shows a Core Data data model file in the editor area.

In Figure 1.9, you see that if you have added an image file to your project, clicking it opens the image in the editor area.

Figure 1.7

Figure 1.7 Edit a nib file in Xcode.

Figure 1.8

Figure 1.8 Edit your data model in Xcode.

Figure 1.9

Figure 1.9 Open resource files.

In other words, no matter what kind of file it is, select it in the project navigator and edit it in the editor (for the file types that Xcode supports).

You have seen how to use the navigator to explore your project and its files, but how do you manage the files themselves? When you create a project, as you will see in Hour 2, the files are automatically created for you. In your own projects, you might need to add files to it. Control-click in the project navigator to bring up the shortcut menu shown in Figure 1.10. For many people, right-clicking the mouse will have the same effect. You can add the new file anywhere you want and move it to the right position in the navigator just by dragging it. If you control- or right-click in a group, the file will be added to that group and you might not have to move it.

Figure 1.10

Figure 1.10 Use the shortcut menu to add files to the project.

Once you have selected a file to add, the sheet shown in Figure 1.11 opens.

Figure 1.11

Figure 1.11 Specify a file to add.

The most important part of this dialog other than the filename is the Destination checkbox. This determines whether the project will use the file that may be somewhere else on your disk or network or whether it will copy it into your project. Normally, you do want to copy the file into the project so that you can then move the entire project folder to another computer if necessary.

The filter bar at the bottom of the project navigator lets you filter by filename (or part thereof). The + in the bottom-left lets you add a new file with a template (it is not the same as the add file to project command shown in the shortcut menu in Figure 1.10). Three symbols to the right of the + limit your navigation. From left, here are their effects:

  • Show only recently edited files
  • Show only files with source-control status such as modified
  • Show only files with unsaved changes

Symbol inline.jpg–2

The symbol navigator, shown in Figure 1.12, shows you the symbols in your project: the classes (indicated with C), methods (M), and properties (P). Interface Builder actions (A) and outlets (O) manage the interactions between your code and your interface.

Figure 1.12

Figure 1.12 Use the symbol navigator.

Properties are identified by P unless they are Interface Builder outlets—a special kind of property. The synthesize directive that is the companion to a property directive is flagged with a V (for variable).

  • You will find out more about the property and synthesize directives in Hour 3, “Understanding the Basic Code Structure,” p. 63.

At the bottom of the symbol navigator, you can filter the display. Use the search box to type text to search for in symbol names. To the left of the filter bar, symbols let you choose what to display and hide. From left, the following effects are available:

  • Show only class symbols—that is, no globals
  • Show only symbols defined in the project
  • Show only containers such as classes and categories; do not show members

Search inline.jpg–3

The search navigator packs a lot of searching into a small space. You can use it by simply typing a search term into the box; Xcode will search for it through the project. The list of results (if any) is shown in the search navigator. You will see the relevant filename, a symbol such as the ones shown previously in Figure 1.12, and the beginning of the line of code. The search term is highlighted in yellow in each line. Sometimes this means that you do not see the beginning of the line, but never fear—a click on the line will display it in the editor area, or you can hover the pointer over it to see a tooltip with the full text.

You can switch between searching and replacing text at the upper-left, as shown in Figure 1.13. In addition, at the bottom of the search navigator, the filter bar lets you search within the results. In Figure 1.13, for example, the find was executed on “detail.” (You can see this because “detail” is highlighted in all of the search results.) The filter bar is used to filter on “item.” If you look at the search results, you will see that “detail” is always found, but each of those results also contains “item,” which is not highlighted because it was not part of the original search. You can duplicate these results for yourself. Conduct a search without a filter, and then add a filter. You’ll see that the number of results is reduced.

Just to the right of the magnifying glass in the search field, a disclosure triangle lets you show or hide the Find Options shortcut, as shown in Figure 1.14. It also lets you repeat recent searches.

Figure 1.13

Figure 1.13 Specify a search.

Figure 1.14

Figure 1.14 Show or hide Find Options shortcuts.

The search navigator searches throughout the project. The Edit menu has traditional single-file Find commands, as shown in Figure 1.15.

Figure 1.15

Figure 1.15 The Edit menu provides a multitude of search and replace options.

Issue inline.jpg–4

The issue navigator lets you view the issues with your project. In the old days, these used to be called compile errors, but with Xcode, you will have many fewer compile errors. Do not get your hopes up, though. That is because Xcode has a powerful parser that checks your code as you type. It is as lively as a spell-checker, but it looks for syntax errors as well as ordinary misspellings. This means that compile errors now show up much earlier—just as you are typing them in many cases. The issue navigator lets you see them. You can display them by file (the traditional way of showing compile errors), but you can also display them by type so that like errors are grouped together. Sometimes that can make fixing the errors faster, particularly if you are consistently mistyping a variable name.

Figure 1.16 shows the issue navigator. In addition, note that, in the breakpoint gutter at the left of the editor area, symbols show up as soon as you have made the offending keystroke. (An extra s has just been added to synthesize—synthessize.)

Figure 1.16

Figure 1.16 The issue navigator helps you correct errors as you type.

Debug inline.jpg–5

Debug shows you the calling sequence for each of your app’s threads (in the simplest case, there is only one). For example, Figure 1.17 shows the app stopped in DetailViewController viewWillAppear. That was called from UISplitViewController viewWillAppear, and so on back to the bottom of the calling sequence—main, which starts the program running.

Figure 1.17

Figure 1.17 Use the debug navigator to track a calling sequence.

Breakpoint inline.jpg–6

Breakpoints let you stop program execution at specific lines of code. You place a breakpoint in the breakpoint gutter to the left of the editor area and, when the program is about to execute that line of code, it stops. You can then inspect the variables in the debug area. In Figure 1.17, a breakpoint was set in the editor area at [super viewWillAppear:animated]. The program stopped just before executing that line of code. The calling sequence is visible in the debug navigator. In the editor area, you see the breakpoint, and, to its right, a small green arrow that points to the line of code about to be executed. If you have several breakpoints, you need to know which one has just stopped the app.

Beneath the editor area, the debug area shows you information about the breakpoint. On the left is a view of the variables at this moment. On the right are console messages. Buttons at the upper-right of the debug area let you choose which—or both—views to display. In the view of variables, you can expand and collapse containers as you examine exactly what data is where.

To remove a breakpoint, drag it out of the breakpoint gutter. You can also use the breakpoint navigator to list the breakpoints. Clicking one will take you to the line of code. You can drag breakpoints out of the breakpoint navigator to remove them if you prefer not to drag them out of the breakpoint gutter.

Log inline.jpg–7

Finally, the log navigator keeps track of what you’ve been doing with this app.Figure 1.18 shows the log navigator. The events are in reverse chronological order (latest first). As always in the navigator, a filter bar lets you filter the entries so you can easily find builds or other specific types of entries; you can also use the control at the bottom-left to see the most recent log entries. Clicking a log entry shows you the console results for that compile, build, or other action.

Figure 1.18

Figure 1.18 The log navigator keeps track of your work.

  • + Share This
  • 🔖 Save To Your Account