The answer lies in what is known as the fragile base class problem.

In standard Objective C runtimes, including Apple’s, classes are actually plain C structures, defined in /usr/include/objc/objc-class.h. (This hints at how toll-free bridging is possible between CoreFoundation’s C data structures and Foundation’s Objective C objects.)

Objective C programmers are happily aware that methods are dynamically bound at runtime. This is the secret sauce behind much of Objective C’s magic, such as categories, message forwarding, and runtime introspection. However, unlike with method dispatching, which works by name, instance variables are referenced by their memory offsets in the class structure and statically bound at compile time. So if the base class structure ever changes in size, or if the instance variables are rearranged, subclasses need to recompiled as well, or the layout of objects in memory will be incorrect and your application will crash. (This is why Apple tends to pad base class structures, if not hide them outright, for forward compatibility; the class definition of NSNotificationCenter shows an example of this.)

Note that the fragile base class problem doesn’t affect most application developers, because in application code, your base classes and your subclasses tend to be compiled simultaneously, and you assume that the base classes you’re using in frameworks won’t be changing. So unless you’re writing a public API, you don’t generally need to worry about this problem.

Nevertheless, even for application developers, it’s good to understand how Objective C really works. Situations like this reveal how Objective C really is merely a thin layer on top of C. In fact, when you write Objective C syntax such as [object message:arg], it’s really shorthand for primitive C function calls such as objc_msgSend(). (This is why if you try to send a message to a released object, you’ll see objc_msgSend in the backtrace of the crash.)

The following is straight C code. It shouldn’t be hard to read it and translate it to its Objective C equivalent.

#include <objc/objc.h>


void * pool = objc_msgSend(objc_lookUpClass("NSAutoreleasePool"), sel_getUid("alloc"));
objc_msgSend(pool, sel_getUid("init"));

void * date = objc_msgSend(objc_lookUpClass("NSDate"), sel_getUid("date"));
void * string = objc_msgSend(date, sel_getUid("description"));
printf("%s\n", objc_msgSend(string, sel_getUid("UTF8String")));

objc_msgSend(pool, sel_getUid("release"));

If the column is wide enough, the date is displayed in a nice long format:

Wednesday, January 3, 2007, 12:34 PM

As the table column is resized, the date is dynamically reformatted to fit in the available width:

Wednesday, January 3, 2007, 12:34 PM
January 3, 2007, 12:34 PM
Jan 3, 2007, 12:34 PM
1/3/07, 12:34 PM
1/3/07

It also displays relative date strings if the date is recent enough:

Today, 12:34 PM
Yesterday, 12:34 PM

This level of craftsmanship and attention to detail is what made the original Macintosh Finder so respected and loved. It’s nice that this feature has been carried over to the Mac OS X Finder.

Unfortunately, the standard Cocoa classes don’t give you this behavior for free.

TableColumnDateFormatter is a subclass of NSDateFormatter which implements similar behavior. To use it, drop the TableColumnDateFormatter folder into your project, then add the following code:

#import "TableColumnDateFormatter.h"

- (void) awakeFromNib
{
	TableColumnDateFormatter * df = [[TableColumnDateFormatter alloc] init];
	NSTableColumn * tableColumn = [tableView tableColumnWithIdentifier:@"date"];
	[df setTableColumn:tableColumn];
	[df release];
}

• Sources: TableColumnDateFormatter.zip (6K)

It turns out that you can’t, at least not directly. You have to use the CFPreferences API.

BundleUserDefaults is a subclass of NSUserDefaults which wraps around CFPreferences and allows you to specify a persistent domain name. Just initialize it with your domain string, and use it like you’d normally use NSUserDefaults.

You can even use your instance of BundleUserDefaults with NSUserDefaultsController by calling an undocumented setter method -[NSUserDefaultsController _setDefaults:]:

+ (void)initialize
{
BundleUserDefaults * ud = [[BundleUserDefaults alloc] initWithPersistentDomainName:@"com.example.test"];
[[NSUserDefaultsController sharedUserDefaultsController] _setDefaults:ud];
[ud release];
}


This makes it really easy to implement a preferences panel in your plug-in or shared framework, without writing any additional code. Just use Cocoa Bindings to bind to the shared user defaults controller, paste in the above code snippet, and you’re done.

• Sources: BundleUserDefaults.h and BundleUserDefaults.m

Spotlight sometimes misses files, namely those tucked away inside bundle structures or system directories. Unfortunately, because Spotlight is designed to optimize general searches, it falls short when you’re trying to do specific searches.

Find File, Sherlock, and Spotlight

You might remember that back in System 7.5 (1995), Apple introduced a Find File utility which allowed one to search a volume by file name or other attributes. It was very fast, thanks to a specific design characteristic of the Mac’s native file system: HFS+ stores its catalog data in a centralized manner, instead of distributed across directories. This approach makes the catalog data more susceptible to corruption, but it also makes file searches very fast. There is no need to index file names, because the file system is inherently indexed.

With Sherlock, introduced in Mac OS 8.5 (1997), Apple started moving toward the find-by-content problem space. Spotlight, introduced in Mac OS X v10.4 (2005), represents Apple’s latest solution to the problem of search. The underlying indexing technology used by Spotlight is an evolution of Apple’s SearchKit technology (in turn based on Apple Information Access Toolkit, a.k.a. VTwin), but the Spotlight user experience is a completely new approach, based on the idea of a single search field that applies to all content by default. It’s basically the same thing as what Google calls universal search, but Spotlight obviously applies the idea across the desktop operating system instead of the Internet.

The patent that covers Spotlight, 6847959 (“Universal interface for retrieval of information in a computer system”), was actually filed in 2000, revealing that Apple had been working on universal search for several years before Spotlight was ever introduced. Apple’s first implementation of universal search was actually in iTunes (2001).

Spotlight’s strength, however, is its greatest weakness. If you know exactly what you want to search for, it takes a bit more work on your part to set up a filename-only query (and you can’t do it from the Spotlight menu). Even so, many system directories and temporary files are omitted from the search as a performance optimization, which can pose a real problem if those are the files you’re looking for. This effectively also means that the search results are not guaranteed to be complete. In practice, we’ve gone a step backwards from the simple, reliable Find File of System 7.5.

find and locate

There are also two standard Unix command-line tools which search the file system. The first command-line tool is find. In additional to its awkward interface, find performs a walk of the directory hierarchy because it doesn’t know about HFS+. This makes find slow, although it provides more complete search results than Spotlight.

The second command-line tool is locate. Unlike find, locate uses a index, so searching is fast. Unfortunately (and unlike with Spotlight), the index is only updated automatically when the /etc/weekly script runs, which isn’t guaranteed to happen, especially if your computer tends to be asleep.

FSCatalogSearch()

It’s not obvious, but the functionality of Find File does still exist on Mac OS X. At the heart of Find File is a Carbon File Manager function called FSCatalogSearch. You create an iterator and pass in a struct of search options, and FSCatalogSearch uses that iterator to search until the iterator is exhausted.

Here’s a simple command-line tool which uses FSCatalogSearch to search for files by name.

usage: findfile [-r <volume>] <name>

• Binary: findfile (46K, Mac OS X v10.4)
• Sources: findfile.zip (5K)

Comparison

The best technology for finding files by name, as measured by both completeness of results and performance, is FSCatalogSearch. Ironically, it does not have a visible interface in Mac OS X v10.4. The best approximation is to set up a Smart Folder which searches by Filename or even Raw Query.

mdfind is a command-line interface to the central metadata store that underlies Spotlight. Perversely, mdfind offers better results than the Finder interface to the same technology. The only difference between mdfind and FSCatalogSearch is that mdfind does not enter bundles, so that /Applications/iSync.app/Contents/Resources/orangelight.tiff, for example, won’t be found.

P.S. Here’s a tip. You can actually enclose your search terms in quotation marks:

“example”

Spotlight will limit your search by name. (This only works from the Spotlight menu.)