We’ll approach this by giving you an object you can create before some critical section and release after it’s over. You’ll use it like so:

MyWatchdogTimer *timer = [[MyWatchdogTimer alloc] initWithTimeout:2.0];

// some piece of code that might take a while, but should never take
// more than 2 seconds.
[self myPotentiallyLengthyTask]

[timer invalidate];
[timer release];

If the timer fires, you know the operation took too long. If it didn’t all is well, you release it and we’re done.

The Class

The object class is pretty simple:

@interface MyWatchdogTimer {
@private
    dispatch_source_t     _timer;
}

- (id)initWithTimeout:(NSTimeInterval)timeout;
- (void)invalidate;

@end

As you can see, we’re merely storing our dispatch source we’ll be using as a timer.

When doing asynchronous tasks, it’s very common to use an invalidation idiom for shutting the task down. This pattern can be seen in run loop sources, as well as GCD itself (dispatch_cancel). This ensures the task will be torn down at a time that is appropriate, i.e. it can shut down cleanly.

The Implementation

@implementation MyWatchdogTimer

- (id)initWithTimeout:(NSTimeInterval)timeout {
    self = [super init];
    if (self) {            
        dispatch_queue_t queue = dispatch_get_global_queue(
                                    DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

        // create our timer source
        _timer = dispatch_source_create(
                           DISPATCH_SOURCE_TYPE_TIMER, 0, 0,
                           queue);

        // set the time to fire (we're only going to fire once,
        // so just fill in the initial time).
        dispatch_source_set_timer(_timer,
               dispatch_time(DISPATCH_TIME_NOW, timeout * NSEC_PER_SEC),
               DISPATCH_TIME_FOREVER, 0);

        // Hey, let's actually do something when the timer fires!
        dispatch_source_set_event_handler(_timer, ^{
            NSLog(@"WATCHDOG: task took longer than %f seconds",
                    timeout);
            // ensure we never fire again
            dispatch_source_cancel(_timer);
        });

        // now that our timer is all set to go, start it
        dispatch_resume(_timer);
    }
    return self;
}

- (void)dealloc {
    dispatch_source_cancel(_timer);
    dispatch_release(_timer);
    [super dealloc];
}

- (void)invalidate {
    _dispatch_source_cancel(_timer);
}

@end

That’s it. Let’s go over what we’re doing here.

Our strategy is to install the timer onto a concurrent queue. We want it to run at the same time as our current thread, no? So we get a reference to the standard priority concurrent queue.

Then we create our timer source, using dispatch_source_create. In this case, we’re creating a timer (there are a few different source types), so we pass DISPATCH_SOURCE_TYPE_TIMER as the first parameter. The other parameters are unused for timers.

Now that we have the timer, we need to set the start time. It’s specified in nanoseconds, so we need to take our input time and multiply it accordingly. We use dispatch_time so that we can specify a time from now. The third parameter is the interval, but since we’re only going to fire it once, we just set it to forever. You can also use 0 since we explicitly cancel it when we fire.

Next, we set our event handler. This is how you tell the source what to do when the timer fires. In our case, we merely log, but you could do whatever you like. You could also create a version of this that took a block passed into the init method and execute that when the timer fires. That would be pretty handy if you want to do specialized things for each watchdog you create.

Note that we cancel the timer when it fires. This is to ensure it will never fire again.

And finally, we start the timer running with dispatch_resume. All sources are created in the suspended state, allowing you to set them up properly before they are started.

In our dealloc, we merely cancel the timer and release it. It does no harm if it’s already been cancelled. This covers the case where the watchdog doesn’t fire, we want to kill it and move on.

In invalidate, all we do is cancel the source. This will ensure it does not fire. It’s possible you might invalidate it just when it’s firing, but that’s OK. You were just on the cusp of the timeout, and you should have been faster!

If you don’t like to have to invalidate and then release the object, you could always create an invalidateAndRelease method to save some typing.

Timers In General

This is one specific use of a timer in GCD, clearly you can use them in many other cases where you want things to execute concurrently. If you needed to return results to your main thread, you can just use dispatch_async to execute the code on the main queue (dispatch_get_main_queue() as we’ve seen in previous posts.

If you just want a timer to run on the main thread, you can certainly install a GCD timer on the main queue, or you could just use NSTimer. Whatever floats your… you know.

If nothing else, this might give you ideas on how you could use dispatch timers in your application.

That’s it, enjoy!

Starting Up…

While we’ve seen that we can easily put things onto a concurrent queue, in many cases, you’ll want to create your own FIFO queue. These allow you to:

1. guarantee order of operations
2. implement synchronization without locks
3. arrange these queues into groups to help wait on multiple queues at once
4. know when a queue is empty

The synchronization case will be left for my next post, but we’ll try to cover the others here.

First, we need to create a queue. Simple enough:

dispatch_queue_t myQueue = dispatch_queue_create("com.mycompany.myqueue", 0);

The first parameter is just some identifier, you can use anything you want, including NULL, but reverse domain is usually a good case. You’ll actually see this name in backtraces in gdb to help you know which queue is which.

Once you have a queue, it’s just like we’ve seen before. We can start to put tasks on it.

dispatch_async(myQueue, ^{
    printf("this is a block!\n");
});

And as noted, whenever you create your own queue, it is a FIFO queue. So everything will execute in the order you put blocks onto the queue. And you always know that the preceding block is complete before the next block executes.

Finished Yet?

We’ve implemented a simple job queue and can put blocks onto it, but how do you know when it is done? There are two ways you can determine this. First, you can just use dispatch_sync to help you.

// wait for queue to empty
dispatch_sync(queue, ^{});

Basically, we’re using dispatch_sync here to force us to wait until the block passed finishes before continuing. Your thread will block until the block finally gets a chance to run and finish. At that point, you know the queue is empty (assuming you’re not doing something like posting to that queue from other queues).

You should generally only use the method above if you only have one queue and don’t mind blocking your thread until the task is done. For tasks that take a while, that would be bad, particularly on iOS where you’ll get watchdogged if your main thread is blocked for too long.

If you don’t want to wait, then you could simply push an async block to notify you when the block runs. You might, for example, do something like this during shut-down of your object (and related queue).

- (void)shutdown {
    // don't allow more blocks to be queued
    _valid = NO;

    // allow our owner to release us while we clean up
    [self retain];

    // now push an async task to tell us when we're done
    dispatch_async(_queue, ^{
        [self allTasksDone];
    }
}

- (void)allTasksDone {
    // we're really done and ready to shut down
    // we can now release ourselves
    [self release];
}

Dispatch Groups

The other method to do this involves dispatch groups. This allows you to create and wait on multiple queues to become empty, though it would also work for one queue. To create a group is even simpler than creating a queue. Once you have your group, you submit blocks to the group, as such:

dispatch_group_t group = dispatch_group_create();

dispatch_group_async(group, queue, ^{
    printf("This block is associated with our group\n");
});

Note that we used dispatch_group_async instead of dispatch_async. This ensures the block is associated with the group. To wait on the group, we just call:

dispatch_group_wait(group, DISPATCH_TIME_FOREVER);

The second parameter just indicates how long to wait before giving up. Most times you’d pass DISPATCH_TIME_FOREVER as we did here.

Keep in mind that only blocks that you started with dispatch_group_async and therefore were associated with the group can be waited on with dispatch_group_wait. If you started that block otherwise, you’d be waiting forever, indeed.

Like we talked about above, this is going to block the thread you call this on though. How would we instead notify when all queues were empty? There’s an API for that:

dispatch_group_notify(group, queue, ^{
    [self allTasksDone];
});

This will call allTasksDone when all blocks submitted to the group are finished, regardless of how many queues comprise the group.

Canceling Tasks

Often times, you want to put tasks onto a job queue, and then cancel one or more of them. However, you can’t cancel a block via any sort of API, so they always must run to completion. So it’s up to us to expedite that if need be.

In the example above, we wanted to wait until all tasks were done. Before submitting our sentinel block, we set _valid to NO. We can use this to help us do cancelation and hence shut the queue time in a timely manner. Perhaps you’re writing image thumbnails and you want the current one to finish, but all others to abort. You can just check the _valid flag in your blocks:

dispatch_async(queue, ^{
    if (_valid) {
        [self processFile:fileURL];
    }
});

Once that flag is set every block that started to run would instead immediately exit.

Another cancelation idiom is the case where you start a task that’s searching for data on one query and the query has changed. The canonical example might be type-ahead. You can accomplish this by having a sort of ever-changing sentinel. You could do this as a integer seed, or in this case, perhaps we just store off a copy of the query we are doing and we compare that to the ‘current’ query. We’ll need some synchronization for this because the term will be referenced from our main thread and the thread the block is running on.

- (NSString *)currentTerm {
    @synchronized(self) {
        return [[_term copy] autorelease];
    }
}

- (void)setCurrentTerm:(NSString *)term {
    @synchronized(self) {
        if (term != _term) {
            [_term release];
            _term = [term copy];
        }
    }
}

- (void)searchWithTerm:(NSString *)term {
    self.currentTerm = term;

    dispatch_async(_queue, ^{
        [self performSearchWithTerm:term];
    });
}

- (void)performSearchWithTerm:(NSString *)term {
    if ([term isEqualToString:self.currentTerm]) {
        // do searching here and periodically double-check
        // term against self.currentTerm to see if it changed

        // When we have results, pass them to the main thread
        // Must check against current term again for safety.
        dispatch_async(dispatch_get_main_queue(), ^{
            if ([term isEqualToString:self.currentTerm]) {
                [self searchReturnedResults:results];
            }
        }
    }
}

This one shows not only how to check against the current search term, but it also demonstrates another pattern where you return results.

Note that we store off the current term into the object, but we pass the original term into our block. While the block executes, we periodically compare our search term to the current term. If it changes, we stop processing and exit. However we might get as far as finding and returning results, which we then send back to the main thread. But we could have changed the current term in between the time when the block was queued for the main thread and the time that block was executed, so we check the term for one last time before returning results. It’s extremely important to do this check, otherwise you’ll end up wondering why you’re processing data that’s no longer valid, or worse.

Until Next Time

That pretty much covers creating and using a job queue. We discussed how to create a queue and add tasks, how to wait for tasks to complete, and also how to effectively cancel tasks in the queue. We also ended up covering how to successfully shut down an object that owns a queue. These patterns should help you replace your current use of threads with GCD. If only we could get rid of locking. Oh wait, we can! That’s for next time

The Ultimate Callback

If you recall, blocks are snippets of code you can run which capture information about their environment as needed. That is, they behave like closures in other languages such as Javascript.

Because of this, they are the ultimate callback. You can pass parameters to them, and they can reference variables in the current scope the block is introduced in. You can also pass blocks around as objects, and copy them as needed, as we’ll see later.

We’ve already seen the most basic callback in use in the last post, where we had a simple block that looked like this:

^{ printf("this is a block"); }

This is what you’d use for a call to dispatch_async, etc. This is essentially a block that takes no parameters and returns no result. You can actually typedef such a thing as follows:

typedef void (^GenericCallback)(void);

Or just define the types directly as:

void (^)(void) myCallback;

It’s pretty much the exact same syntax as a function pointer, but you substitute a ^ for the *. But blocks can also take parameters and return values:

NSString *(^)(int a, NSString *b);

In fact, some of the newer APIs take blocks now instead of using callbacks or target/selector. Consider this method in NSArray.h:

- (void)enumerateObjectsUsingBlock:(void (^)(id obj, NSUInteger idx,
                 BOOL *stop))block;

This method allows you to iterate over all items in the array. Each time your block is called, you get the object, the index, and a stop parameter (if you want to terminate iteration). You can use it as such:

[myArray enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    NSLog(@"Item %d is %@", idx, obj);
}];

So in its most basic use, it becomes an inline callback. But unlike a normal callback, it has the advantage of context. Let’s say we have an object’s identifier. I need to compare that to each item in an array’s identifier until we find a match. You can do the following:

NSUInteger index;
NSString *myIdentifier = myObject.identifier;

index = [myArray indexOfObjectPassingTest:
                 ^(id obj, NSUInteger idx, BOOL *stop) {
                    return ([obj.identifier isEqualToString:myIdentifier]);
                 }];

The advantage here obviously is that we don’t need to pass any sort of ‘userData’ or ‘refCon’ along with the block. That comes for free because myIdentifier is in scope as far as the block is concerned. Clearly this is far more powerful than ye callbacks of olde.

As the implementer of such a function, you call blocks just like you call a function. In this example, we’ll define a contrived method that takes a math function that operates on its members.

- (int)performMathFunction:(int (^)(int a, int b))operation {
    return operation(_a, _b);
}

// then someplace later...
int result1 = [self performMathFunction:^(int a, int b) { return a + b; }];   
int result2 = [self performMathFunction:^(int a, int b) { return a / b; }];

Kind of useless in and of itself, but the point is clear in that you can use a block where you might have otherwise used a callback, but now you have the advantage of allowing the callback to take its data with it.

Blocks as Objects

Another benefit is that you can hold onto blocks as you would objects. There are two methods defined for copying and releasing blocks: Block_copy and Block_release. These are handy if you want to allow a block to be kept around by an implementation to be called later. This is ultimately what dispatch_async uses to take your block and run it over on some other thread. You only generally need to use it if you will be running the block after the function that passed the block will have been exited by the time it is called.

Please note that if you are using a synchronous function such as the NSArray methods above, you don’t need to do any copy/release because it’s all happening right then and there in your thread. This is only for those cases where you want to for whatever reason call a block sometime later.

When using Objective-C, you can treat them like almost any other object and just use copy and release. For example, another contrived example:

@class MyObject;

typedef void (^MyCompletionHandler)(MyObject* object);

@interface MyObject : NSObject {
    ...
    MyCompletionHandler        _completion;
}

@property(nonatomic, copy) MyCompletionHandler   completionHandler;

@end

@implementation MyObject

...

// Implementing this just to show it in action, 
// but you could just use @synthesize
- (void)setCompletionHandler:(MyCompletionHandler)completion {
    [_completion release];
    _completion = [completion copy];
}

...

- (void)taskIsComplete {
    _completion(self);
}
@end

When you copy a block, it’s context goes with it. If you copy a block in Objective-C, the objects referenced therein will get retained when the block is copied. We touched on this last time. Remember though that in C (or really, when using C types like CFArrayRef), this does not happen, and you will need to retain objects before your block and release them inside to ensure that when the block is run it really has a reference to the object.

Be Cautious of Loops

This copying/retaining semantics of blocks is very useful as it means your objects won’t go away while your block is being executed on some other thread, but you can also get into trouble if you happen to be using them only on one thread and the context in a block contains a reference to some parent structure. You’ll get into a retain-loop. Consider a UITableViewCell subclass that you want to initialize with a block to perform some action:

// inside your controller's tableView:cellForRowAtIndexPath:
cell = [[MyCell alloc] initWithBlock:^(MyCell* cell) {
           [self adjustCell:cell];
       }];

So here we have a block that calls a method on the controller. Simple enough. But when that cell is created, it’s init method might copy the block to ensure the block is valid at all times. The problem is, it references self. But that self is the view controller. So you have a view controller retained by one of its descendants. This creates a retained object loop that ultimately means this controller will never get released.

The only way I’ve found to deal with this is by creative use of __block variables. But we haven’t talked about that, now have we? Guess it’s time…

Modifying Local Variables in a Block

While blocks can reference variables in the context they are defined, those variables are read-only. This is done (I presume) for efficiency’s sake, and 99 times out of 100 this is fine. However, there are times when you want to change the value of one of those variables. The way you do this is to prefix them with the __block modifier. Consider:

int     x = 10;

dispatch_sync(aQueue, ^{
    x = x + 10;
    printf("block says x is %d\n", x);
});

printf("x is %d\n", x);

Yet another contrived example, but here we want to call a block via dispatch_sync. Unlike dispatch_async, dispatch_sync executes code synchronously. You might wonder why you’d do that. Well, you’ll have to wait until another blog post In any case, this block wants to modify the value of x. The output of this is:

block says x is 20
x is 10

Not quite what you expected, perhaps. The variable x was perfectly mutable inside the block, but it never affected the original scope. We can fix this easily just by adding __block:

__block int x = 10;

And then our output is what you’d expect:

block says x is 20
x is 20

And all’s right with the world again.

But how does this knowledge help us avoid the retain cycle we saw above? Well, it turns out that __block variables are actually not retained when the lock is copied. So you can do this:

// inside your controller's tableView:cellForRowAtIndexPath:
__block me = self;
cell = [[MyCell alloc] initWithBlock:^(MyCell* cell) {
           [me adjustCell:cell];
       }];

Since the self doesn’t get retained this time, we avoid the retain cycle. While it strikes me as iffy, it does work, and it’s the only way I’ve found to deal with this situation. You can’t simply avoid copying the block if you want to call it later, because the scope will be gone by the time the function that declared the block exits. That will lead to nothing but sadness.

Now You’re a Blockhead, Too

At this point, you know just about everything there is to know about blocks. Some of what we’ve talked about here is going to help us when we discuss using blocks and dispatch queues to implement synchronization in a future post. Believe me, GCD does it all. It’s one technology that might convince you to make your apps depend on it completely to the point of requiring it to run. Doing the types of things GCD can do any other way seems so… primitive.

But what if I could thread until the break of dawn and not have to worry as much about those situations? That’s exactly what Grand Central Dispatch gives you on Mac OS X, and now iOS — access to concurrency without nearly as much pain.

This new world, however, does require you to think about problems a bit differently. I, at least, am so used to threading the old fashioned way that I had to figure out how to use dispatch_async and friends instead of my old cohorts.

One thing I will throw out there first is that threading with Obj-C/Foundation is so much easier than doing all the nasty work yourself. Methods like detachThreadSelector, et. al. go a long way towards making life simpler. NSOperation is also a big help. But GCD takes us beyond that with blocks (closures) and a full set of lower-level primitives that interact with Obj-C in ways that make sense and do most of the heavy lifting. But there are certainly some things you need to keep in mind, particular if you are using Obj-C.

Blocks

The first thing to learn about in this new world (and really, the thing that makes this all possible) is blocks. Blocks are essentially what other languages refer to as closures. All that ultimately matters is that it’s a way of designating a snippet of code to run. Think of them as fancy callbacks which can take any data they need with them (i.e. their context is omnipresent).

You specify a block with a special syntax. Ultimately, you enclose a block with ^{}:

^{ printf("this is a block!\n"); }

In the interest of keeping things simple, we’ll stop there and get onto some other basics.

Dispatch Queues

Typically, you’ll put blocks onto dispatch queues. There are two types of queues, concurrent, and FIFO. Regardless of the type of queue, you always know that blocks will be started in the order they are placed onto a particular dispatch queue. But in the concurrent case, they will be run on separate threads, whereas in the FIFO case you can run blocks one after the other, each one waiting for the previous one to finish first.

You can access a queue in three ways:

1. call dispatch_get_global_queue(). This will give you a built-in concurrent queue. There are three, each at a different priority (low, medium, high).
2. call dispatch_get_main_queue(). This queue represents a dispatch queue on the main thread. This is a FIFO queue, and tasks are run at ‘event time’ (i.e. inside the run loop).
3. create your own queue with dispatch_queue_create(). This will always give you your very own FIFO queue.

Concurrent queues will create as many threads as needed to run the tasks. This doesn’t mean it will run as many threads as there are tasks, however, it is up to GCD to figure out how many threads make sense for the number of tasks which are attempting to run. So you might not always get 100% concurrency, as it might limit the number of threads to something smaller than the number of blocks waiting to run. But ultimately, to you the coder, it doesn’t matter. You just know that your tasks will be run at some point.

One thing to pay attention to is that concurrent queues are really concurrent. Just because they have the word ‘queue’ in their name doesn’t mean tasks run one after the other. It means they will start in a predictable order, but they will most often times be running at the same time. So only put tasks on concurrent queues that you can safely run in parallel. Many people seem to get bitten by this.

Queues vs. Threads

One of the things that confused me at first was that queues have nothing to do with threads you create. The only thread with a queue reserved for it is the main thread. I was so used to a life where each thread you create would get its own runloop and event queue (at least in Carbon) that I was thinking it might be the same here. But it is not (nor should it be). There is a function called dispatch_get_current_queue() (so really, there’s a fourth way to access a dispatch queue), but it is really for use inside a block that’s being executed. Calling it outside of a block will yield the default concurrent queue, which is generally not very meaningful.

What this means is that if you create a thread, that thread has nothing to do with GCD, and doesn’t tie into GCD at all. Of course, with GCD in the mix, if you create a thread, you might be doing something you don’t have to do. You can pretty much accomplish every thing you used to via threads with dispatch queues and blocks (and some other constructs we won’t discuss right now). Heck, you can even implement synchronization without locks. But that’s for another time.

Running Tasks

We’ve now talked about the two parts we need in order to finally run a task concurrently. In order to start an asynchronous task, you use dispatch_async(). Let’s say we wanted to run that block we used above. Here’s what we’d do:

dispatch_queue_t queue = dispatch_get_global_queue(
                                 DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

dispatch_async(queue, ^{
    printf("this is a block!\n");
});

That’s all there is to it. First we got access to one of the global concurrent queues, running a normal priority, then we called dispatch_async, specifying the queue and the block to run. It’s common to use the formatting you see above as it make reading the code a bit clearer.

I mentioned that blocks behave like closures and are run with their context intact. Let’s see that in action:

int i = 20;

dispatch_async(queue, ^{
    printf("The number was %d\n", i);
});

This will print:

The number was 20

So all variables in scope at the time the block was created are valid for the block’s execution later. In this case, we’re able to access i without issue.

So great, we ran a task. Yay for us, what if we need to know when it’s done? There are a couple of solutions, but let’s stick with the purity of what we’re working with: dispatch_async to the rescue!

dispatch_async(queue, ^{
    NSArray *results = ComputeBigKnarlyThingThatWouldBlockForAWhile();

    // tell the main thread
    dispatch_async(dispatch_get_main_queue(), ^{
        ProcessResults(results);
    });
});

In this case, after doing whatever long task you wished to make concurrent, we can then just use dispatch_async again to execute the ProcessResults function on the main thread. This is really the same thing as doing performSelectorOnMainThread:, but more flexible in that you aren’t restricted to what you can ‘pass’ to it.

Blocks in Objective-C

When used in Objective-C, block automatically retain any objects referenced within them. This is extremely helpful, as often times you might reference self, let’s say. This means your object won’t go away until that block has executed. So you’ll never run into situations where objects used inside the block have disappeared out from under you.

This isn’t true in C. If you were using CoreFoundation types in a C function, you’ll need to retain objects before calling dispatch_async and release them inside the block. For example:

void SaveArrayAsync(CFArrayRef array) {
    CFRetain(array);

    dispatch_queue_t queue = dispatch_get_global_queue(
                                 DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

    dispatch_async(queue, ^{
        SaveToDisk(array);
        CFRelease(array);
    }
}

But, as mentioned, in Objective-C, it’s not even something you need to think about.

- (void)saveArrayInBackground:(NSArray *)array {
    dispatch_queue_t queue = dispatch_get_global_queue(
                                 DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

    dispatch_async(queue, ^{
        [self saveToDisk:array];
    }
}

More to Come

We’ve covered just enough to start to be dangerous, but I think we’re at a good stopping point for now. I’ll be writing several more entries on using GCD and specifically how to take an old threaded concept and what you’d instead do with GCD. I’ll try to be regular about timing of these articles, so keep your eyes peeled.

We should use original tools to create iPad apps, not because Steve Jobs said so, but because these tools create products with flesh and bone, that is: an understanding of both the purpose, the potential and the limits of the iPad technology.

I’ve never been a fan of cross-platform frameworks, even though I’ve been involved in four to speak of to date (not always by choice). I like to think I’m pretty good at it at this point, but even the best of us ends up with mediocre platform support or performance because you’re trying to wedge your idea of the universe onto another. And we know from watching Fringe what happens when two universes meet.

I think the true turning point started at around Xcode 3.0. Xcode is now quite simply the best IDE I’ve ever used. Most all of my complaints have been solved over time, and admittedly I’ve figured out a few things along the way that made me finally get how it all works. I thought I’d point out a few of the things that made me realize that Xcode rocks. If you’re an Xcode aficionado, I’m sure you’ll already know these.

Fast Compilations

It’s just simply super fast to compile. On my last project, I was able to clean in about 5 minutes on an iMac. In Visual Studio on my quad-core PC it took like 20 minutes clean or not. Granted it has more files to build, but wow. Slow. To the point that any time you realized you’d have to build Windows and you weren’t at top-of-tree you were like “there goes a half hour”. These days, doing iPhone apps, my app at work takes about 20 seconds to clean build. And more like about 2 second to build/link and fire up the simulator for a quick change.

Settings That Are Useful

Setting project settings used to frustrate me on Xcode. You have project settings, and then you have target settings, and it just seemed like too much. I’ve finally gotten to get the how and the why around this and I understand it all now. Recently though I had to mess with settings, and I think if it weren’t for two features, I’d still be trying to find and set the settings correctly:

• ability to filter settings. Type ‘install’ in the search box and get all settings having to do with install paths, etc. Avoids having to scan a big giant list of options.
• the fact that Xcode actually shows you the computed paths. If you click something it might be generated from variables, etc. but once it’s commited you see the path it’s going to use. I can’t begin to tell me how much time that saved me the other day when I was wondering why something wasn’t working. This was always a source of frustration in Visual Studio for me.

They might not seem like OMG features on the surface, but the time it saved makes me say OMG anyway.

Code Completion

The code completion feature of Xcode used to be frustrating to use, but in recent releases it works extremely well. It’s smart completion combined with text macros completing code fragments like if statements, etc. makes it damn quick to write code. And furthermore, you can adjust the templates of the generated code to match your code style either by creating your own text macros or by setting some defaults on the command line by setting the XCCodeSenseFormattingOptions property. For example, I like open braces of a block to always be on the next line. It help readability for me and it also helps editing a bit. Just setting a few options using that default and you can get the Xcode text completion to do your bidding.

Syntax-Aware Editing

I love the syntax-aware editing, particularly with cut and paste. Often times I’ll even cut and paste a section of code just to make it fix it up (maybe there’s another way but I’m too lazy to find out). As mentioned above, you can tweak some defaults if the code style doesn’t please you. But it’s nice to type a ‘}’ and have it put it where it belongs. Or split a call to an objective-c method across multiple lines and have it line everything up for you at the colons. One other thing that I like is when you perhaps take a method and add another call to it. For example, let’s say you typed: [foo retain] and now you want to add autorelease. Just follow it up with autorelease] and Xcode will put the starting [ in the right place. It doesn’t always get it right, but in most cases it does. Very nice, as it is certainly a bit annoying to otherwise have to go back to the start yourself just to add a starting [, which has always been one of my nits about obj-c syntax. I like it when the tools make my nits a non-issue.

Refactoring Tools

The refactoring tools that Xcode provides are really nice. The current transformations that are supported are definitely helpful at times, and I hope they continue to think of more goodness they can add here.

Slipstream Drive

With all the above features — in general lots of ‘little things’ that make things just work — Xcode allows me to write code incredibly fast. I feel like code just flows out of my fingers and the IDE just knows what to do with it. Occasionally though, I’ll long for a couple of smaller niceties from Visual Studio, or perhaps the code completion isn’t quite doing what I want, and it kind of knocks me out of slipstream drive. I’ve recently filed a couple of enhancement requests for them. We’ll see what comes of them, but if they did manage to get them in, I would truly have an all-powerful programming tool at my fingertips.

I’m sure there’s more things (data modeling, etc.) but I haven’t used all those features. My bliss these days comes from just being able to sit down and get incredible amounts of work done in a relatively small amount of time. To me, that’s what makes Xcode so amazing and pleasurable to use.

Bet you didn’t expect to hear me ever say that, now did you?

When the app store opened, I downloaded several Twitter clients. Each was interesting in their own right, but I couldn’t use any of them because of one reason: the scrolling performance. I didn’t get why everyone’s scrolling was not as smooth as any of the built-in iPhone applications. For me, it made the apps frustrating to use, to the point that I just never used them.

A Simple Proof

As an experiment, I wanted to prove that I could make something that scrolled as good as the Apple-made stuff. I had already done other samples using the Twitter API as part of Blueprint at Yahoo! as well as in a Widget for Konfabulator I worked on but never finished. So I figured it would be fairly quick to throw something together.

I wrote a simple web fetcher and then did a rudimentary list. Originally, it was completely a navigation based app. You’d get a list of items such as ‘With Friends’, ‘History’, etc. and click those and get the listing of 20 tweets (the default that you get with the API). It was at this point that I started messing with getting the scrolling fast. In the end, it was smooth as silk. But I also didn’t have features such as the current balloon look and clickable links and @names.

The clickable links took me quite a while to get to work. I spent much time working on line breaking and making sure it was as efficient as it could be, using Instruments to find and eliminate bottlenecks.

After that, I had something that could line break beautifully and yet it still scrolled incredibly fast. Implementing the balloon look however, did slow it down a bit, but again I spent a lot of time trying to cache and get things to the point that you see it today.

But even after all that, there was still tons to do. I mean, it was really just something to prove to myself I could do this. But at this point, I realized I was onto something real here and could really build something exciting. But there were plenty of competition out there. Why build another Twitter app? I wasn’t really sure, but I kept going anyway to see where it took me. By the time I got to the end, I knew I had something big on my hands.

Making It Real

For the next few weeks I worked pretty much 24/7 getting things to cache properly, push things off onto threads as much as possible, use a real database, etc. and make sure that things just worked correctly. Despite the simplicity of what Twitter is, making an application to really behave properly and ensure that things are always as you expect is pretty darn hard. Even something as ‘simple’ as clicking a tweet and then iterating your tweets with the up and down arrows in the upper right was interesting. Not because of the iteration of the items, but because you now have yet another view that needs to be aware of state changes in the application. For example, if you favorite something, I needed to make sure that if it was showing elsewhere in the UI the change was reflected. Good times.

I also rewrote certain sections more than once to get things right. The database for example, was originally just a plist, but the more complicated the UI became, the more necessary SQLite was. And that had to be threaded for even more fun. I had also originally started with MGTwitterEngine, but ended up writing my own engine for two reasons:

1. design-wise, MGTwitterEngine didn’t fit with what I needed to to (it was too centralized, I needed many delegates, not just one).
2. I decided to use JSON instead of XML to try to keep the data smaller and simpler to parse. XML really is a pain to deal with.

And since I didn’t find a JSON parser that seemed to be small enough and simple enough to integrate, I wrote one. Admittedly, it’s been something I’ve wanted to do for a while. I’m sure somewhere out there there’s a JSON parser that would have fit the bill, but I didn’t find it in my cursory search of the interweb tubes.

Details, Details

You know all those ‘standard’ form controls you see in all the Apple applications? Yeah, they ain’t standard. So a bit of time was put into creating my own version of those constructs and making them look and behave as closely to the Apple stuff as I could.

I also needed to handle image uploads and tweet compositions, loading followers so you can help address messages, doing the first run screen, etc. Lots of little things to make stuff right.

And even after I thought I had everything done, I ended up rewriting the messaging section to what you see today. It originally had inbox and sent like the web site, but one of my beta testers suggested a threaded view. At first I was like “man, that’s going to take forever”, but it only took me a day or two to get right. Most of my time in fact was spent drawing the stupid balloons to try and match the SMS app, only this time in delicious purple!

That was the making of 1.0. Right before I handed it over to Tapulous, I also added:

• Flickr upload support
• Re-tweet functionality
• Ability to quit during writing a tweet and come back to where you left off the next time you launch.

I know there are several other thing that people want. I originally did envision adding things like multiple account support, etc. and I see that people also really want to have it save where you last were and not jump to the top when you load tweets. That one actually came up during development and there seemed to be strong arguments on both sides. So I left it as it was, but perhaps Tapulous can add that as an option.

People also have been asking for the ability to tap the status bar and have it jump to the top, but it already does that (the iPhone frameworks do it for you in fact). Perhaps there’s a bug in there that stops it from working sometimes.

So that’s my story, and I’m sticking to it. The best part for me has been seeing people’s comments on Twitter which echo exactly those attributes I held dear in its inception:

• UI speed. It tries its best to not get ‘stuck’. It only now gets stuck when it’s loading the table for the first time. I hope.
• Simplicity. It’s not glossy black. It’s just iPhone.
• Power. You can do almost everything the Twitter API allows: follow friends, drill down in a user’s history or followers, search for your favorite terms, etc.

Thanks

I want to thank everyone that helped me test the application and suggested features, etc. This includes Arlo Rose, Rob Marquardt, Karl Adam and Aaron Hurley. These people had much input into the end design. Arlo suggested the use of the Tab Bar over the nav-style interface. Karl caused me to go to threaded messages, Rob and Aaron both suggested many different enhancements to make things more user-friendly and do what you’d expect. You can blame Rob in particular for my adding Flickr upload.

Again, thank you all. It was a great project!

First, it’s been approved for sale! But I haven’t seen it show up and sadly I don’t have a link to it. Read on for why.

The main reason the app was delayed so long coming out is because I had been been trying to figure out exactly what to do with it. I might be in a situation soon that will actually prevent me from being able to maintain the application, so I wanted to see if I could find a good stewart for my baby. I’ve chosen to hand the application over to Tapulous, maker of Tap Tap Revenge, Twinkle, FriendBook, Fortune and Collage, with whom I have a good working relation.

I think this is going to be great for Tweetsville, as they have better resources at their disposal to help support and grow the application. I also think they have some technology which can help Tweetsville be even better than it is. At the same time, there’s some stuff I did for my app that I believe will benefit Tapulous.

There is no plan to have Twinkle and Tweetsville merge. They are to be separate applications with separate audiences. Twinkle is about locality and the Tapulous network, and Tweetsville is purely a Twitter application.

One of the advantages here for users is that there will be choice. There will ultimately be two versions of Tweetsville. The first will be a paid version currently slated for $3.99. The second will come a few weeks later and will be a free ad-supported version.

I’m confident this will move is the best thing for the Tweetsville app as well as users in the long run. You’ll get more choices and better support than I would have been able to provide on my own. I feel the app is in good hands, as I have a great working relationship with Tapulous (I’m actually doing a little work on Twinkle 1.3 these days too).

So look for it to appear in the App Store on Monday the 10th of November!

Update Actually the date is apparently going to be the 12th.

self.opaque = NO;
self.backgroundColor = nil;
self.clearsContextBeforeDrawing = YES;

But all I really needed to do was:

self.backgroundColor = [UIColor clearColor];

Same transparency, and I’m guessing (hoping?) that it might be a bit more efficient (unless of course, the innards look for clear color and effectively do what I used to).

Hey, even if it’s not more efficient, it’s certainly simpler to type and it seems to have the same effect!

Sadly, this is one thing I didn’t figure out on my own, but rather spied in some other sources, but I wanted to throw it out there for ‘all uh yous’.

Before digging into it, I should say this: threads are evil. If you don’t believe this, then I believe you are made of living tissue over metal endoskeleton. You should endeavor to avoid threads at all cost. In most cases, timers are your best friend. Know them. Love them.

Of course, there are times when you need to use threads. I needed to add a few threaded operations to my iPhone application to make sure the UI stayed responsive. On the project at Adobe, we were doing thumbnailing of images, definitely something you don’t want happening on the main thread.

1. Avoid recursive locks

A recursive lock is a lock which allows the same thread that locked it to lock it again. The advantage is that you don’t need to worry about what’s locked and what’s not on any particular thread. They also make it easy to retrofit locks into existing code.

The problem though is they most often end up being used to lock large pieces of code for indeterminate amounts of time. This makes things very coarse-grained. They also lead to issues where if you didn’t unlock the exact right amount of times, you will leave a thread holding the lock forever. It’s very easy for this to happen. And these problems are nearly impossible to find because the lock that was taken is usually very far away from where the hang/deadlock happens later.

Better to use a real honest-to-goodness lock. This means that if a thread tries to lock a lock that’s already, well, locked, you’ll deadlock. This is good. I like this, just as I like crashes. I know, you think I’m crazy, but if you deadlock on your own thread, then you know you just did something bad. Most likely, you’ve called out of a function when locked to another function that ends up needing the same resource.

Most people, when confronted with this, switch to recursive locks. Problem solved, right? Wrong. You’ve just opened yourself up to a world of hurt, mostly due to what I said above. So what do you do? Well, what I typically do is split the function into two. Consider:

// Some public API
void IncrementCounter()
{
    Lock();
    fCounter++;
    Unlock();
}

// Another public API
void MyFunction()
{
    Lock();
    // do some magic that requires us to increment the counter
    IncrementCounter(); // BAD: DEADLOCK!!
    Unlock();
}

So here we have a public function that wants to call another public function, but both of them want to lock. What I end up doing is just creating an internal function.

void IncrementCounter()
{
    Lock();
    IncrementCounterWhileLocked();
    Unlock();
}

void MyFunction()
{
    Lock();
    IncrementCounterWhileLocked();
    Unlock();
}

void IncrementCounterWhileLocked()
{
    fCounter++;
}

That’s it. So basically, put the locks on the outermost (public) layer and do whatever you need to while locked on the internal layer. Yes, it’s more typing, but it’s really clarifies exactly what is going on.

The other thing about non-recursive locks like pthread_mutex is that is also forces the next two points on you, which you probably would want to do anyway.

2. Keep it short and sweet

You should hold your locks for as short a period of time as is necessary or practical. Using a non-recursive lock helps to enforce this rule. This is convenient since contention will be reduced. On the other hand, don’t go insane and lock every little thing. Make your locks coarse-grained enough to avoid many trips to the kernel via locking, but fine-grained enough to know that contention is low between threads so they aren’t running choppily.

3. Call out when locked, go to jail

Never, ever lock a mutex and then call out to some other function (unless it’s some other utility function on the same object that expects the resource to be locked). This is a deadlock waiting to happen, as that callout might end up calling something that also wants that lock. Now you’re deadlocked. Use of recursive locks over large bodies of code almost always makes this a certainty to occur.

So you should never do this:

void MyFunction()
{
    Lock();

    // ... do whatever work ...

    (*fCallback)(); // UNSAFE, could even call MyFunction again!

    // ... more work ...

    Unlock();
}

But instead, do this:

void MyFunction()
{
    Lock();
    // ... do whatever work ...
    Unlock();

    (*fCallback)(); // OK

    Lock();
    // ... more work...
    Unlock();
}

(As a side note, it is fine to use a recursive lock if you follow 2 & 3 religiously and can guarantee correctness, as then the locality of the locks should make things obvious where problem are when there is a problem. But I still prefer non-recursive. It forces you to get it right, and enough can already go wrong with threaded programming.)

My original document also had notes about other topics, but they were more specific to our project. I think the above has universal relevance, however. As I originally mentioned, our project was violation all three rules, but I’m pretty sure the root cause was #1. All other evil tends to stem from there.

I think if you follow these three rules, you’ll take a lot of the guesswork out about what’s locked when, and you’ll find problems immediately (it will just deadlock, which is typically an easy fix). This should allow you to focus on the more important issues and sidestep the nastiness that might otherwise befall you.