Single-click StalledViewController.h and replace the existing contents with the following:

#import <UIKit/UIKit.h>

@interface StalledViewController : UIViewController {
    UITextField     *numOperationsInput;
    UIProgressView  *progressBar;
    UILabel         *progressLabel;
}

@property (nonatomic, retain) IBOutlet UITextField *numOperationsInput;
@property (nonatomic, retain) IBOutlet UIProgressView *progressBar;
@property (nonatomic, retain) IBOutlet UILabel *progressLabel;

- (IBAction)go;
@end

We haven't seen a controller class header this simple in quite a while, have we? Nothing here should be unfamiliar to you. We have three outlets that are used to refer to the three user interface elements whose values we need to update or retrieve, and we have a single action method that gets fired by the one button on our interface. Make sure you save StalledViewController.h.

Double-click StalledViewController.xib to launch Interface Builder. Drag a Round Rect Button from the library to the window titled View, placing the button against the upper-right margins using the blue guidelines. Double-click the button and change its title to Go. Control-click from the new button to File's Owner and select the go action.

Now drag a Text Field from the library and place it to the left of the button. Use the blue guides to line up the text field and place it the correct distance from the button. Resize the text field to about two-third of its original size, or use the size inspector and change its width to 70 pixels. Double-click the text field and set its default value to 10000. Press

Drag a Label from the library and place it to the left of the text field. Double-click it to change its text to read # of Operations and then adjust its size and placement to fit in the available space. You can use Figure 14-1 as a guide.

From the library, bring over a Progress View and place it below the three items already on the interface. We placed it a little more than the minimum distance below them as indicated by the blue guides, but exact placement really doesn't matter much with this application. Once you place the progress bar, use the resize handles to change its width so it takes up all the space from the left margin to the right margin. Next, use the attributes inspector to change the Progress field to 0.0. Finally, control-drag from File's Owner to the progress view and select the progressBar outlet.

Drag one more Label from the library and place it below the progress view. Resize the label so it is stretches from the left to the right margins. Control-drag from File's Owner to the new label and select the progressLabel outlet. Then, double-click the label and press the delete key to delete the existing label text.

Save your nib, close Interface Builder, and head back to Xcode.

Select StalledViewController.m and replace the existing contents with the following code:

#import "StalledViewController.h"

@implementation StalledViewController
@synthesize numOperationsInput;
@synthesize progressBar;
@synthesize progressLabel;

- (IBAction)go {
    NSInteger opCount = [numOperationsInput.text intValue];
    for (NSInteger i = 1; i <= opCount; i++) {
        NSLog(@"Calculating square root of %d", i);
        double squareRootOfI = sqrt((double)i);
        progressBar.progress = ((float)i / (float)opCount);
        progressLabel.text = [NSString stringWithFormat:
            @"Square Root of %d is %.3f", i, squareRootOfI];
    }
}

- (void)viewDidUnload {
    [super viewDidUnload];
    self.numOperationsInput = nil;
    self.progressBar = nil;
    self.progressLabel = nil;
}

- (void)dealloc {
    [numOperationsInput release];
    [progressBar release];
    [progressLabel release];
    [super dealloc];
}

@end

Let's focus on the go method, because that's where the problem is. Everything else is stuff you've seen before. The method starts by retrieving the number from the text field.

NSInteger opCount = [numOperationsInput.text intValue];

Then, we go into a loop so we can calculate all of the square roots.

for (NSInteger i = 1; i <= opCount; i++) {

We log which calculation we're working on. In shipping applications, you generally wouldn't log like this, but logging serves two purposes in this chapter. First, it lets us see, using Xcode's debugger console, that the application is working even when our application's user interface isn't responding. Second, logging takes a non-trivial amount of time. In real-world applications, that would generally be bad, but since our goal is just to do processing to show how concurrency works, this slow-down actually works to our advantage. If you choose to remove the NSLog() statements, you will need to increase the number of calculations by an order of magnitude because the iPhone is actually capable of doing tens of thousands of square root operations per second and it will hardly break a sweat doing ten thousand without the NSLog() statement in the loop to throttle the speed.

NSLog(@"Calculating square root of %d", i);

Then we calculate the square root of i.

double squareRootOfI = sqrt((double)i);

And update the progress bar and label to reflect the last calculation made, and that's the end of our loop.

progressBar.progress = ((float)i / (float)opCount);
         progressLabel.text = [NSString stringWithFormat:
             @"Square Root of %d is %.3f", i, squareRootOfI];
    }

The problem with this method isn't so much what we're doing as where we're doing it. As we stated earlier, action methods fire on the main thread, which is also where user interface updates happen, and where system events, such as those that are generated by taps and touches, are processed. If any method firing on the main thread takes too much time, it will affect your application's user experience. In less severe cases, your application will seem to hiccup or stall at times. In severe cases, like here, your application's entire user interface will freeze up.

Save StalledViewController.m and build and run the application. Press the Go button and watch what happens. Not much, huh? If you keep an eye on the debug console in Xcode, you'll see that it is working away on those calculations (Figure 14-2) thanks to the NSLog() statement in our code, but the user interface doesn't update until all of the calculations are done, does it?

Note that if you do click in the text field, the numeric keypad will not disappear when you tap the Go button. Since there's nothing being hidden by the keypad, this isn't a problem. In the final version of the application, we'll add a table that will be hidden by the keypad. We'll add some code to deal with that situation as needed.

Figure 14.2. The debug console in Xcode shows that the application is working, but the user interface is locked up

If we have code that takes a long time to run, we've basically got two choices if we want to keep our interface responsive: We can break our code into smaller chunks that can be processed in pieces, or we can move the code to a separate thread of execution, which will allow our application's run loop to return to updating the user interface and responding to taps and other system events. We'll look at both options in this chapter.

First, we'll fix the application by using a timer to perform the requested calculations in batches, making sure not to take more than a fraction of a second each time so that the main thread can continue to process events and update the interface. After that, we'll look at using an operation queue to move the calculations off of the application's main thread, leaving the main thread free to process events.

Creating an instance of NSTimer is quite straightforward. If you want to create it, but not schedule it with the run loop right away, use the factory method timerWithTimeInterval:target:selector:userInfo:repeats:, like so:

NSTimer *timer = [NSTimer timerWithTimeInterval:1.0/10.0
        target:self
        selector:@selector(myTimerMethod:)
        userInfo:nil
        repeats:YES]

The first argument to this method specifies how frequently you would like the timer to fire and call its method. In this example, we're passing in a tenth of a second, so this timer will fire approximately ten times a second. The next two arguments work exactly like the target and action properties of a control. The second argument, target, is the object on which the timer should call a method, and selector points to the actual method the timer should call when it fires. The method specified by the selector must take a single argument, which will be the instance of NSTimer that called the method. The fourth argument, userInfo, is designed for application use. If you pass in an object here, that object will go along with the timer and be available in the method the timer calls when it fires. The last argument specifies whether the timer repeats or fires just once.

Once you've got a timer and are ready for it to start firing, you get a reference to the run loop you want to schedule it into, and then add the timer. Here's an example of scheduling the timer into the main run loop:

NSRunLoop *loop = [NSRunLoop mainRunLoop];
    [loop addTimer:timer forMode:NSDefaultRunLoopMode];

When you schedule the timer, the run loop retains the timer. You can keep a pointer to the timer if you need to, but you don't need to retain the timer to keep it from getting deallocated. The run loop will retain the timer until you stop the timer.

If you want to create a timer that's already scheduled with the run loop, letting you skip the previous two lines of code, you can use the factory method scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:, which takes exactly the same arguments as timerWithTimeInterval:target:selector:userInfo:repeats:.

NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:1.0/10.0
        target:self
        selector:@selector(myTimerMethod:)
        userInfo:nil
        repeats:YES]

When you no longer need a timer, you can unschedule it from the run loop by calling the invalidate method on the instance. Invalidating a timer will stop it from firing any further and remove it from the run loop, which will release the timer and cause it to be deallocated unless it's been retained elsewhere. Here's how you invalidate a timer:

[timer invalidate];

Timers are very handy for any number of purposes. As a tool for keeping your interface responsive, they do have some limitations, however. The first and foremost of these limitations is that you have to make some assumptions about how much time is available for the process that you're implementing. If you have more than a couple of timers running, things can easily get complex and the logic to make sure that each timer's method gets an appropriate share of the available time without taking too much time away from the main thread can get very complex and abstruse.

Timers are great for when you have one, or at most, a small number, of long-running tasks that can be easily broken down into discrete chunks for processing. When you have more than that, or when the processes don't lend themselves to being performed in chunks, timers become far too much trouble and just aren't the right tool for the job.

Let's use a timer to get the Stalled application working the way our users will expect it to work, then we'll move on and look at how we handle scenarios where we have more than a couple of processes.

Before we start modifying our controller class, let's create a class to represent our batch of calculations. This object will keep track of how many calculations need to be performed as well as how many already have. We'll also move the actual calculations into the batch object as well. Having this object will make it much easier to do processing in chunks, since the batch will be self-contained in a single object.

Single-click the Classes folder in the Groups & Files pane, then type

#import <Foundation/Foundation.h>

#define kExceededMaxException   @"Exceeded Max"

@interface SquareRootBatch : NSObject {
    NSInteger   max;
    NSInteger   current;
}

@property NSInteger max;
@property NSInteger current;

- (id)initWithMaxNumber:(NSInteger)inMax;
- (BOOL)hasNext;
- (double)next;

- (float)percentCompleted;
- (NSString *)percentCompletedText;
@end

We start off by defining a string that will be used for throwing an exception. If we exceed the number of calculations we've specified, we will throw an exception with this name.

#define kExceededMaxException   @"Exceeded Max"

Then we define two instance variables and corresponding properties for the maximum number whose square root will be calculated and the current number whose square root is being calculated. This will allow us to keep track of where we are between timer method calls.

@interface SquareRootBatch : NSObject {
    NSInteger   max;
    NSInteger   current;
}
@property NSInteger max;
@property NSInteger current;

Next, we declare a standard init method that takes one argument, the maximum number for which we are to calculate the square root.

- (id)initWithMaxNumber:(NSInteger)inMax;

The next two methods will enable our batch to work similarly to an enumerator. We can find out if we still have numbers to calculate by calling hasNext, and actually perform the next calculation by calling next, which returns the calculated value.

- (BOOL)hasNext;
- (double)next;

After that, we have two more methods used to retrieve values for updating the progress bar and progress label:

- (float)percentCompleted;
- (NSString *)percentCompletedText;

And that's all she wrote for this header file. Save SquareRootBatch.h and then flip over to SquareRootBatch.m. Replace the contents with this new version:

#import "SquareRootBatch.h"

@implementation SquareRootBatch
@synthesize max;
@synthesize current;

- (id)initWithMaxNumber:(NSInteger)inMax {
    if (self = [super init]) {
        current = 0;
        max = inMax;
    }
    return self;
}

- (BOOL)hasNext {
    return current <= max;

}

- (double)next {
    if (current > max)
        [NSException raise:kExceededMaxException format:
            @"Requested a calculation from completed batch."];

    return sqrt((double)++current);
}

- (float)percentCompleted {
    return (float)current / (float)max;
}

- (NSString *)percentCompletedText {
    return [NSString stringWithFormat:@"Square Root of %d is %.3f", current,
        sqrt((double)current)];
}

@end

Basically, we've taken the logic from our go method and distributed it throughout this little class. By doing that, we make the batch completely self-contained, which will allow us to pass the batch along to the method fired by the timer by making use of the userInfo argument.

Let's rewrite our controller class to use this new timer. Since our user interface will be useable while the batch is running, we want to make the Go button become a Stop button while the batch is running. It's generally a good idea to give users a way to stop long-running processes if feasible.

Single-click StalledViewController.h and insert the following bold lines of code:

#import <UIKit/UIKit.h>

#define    kTimerInterval  (1.0/60.0)
#define     kBatchSize      10

@interface StalledViewController : UIViewController {
    UITextField     *numOperationsInput;
    UIProgressView  *progressBar;
    UILabel         *progressLabel;
    UIButton       *goStopButton;

BOOL           processRunning;
}

@property (nonatomic, retain) IBOutlet UITextField *numOperationsInput;
@property (nonatomic, retain) IBOutlet UIProgressView *progressBar;
@property (nonatomic, retain) IBOutlet UILabel *progressLabel;
@property (nonatomic, retain) IBOutlet UIButton *goStopButton;

- (IBAction)go;
- (void)processChunk:(NSTimer *)timer;

@end

The first constant we defined—kTimerInterval—will be used to determine how often the timer fires. We're going to start by firing approximately 60 times a second. If we need to tweak the value to keep our user interface responsive, we can do that as we test. The second constant, kBatchSize, will be used in the method that the timer calls. In the method, we're going to check how much time has elapsed as we do calculations because we don't want to spend more than one timer interval in that method. In fact, we need to spend a little less than the timer interval because we need to make resources available for the run loop to do other things. However, it would be wasteful to check the elapsed time after every calculation, so we'll do a certain number of calculations before checking the elapsed time, and that's what kBatchSize is for. We can tweak the batch size for better performance as well.

We're also adding an instance variable and property to act as an outlet for the Go button. That will enable us to change the button's title to Stop when a batch is processing. We also have a Boolean that indicates whether a batch is currently running. We'll use this to determine what to do when the button is tapped and will also use it to tell the batch to stop processing when the user taps the Stop button. We also added one method, processChunk:, which is the method that our timer will call and that will process a subset of the batch.

Save StalledViewController.h and double-click StalledViewController.xib.

Once Interface Builder opens up, control-drag from File's Owner to the Go button. Select the goStopButton action. That's the only change we need, so save the nib and close Interface Builder.

Back in Xcode, single-click on StalledViewController.m. At the top of the file, add the following bold lines of code. The first will import the header from the batch object we created, and the second synthesizes the new outlet property we added for the button.

#import "StalledViewController.h"
#import "SquareRootBatch.h"

@implementation StalledViewController
@synthesize numOperationsInput;
@synthesize progressBar;
@synthesize progressLabel;
@synthesize goStopButton;
...

Next, replace the existing go method with this new version:

- (IBAction)go {
    if (!processRunning) {
        NSInteger opCount = [numOperationsInput.text intValue];
        SquareRootBatch *batch = [[SquareRootBatch alloc]
            initWithMaxNumber:opCount];

        [NSTimer scheduledTimerWithTimeInterval:kTimerInterval
            target:self
            selector:@selector(processChunk:)
            userInfo:batch
            repeats:YES];
        [batch release];
        [goStopButton setTitle:@"Stop" forState:UIControlStateNormal];
        processRunning = YES;
    } else {
        processRunning = NO;
        [goStopButton setTitle:@"Go" forState:UIControlStateNormal];
    }

}

We start the method out by checking to see if a batch is already running. If it isn't, then we grab the number from the text field, just as the old version did:

if (!processRunning) {
        NSInteger opCount = [numOperationsInput.text intValue];

Then, we create a new SquareRootBatch instance, initialized with the number pulled from the text field:

SquareRootBatch *batch = [[SquareRootBatch alloc]
            initWithMaxNumber:opCount];

After creating the batch object, we create a scheduled timer, telling it to call our processChunk: method every sixtieth of a second. We pass the batch object in the userInfo argument so it will be available to the timer method. Because the run loop retains the timer, we don't even declare a pointer to the timer we create.

Next, we set the button's title to Stop and set processRunning to reflect that the process has started.

[goStopButton setTitle:@"Stop" forState:UIControlStateNormal];
        processRunning = YES;

If the batch had already been started, then we just change the button's title back to Go and set processRunning to NO, which will tell the processChunk: method to stop processing.

} else {
        processRunning = NO;
        [goStopButton setTitle:@"Go" forState:UIControlStateNormal];
    }

Now that we've updated our go method, add the following new method (place it right below go) that will process a chunk of the overall batch:

- (void)processChunk:(NSTimer *)timer {
    if (!processRunning) {  // Cancelled
        [timer invalidate];
        progressLabel.text = @"Calculations Cancelled";
        return;
    }

    SquareRootBatch *batch = (SquareRootBatch *)[timer userInfo];
    NSTimeInterval endTime = [NSDate timeIntervalSinceReferenceDate] +
        (kTimerInterval / 2.0);

    BOOL isDone = NO;
    while (([NSDate timeIntervalSinceReferenceDate] < endTime) && (!isDone)) {
        for (int i = 0; i < kBatchSize; i++) {
            if (![batch hasNext]) {
                isDone = YES;
                i = kBatchSize;
            }
            else {
                NSInteger current = batch.current;
                double nextSquareRoot = [batch next];
                NSLog(@"Calculated square root of %d as %0.3f", current,
                    nextSquareRoot);
            }
        }
    }
    progressLabel.text = [batch percentCompletedText];
    progressBar.progress = [batch percentCompleted];

    if (isDone) {
        [timer invalidate];
        processRunning = NO;
        progressLabel.text = @"Calculations Finished";
        [goStopButton setTitle:@"Go" forState:UIControlStateNormal];
    }
}

The first thing this method does is see if the user has tapped the Stop button since the last time the method was called. If it was, we invalidate the timer, which will prevent this method from being called any more by this timer, ending the processing of this batch. We also update the progress label to tell the user that we canceled.

if (!processRunning) {  // Cancelled
        [timer invalidate];
        progressLabel.text = @"Calculations Cancelled";
        return;
    }

Next, we retrieve the batch from the timer.

SquareRootBatch *batch = (SquareRootBatch *)[timer userInfo];

After that, we calculate when to stop processing this batch. For starters, we're going to spend half of the time available to us working on the batch. That should leave plenty of time for the run loop to receive system events and update the UI, but we can always tweak the value if we need to.

NSTimeInterval endTime = [NSDate timeIntervalSinceReferenceDate] +
        (kTimerInterval / 2.0);

We set a Boolean that we'll use to identify if we have reached the end of the batch. We'll set this to YES if hasNext returns NO.

BOOL isDone = NO;

Then, we go into a loop until we either reach the end time we calculated earlier, or there's no calculations left to do.

while (([NSDate timeIntervalSinceReferenceDate] < endTime) && (!isDone)) {

We're going to calculate the square root for several numbers at a time rather than checking the date after every one, so we go into another loop based on the batch size we defined earlier.

for (int i = 0; i < kBatchSize; i++) {

In that loop, we make sure there's more work to be done. If there isn't, we set isDone to YES and set i to the batch size to end this loop.

if (![batch hasNext]) {
                isDone = YES;
                i = kBatchSize;
            }

If there is another number to calculate, we grab the current value and its square root and log the fact to the debug console.

else {
                NSInteger current = batch.current;
                double nextSquareRoot = [batch next];
                NSLog(@"Calculated square root of %d as %0.3f", current,
                    nextSquareRoot);
            }
        }
    }

After we're done with processing a chunk, we update the progress bar and label.

progressLabel.text = [batch percentCompletedText];
    progressBar.progress = [batch percentCompleted];

And, if we're all out of rows to process, we invalidate the timer and update the progress label and button.

if (isDone) {
        [timer invalidate];
        processRunning = NO;

progressLabel.text = @"Calculations Finished";
        [goStopButton setTitle:@"Go" forState:UIControlStateNormal];
    }

All that's left to do now is to take care of our new outlet in the viewDidUnload and dealloc methods, so add the lines in bold to your existing code:

- (void)viewDidUnload {
    self.numOperationsInput = nil;
    self.progressBar = nil;
    self.progressLabel = nil;
    self.goStopButton = nil;
}

- (void)dealloc {
    [numOperationsInput release];
    [progressBar release];
    [progressLabel release];
    [goStopButton release];
    [super dealloc];
}

Go ahead and take this new version for a spin. Build and run your project and try entering different numbers. As the calculations happen, your user interface should get updated (Figure 14-3) and the progress bar should make its way across the screen. While a batch is processing, you should be able to tap the Stop button to cancel the processing.

Figure 14.3. Now that we're using a timer, the application is no longer stalled

That's great, and our users are now able to start and stop the process and can continue to use the application while the calculations are being performed. But, if we had more tasks going on in the background, this option wouldn't be ideal. Trying to calculate how much time to let each batch use would be non-trivial. Fortunately, Apple has given us the operation queue and has put all sorts of non-trivial logic in it so that we don't have to reinvent the wheel. Let's take a look at operation queues now.

As we've mentioned before, every application has at least one thread, which is a sequence of instructions. The thread that begins executing when the program is launched is called the main thread. In the case of a Cocoa Touch application, the main thread contains the application's main run loop, which is responsible for handling inputs and updating the user interface. Although there are some instances where Cocoa Touch uses additional threads implicitly, pretty much all application code that you will write will fire on the main thread unless you specifically spawn a thread or use an operation in an operation queue.

To implement concurrency, additional threads are spawned, each tasked to perform a specific set of instructions. Each thread has equal access to all of your application's memory. This means that any object except local variables, can potentially be modified, used, and changed in any thread. Generally speaking, there's no way to predict how long a thread will run, and if there are multiple threads, there's no way to predict, with any certainty, which thread will finish first.

These two thread traits—the fact that they all share access to the same memory, and that there's no way to predict what share of the processing time each will get—are the root cause of a number of problems that come along for the ride when doing concurrent programming. Operation queues provide some relief from the timing problem, since you can set priorities and dependencies, which we'll look at a little later, but the memory sharing issue is still very much a concern.

static int i;
    for (i = 0; i < 25; i++) {
        NSLog(@"i = %d", i);
    }

Thread 1:               Thread 2:               Thread 3:

i = 0                   i = 2                   i = 5
i = 1                   i = 3                   i = 10
i = 4                   i = 6                   i = 13
i = 7                   i = 8                   i = 18
i = 9                   i = 11                  i = 19
i = 12                  i = 14                  i = 24
i = 15                  i = 17
i = 16                  i = 21
i = 20                  i = 22
i = 23

@implementation Person : NSObject {
    NSString *firstName;
    NSString *lastName;
}

@property (nonatomic, retain) NSString *firstName;
@property (nonatomic, retain) NSString *lastName;

@end

person.firstName = @"Samantha";
    person.lastName = @"Stephens";

NSLog(@"Now processing %@ %@.", person.firstName, person.lastName);

Now processing Samantha Washington.

@synchronized(self) {
    person.firstName = @"Samantha";
    person.lastName = @"Stephens";
}

- (NSMutableString *)foo {
    return foo;
}

- (NSMutableString *)foo {
    NSString *ret;
    @synchronized(self) {
        ret = [[self retain] autorelease];
    }
    return ret;
}

- (void)setFirstName:(NSString *)inFirst lastName:(NSString *)inLast {
    @synchronized (self) {
        self.firstName = inFirst;
        self.lastName = inLast;
    }
}

[NSThread sleepForTimeInterval:2.5];

[NSThread sleepUntilDate:[NSDate dateWithTimeIntervalSinceNow:2.5]];

We're going to look at operation queues in a moment, but before we do that, we need to talk about operations, which are the objects that contain the sets of instructions that the operation queue manages. Operations usually take the form of custom subclasses of NSOperation. You write the subclass and, in it, you put the code that needs to be run concurrently.

When implementing an operation for use in an operation queue, there are a few steps you need to take. First, you create a subclass of NSOperation and define any properties that you'll need as inputs or outputs from the operation. In our square root example, we will create a subclass of NSOperation and define properties for current and max on it.

The only other thing you have to do is to override the method called main, which is where you put the code that makes up the operation. There are a couple of things you need to do in your main method. The first thing you need to do is wrap all of your logic in a @try block so you can catch any exceptions. It's very important that an operation's main method not throw any exceptions. They must be caught and handled without being re-thrown. An uncaught exception in an operation will result in a fatal application crash.

The second thing you have to do in main is to create a new autorelease pool. Different threads cannot share the same autorelease pool. The operation will be running in a separate thread, so it can't use the main thread's autorelease pool, so it's important to allocate a new one.

Here's what a skeleton main method for an NSOperation subclass looks like:

- (void)main {
    @try {
        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

                // Do work here...

        [pool drain];
    }
    @catch (NSException * e) {

// Important that we don't re-throw exception here
        NSLog(@"Exception: %@", e);
    }
}

MyOperation *firstOperation = [[MyOperation alloc] init];
    MyOperation *secondOperation = [[MyOperation alloc] init];
    [secondOperation addDependency:firstOperation];
    ...

NSArray *dependencies = [secondOperation dependencies];

[secondOperation removeDependency:firstOperation];

[firstOperation setQueuePriority:NSOperationQueuePriorityVeryHigh];

NSOperationQueuePriority *priority = [firstOperation queuePriority];

[firstOperation cancel];

Now you know how to create operations, so let's look at the object that manages operations, NSOperationQueue. Operation queues are created like any other object. You allocate and initialize the queue, like so:

NSOperationQueue *queue = [[NSOperationQueue alloc] init];

[queue addOperation:newOp];

[queue setMaxConcurrentOperationCount:1];

[queue setMaxConcurrentOperationCount:
        NSOperationQueueDefaultMaxConcurrentOperationCount];

We're going to start by creating our NSOperation subclass. Single-click the Classes folder and press

Single-click SquareRootOperation.h and replace its contents with the following:

#import <Foundation/Foundation.h>

#define kBatchSize          100
#define kUIUpdateFrequency  0.5

@class SquareRootOperation;
@protocol SquareRootOperationDelegate
- (void)operationProgressChanged:(SquareRootOperation *)op;
@end

@interface SquareRootOperation : NSOperation {
    NSInteger   max;
    NSInteger   current;
    id          delegate;
}

@property NSInteger max;
@property NSInteger current;
@property (assign) id<SquareRootOperationDelegate> delegate;

- (id)initWithMax:(NSInteger)inMax
         delegate:(id<SquareRootOperationDelegate>)inDelegate;
- (float)percentComplete;
- (NSString *)progressString;

@end

We start off by defining two constants. The first, kBatchSize, will be used to set how many calculations we perform before checking to see if our operation has been cancelled. The second, kUIUpdateFrequency, specifies how often, in seconds, we update the user interface. We are going to be doing, literally, thousands of calculations a second. If we update the interface from every thread every time we do an update, that's an awful lot of updates. Remember, updates to the user interface have to be done on the main thread. We'll show how to safely do that from an operation in a moment, but doing it incurs overhead. Different threads can't talk to each other directly.

You don't need to understand the process that threads use to communicate, but you do need to understand that there is overhead associated with sending messages between threads. Fortunately, as you'll see in a moment, the complexity of inter-thread communication is hidden from us. But there's still a cost involved with that communication that will slow things down if we do it too frequently. By reducing the updates to every half a second, we eliminate a lot of unnecessary inter-thread communications. As you test your application, you might want to tweak this value. You might find that more or less frequent updates give a better user experience, but these settings seem to be a good starting point and give decent results both on the device and on the simulator.

#define kBatchSize          100
#define kUIUpdateFrequency  0.5

After that, we create a protocol for our thread's delegate. Our operation's delegate will be the controller class for our application's main view: StalledViewController. We'll call this protocol's only method to tell that controller that changes have been made that need to be reflected in the row that represents our operation in the table view.

@class SquareRootOperation;
@protocol SquareRootOperationDelegate
- (void)operationProgressChanged:(SquareRootOperation *)op;
@end

After that, things are pretty similar to our SquareRootBatch class from the timer example, except instead of subclassing NSObject, we subclass NSOperation. In addition to the instance variables and properties for current and max calculation, we also have an instance variable and property for our delegate:

@interface SquareRootOperation : NSOperation {
    NSInteger   max;
    NSInteger   current;
    id          delegate;
}

@property NSInteger max;
@property NSInteger current;
@property (assign) id<SquareRootOperationDelegate> delegate;

We have an init method that takes the max number of calculations and a delegate:

- (id)initWithMax:(NSInteger)inMax
         delegate:(id<SquareRootOperationDelegate>)inDelegate;

And we have two methods that can be called by our delegate to get the current values for the progress bar and label:

- (float)percentComplete;
- (NSString *)progressString;
@end

Make sure you save SquareRootOperation.h and then switch over to SquareRootOperation.m. Replace the current contents with the following:

#import "SquareRootOperation.h"

@implementation SquareRootOperation
@synthesize max;
@synthesize current;
@synthesize delegate;

- (id)initWithMax:(NSInteger)inMax
         delegate:(id<SquareRootOperationDelegate>)inDelegate {
    if (self = [super init]) {
        max = inMax;
        current = 0;
        delegate = inDelegate;
    }
    return self;
}

- (float)percentComplete {
    return (float)current / (float)max;
}

- (NSString *)progressString {
    if ([self isCancelled])
        return @"Cancelled...";
    if (![self isExecuting])
        return @"Waiting...";
    return [NSString stringWithFormat:@"Completed %d of %d", self.current,
        self.max];
}

- (void)main {
    @try {
        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
        NSTimeInterval  lastUIUpdate = [NSDate timeIntervalSinceReferenceDate];
        while (current < max) {
            if (self.isCancelled)
                self.current = max + 1;
            else {

self.current++;
                double squareRoot = sqrt((double)current);
                NSLog(@"Operation %@ reports the square root of %d is %f",self,
                    current, squareRoot);
                if (self.current % kBatchSize == 0) {
                    if ([NSDate timeIntervalSinceReferenceDate] > lastUIUpdate +
                        kUIUpdateFrequency) {
                        if (self.delegate && [delegate respondsToSelector:
                            @selector(operationProgressChanged:)])
                            [(NSObject *)self.delegate performSelectorOnMainThread:
                                @selector(operationProgressChanged:) withObject:self
                                waitUntilDone:NO];
                        [NSThread sleepForTimeInterval:0.05];
                        lastUIUpdate = [NSDate timeIntervalSinceReferenceDate];
                    }
                }
            }
        }
        [pool drain];
    }
    @catch (NSException * e) {
        // Important that we don't re-throw exception, so we just log
        NSLog(@"Exception: %@", e);
    }
}

@end

The init method is pretty standard, and the percentComplete method is just like the one we had earlier in the chapter for the timer-based version of the application. The first code we need to look at is progressString. All this does is return a string that represents the current amount of progress in the operation and will be used in the cell that represents this row (see Figure 14-4). The one extra step we take here to set the label to Cancelled... if the operation has been cancelled. Remember, earlier, we said that cancelled operations that haven't started executing sit in the queue with their isCancelled property set to YES until they get kicked off, at which point they don't do any processing and fall out of the queue. Since we don't have any way to remove these operations from the queue, we do the next best thing and update the label that is displayed in the table to show that the user requested that this operation be cancelled. Otherwise, we return Waiting... if the operation hasn't started yet, or a string identifying how many square roots we've calculated so far if we are executing.

- (NSString *)progressString {
    if ([self isCancelled])
        return @"Cancelled...";
    if (![self isExecuting])
        return @"Waiting...";
    return [NSString stringWithFormat:@"Completed %d of %d", self.current,
        self.max];
}

The next method is the soul of our operation, and it warrants some special attention. The main method is the one that gets called when this operation gets kicked off by the queue. Our operation is going to be running in a thread, so we start of by wrapping everything in a @try block and allocating an autorelease pool.

- (void)main {
    @try {
        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

Then we declare and initialize a variable that will be used to keep track of how much time has elapsed since the last time we updated the user interface.

NSTimeInterval  lastUIUpdate = [NSDate timeIntervalSinceReferenceDate];

Next, we start our loop until current is equal to max.

while (current < max) {

Every time through the loop, we check to see if our operation has been cancelled. If it has, then we set current to one more than max, which will cause our loop to end, and will end our method.

if (self.isCancelled)
                self.current = max+1;

If our operation hasn't been cancelled, then we increment current, calculate its square root, and log the result.

else {
                self.current++;
                double squareRoot = sqrt((double)current);
                NSLog(@"Operation %@ reports the square root of %d is %f",self,
                    current, squareRoot);

We then use modulus math to determine if we should check the time. Remember, we specified a batch size constant that tells how often we should check if it's time to do a user interface update, so every time current modulo kBatchSize equals zero, then we've reached a multiple of kBatchSize and should check to see if it's time to update the user interface.

if (self.current % kBatchSize == 0) {

If we've processed an entire batch, we check the current time and compare it to the time of the last update added to the update frequency. If the current time is greater than those values added together, it's time to push another update out to our controller so it can get reflected in the user interface.

if ([NSDate timeIntervalSinceReferenceDate] > lastUIUpdate +
                        kUIUpdateFrequency) {

We make sure we have a delegate and that it responds to the correct selector before using performSelector:onMainThread:withObject:waitUntilDone: to let the controller know that the row that represents this operation should be updated. This is a great method that allows us to communicate back to the main thread without having to deal with the nitty-gritty aspects of inter-thread communications. It's an absolutely lovely method, just ask anybody who's had to do it the old-fashioned way using Mach ports.

if (self.delegate && [delegate respondsToSelector:
    @selector(operationProgressChanged:)])

[(NSObject *)self.delegate performSelectorOnMainThread:
    @selector(operationProgressChanged:) withObject:self
    waitUntilDone:NO];

After we update the interface, we're going to sleep for a fraction of a second. This is optional, and the exact value to use here would probably get adjusted as we tested our application, but it's often a good idea to block periodically to yield some time. As of the time this book was written, iPhones and iPod touches come with a single processor with a single core, so yielding some time to the main thread is going to keep our app a little more responsive than it might otherwise be.

[NSThread sleepForTimeInterval:0.05];

Finally, we update lastUIUpdate with the current time so the next time through the loop, we know how long has passed since we updated the user interface.

lastUIUpdate = [NSDate timeIntervalSinceReferenceDate];
                    }
                }
            }
        }

Once we're done, we have to drain the autorelease pool, otherwise we'll end up leaking everything that's in the pool.

[pool drain];
    }

Finally, we catch any exceptions. In this application, we just log them. If you need to do something else here, like show an alert, make sure that you call methods on the main thread to do it. Do not do any UI work directly in an operation because UIKit is not thread safe. Yes, we did say that already, but it's important.

Oh, and by the way? UIKit is not thread safe.

Also, whatever you do, do not throw an exception here. Because this operation is executing on a non-main thread, there is no higher-level exception hander available to catch that exception. This means that any exceptions thrown here will be uncaught exceptions, which is a fatal condition at runtime (aka, a fatal crash).

@catch (NSException * e) {
        // Important that we don't re-throw exception, so we just log
        NSLog(@"Exception: %@", e);
    }
}

Make sure you save SquareRootOperation.m.

We no longer need our progress view and progress label on our user interface, but we do need a table to show the operation queue's operations. Before we go to Interface Builder to make the interface changes, we need to make some changes to StalledViewController.h:

#import <UIKit/UIKit.h>
#import "SquareRootOperation.h"

@interface StalledViewController : UIViewController
<SquareRootOperationDelegate, UITableViewDelegate, UITableViewDataSource>
{
    UITextField     *numOperationsInput;
    UIProgressView  *progressBar;
    UILabel         *progressLabel;
    UITableView     *tableView;
    NSOperationQueue    *queue;
}
@property (nonatomic, retain) IBOutlet UITextField *numOperationsInput;
@property (nonatomic, retain) IBOutlet UIProgressView *progressBar;
@property (nonatomic, retain) IBOutlet UILabel *progressLabel;
@property (nonatomic, retain) IBOutlet UITableView *tableView;
@property (nonatomic, retain) NSOperationQueue *queue;

- (IBAction)go;
- (IBAction)cancelOperation:(id)sender;
- (IBAction)backgroundClick;

@end

We imported SquareRootOperation.h, which is the header for the operation class we just created, and then conformed our class to the SquareRootOperationDelegate protocol in addition to the two table view delegates it was already conformed to. We also added an instance variable and property to serve as an outlet to a table view and another instance variable and property for our operation queue.

We added two methods, one that will be used to cancel operations and that will be called when the user taps the accessory pane of a row in the table. The backgroundClick method shouldn't need any explanation at this point. Because our table will be partially obscured by the keyboard, we need to provide a way to make the keyboard go away, which this method will do.

Save StalledViewController.h and double-click StalledViewController.xib to launch Interface Builder.

Once Interface Builder opens up, if the window labeled View is open, close it. Now, click on the View icon in the main window, press

Now double-click the Control icon, which used to be the View icon, to open our application's user interface back up. Single-click the progress view and hit the delete key. Then single-click the progress label (the empty label below the progress bar) and press delete again.

Look in the library for a table view and drag it over to the Control window. Place it in the window, then use the resize handles so that it takes up all of the window from the left side to the right (not the margins, the full window), and from the very bottom of the window until just below the existing text field, button, and label, using the blue guidelines for proper distance.

Control-drag from File's Owner to the table view and select the tableView outlet. Then, control-drag back from the table view to File's Owner twice. The first time, select the delegate outlet, the second time select the dataSource outlet.

Once you've done that, save the nib, quit Interface Builder, and go back to Xcode.