Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog
 
 Archive
 
 Blog Topics
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

Large Cocoa Projects

Rainer Brockerhoff, the man without version control, has posted a nice collection of links to posts responding to Brent Simmons' thoughts on large Cocoa projects, plus his own comments on the matter.

Interesting reading altogether. I generally work the same way, and though I never formulated it in my brain, I found that I rarely send notifications either (only in library classes that are, conceptually, part of Cocoa). The only point where I'm noticeably different is that I'm more of a mouse person. Sorry little kittens.

I also do a little folder structure on disk: I have one honkin' huge folder, the UliKit, containing all kinds of utility classes, and of course most of those categories. Also, in projects that have some sort of plugins, I generally put the "built-in plugins" in their own folder, like the custom field types in AngelTemplate.

I also have some bigger reusable code modules that I don't have in the UliKit, most notably UKDistributedView and UKProgressPanel, and a few others. But generally, I have a one-folder-per-project structure on disk, everything littered around the project, with a README.txt part of the project and the only other folders generally being for resources.

Another feature that's very helpful to get around a project is the filter field in Xcode's toolbar, to quickly find the particular source file you're looking for among those 600. Particularly useful when you only know a word in the middle of the file name, and it almost works like type selection, in that it narrows down the searches, and then you can tab into the Detail View and pick the file you want, or use the contextual menu to reveal it in Groups and Files and operate some more on it. The only trouble is, it doesn't work in "Condensed" mode, which I generally prefer.

Though there's some comments by readers I don't agree with as much (No, I'm not talking about the guy bashing liquid layouts -- I hate fixed-width web sites that would force me to scroll even on a cinema display):

I generally try to use categories for two purposes only: To add general-purpose code to a system object that ends up in my UliKit, to more strictly separate the public and private interface of a class, or to split up a class across several files (well, and for informal protocols, but that's a hack ObjC 2.0 will make unnecessary in a few years). In particular, I try not to have any project-specific categories on system classes, because that generally only is a lazy attempt at re-purposing an object that should be subclassed or wrapped.

I say try, because there's a few cases that are so ugly to solve, that suddenly this becomes the cleanest solution.

Reader Comments: (RSS Feed)
No comments yet
Comment on this article:
Name:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

 
Created: 2007-04-29 @001 Last change: 2007-04-29 @231 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.