Richard Hult

Small gotcha when using NSView as delegate for CALayer

2010-01-07T00:00:00-08:00

I ran into another small unexpected behavior when working on some Core Animation code recently. I had a subclass of NSView that acted as a layer-hosting view. The layers that the view hosted had the view set as delegate to do some simple drawing.

I didn’t want the layers to animate their bounds so I did the usual:

[layer setActions:[NSDictionary dictionaryWithObjectsAndKeys:
                   [NSNull null], @"bounds",
                   [NSNull null], @"position",
                   nil]];

…which to my surprise didn’t work. After digging around for a while I found out that NSView implements actionForLayer:forKey, which has precedence over the actions dictionary. The quick and dirty solution was to override it and return a null action for the relevant keys:

- (id<CAAction>)actionForLayer:(CALayer *)layer forKey:(NSString *)event
{
    if ([event isEqualToString:@"position"] || [event isEqualToString:@"bounds"]) {
        return (id<CAAction>)[NSNull null];
    }

    return nil;
}

However, my guess is that NSView is not really meant to be used as delegate for its hosted layers like this. A better design in most cases would be to either subclass the layer to do its own drawing, or to use a separate controller for event handling or other book keeping for the layer(s).

So in reality this is not really a problem but I thought I’d post it here in case someone else runs into this problem.

KVO problems with CALayer on 10.5?

2009-12-13T00:00:00-08:00

I was trying out some code on 10.5 that was originally developed on 10.6, and ran into a number of really strange issues. At first they seemed almost random and unrelated but after debugging for a while it turned out they were all related to key-value observation in some way or another.

After more debugging, it became clear that for some reason I was not getting any observer callbacks and Cocoa bindings weren’t working for certain objects.

This looked suspicious, and sure enough, implementing:

+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key
{
    BOOL notifies = [super automaticallyNotifiesObserversForKey:key];
    NSLog(@"Notifies for key %@: %d", key, notifies);
    return notifies;
}

in one of the affected classes showed that the return value was always NO, even for properties that I had declared myself!

The reason is that CALayer’s implementation of automaticallyNotifiesObserversForKey: in 10.5 returns NO for all keys. In 10.6 it works as expected, returning only NO for its own properties.

Fortunately the work-around is simple: just implement the class method yourself and return YES for your own properties:

+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key
{
    if ([key isEqualToString:@"myKey"]) {
        return YES;
    }

    return [super automaticallyNotifiesObserversForKey:key];
}

Tinybird – here we go!

2009-11-30T00:00:00-08:00

If you follow me on twitter, you have already noticed that our new company Tinybird was announced last week. Some of the code posts here in my blog were written as side-effect of working on Harmony, the break reminder tool that Tinybird is giving away as a small launching gift. I hope you’ll enjoy it!

Height-for-width layout with CATextLayer (part 2)

2009-10-27T00:00:00-07:00

Last week I wrote about my experiments to get a height-for-width layout working with a Core Animation text layer. In other words, a layer that resizes vertically to fit its text within a certain width. So far we have the text measuring right and now it’s time to put it to use.

Let’s start with an illustration to show what the end goal is:

The text is automatically wrapped to fit the available size, which by itself is nothing new, as long as you manually provide the width and height, but in this case the size needs to be calculated from the height.

Layout managers

The way Core Animation handles laying out layers is through the layout manager protocol:

- (CGSize)preferredSizeOfLayer:(CALayer *)layer;
- (void)layoutSublayersOfLayer:(CALayer *)layer;
- (void)invalidateLayoutOfLayer:(CALayer *)layer;

In this post I will focus on the two former, preferredSizeOfLayer: and layoutSublayersOfLayer:. The latter is useful when you are caching results and need to invalidate them, but we ignore that for now.

Constraints

The layout manager implementation shipped with Core Animation is called CAConstraintLayoutManager, and works by letting you apply constraints on certain properties of the layer’s geometry. Those are min/mid/max for x/y, width and height. You can also scale and offset the resulting values by constant values which gives a very high level of freedom to set up simple or complex relationships between different layers. In our example, as seen on the images above, we have three layers: the white background, the blue frame, and the text. As I want the blue frame to be resized to fit the text, the easiest setup was to add both the blue frame and the text layer as direct sublayers of the white background. The constraints then become:

Resize the text layer’s width to follow the width of the background (with some margin)
Center the text layer horizontally within the background
Adjust the text layer’s bottom at the bottom of the background (with some margin)
Make the blue frame follow the size of the text layer (with padding)
Center the blue frame relative to the text layer

With the standard layout manager, this results in the text layer being one line and the text to be truncated at the right edge. This is because the text layer reports its preferred frame size to have the height of one line of text.

The height-for-width layout manager

Enter our custom layout manager. Since we still want to be able to use constraints, we subclass the constraints layout manager. By overriding its method preferredSizeOfLayer: and have it assign the size we calculated in the previous post to the text layer, we can get the behavior we want (but with one caveat, more about that soon):

- (CGSize)preferredSizeOfLayer:(CALayer *)layer
{
    if ([layer isKindOfClass:[CATextLayer class]] && ((CATextLayer *)layer).wrapped) {
        CGRect bounds = layer.bounds;
        bounds.size = [self frameSizeForTextLayer:(CATextLayer *)layer];
        layer.bounds = bounds;
    }

    return [super preferredSizeOfLayer:layer];
}

The caveat is that the layout manager goes through the layers to resize and place them, including setting the width of the text. Setting the width of the text could change its height, and some constraints might need to be redone after doing that!

This means we also have to override layoutSublayersOfLayer: to add a small hack. We first invoke super’s implementation to handle the normal constraints based layout. Then we setup the new heights for any text layers as a result of the first pass. Finally we invoke super’s implementation again. As long as you don’t have constraints that would change the text width in the second pass, this works nicely.

- (void)layoutSublayersOfLayer:(CALayer *)layer
{
    // First let the regular constraints kick in to set the width of text layers.
    [super layoutSublayersOfLayer:layer];

    // Now adjust the height of any wrapped text layers, as their widths are known.
    for (CALayer *child in [layer sublayers]) {
        if ([child isKindOfClass:[CATextLayer class]]) {
            [self preferredSizeOfLayer:child];
        }
    }

    // Then let the regular constraints adjust any values that depend on heights.
    [super layoutSublayersOfLayer:layer];
}

This is obviously stretching the intention of the constraint layout manager, but it works for simple and common layer trees like the one described here. There are also some easy opportunities for optimizing the code, as I tried to keep it as simple as possible (such as caching the text measuring, and not laying out unless necessary).

I hope the posts and code will prove useful for someone else besides me. And as usual, if anyone knows a better way to do this, please let me know.

The code is available as an Xcode project in a git repo or source package.

Height-for-width layout with CATextLayer

2009-10-20T00:00:00-07:00

For a project I’m working on, I needed a Core Animation text layer that could adapt its height depending on the available width. This is commonly called a “height-for-width” layout. The stock CATextLayer and CAConstraintLayoutManager can’t really do this, but since you can implement custom layout managers, that’s where I started.

The two most important methods of the layout manager protocol are:

// To implement in the CALayoutManager implementation:
- (CGSize)preferredSizeOfLayer:(CALayer *)layer;
- (void)layoutSublayersOfLayer:(CALayer *)layer;

The idea was to override preferredSizeOfLayer: to special-case any CATextLayers that had wrapping enabled and calculate the needed height for any given width. My first somewhat naive attempt was to use the AppKit’s NSString additions like sizeWithAttributes: or boundingRectWithSize:options:attributes:. The results were almost right but not quite the same as what Core Animation itself would get. Using this approach, the layer would adjust its height according to the available width, but not exactly right. For some widths, the height would be one line to tall or short.

The second option was to use the Cocoa text system and put together the various pieces in order to measure the height with some more control over the process. This consisted of creating an NSTextStorage instance (and setting up the text and its attributes), an NSTextContainer instance (with the right width, and “infinite” height), and an NSLayoutManager instance. After putting those together and forcing a layout which is otherwise done lazily, I got the bounds from the layout manager. The code looked something like this:

// Measures the height needed for a given width using the Cocoa text system:
- (CGSize)frameSizeForTextLayer:(CATextLayer *)layer
{
    NSTextStorage *storage;
    if ([layer.string isKindOfClass:[NSAttributedString class]]) {
        storage = [[NSTextStorage alloc] initWithAttributedString:layer.string];
    } else {
        storage = [[NSTextStorage alloc] initWithString:layer.string];

        /* ... set up the attributes for the storage, like the font ... */
    }

    NSTextContainer *container = [[NSTextContainer alloc] initWithContainerSize:NSMakeSize(layer.bounds.size.width, FLT_MAX)];
    NSLayoutManager *manager = [[NSLayoutManager alloc] init];

    [manager addTextContainer:container];
    [storage addLayoutManager:manager];

    // The text layer doesn't use fragment line padding.
    [container setLineFragmentPadding:0];

    // Force layout, since it's done lazily.
    [manager glyphRangeForTextContainer:container];

    return [manager usedRectForTextContainer:container].size;
}

The result was much better this time, as a matter of fact so good that I thought it was finally right. But then I discovered that for some fonts there was still a small difference between CATextLayer’s measurements and mine. I could not find any parameters that would remove the differences, but some investigations seemed to indicate that the difference was in how the line heights, line spacing or maximum line height was set up. Or perhaps there is some rounding going on in the Cocoa text system to get text lines to end up on evenly aligned pixel boundaries? Either way, I didn’t really feel like going the trial-and-error way to get the (hopefully) right results…

After doing some more debugging in Xcode, it looked like CATextLayer actually uses Core Text directly, so I decided to try that next. This was quite similar to using the Cocoa text system, not surprising as the latter is built as a quite thin layer on top of the former.

Finally, it looked like the results were matching CATextLayer! :) The code that does the text measuring now looked like the following:

// Measures the height needed for a given width using Core Text:
- (CGSize)frameSizeForTextLayer:(CATextLayer *)layer
{
    NSAttributedString *string = [self attributedStringForTextLayer:layer];
    CTTypesetterRef typesetter = CTTypesetterCreateWithAttributedString((CFAttributedStringRef)string);
    CGFloat width = layer.bounds.size.width;
    
    CFIndex offset = 0, length;
    CGFloat y = 0;
    do {
        length = CTTypesetterSuggestLineBreak(typesetter, offset, width);
        CTLineRef line = CTTypesetterCreateLine(typesetter, CFRangeMake(offset, length));
        
        CGFloat ascent, descent, leading;
        CTLineGetTypographicBounds(line, &ascent, &descent, &leading);
        
        CFRelease(line);
        
        offset += length;
        y += ascent + descent + leading;
    } while (offset < [string length]);
    
    CFRelease(typesetter);
    
    return CGSizeMake(width, ceil(y));
}

The method attributedStringForTextLayer: sets up an NSAttributedString correctly from the string, font and fontSize properties of a text layer.

At this point, the height-for-width layout was halfway through complete. The remaining issue left to solve was how make the layout manager do something useful with the calculated height and use it as an input for the regular constraints, for example to place something above the text layer, or to make a nice looking box sized to fit the wrapped text. But that, and the full source code will be available in an upcoming post soon. Stay tuned!

Blog moved to github

2009-10-12T00:00:00-07:00

After trying out blogspot/blogger for a while, I realized it is not ideal for a code blog. Micke pointed me to the solution created by Tom Preston-Werner, which looked perfect for my needs. Simple and very flexible, and since I sit all day in front of my terminal typing git commands, the work flow is also very familiar ;)

Tom’s post about the motivation for creating Jekyll (the site generator used to power the blog) is spot on: Blogging Like a Hacker.

So, I have moved over the posts from my old blog, and new posts will only appear here. See you!

Getting HideOnLaunch right

2009-06-30T00:00:00-07:00

In a previous post I described how to set up an app to launch automatically on login. After posting that, I’ve noticed that it seems like the “Hide on launch” property often seems to be mixed up with the kLSSharedFileListItemHidden key (for an example, see this thread from 2008 on Cocoa-dev).

So in an attempt to improve chances of people finding the right answer when searching for the incorrect key kLSSharedFileListItemHidden, here is the relevant snippet again:

NSDictionary *properties =
    [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES]
                                // NOTE, notice the key name:
                                forKey:@"com.apple.loginitem.HideOnLaunch"];

LSSharedFileListItemRef itemRef = 
    LSSharedFileListInsertItemURL(loginItemsListRef,
                                  kLSSharedFileListItemLast,
                                  NULL,
                                  NULL,
                                  (CFURLRef)bundleURL,
                                  (CFDictionaryRef)properties,
                                  NULL);
...

Making an NSSlider snap to tick marks

2009-05-26T00:00:00-07:00

Have you noticed how the sliders in the energy savings panel in the system preferences behave a little differently from your average slider? They have this nice touch of resistance when you drag the slider across a tick mark, making it easy to end up exactly on a mark. I wanted the same behavior for a slider in my app, and found out that it isn’t builtin in the slider. The way I solved it was by connecting an action to the slider, where I manually restrict the value a bit:

- (IBAction)sliderValueChanged:(id)sender
{
    double range = [sender maxValue] - [sender minValue];
    double tickInterval = range / ([sender numberOfTickMarks] - 1);    

    double relativeValue = [sender doubleValue] - [sender minValue];

    // Get the distance to the nearest tick.
    int nearestTick = round(relativeValue / tickInterval);
    double distance = relativeValue - nearestTick * tickInterval;

    // Change the check here depending on how much resistance you
    // want, or if you don't want it to depend on the tick interval.
    if (fabs(distance) < tickInterval / 8) {
        [sender setDoubleValue:[sender doubleValue] - distance];
    }
}

Then you have to make the slider continously perform the action when moved, instead of just when releasing it. This can be done either by checking the “Continous” check button in Interface Builder or programmatically using:

- (void)setContinuous:(BOOL)flag

on the slider instance.

There might be a better way to do this, if anyone knows about it I’m all ears :)

Keyboard shortcuts in Xcode and Interface Builder

2009-04-29T00:00:00-07:00

If you, like me, are trying to avoid using the mouse (for ergonomic reasons) as much as possible, you probably already have noticed that the Mac is quite alright when it comes to keyboard accessibility. This includes Xcode and Interface Builder, even though the latter by nature requires quite a bit of mouse wrestling. There are also some nice features that can help you having to type less.

Recently, I have been trying to collect the most useful keyboard shortcuts and really learn them so I’m not tempted to use the mouse more than necessary. Here’s the list so far:

Xcode

Besides all the normal text editing shortcuts, I often use those: (⇧ = shift, ⌘ = cmd, ^ = ctrl, ⌥ = option)

⇧⌘E = Zoom the editor by hiding the list above it
⇧⌘D = Open quickly, useful for quickly open any file in the project our elsewhere
^⌘T = Edit all in scope, this saves a lot of tedious editing
^/ = Next placeholder in completions
^. = Toggle between completions
⌥⌘-Up = Toggle between the header/source
^1 = Pop up the file history menu, useful when navigating the project files

The shortcut ^. deserves some extra attention, as it also completes text macros which can save a lot of typing. There is a whole slew of macros that you can use, just a few examples:

pim = expands to #import “file”, highlighting file so you can change it easily
a = expands to the standard alloc/init combination
init = expands to a standard init skeleton
dealloc = expands to the standard dealloc skeleton

Interface Builder

Interface builder also has a few ones I often use:

⌘ while resizing a window = live autoresizing
^⌘ + up/down = select parent/child of selected view
^⌘ + left/right = select previous/next sibling

Global shortcuts

Finally I have a tiny list of desktop wide shortcuts (obviously in addition to the well known ones like ⌘-Tab etc) I sometimes find useful:

^F2 = Focus the application menu

… I said it’s tiny!

I hope this can be useful for others as well.

Adding a preference to launch app on login using the Shared File List API

2009-04-16T00:00:00-07:00

I wanted to make my app launch automatically on login, and looked around for ways to do that programmatically. I first found two ways to do it, both a little bit less than ideal: either using Apple Events to talk to System Events, or by using NSUserDefaults (or CFPreferences) to tweak values in the persistent domain loginwindow (as opposed to the app’s own persistent domain where the preferences for the app are stored). The Apple Events way seemed a bit hackish to me, as did the NSUserDefaults way, considering it meant poking at preferences you don’t own.

Nonetheless, I decided to try the latter, so I went ahead and implemented a simple controller that exposed only one property that I could then bind to a check box button in Interface Builder using Cocoa bindings:

@property BOOL launchOnLogin;

To show more clearly what I did, here’s the part that reads the current login items:

NSUserDefaults *defaults;
NSDictionary *domain;

defaults = [NSUserDefaults standardUserDefaults];
  
domain = [defaults persistentDomainForName:@"loginwindow"];
if (domain) {
    NSArray *items = [domain objectForKey:@"AutoLaunchedApplicationDictionary"];

    for (NSDictionary *entry in items) {
        NSString *entryPath = [entry objectForKey:@"Path"];
        // ... do something with the entry ...
    }
}

The writing part is similar, getting a copy of the existing array, then adding or removing our own item and then setting as the new array:

[domain setObject:updatedItems forKey:@"AutoLaunchedApplicationDictionary"];

// Update the setting.
[defaults setPersistentDomain:domain forName:@"loginwindow"];

// Write changes to disk so the system settings will be up to date
// if opened before the changes are automatically synced.
[defaults synchronize];

While this approach works in general, there’s a problem: the login items list in the system settings panel is not updated when changing the setting in my app’s preferences, and the other way around. Maybe not a big problem, but it made me search some more, which led me to the following note in the release notes for the Launch Services framework in Leopard:

The Shared File List API is new to Launch Services in Mac OS X Leopard. This API provides access to several kinds of system-global and per-user persistent lists of file system objects, such as recent documents and applications, favorites, and login items. For details, see the new interface file LSSharedFileList.h.

The mentioned header file is the only documentation for this new API, but it is quite straightforward: you create an instance of the right list, in this case the login items list for the session. Then there is a bunch of things you can do with the list, what’s interesting for our use case is to get a copy of the array in the list, to add or remove an item, or to register an observer callback for a list. The callback is called when the list changes, which makes it possible for the UI to update accordingly.

Since my app already depends on Leopard, I decided to rewrite my code using LSSharedFileList. The UI was already set up to use the simple controller described above, so a quick rewrite of the controller was enough. I create the list in my init method and add an observer:

loginItemsListRef = LSSharedFileListCreate(NULL,
                                           kLSSharedFileListSessionLoginItems,
                                           NULL);
if (loginItemsListRef) {
    // Add an observer so we can update the UI if changed externally.
    LSSharedFileListAddObserver(loginItemsListRef,
                                CFRunLoopGetMain(),
                                kCFRunLoopCommonModes,
                                loginItemsChanged,
                                self);
}

The matching tearing down is done in dealloc:

if (loginItemsListRef) {
    LSSharedFileListRemoveObserver(loginItemsListRef,
                                   CFRunLoopGetMain(),
                                   kCFRunLoopCommonModes,
                                   loginItemsChanged,
                                   self);
    CFRelease(loginItemsListRef);
}

The callback for the observer is a plain old C funtion:

static void
loginItemsChanged(LSSharedFileListRef listRef, void *context)
{
    LoginItemsController *controller = context;

    // Emit change notification for the bindnings. We can't do will/did
    // around the change but this will have to do.
    [controller willChangeValueForKey:@"launchOnLogin"];
    [controller didChangeValueForKey:@"launchOnLogin"];
}

The rest of the code just needs to check if our app bundle is listed in the login items list in the getter for the property, and add it or remove it in the setter:

// Get an NSArray with the items.
- (NSArray *)loginItems
{
    CFArrayRef snapshotRef = LSSharedFileListCopySnapshot(loginItemsListRef, NULL);
    
    // Use toll-free bridging to get an NSArray with nicer API
    // and memory management.
    return [NSMakeCollectable(snapshotRef) autorelease];
}

// Return a CFRetained item for the app's bundle, if there is one.
- (LSSharedFileListItemRef)mainBundleLoginItemCopy
{
    NSArray *loginItems = [self loginItems];
    NSURL *bundleURL = [NSURL fileURLWithPath:[[NSBundle mainBundle] bundlePath]];
    
    for (id item in loginItems) {
        LSSharedFileListItemRef itemRef = (LSSharedFileListItemRef)item;
        CFURLRef itemURLRef;
        
        if (LSSharedFileListItemResolve(itemRef, 0, &itemURLRef, NULL) == noErr) {
            // Again, use toll-free bridging.
            NSURL *itemURL = (NSURL *)[NSMakeCollectable(itemURLRef) autorelease];
            if ([itemURL isEqual:bundleURL]) {
                CFRetain(item);
                return (LSSharedFileListItemRef)item;
            }
        }
    }
    
    return NULL;
}

- (void)addMainBundleToLoginItems
{
    // We use the URL to the app itself (i.e. the main bundle).
    NSURL *bundleURL = [NSURL fileURLWithPath:[[NSBundle mainBundle] bundlePath]];
    
    // Ask to be hidden on launch. The key name to use was a bit hard to find, but can
    // be found by inspecting the plist ~/Library/Preferences/com.apple.loginwindow.plist
    // and looking at some existing entries. Thanks to Anders for the hint!
    NSDictionary *properties;
    properties = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES]
                                             forKey:@"com.apple.loginitem.HideOnLaunch"];
    
    LSSharedFileListItemRef itemRef;
    itemRef = LSSharedFileListInsertItemURL(loginItemsListRef,
                                            kLSSharedFileListItemLast,
                                            NULL,
                                            NULL,
                                            (CFURLRef)bundleURL,
                                            (CFDictionaryRef)properties,
                                            NULL);
    if (itemRef) {
        CFRelease(itemRef);
    }
}

- (void)removeMainBundleFromLoginItems
{
    // Try to get the item corresponding to the main bundle URL.
    LSSharedFileListItemRef itemRef = [self mainBundleLoginItemCopy];
    if (!itemRef)
        return;
    
    LSSharedFileListItemRemove(loginItemsListRef, itemRef);
    
    CFRelease(itemRef);
}

#pragma mark Property accessor methods
- (BOOL)launchOnLogin
{
    if (!loginItemsListRef)
        return NO;

    LSSharedFileListItemRef itemRef = [self mainBundleLoginItemCopy];    
    if (!itemRef)
        return NO;
    
    CFRelease(itemRef);
    return YES;
}

- (void)setLaunchOnLogin:(BOOL)value
{
    if (!loginItemsListRef)
        return;
    
    if (!value) {
        [self removeMainBundleFromLoginItems];
    } else {
        [self addMainBundleToLoginItems];
    }
}

That’s all! Not only does this give you synchronization between your preferences panel and the system settings, but also feels more correct than poking at a different application’s or subsystem’s persistent domain.

Note: There is also a “seed” for each list that can be used to check if the list has changed. Using that you can make sure that any change notification is not emitted unless necessary (see LSSharedFileListGetSeedValue()). The example above doesn’t do that, so there will be notification sent out when toggling the setting from the app’s preferences.

Registering defaults for NSUserDefaults using a property list

2009-04-09T00:00:00-07:00

In a previous post about using property lists, I wrote a little about property lists and a use case I had for them. Another one I ran in to recently is related to user defaults:

NSUserDefaults is the system in Mac OS X that handles user preferences. Applications usually register default values at launch time, so that all preferences have a sane default value in case the user hasn’t set one for a particular preference. Most examples I’ve found on the subject do something along the lines of:

// Register user defaults in the class initializer.
+ (void)initialize
{
    NSDictionary *appDefaults = [NSDictionary dictionaryWithObjectsAndKeys:
                                 @"YES", @"ShowToolBar",
                                 @"NO", @"AutoSaveEnabled",
                                 // ... lots of objects and keys here,
                                 nil];

    [[NSUserDefaults standardUserDefaults] registerDefaults:appDefaults];
}

However, if you have many keys, or just want to make it possible to change them without recompiling, they can be managed through a property list file instead of doing it programmatically. To do that, first create a property list by selecting File → New File… or pressing ⌘-N in Xcode and selecting Property List in the Other category. Then add the default values using the property list editor.

Assuming the plist file is named UserDefaults.plist, the code can then be changed to:

+ (void)initialize
{
    NSString *defaultsPath = [[NSBundle mainBundle] pathForResource:@"UserDefaults"
                                                             ofType:@"plist"];
    NSDictionary *appDefaults = [NSDictionary dictionaryWithContentsOfFile:defaultsPath];

    [[NSUserDefaults standardUserDefaults] registerDefaults:appDefaults];
}

Using property lists

2009-04-04T00:00:00-07:00

Before entering the Cocoa world, whenever I needed to store and retrieve some small amount of data in an application, I usually handcrafted an XML format and wrote a matching XML parser using either DOM or SAX. This often meant a lot of uninspiring code duplication. On Mac OS X, there is a standardized format that is used throughout the system called property list or “plist”. Not only are there APIs to parse plists into the familiar data structures in Cocoa, but there is also a builtin editor for plists in Xcode.

This came in handy recently in some code I was working on. I needed to store 20 or 30 pairs of strings and select one pair randomly from time to time. Instead of entering the strings in the code, they were put into a plist file.

Create and edit a plist

It’s easy to create a property list. In Xcode, just select File → New File… or press cmd-N, and select the template Property List in the Other category. Then add the data you wish to, using the property list editor in Xcode. You can of course also handwrite the XML using any text editor.

Use the data

Assume that the property list is structured with a top-level key called Pairs, whose value is an array of our string pairs. Each pair in turn is also an array, with two strings in each. The code to read the list could then look as follows:

- (void)readStringPairs
{
    NSString *path = [[NSBundle mainBundle] pathForResource:@"MyFileName"
                                                     ofType:@"plist"];
    NSDictionary *toplevelDict = [NSDictionary dictionaryWithContentsOfFile:path];

    // Get the array of pairs, retain it as we need it later.
    pairs = [[toplevelDict valueForKey:@"Pairs"] retain];
}

- (void)randomizeStrings
{
    // Get a random pair, represented by an array.
    NSArray *pair = [pairs objectAtIndex:arc4random() % [pairs count]];

    // Get the two strings.
    NSString *name = [pair objectAtIndex:0];
    NSString *description = [pair objectAtIndex:1];

    // Do something with the strings here.
}

If you need something a little bit more flexible or complex, you can nest dictionaries and arrays in the plist as well. As a matter of fact, my original code doesn’t only have two strings per pair, but one string and an array of strings.