Question

Application Specific Information:
com.oneorangetree.iphoneexample failed to launch in time 
elapsed total CPU time (seconds): 3.500 (user 1.680, system 1.820), 17% CPU 
elapsed application CPU time (seconds): 0.920, 5% CPU

When the app loads, it does ALOT of stuff in viewDidLoad
It takes about 30 seconds to complete. How can I put this in a background thread or something to speed up the app and prevent the crash (because it took too long to load)

Answer 1

I’ve used NSOperation/NSOperationQueue in the past for simple threading. Specifically, NSInvocationOperation makes it really easy to spin a method call that takes a while off, and NSOperationQueue practically threads it for you. The method you’re spawning off has to be thread safe, but that is not particularly hard to do. For example, you could create an NSOperationQueue in your -init or -viewDidLoad methods, and then add the NSInvocationOperation to the queue and send it on it’s way.

NSOperationQueue *opQueue = [[NSOperationQueue alloc] init];
NSInvocationOperation *lengthyTask = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(processAddresses) object:nil];
[opQueue addOperation:lengthyTask];
[lengthyTask release];

One of the kinda cool things (especially on the desktop) is that on 10.6 (and iOS 4) Grand Central Dispatch is automatically used.

While threading a lengthy task should make your app be more responsive (especially if you watch the results and display them as they come in from the threaded task, maybe with KVO), it would be beneficial to implement some caching. Reloading the address book every launch would be very costly, especially most people don’t change their address books a lot. You could store the computed data in a local file or database (Core Data is not too hard to use, and if it’s too slow you can use SQLite directly). Then on launch, you can run through the address book, comparing the modification dates on each record from the last time your app was run, geocoding the newly modified records.