Landon Fuller

Introduction

On Friday, Plausible Labs released PLBlocks, an SDK that allows you to immediately begin experimenting with blocks (also known as closures) on Mac OS X 10.5 and iPhone OS 3.0. While the original announcement included a very brief introduction to blocks, I thought it might be worthwhile to provide some concrete examples of using blocks in your own code.

Example Code

All the sample code and implementation classes for this article are available via my block_samples github repository. You may download the repository as an archive (no git required) by pressing the "download" button next to the repository name.

To get started with the PLBlocks SDK, check out the download and installation instructions on the project page. Please note that PLBlocks is still in beta.

NSOperationQueue

On Mac OS X and iPhoneOS, there are a variety of ways to schedule operations on a background thread. One method that's often used is calling -[NSObject performSelectorInBackground:withObject:] to execute a method in the background, and then -[NSObject performSelectorOnMainThread:withObject:waitUntilDone:] to provide the results to the primary thread.

This works, but it's not as convenient as it could be:

• Every background task requires at least one new method definition.
• Methods can only accept one (or two) arguments.
• There's no easy way to provide the background method with additional state.

Using blocks -- and a few small extensions to NSOperationQueue and NSThread -- we can instead encapsulate this full exchange in one method, using a block to run the background operation, and a nested block to handle the response directly on the main thread:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    // Allocated here for succinctness.
    NSOperationQueue *q = [[NSOperationQueue alloc] init];
 
    /* Data to process */
    NSData *data = [@"Hello, I'm a Block!" dataUsingEncoding: NSUTF8StringEncoding];
 
    /* Push an expensive computation to the operation queue, and then
     * display the response to the user on the main thread. */
    [q addOperationWithBlock: ^{
        /* Perform expensive processing with data on our background thread */
        NSString *string = [[NSString alloc] initWithData: data encoding: NSUTF8StringEncoding];
         
        /* This is the "expensive" part =) */
        sleep(5);
         
        /* Inform the user of the result on the main thread, where it's safe to play with the UI. */
        [[NSThread mainThread] performBlock: ^{
            NSAlert *alert = [[[NSAlert alloc] init] autorelease];
             
            [alert addButtonWithTitle: @"OK"];
            [alert setMessageText: [NSString stringWithFormat: @"Processing completed: %@", string]];
            [alert runModal];
        }];
 
        /* We don't need to hold a string reference anymore */
        [string release];
    }];
}

The first block is scheduled to run on the NSOperationQueue, and inside contains an additional nested block. When the operation has completed, it schedules its nested block to run on the main thread, where the result can be presented to the user, or passed on for further processing.

You can find the full NSOperationQueue and NSThread extensions -- including example usage -- here.

UIActionSheet

If you've done any iPhone development, you'll know that using UIActionSheet is a bit complicated -- more so if you want to share an action sheet implementation across view controllers, or display multiple UIActionSheets from a single view controller.

If you've used UIActionSheet in the past, you've had to do the following:

• Create a UIActionSheet instance in your view controller.
• Add the UIActionSheetDelegate protocol to your view controller.
• Add the -[UIActionSheetDelegate actionSheet:clickedButtonAtIndex:] delegate method.
• Match the button index and source action sheet to your intended action, fetch any state you need, and execute.

Using blocks, we can significant reduce the effort required to define and use a UIActionSheet. Instead of defining a delegate, and matching index values to your button actions, we can simply pass a block that implements the button's action directly:

- (void) displaySheet {
    PLActionSheet *sheet = [[PLActionSheet alloc] initWithTitle: @"Destination"];
    
    /* A re-usable block that simply displays an alert message */
    void (^alert)(NSString *) = ^(NSString *message) {
        UIAlertView *alert = [[UIAlertView alloc] initWithTitle: @"Destination Selected"
                                                        message: message
                                                       delegate: nil
                                              cancelButtonTitle: @"OK"
                                              otherButtonTitles: nil];
        
        [alert show];
        [alert release];
    };
    
    [sheet addButtonWithTitle: @"Work" block: ^{
        alert(@"Work selected");
    }];
    
    [sheet addButtonWithTitle: @"Home" block: ^{
        alert(@"Home selected");
    }];
    
    [sheet addButtonWithTitle: @"School" block: ^{
        alert(@"School selected");
    }];
    
    [sheet setCancelButtonWithTitle: @"Cancel" block: ^{}];
 
    [sheet showInView: self.window];
    [sheet release];
}

That's it -- there is nothing else. The blocks used for each button automatically have access to the enclosing method's variables, and we even use another block (alert) to avoid retyping the UIAlertView boilerplate or cluttering our class with an alert method.

You can find the full UIActionSheet wrapper -- including example usage -- here.

Conclusion

I hope you'll find these examples useful in experimenting with and incorporating blocks into your own software. There are quite a few other ways that blocks can be leveraged to decrease code size and complexity, and I'll plan on writing future articles on the subject.

If you'd like to discuss blocks, the PLBlocks implementation, or having any other questions, feel free to join the PLBlocks mailing list.