views:

327

answers:

3

I know how to write a Cocoa project, with classes, xib files, localizations, property lists, resources, ...

Sometimes, when I want to learn a specific API or a how-to for a cool feature, apple reference manuals or programming guides point to examples to download.

And sometimes, I feel lost digging in all this source code and not finding where to start or how everything goes together.

I think the main obstacle for me is that a Cocoa project is not text only. Object instantiations and connections between objects can be defined in xib files. Multiple xib files may coexist with the main xib file being declared in a property list. In the end I find myself switching between multiple windows of interface builder and multiple editors of Xcode, never sure that I look at the correct file...

My question is: how do you handle such situations? Have you some tips for browsing a Cocoa project that you didn't write?


Update: Here is my interpretation of answers:

Possibles ways of dealing with this complexity are:

  • Experience. The more you know about structure of Cocoa projects the more efficient you are in finding and following non obvious links between .m/.h files and .xib files. I am interested in resources on what and where I should look at first, IBOutlets, delegates, bindings, ...

  • Static analysis. For text only projects, I use Doxygen which is able to draw dependency, calling/caller and inheritance graphs. From the answers, I learn that OmniGraffle might be able to do such things with Xcode projects including XIB files. If someone has informations on this or knows other tools, please add an answer to this question.

  • Dynamic analysis. Let the program run and show its internal behaviour, with a debugger or NSLogs. This is an interesting approach, though I am not sure that I won't be lost also in data mining all debugging traces...

I would thank all contributors and encourage others to participate, even with partial answers. I will update this synthesis as I gather new informations.


Update 2: There is a newer question on this kind of issue: Cocoa suggested techniques for debugging binding problems between Xcode and Interface Builder? Its answers may be of interest.

A: 

I recommend getting and reading a book. LaMarche's Beginning iPhone Development is a good resource for all things Interface Builder with regards to iPhone.

Also, Jonathan Z. (aka NerveGas) 's book is also good.

Then, read source code and check out Apple's sample projects.

Good Luck!

Genericrich
Thank you for your advice. I think that reading source code is a good way to learn. I would just point out that my concern is not a lack of knowledge, but a feeling that important information for understanding a Cocoa project is disseminated in multiple places: Xcode, IB, .m, .nib, .plist, ...
mouviciel
+2  A: 

When I have a large code base to get familiar with I often find a tool that can generate UML (or at least inheritance) graphs useful.

For your case, I'm not so sure (I'm currently working through LaMarche's iPhone book)... I know exactly where you're coming from...

One thing that occurs to me is that all important IB objects must have an associated IBOutlet in your code, or IBAction method... Perhaps a UML generating tool could be useful...

dicroce
A tool able to generate graphs from both Xcode and IB would be great! For IBOutlet 2) what about delegates, data sources, bindings...?
mouviciel
I know that OmniGraffle will generate a diagram if you drag an Xcode project on it. I've only used it to look at object inheritance, but others have mentioned using it with NIBs.
Brad Larson
+2  A: 

One tip that I picked up was to stick a load of breakpoints in the sample code, build and then run the program;

You'll be able to see what actions are causing what bits of code to run.

You can generate inheritance diagrams from within Xcode:

Highlight the source files that you want to examine and then, from the menu: Design | Class Model | quick model.

Abizern
This is interesting. I didn't think of dynamic approaches.
mouviciel