Tải bản đầy đủ - 0 (trang)
Chapter 6. Anatomy of an Xcode Project

Chapter 6. Anatomy of an Xcode Project

Tải bản đầy đủ - 0trang

New 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

variables list.

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


The Editor

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

secondary windows.


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.

Secondary windows

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


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 6. Anatomy of an Xcode Project

Tải bản đầy đủ ngay(0 tr)