Lập trình Wrox Professional Xcode 3 cho Mac OS part 10 potx

80
❘
CHAPTER 5 SOURCES
or Objective - C source fi les. Trying to add the companion header fi les to those targets at the same time
does nothing, but some native targets have a Copy Files phase that accepts any kind of fi le. The end
result is that all of the .h fi les get added to the target ’ s Copy Files phase, and the target dutifully copies
all of the headers fi les in your project into the fi nal application. This is probably not what you want.
To fi x this, select the project structure group in the Groups & Files list to display all of the fi les in
the project in the details window (choose View ➪ Details if you are using the Condensed layout
style). In the details list, click the icon (fi le type) column to sort the items by type. Click the fi rst
header fi le in the list, then scroll down and Shift - click the last one to select all of the header fi les in
the project. Now choose File ➪ Get Info to get an aggregate Info window for all of the header fi le
items. Switch to the Targets tab and uncheck all of the targets. This removes all of the header fi les
from all of the targets in your project.
You can adapt this technique to make similar changes in other types of fi les.
REMOVING SOURCE ITEMS
Removing source items from your project is just about as easy as you would imagine it would be.
Select one or more source items and press the Delete key, choose Edit ➪ Delete, or
Right/Control+click ➪ Delete. Xcode presents a dialog box, as shown in Figure 5 - 22. The Delete
References button only removes the source item (reference) from your project structure group.
The Also Move to Trash button removes the source item and moves the fi le(s) it refers to the system
Trash folder.
FIGURE 5-22
REORGANIZING SOURCES
This section walks you through reorganizing the fi les in a project. This usually entails rearranging
the actual fi les and then altering the source item references to agree.
When you ’ re working with source item references, it ’ s useful to know when an item ’ s reference is
valid and when it ’ s broken. Whenever Xcode discovers that a reference no longer refers to a fi le or
folder, the item in the source group turns red. Figure 5 - 23 shows invalid references for the Two.h ,
Two.m , and main.cpp items.
c05.indd 80c05.indd 80 1/21/10 1:22:12 PM1/21/10 1:22:12 PM

Download at getcoolebook.com
Again, this is hard to see in black - and - white. Red items are usually a clue that the item ’ s reference
needs to be fi xed — but not always. Whenever you create a new project or target, a source item is
created for the product that will be produced. Until you successfully build the target, its product
doesn ’ t exist and its product item in the source tree will be red. This is perfectly normal and
expected.
You can fi x a reference in two ways: open the Info window for the item and correct its Path
attribute, or put the fi le or folder the item is pointing to where the reference expects it to be.
Xcode immediately recognizes that the reference is valid again, and changes the item ’ s color
back to black.
The next three sections present typical project item reorganization chores, and the steps you need to
follow to keep your source item references valid.
Moving Files
The ReorganizeMe1 project, shown in Figure 5 - 24, has two subfolders: Main and Flipside .
You decide that the SpinningWidget class fi les need to be moved from the Main group to the
Flipside group.
FIGURE 5-23
Reorganizing Sources
❘
81
c05.indd 81c05.indd 81 1/21/10 1:22:13 PM1/21/10 1:22:13 PM
Download at getcoolebook.com
82
❘
CHAPTER 5 SOURCES
To relocate the two fi les, follow these steps:
1. Open the ReorganizeMe1 project.
2. Drag the SpinningWidget.h and SpinningWidget.m items from the Main group into the
Flipside group.
3. Control/Right - click the Main source group and choose Reveal in Finder.

4. In the Finder window, move the two source fi les, SpinningWidget.h and SpinningWidget.
m , from the Main folder into the Flipside folder.
5. Switch back to the project window. Notice that the two source items are now red. Select
both items and choose File ➪ Get Info.
6. In the multi - item Info window, click the Choose button. Select the Flipside folder and
click Choose. The item references are now valid again.
Whenever you move a source item, Xcode adjusts the path (never the reference type) of the item so
it continues to refer to the same fi le or folder. This is convenient in one sense, because it allows you
to reorganize your source items freely without breaking any references. The disadvantage is that it
permits you to create convoluted item references with relative paths through parent folders and an
organization that no longer refl ects the organization of the physical fi les.
All of the items in this exercise use enclosing - group references. When you moved the two source fi le
items from one group to the other in step 2, Xcode recalculated new paths starting from
the new group back to the old one ’ s folder. If you had stopped and looked at the attributes of the
two items after step 2, their paths would have been
/Main/SpinningWidget.h and
/Main/SpinningWidget.m . This also explains why the two items were still valid after the move.
In step 4, you moved the actual fi les. As a result, the fi les were no longer in the Main folder and the
source item references broke. When you switched back to the project window, Xcode displayed
the two items in red.
FIGURE 5-24
c05.indd 82c05.indd 82 1/21/10 1:22:13 PM1/21/10 1:22:13 PM
Download at getcoolebook.com
In steps 5 and 6, you examined the attributes of the two items in a multi - item Info window and used
it to point both items to their respective fi les in the Flipside folder. Remember that when you select
a new path for multiple items , you ’ re selecting the parent folder for every individual item — you ’ re
not setting every item to the same path. The path for each was recalculated using a relative path to
the Flipside folder (which is nothing, because the enclosing group ’ s folder is the Flipside folder)
and their respective fi lenames. The references are once again valid.
Rearranging Folders

Now you are going to relocate entire folders. This demonstrates the principle advantage of using
enclosing - group references in your project.
ReorganizeMe2 has a Source folder that contains two subfolders: Product and Order . The project
is about to grow into a client and server. The source fi les for the client and server are to be kept
apart, and the common code moved into a shared tree. Follow these steps:
1. Open the ReorganizeMe2 project.
2. Select the Order group. Control/Right - click the Order group and choose Reveal in Finder.
In the Finder window, create three new folders inside the Source folder: Common , Client ,
and Server . Drag the Product and Order folders into the Common folder.
3. Switch back to the project window. Select the Product and Order groups and choose Project
➪ Group to enclose them in a new group. Name the group Common. Use the File ➪ New
Group command to create new groups named Client and Server in the Source group.
4. Select the Common group. Control/Right - click the Common group and choose Get Info. In
the Info window, click the Choose button and select the Common folder in the project. Click
Choose to change the path.
5. Repeat step 4 for the Client and Server groups, choosing the Client and Server folders,
respectively.
The Order and Product source groups refer to the Order and Product subfolders in their enclosing
group ’ s folder. Moving the Order and Product folders into the newly created Common folder broke
the references to those folders, and all the references of the items they contained.
In step 3, the new groups Common, Client, and Server were created with enclosing group references
that referred to the folder in the source group (remember that this is the default for all newly created
source groups). Although the Order and Product groups are now enclosed in the Common group,
they still indirectly refer to the same location and are still broken.
In step 4, you changed the Common group ’ s folder from the Source folder to the new
Common subfolder. As soon as that happened, the references in the Order and Product folders were
valid again.
Step 5 simply prepared the other two groups, Client and Server, so they reference fi les in their
respective folders.
When you ’ re using enclosing - group references, it is usually easier to rearrange folders than it is to

move individual fi les around. Xcode only adjusts the path of the group being moved. Items within
that group are not adjusted and continue to have the same relative relationship to their enclosing
group. After the parent group references are fi xed, all of the child references are valid again.
Reorganizing Sources
❘
83
c05.indd 83c05.indd 83 1/21/10 1:22:14 PM1/21/10 1:22:14 PM
Download at getcoolebook.com
84
❘
CHAPTER 5 SOURCES
Reorganizing by Re - adding
You can see how using the multi - item Info window and relative references can save a lot of time
when changing references for large trees of groups and fi les. If you ’ re moving just a few folders
around, that ’ s probably the best way, but even this can be a fair amount of work if you ’ re making a
lot of changes at once.
Another technique is simply to throw the whole thing away and let Xcode rebuild all of the
relationships from scratch. Start with the ReorganizeMe3 project. All of the items in this project
have enclosing - group references.
ReorganizeMe3 has several subfolders: Database , Product , Order , ShoppingCart , and Utilities .
Create three new folders in the Source folder: Common , Client , and Server . Move the Database
folder into the Server folder. Move the ShoppingCart folder into the Client folder. Move the
Product , Order , and Utilities folders into the Common folder. The fi le structure should now look
like Figure 5 - 25.
FIGURE 525
Now follow these steps:
1. Open the ReorganizeMe3 project.
2. Select the Source group. Control/Right - click the Source group and choose Delete. In the
dialog box, click Delete References.
3. Select the Project Structure group. Choose Project ➪ Add to Project. Select the Source

folder and click the Add button.
4. In the Add to Project dialog box, uncheck the Copy option, set Reference Type to Default,
and select Recursively Create Groups for Any Added Folders. Click the Add button.
c05.indd 84c05.indd 84 1/21/10 1:22:15 PM1/21/10 1:22:15 PM
Download at getcoolebook.com
Remember that the project document doesn ’ t contain any of the source material for your project;
just references to those fi les. In step 2, you deleted all of the references to the source fi les in this
project — but just the references; the original source fi les are still in the project folder.
In steps 2 and 3, you used the Add to Project command to re - create new groups and source fi le items
that match the reorganized folder hierarchy exactly.
If you have major asset reorganization to do, the fastest and easiest way to rectify your groups and
source items might be simply to start over. This might inadvertently include other fi les, or place fi les
in targets that don ’ t belong there, but these aberrations can usually be dealt with swiftly.
Why you would not want to let Xcode rebuild all the groups and items? Deleting
the source items also deletes any other attributes associated with those items.
File encoding, custom tab settings, specifi c target membership, comments, and
build options are lost when the source items are deleted. The newly created
source items will all have default attributes. If you need to preserve attributes for
a large number of source items, you probably have no choice but to reorganize
the groups and folders “ the hard way, ” using one of the fi rst two techniques.
SUMMARY
You should now have a clear understanding of how Xcode refers to source fi les in a project. As you
work with Xcode, keep these key concepts in mind:
Every source item has a path to the fi le or folder to which it refers.
A path can be absolute, relative to the project folder, or relative to the folder of the enclosing
group.
File, folder, and framework items have the same names as the source fi les or folders to
which they refer. Renaming the source item renames the physical fi le or folder. In contrast,
the name of a source group is independent of the folder to which it refers.
The path and reference type of an item can be changed in an Info window. A multi - item

Info window can change the location or reference type for several items at once.
Moving an item in the source tree adjusts its path so that it continues to refer to the same
fi le or folder.
Now that you can add new and existing source fi les to your project, you will undoubtedly want to
edit them. Editing text is the topic of the next chapter.
➤
➤
➤
➤
➤
Summary
❘
85
c05.indd 85c05.indd 85 1/21/10 1:22:16 PM1/21/10 1:22:16 PM
Download at getcoolebook.com
c05.indd 86c05.indd 86 1/21/10 1:22:19 PM1/21/10 1:22:19 PM
Download at getcoolebook.com