Dan Wood: The Eponymous Weblog (Archives)

Dan Wood Dan Wood is co-owner of Karelia Software, creating programs for the Macintosh computer. He is the father of two kids, lives in the Bay Area of California USA, and prefers bicycles to cars. This site is his older weblog, which mostly covers geeky topics like Macs and Mac Programming. Go visit the current blog here.

Useful Tidbits and Egotistical Musings from Dan Wood

Categories: Business · Mac OS X · Cocoa Programming · General · All Categories

Wed, 15 Aug 2007

Source Code Organization

permanent link · Topic/Cocoa
/Cocoa

Justin "Carpe Aqua" Williams reveals, on his Pinup CalendarBlog , his technique for organizing source code. I thought I'd link to it, since it's useful and very close to what we do. I don't have a strict template I follow (perhaps I should) but his approach is pretty close.

Some additions I'd suggest would be accessors (getters and setters; his "accessors & mutators" could be split up maybe), public methods (general functionality documented in the header file), and private methods or support methods, special functions not exposed to the outside world.

If you have lots of different kinds of delegate methods, you can always split up any of your categories into sub-categories (e.g. TextField delegate, Window Delegate, data source, etc. For a subcategory, you could forgo #pragma mark - to make the subcategory stand out less in the popup.

If you have a class that is really huge, it's actually helpful to split it up into multiple files. One ".h" file, declaring multiple categories, with the implementation of each category defined in separate files. For example, our document window controller subclass is so big, it merits nine files!

  • KTDocWindowController.m (general methods)
  • KTDocWindowController+Accessors.m
  • KTDocWindowController+ModalOperation.m
  • KTDocWindowController+Pasteboard.m
  • KTDocWindowController+SiteOutline.m
  • KTDocWindowController+SplitView.m
  • KTDocWindowController+Toolbar.m
  • KTDocWindowController+WebView.m
  • KTDocWindowController+WebEditing.m

A final hint: define a macro "mark" to insert the two pragma-mark lines, using Completion Dictionary.

Cool Building tips from Terrence

permanent link · Topic/Cocoa
/Cocoa

Terrence has written a couple of really cool posts about work he's done that greatly speed up & simplify build processes in Cocoa & XCode....

PNG compression performance

permanent link · Topic/Cocoa
/Cocoa

I've been hearing complaints about how big PNGs are when saved by Sandvox, but I finally got around to testing out this issue. Check out these results.

SourceDimensionsFile Size
JPEG original before reducing & sharpening1200 x 1600912.1 KB
-[NSBitmapImageRep representationUsingType: NSJPEGFileType]
(quality 0.7)		480x640101.6 KB
-[NSBitmapImageRep representationUsingType: NSPNGFileType]480x640376.1 KB
Above PNG then processed by PNGCrusher480x640303.7 KB

Notice that the PNG file when saved from Cocoa are almost four times the size of the JPEG. Of course, the quality (0.7) is going to impact the JPEG size, but that's still quite a hit!

When I processed the output file through PNGCrusher, It was able to squeeze a good chunk of wasted space out of the file. This means that the compression algorithm supplied by Cocoa isn't very optimal. (It would be nice to have a parameter to pass in to determine how much to optimize, the tradeoff being speed of course.)

I wanted to get a sense of how Preview.app would do with this. I saved the scaled-down image from my program as lossless TIFF, then opened and saved as PNG from preview. The results were almost the same, just a few bytes in difference. It's good to know that at least Cocoa's API isn't worse than what Preview uses. As with the API, it might be nice to have some control over how optimized the compression should be!

I think I'm going to file two bugs to Apple. One requesting API access to better PNG optimization; another requesting Preview to control this optimization.