Recently, my friend wanted to add print statements to every function for a debug build. This was early in the development process, and it seemed that quick and dirty would work as well as anything. After struggling with it for a while he dashed off a quick “ah ha” email. His results:

I wouldn’t rely on this for final code but it is useful for a quick debug.

So one bug, that I manage to repeat just about every project, is errors with the constants that reference resources. I get the names of PNG files, tags and identifiers wrong all the time. Or I change the name in the resource, even something simple like capitalization. Fortunately with enough testing these errors come to light. But I’ve also solved this problem before. And in a way that uses the compiler to test for some form of correctness. The simple solution is to create a process that preprocesses the resources and creates a source file with all the constants.

But how to drive the preprocess? Xcode custom build phases and custom build scripts are nearly ideal for this type of work and they’re easy to set up. Just select the project root in the navigator, then the target and finally either the build phase or build rules.

This is the Build Phases Panel. Build Phase scripts run once for every compile. I use these for output that is affected by many files, such as a list of all PNGs. In the bottom right corner is the Add Build Phase picker. Select “Add Run Script” to add a new Build Phase script. The ordering of phases can be easily changed by dragging the Run Script title bar. Make sure that this comes before the compile sources because the compile is going to use the results of this output.

I generally find it useful to have the majority of the script in a separate file. That way I can easily reuse the functionality. Its also helpful while debugging the script to be able to run it directly from the command line.

Those actions that are more specific to the project I tend to not place in the script file. The ‘cd’ and ‘cp’ in the illustration above are examples of this. Even as I write this I’m not fully convinced that this is the best solution. The nice thing is that if I change the script and it doesn’t work the compiler will tell me something is wrong. To me thats testing early and testing often.

This is the Build Rules Panel. The Add Build Rule is a simple button. Build Rules are run once for each file, and the Process menu can be used to select which type of file it is run with. You could replicate the functionality of a Build Rule with a Build Phase that walks the project hierarchy. The advantage of a Build Rule is that it is sensitive to changes to the input file and will only process files that have an actual change. It also ensures that the input files are actually in the project.

The Build Phase script that I’ve included in this project creates a list of defines for the PNG files. Its written in Ruby. I’m not a Ruby programmer so it may be a bit rough.

#! /usr/bin/env ruby

dest = File.open(ARGV[0],File::CREAT|File::WRONLY,0777)

Dir.foreach(".") { |file|
    expression =  /.png$/
    if expression.match file #filename ends with .png
        name = File.basename(file,".png")
        dest.puts "#define k_png_"+ name + " @\"" + name + "\""
    end
}

dest.close

and its output is

#define k_png_glyphicons_002_dog @"glyphicons_002_dog"
#define k_png_glyphicons_031_bus @"glyphicons_031_bus"
#define k_png_glyphicons_042_group @"glyphicons_042_group"
#define k_png_glyphicons_070_umbrella @"glyphicons_070_umbrella"
#define k_png_glyphicons_132_inbox_minus @"glyphicons_132_inbox_minus"
#define k_png_glyphicons_143_database_ban @"glyphicons_143_database_ban"
#define k_png_glyphicons_158_playlist @"glyphicons_158_playlist"
#define k_png_glyphicons_193_circle_ok @"glyphicons_193_circle_ok"
#define k_png_glyphicons_264_fishes @"glyphicons_264_fishes"
#define k_png_glyphicons_304_vimeo @"glyphicons_304_vimeo"

Your could perform all sorts of remapping of the of the characters, such as all caps or camel case and remove the underscores, but I prefer that generated items be as easily identified with their source as possible and so do a minimal amount of processing.

The Build Script script uses an xml parser to extract the attributes of various elements and again uses a very simple define for the mapping.

#! /usr/bin/env ruby

require "rexml/document"
dest = File.open(ARGV[1],File::CREAT|File::WRONLY,0777)
src = REXML::Document.new File.open(ARGV[0])

src.elements.each("//@storyboardIdentifier").each do
    |element|
    if element.value != ""
        dest.puts "#define k_storyboard"+ element.value + " @\"" + element.value + "\""
    end
end

src.elements.each("//@reuseIdentifier").each do
    |element|
    if element.value != ""
        dest.puts "#define k_reuseIdentifier"+ element.value + " @\"" + element.value + "\""
    end
end

src.elements.each("//@tag").each do
    |element|
    if element.value != ""
        dest.puts "#define k_tag"+ element.value + " @\"" + element.value + "\""
    end
end

dest.close

and its output is

#define k_storyboardMasterObject @"MasterObject"
#define k_storyboardTableController2 @"TableController2"
#define k_reuseIdentifierTitle_1 @"Title_1"
#define k_reuseIdentifierCell_Type_2 @"Cell_Type_2"
#define k_tag12345 @"12345"

The final step in both of these is to copy the files produced back to a location that can be referenced from your normal source code. By convention I create a directory to hold all the generated files. This makes it really easy to identify them so you don’t do things like edit by hand.

This technique doesn’t solve all errors. You can still reference the wrong file, tag or identifier, rather that a nonexistent one. But it does prevent the most common error with little effort. And any help, however minor, adds to my satisfaction with the result.

Theres a demo project here. I’m still refining the scripts and maybe next time I’ll include type checked code rather than just pound defines. Wouldn’t it be cool to be able to write [[CodeGenerator shared] loadPNG_foo] and know that it will work.

Recently, I finished an application that used a UITabViewController to manage multiple master controllers. The starting point was MultipleDetailViews. Its a great starting point but doesn’t leverage the new Storyboard paradigm. I’m going to re-implement this sample to iOS 5.

The UISplitViewController manages two view controllers, a master controller and a detail controller. The master controller manages the left portion in landscape mode and the popover while in portrait mode. The detail view controller is always visible.

This demo extends that by using a Tab view controller to manage multiple master controllers and swapping in detail controller associated with the active master controller.

Step 1: Create the Project

Open up Xcode and from the main menu choose File\New\New Project. Choose the iOS\Application\Master-Detail Application template, and click Next. Name the product MultipleMasterDetailViews, select iPad for the Device family, and make sure just the Use Automatic Reference Counting checkbox is checked, click Next and save the project by clicking Create.

Step 2: Modify the Storyboard

The UISplitViewController contains UINavigationController contains MDMasterViewController. This project inserts a UITabBarController as a container between the UISplitViewContoller and the UINavigationController. Do this by dragging a UITabBarController onto the storyboard and option drag from the UISplitViewController to the UITabBarController. Select Relationship-masterViewController when prompted. Delete the default UIViewControllers from the UITabBarController and add the UINavigationController/MDMasterViewController as a tab. Duplicate the UINavigationController/MDMasterViewController and this second one as a tab as well. We’re reusing the MDMasterViewController for demonstration purposes only. In practice they might be different classes.

The final modification to the storyboard is to add another scene for the second detail view. Using the current UINavigationController/MDDetailViewController as a prototype, copy and paste a new scene into the Storyboard. This new scene needs an identifier because it is loaded using instantiateViewControllerWithIdentifier:(NSString*).

Set the identifier property of the UINavigationController to “Detail 2 Root” (I wish that Xcode would automatically create a header file to automate this fragile mapping, hint, hint).

The Storyboard layout should now be similar to this.

Step 3: Master Detail Manager

The Apple sample code implements the UISplitViewControllerDelegate in the detail view controller. I’m using the Composition pattern to implement this functionality for increased reusability. Create a new class that implements the UISplitViewControllerDelegate and  UITabBarDelegate. This implementation assumes that all the DetailViewControllers are imbedded in a UINavigationController and that the first item  of the UISplitVeiwController.viewControllers is a UITabBarController. This initWithSplitViewController: updates the delegate properties of both the splitViewController and the master controller (the first controller) to self. The array that’s provided must also have the same number of detail controllers as controllers in the tabBarController.viewControllers.

@interface MDMultipleMasterDetailManager
           : NSObject

-(id)initWithSplitViewController:(UISplitViewController*)splitViewController
       withDetailRootControllers:(NSArray*)detailControllers;

@end

The implementation of initWithSplitController is relatively straight forward.

@implementation MDMultipleMasterDetailManager

@synthesize splitViewController = __splitViewController;
@synthesize detailControllers = __detailControllers;
@synthesize masterBarButtonItem = __masterBarButtonItem;
@synthesize masterPopoverController = __masterPopoverController;
@synthesize currentDetailController = __currentDetailController;

-(id)initWithSplitViewController:(UISplitViewController*)splitViewController withDetailRootControllers:(NSArray*)detailControllers
{
    self = [super init];
    if(self){
        __splitViewController = splitViewController;
        __detailControllers = [detailControllers copy];
        UINavigationController* detailRoot = [splitViewController.viewControllers objectAtIndex:1];
        __currentDetailController = detailRoot.topViewController;

        splitViewController.delegate = self;
        UITabBarController* tabBar = [splitViewController.viewControllers objectAtIndex:0];
        tabBar.delegate = self;
    }

    return self;
}

The UISplitViewControllerDelagate methods have to manage the currently active detail controller and maintain enough state to update other detail controllers if they become active. This implementation modifies the left button of the detail controllers directly.

/* forward the message to the current detail view
 */
-(void)splitViewController:(UISplitViewController *)svc willHideViewController:(UIViewController *)aViewController withBarButtonItem:(UIBarButtonItem *)barButtonItem forPopoverController:(UIPopoverController *)pc
{
    self.masterBarButtonItem = barButtonItem;
    self.masterPopoverController = pc;

    barButtonItem.title = NSLocalizedString(@"Master", @"Master");

    [self.currentDetailController.navigationItem setLeftBarButtonItem:self.masterBarButtonItem animated:YES];
}

/* forward the message to the current detail view
 * all detail views must implement UISplitViewControllerDelegate
 */
-(void)splitViewController:(UISplitViewController *)svc willShowViewController:(UIViewController *)aViewController invalidatingBarButtonItem:(UIBarButtonItem *)barButtonItem
{
    self.masterBarButtonItem = nil;
    self.masterPopoverController = nil;

    [self.currentDetailController.navigationItem setLeftBarButtonItem:nil animated:YES];

}

The UITabBarControllerDelegate just swaps the button and popover from the previous detail controller to the detail controller associated with the currently selected master controller.
According the the UIPopoverController documentation the navigation bar is automatically included in the passthrough views. As the detail controllers are exchanged, the passthrough views of the popover need to be updated as well.

// change detail view to reflect the current master controller
-(void)tabBarController:(UITabBarController *)tabBarController didSelectViewController:(UIViewController *)viewController{
    UINavigationController* detailRootController = [self.detailControllers objectAtIndex:tabBarController.selectedIndex];
    UIViewController* detailControler = detailRootController.topViewController;

    if(detailControler != self.currentDetailController)
    {
        [self.currentDetailController.navigationItem setLeftBarButtonItem:nil animated:NO];
        self.currentDetailController = detailControler;

        UIViewController* tabBarController = [self.splitViewController.viewControllers objectAtIndex:0];

        self.splitViewController.viewControllers = [NSArray arrayWithObjects:tabBarController,detailRootController, nil];

        // replace the passthrough views with current detail navigationbar
        if([self.masterPopoverController isPopoverVisible]){
            self.masterPopoverController.passthroughViews = [NSArray arrayWithObject:detailRootController.navigationBar];
        }
    }
}

Finally, the application delegate needs to be modified to wire this all up. Because we’ve used the delegate pattern, it’s only a couple of lines of code in didFinishLaunchingWithOptions.

@interface MDAppDelegate()
@property (strong,nonatomic)MDMultipleMasterDetailManager* masterDetailManager;
@end

@implementation MDAppDelegate

@synthesize window = _window;
@synthesize masterDetailManager = __masterDetailManager;

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    UISplitViewController *splitViewController = (UISplitViewController *)self.window.rootViewController;

    UIViewController* detail1 = [splitViewController.viewControllers objectAtIndex:1];
    UIViewController* detail2 = [splitViewController.storyboard instantiateViewControllerWithIdentifier:@"Detail 2 Root"];

    self.masterDetailManager = [[MDMultipleMasterDetailManager alloc] initWithSplitViewController:splitViewController
                                withDetailRootControllers:[NSArray arrayWithObjects:detail1,detail2,nil]];

    return YES;
}

And the Link to the GIT Repository

Here’s a link to public GIT repository project if you want to look at a working example. I hope you find it useful.