Tải bản đầy đủ - 0trang
Chapter 6. Anatomy of an Xcode Project
Even before you’ve written any code, an Xcode project is quite elaborate. To see this,
let’s make a new, essentially “empty” project; you’ll see instantly that it isn’t empty at
1. Start up Xcode and choose File → New → New Project.
2. The “Choose a template” dialog appears. The template is your project’s initial set
of files and settings. When you pick a template, you’re really picking an existing
folder full of files; it will be one of the folders at some depth inside /Developer/
Platforms/iPhoneOS.platform/Developer/Library/Xcode/Templates/Project Templates/Application. This folder will essentially be copied, and a few values will be
filled in, in order to create your project.
So, in this case, on the left, under iOS (not Mac OS X!), choose Application. On
the right, select Single View Application. Click Next.
3. You are now asked to provide a name for your project (Product Name). Let’s call
our new project Empty Window.
In a real project, you should give some thought to the project’s name, as you’re
going to be living in close quarters with it. As Xcode copies the template folder,
it’s going to use the project’s name to “fill in the blank” in several places, including
some filenames and some settings, such as the name of the app. Thus, whatever
you type at this moment is something you’ll be seeing in a lot of places throughout
your project, for as long as you work with this project. So use a name that is either
your app’s final name or at least approximates it.
It’s fine to use spaces in a project name. Spaces are legal in the folder name, the
project name, the app name, and the various names of files that Xcode will generate
automatically; and in the few places where spaces are problematic (such as the
bundle identifier, discussed in the next paragraph), the name you type as the Product Name will have its spaces converted to hyphens.
4. Just below the Product Name field is the Company Identifier field. The first time
you create a project, this field will be blank, and you should fill it in. The goal here
is to create a unique string; your app’s bundle identifier, which is shown in gray
below the company identifier, will consist of the company identifier plus a version
of the project’s name, and because every project should have a unique name, the
bundle identifier will also be unique and will thus uniquely identify this project
along with the app that it produces and everything else connected with it. The
convention is to start the company identifier with com. and to follow it with a string
(possibly with multiple dot-components) that no one else is likely to use. For example, I use com.neuburg.matt.
5. Make sure the Device Family pop-up menu is set to iPhone. Make sure that Use
Automatic Reference Counting is checked but that the other two checkboxes are
100 | Chapter 6: Anatomy of an Xcode Project
unchecked. Ignore the Class Prefix field for now; it should be empty, with its default
value “XYZ” shown in grey. Click Next.
6. You’ve now told Xcode how to construct your project. Basically, it’s going to copy
the Single View Application.xctemplate folder from within the Project Templates/
Application folder I mentioned earlier. But you need to tell it where to copy this
folder to. That’s why Xcode is now presenting a Save As dialog. You are to specify
the location of a folder that is about to be created — a folder that will be the project
folder for this project.
The project folder can go just about anywhere, and you can move it after creating
it. So the location doesn’t matter much; I usually create new projects on the Desktop.
7. Xcode 4 also offers to create a git repository for your project. In real life, this can
be a great convenience, but for now, uncheck that checkbox. Click Create.
8. The Empty Window project folder is created on disk (on the Desktop, if that’s the
location you just specified), and the project window for the Empty Window project
opens in Xcode.
The project we’ve just created is a working project; it really does build an iOS app called
Empty Window. To see this, make sure that the Scheme pop-up menu in the project
window’s toolbar reads Empty Window → iPhone 5.0 Simulator (though the exact
system version number might be different), and choose Product → Run. After a while,
the iOS Simulator application opens and displays your app running — an empty grey
To build a project is to compile its code and assemble the compiled code,
together with various resources, into the actual app. Typically, if you
want to know whether your code compiles and your project is consistently and correctly constructed, you’ll build the project (Product →
Build). To run a project is to launch the built app, in the Simulator or
on a connected device; if you want to know whether your code works
as expected, you’ll run the project (Product → Run), which automatically builds first if necessary.
The Project Window
An Xcode project must embody a lot of information about what files constitute the
project and how they are to be used when building the app, such as:
• The source files (your code) that are to be compiled
• Any resources, such as icons, images, or sound files, as well as nib and storyboard
files, that are to be part of the app
• Any frameworks to which the code must be linked as the app is built
The Project Window | 101
Figure 6-1. The project window, on steroids
• All settings (instructions to the compiler, to the linker, and so on) that are to be
obeyed as the app is built
Xcode presents this information in graphical form, and this is one reason why a project
window is so elaborate, and why learning to navigate and understand it takes time.
Also, this single window must let you access, edit, and navigate your code, as well as
reporting the progress and results of such procedures as building or debugging an app.
In short, the single project window displays a lot of information and embodies a lot of
functionality. You won’t lose your way, however, if you just take a moment to explore
this window and see how it is constructed.
Figure 6-1 shows the project window, configured in rather an extreme manner, in order
to display as many parts of the window as possible. In real life, you’d probably never
show all these parts of the window at the same time, except very briefly, unless you had
a really big monitor.
1. On the left is the Navigator pane. Show and hide it with View → Navigators →
Show/Hide Navigator (Command-0) or with the first button in the View segmented
control in the toolbar.
2. In the middle is the Editor pane (or simply “editor”). A project window always
contains at least one Editor pane. I could have displayed this window with multiple
Editor panes, but I was afraid that might make you run screaming from the room.
3. On the right is the Utilities pane. Show and hide it with View → Utilities → Show/
Hide Utilities (Command-Option-0) or with the third button in the View segmented control in the toolbar.
102 | Chapter 6: Anatomy of an Xcode Project
4. At the bottom is the Debugger pane. Show and hide it with View → Show/Hide
Debug Area (Shift-Command-Y) or with the second button in the View segmented
control in the toolbar.
All Xcode keyboard shortcuts can be customized; see the Key Bindings
pane of the Preferences window. Keyboard shortcuts that I cite are the
The Navigator Pane
All navigation of the project window begins ultimately with the Navigator pane, the
column of information at the left of the window. It is possible to toggle the visibility of
the Navigator pane (View → Navigators → Hide/Show Navigator, or Command-0); for
example, once you’ve used the Navigator pane to reach the item you want to see or
work on, you might hide the Navigator pane temporarily to maximize your screen real
estate (especially on a smaller monitor). You can change the Navigator pane’s width
by dragging the vertical line at its right edge.
The Navigator pane itself can display seven different sets of information; thus, there
are actually seven navigators. These are represented by the seven icons across its top;
to switch among them, use these icons or their keyboard shortcuts (Command-1,
Command-2, and so on). You will quickly become adept at switching to the navigator
you want; their keyboard shortcuts will become second nature. If the Navigator pane
is hidden, pressing a navigator’s keyboard shortcut both shows the Navigator pane and
switches to that navigator.
Depending on your settings in the Behaviors pane of Xcode’s preferences, a navigator
might show itself automatically when you perform a certain action. For example, by
default, when you build your project, if warning messages or error messages are generated, the Issue navigator will appear. This automatic behavior will not prove troublesome, because it is generally precisely the behavior you want, and if it isn’t, you can
change it; plus you can easily switch to a different navigator at any time.
The most important general use pattern for the Navigator pane is: you select something
in the Navigator pane, and that thing is displayed in the main area of the project window. Let’s begin experimenting immediately with the various navigators:
Project navigator (Command-1)
Click here for basic navigation through the files that constitute your project. For
example, in the Empty Window folder (these folder-like things in the Project navigator are actually called groups) click AppDelegate.m to view its code (Figure 6-2).
At the top level of the Project navigator, with a blue Xcode icon, is the Empty
Window project itself; click it to view the settings associated with your project and
The Project Window | 103
Figure 6-2. The Project navigator
its targets. Don’t change anything here without knowing what you’re doing! I’ll
talk later in this chapter about what these settings are for.
Symbol navigator (Command-2)
A symbol is a name, typically the name of a class or method. Depending on which
of the three icons in the filter bar at the bottom of the Symbol navigator you highlight, you can view Cocoa’s built-in symbols or the symbols defined in your project.
The former can be a useful form of documentation; the latter can be helpful for
navigating your code. For example, highlight the first two icons in the filter bar
(the first two are dark-colored, the third is light), and see how quickly you can
reach the definition of AppDelegate’s applicationDidBecomeActive: method.
Feel free to highlight the filter bar icons in various ways to see how the contents of
the Symbol navigator change. Note too that you can type in the search field in the
filter bar to limit what appears in the Symbol navigator; for example, try typing
“active” in the search field, and see what happens.
Search navigator (Command-3)
This is a powerful search facility for finding text globally in your project, and even
in the headers of Cocoa frameworks. You can also summon the Search navigator
with Edit → Find → Find in Workspace (Shift-Command-F). To access the full set
of options, click the magnifying glass and choose Show Find Options. For example,
try searching for “delegate” (Figure 6-3). Click a search result to jump to it in your
Issue navigator (Command-4)
You’ll need this navigator primarily when your code has issues. This doesn’t refer
to emotional instability; it’s Xcode’s term for warning and error messages emitted
when you build your project.
104 | Chapter 6: Anatomy of an Xcode Project
Figure 6-3. The Search navigator
To see the Issue navigator in action, you’ll need to give your code an issue. For
example, navigate (as you already know how to do, in at least three different ways)
to the file AppDelegate.m, and in the blank line after the last comment at the top
of the file, above the #import line, type howdy. Build (Command-B), saving if you’re
prompted to. The Issue navigator will display numerous error messages, showing
that the compiler is totally unable to cope with this illegal word appearing in an
illegal place. Click an issue to see it within its file. In your code, issue “balloons”
may appear to the right of lines containing issues; if you’re distracted or hampered
by these, toggle their visibility with Editor → Issues → Hide/Show All Issues. (Now
that you’ve made Xcode miserable, select “howdy” and delete it; build again, and
your issues will be gone. If only real life were this easy!)
Debug navigator (Command-5)
By default, this navigator will appear when your code is paused while you’re debugging it. There is not a strong distinction in Xcode between running and debugging; the milieu is the same. (The difference is mostly a matter of whether
breakpoints are obeyed; more about that, and about debugging in general, in
Chapter 9.) However, if your code runs and doesn’t pause, the Debug navigator
by default won’t come into play.
To see the Debug navigator in action, you’ll need to give your code a breakpoint.
Navigate once more to the file AppDelegate.m, select in the line that says
return YES, and choose Product → Debug → Add Breakpoint at Current Line to
make a blue breakpoint arrow appear on that line. Run the project. (If the project
is already running, the Stop dialog may appear; click Stop to terminate the current
The Project Window | 105
Figure 6-4. The Debug layout
run and begin a new one.) By default, as the breakpoint is encountered, the Navigator pane switches to the Debug navigator, and the Debug pane appears at the
bottom of the window.
This overall layout (Figure 6-4) will rapidly become familiar as you debug your
projects. The Debug navigator displays the call stack, with the names of the nested
methods in which the pause occurs; as you would expect, you can click on a method
name to navigate to it. You can shorten or lengthen the list with the slider at the
bottom of the pane. The Debug pane, which can be shown or hidden at will (View →
Hide/Show Debug Area, or Shift-Command-Y) consists of two subpanes, either of
which can be hidden using the segmented control at the top right of the pane.
• On the left, the variables list is populated with the variables in scope for the
selected method in the call stack (and you can optionally display processor
registers as well).
• On the right is the console, where the debugger displays text messages; that’s
how you learn of exceptions thrown by your running app. Exceptions are extremely important to know about, and this is your only way to know about
them, so keep an eye on the console as your app runs. Note also that View →
Debug Area → Activate Console shows the console pane if only the variables
list is displayed.
You can also use the console to communicate via text with the debugger. This
can often be a better way to explore variable values during a pause than the
Breakpoint navigator (Command-6)
This navigator lists all your breakpoints. At the moment you’ve only one, but when
you’re actively debugging a large project, you’ll be glad of this navigator. Also, this
106 | Chapter 6: Anatomy of an Xcode Project
Figure 6-5. Viewing a log
is where you create special breakpoints (such as symbolic breakpoints), and in
general it’s your center for managing existing breakpoints. We’ll return to this topic
in Chapter 9.
Log navigator (Command-7)
This navigator lists your recent major actions, such as building or running (debugging) your project. Click on a listing to see the log file generated when you
performed that action. The log file might contain information that isn’t displayed
in any other way, and also it lets you dredge up messages from the recent past
(“What was that exception I got while debugging a moment ago?”).
For example, by clicking on the listing for a successful build, and by choosing to
display All and All Messages using the filter switches at the top of the log, we can
see the steps by which a build takes place (Figure 6-5). To reveal the full text of a
step, click on that step and then click the Expand Transcript button that appears
at the far right (and see also the menu items in the Editor menu).
When navigating by clicking in the Navigator pane, modifications to your click can
determine where navigation takes place. For the settings that govern these click modifications, see the General pane of Xcode’s preferences. For example, if you haven’t
changed the original settings, Option-click navigates in an assistant pane (discussed
later in this chapter), and double-click navigates by opening a new window.
The Utilities Pane
The Utilities pane, the column at the right of the project window, consists partly of
inspectors that provide information about, and in some cases let you change the specifications of, the current selection, and partly of libraries that function as a source of
objects you may need while editing your project. Its importance emerges mostly when
you’re working in the nib editor (Chapter 7), and you’ll probably keep it hidden the
rest of the time. But if you have sufficient screen real estate, you might like to keep it
open while editing code, because Quick Help, a form of documentation (Chapter 8),
is displayed here as well; plus, the Utilities pane is the source of code snippets (ChapThe Project Window | 107
ter 9). To toggle the visibility of the Utilities pane, choose View → Utilities → Hide/Show
Utilities (Command-Option-0). You can change the Utilities pane’s width by dragging
the vertical line at its left edge.
Many individual inspectors and libraries are discussed in subsequent chapters. Here,
I’ll just describe the overall physical characteristics of the Utilities pane.
The Utilities pane consists of a set of palettes. Actually, there are so many of these
palettes that they are clumped into multiple sets, divided into two major groups: the
top half of the pane and the bottom half of the pane. You can change the relative heights
of these two halves by dragging the horizontal line that separates them.
The top half
What appears in the top half of the Utilities pane depends on what’s selected in
the current editor. There are two main cases:
A code file is being edited
The top half of the Utilities pane shows either the File inspector or Quick Help.
Toggle between them with the icons at the top of this half of the Utilities pane,
or with their keyboard shortcuts (Command-Option-1, Command-Option-2).
The File inspector is rarely needed, but Quick Help can be useful as documentation. The File inspector consists of multiple sections, each of which can
be expanded or collapsed by clicking its header.
A nib or storyboard file is being edited
The top half of the Utilities pane shows, in addition to the File inspector and
Quick Help, the Identity inspector (Command-Option-3), the Attributes inspector (Command-Option-4), the Size inspector (Command-Option-5), and
the Connections inspector (Command-Option-6). Like the File inspector,
these can consist of multiple sections, each of which can be expanded or collapsed by clicking its header.
The bottom half
The bottom half of the Utilities pane shows one of four libraries. Toggle between
them with the icons at the top of this half of the Utilities pane, or with their keyboard shortcuts. They are the File Template library (Command-Option-Control-1), the Code Snippet library (Command-Option-Control-2), the Object library
(Command-Option-Control-3), and the Media library (Command-Option-Control-4). The Object library is the most important; you’ll use it heavily when editing
a nib or storyboard.
To see a help pop-up describing the currently selected item in a library, press
108 | Chapter 6: Anatomy of an Xcode Project
In the middle of the project window is the editor. This is where you get actual work
done, reading and writing your code (Chapter 9), or designing your interface in a nib
or storyboard file (Chapter 7). The editor is the core of the project window. You can
eliminate the Navigator pane, the Utilities pane, and the Debug pane, but there is no
such thing as a project window without an editor (though you can cover the editor
completely with the Debug pane).
The editor provides its own form of navigation, the jump bar across the top. I’ll talk
more later about the jump bar, but for now, observe that not only does it show you
hierarchically what file is currently being edited, but also it allows you to switch to a
different file. In particular, each path component in the jump bar is also a pop-up menu.
These pop-up menus can be summoned by clicking on a path component, or by using
keyboard shortcuts (shown in the second section of the View → Standard Editor submenu). For example, Control-4 summons a hierarchical pop-up menu, which can be
navigated entirely with the keyboard, allowing you to choose a different file in your
project to edit. Thus you can navigate your project even if the Project navigator isn’t
It is extremely likely, as you develop a project, that you’ll want to edit more than one
file simultaneously, or obtain multiple views of a single file so that you can edit two
areas of it simultaneously. This can be achieved in three ways: assistants, tabs, and
You can split the editor into multiple editors by summoning an assistant pane. To
do so, click the second button in the Editor segmented control in the toolbar, or
choose View → Assistant Editor → Show Assistant Editor (Command-Option-Return). Also, by default, adding the Option key to navigation opens an assistant
pane; for example, Option-click in the Navigator pane, or Option-choose in the
jump bar, to navigate by opening an assistant pane (or to navigate in an existing
assistant pane if there is one). To remove the assistant pane, click the first button
in the Editor segmented control in the toolbar, or choose View → Standard Editor →
Show Standard Editor (Command-Return), or click the “x” button at the assistant
pane’s top right.
Your first task will be to decide how you want multiple editor panes arranged with
respect to one another. To do so, choose from the View → Assistant Editor submenu. I usually prefer All Editors Stacked Vertically, but it’s purely a matter of
personal taste and convenience.
Once you’ve summoned an assistant pane, you can split it further into additional
assistant panes. To do so, click the “+” button at the top right of an assistant pane.
To dismiss an assistant pane, click the “x” button at its top right.
The Project Window | 109
Figure 6-6. Telling an assistant pane to display counterparts
What makes an assistant pane an assistant, and not just a form of split-pane editing,
is that it can bear a special relationship to the primary editor pane. The primary
editor pane is the one whose contents, by default, are determined by what you click
on in the Navigator pane; an assistant pane, meanwhile, can respond to what file
is being edited in the primary editor pane by changing intelligently what file it (the
assistant pane) is editing. This is called tracking.
To see tracking in action, open a single assistant pane and set the first component
in its jump bar to Counterparts (Figure 6-6). Now use the Project navigator to select
AppDelegate.m; the primary editor pane displays this file, and the assistant automatically displays AppDelegate.h. Next, use the Project navigator to select AppDelegate.h; the primary editor pane displays this file, and the assistant automatically displays AppDelegate.m. There’s a lot of convenience and power lurking here,
which you’ll explore as you need it.
You can embody the entire project window interface as a tab. To do so, choose
File → New → New Tab (Command-T), revealing the tab bar (just below the toolbar) if it wasn’t showing already. Use of a tabbed interface will likely be familiar
from applications such as Safari. You can switch between tabs by clicking on a tab,
or with Command-Shift-}. At first, your new tab will look largely identical to the
original window from which it was spawned. But now you can make changes in a
tab — change what panes are showing or what file is being edited, for example —
without affecting any other tabs. Thus you can get multiple views of your project.
A secondary project window is similar to a tab, but it appears as a separate window
instead of a tab in the same window. To create one, choose File → New → New
Window (Command-Shift-T). Alternatively, you can promote a tab to be a window
110 | Chapter 6: Anatomy of an Xcode Project