Database Reference
In-Depth Information
cvs update: Updating ChatAPI/ChatAPI.xcodeproj
U ChatAPI/ChatAPI.xcodeproj/project.pbxproj
No muss, no fuss, no broken project files. This strategy works well for dividing up
work, with a few caveats.
Make Sure All Dependent Projects Do Their Own Unit Testing
Xcode will offer to create a Unit Test target for a library, when you create it. You should
take Xcode up on the offer. By its nature, a dependent library needs to be able to stand
alone, and that includes testing.
This is pretty straightforward if all your library does is implement business logic, or
something else divorced from the UI. It becomes more troublesome if you are going to
try, for example, to divide up the UI responsibilities for the applications into various
subprojects, and then integrate them all up into a main project. In iOS 5, you can do
business level testing by injecting your unit tests into the running application, but in
this case, you need to have an operating
UIApplicationDelegate
. Where are your sub-
projects going to get it? Are you going to have a dummy
main.m
in each of your sub-
projects that fires up the application just far enough to test the UI code? These are the
kinds of issues you need to consider when you start dividing up your project.
Also, as mentioned in the next section, XIBs and other resources can't live in libraries,
so the ability to divide up UI work into multiple developers is fairly limited to begin
with.
You Need to Plan Out Common Resource Issues
Unfortunately, breaking projects up into subprojects doesn't solve all your problems.
In fact, it doesn't solve many of them. For example, there's no way in a static library
to include bundle information, such as localizable strings and images. You need a
framework to do that, and at the moment, Apple doesn't allow custom frameworks for
the iOS family of products. Maybe sometime in the future, this will be available, but
for the moment, you're fairly much screwed if you want to keep your localizations close
to the library.
This doesn't mean that you can't take advantage of
NSLocalizedString
in your li-
braries, just that the actual
Localized.strings
files are going to have to live in the main
project. And as I mentioned, those files are a real bear to merge, because they are
UTF-16 format. The best strategy is going to depend on the dynamics of the group, but
it probably makes sense to appoint a single “stringmeister,” who is responsible for the
overall coordination of the string files. This person can also serve as a liaison to the
translation resources (in-house or contracted) that are actually going to do the work.
This is also a good practice because, in the absence of a single person riding herd on
the strings, you tend to end up with duplication all over the place as multiple developers
