Riffs on Thoughts about large Cocoa projects

Brent Simmons shared a few thoughts on managing largish Cocoa projects. Here’s my riffs off his notes:

Notifications can make code hard to follow

Agreed: you should treat notifications like they’re a last resort, especially in application code. Think of the common notifications you deal with, and you’ll realize they originate from Cocoa. There’s a reason for this: notifications are a way to couple very independent classes. As in: classes that will be written a few years from now.

Think of your Cocoa application as a layer cake: Foundation at the bottom, AppKit in the middle, your code on top. It’s OK for higher levels to know about and use lower levels, but not going the other way. By keeping the lower levels ignorant of its clients (the higher levels), you keep them reusable.

Most of the time you’re using notifications, it’s because of this architecture. The great part is that AppKit is highly reusable. The downside is since AppKit has no idea about how its being used, it has to use this highly generalized mechanism to communicate with its client. (Fortunately, Cocoa often codifies the general notification mechanism through an explicit delegate pattern (i.e. NSApplicationDidFinishLaunchingNotification vs. -applicationDidFinishLaunching:) making things easier to follow.)

So unless you’re writing a framework that can have multiple clients, you probably are better off sending messages directly.

Key-Value Observing: for prefs only

Yup: KVO is magic. Use it sparingly outside its standard UI-binding domain.

Bindings are for basic stuff

Agreed.

Use #pragma mark, use the function popup. […] It?s the fastest way I?ve found to get a quick look at what?s in a file.

I do the same thing. A couple of other things that sometimes get “wait! how did you do that?!?” reactions at PSIG and CAWUG:

• command-double-click to jump to the target symbol’s implementation. (option-double-click also opens up the documentation browser, but I never use it since I despise Xcode’s built-in doc browser.)

• Use control+arrow keys to jump around in interCapitializedWords. This is an old CodeWarrior-ism that not enough folks are using.

I put a Source directory inside my project directory. Inside Source is all the .h and .m files. Flat. No sub-folders

I’m even worse: all the source goes right alongside the .xcodeproj file. I have projects with 600+ source files, just lying flat there. As Brent writes, all the real logical organization sits in the Xcode project itself. Mostly this is due to a failing of Xcode (its inability to handle folder reference with sources), but the organization has to be somewhere, and not duplicated. Xocde it is, then.

Parroting Brent, keep things flat as possible. Never beyond two levels deep. Smart groups and the search box makes it easy to slice through even large projects, so don’t waste time setting up and maintaining elaborate hierarchies. Half your team will just disagree with those hierarchies anyway, but everyone appreciates a singular (but searchable!) mess.

Wednesday, April 25, 2007
07:15 PM