I have a UITableView that displays images associated with contacts in each row. In some cases these images are read on first display from the address book contact image, and
A simple method that may be Good Enough for your task: use NSOperation
s' dependencies feature.
When you need to submit an operation, get the queue's operations and search for the most recently submitted one (ie. search back from the end of the array) that hasn't been started yet. If such a one exists, set it to depend on your new operation with addDependency:
. Then add your new operation.
This builds a reverse dependency chain through the non-started operations that will force them to run serially, last-in-first-out, as available. If you want to allow n (> 1) operations to run simultaneously: find the n th most recently added unstarted operation and add the dependency to it. (and of course set the queue's maxConcurrentOperationCount
to n.) There are edge cases where this won't be 100% LIFO but it should be good enough for jazz.
(This doesn't cover re-prioritizing operations if (e.g.) a user scrolls down the list and then back up a bit, all faster than the queue can fill in the images. If you want to tackle this case, and have given yourself a way to locate the corresponding already-enqueued-but-not-started operation, you can clear the dependencies on that operation. This effectively bumps it back to the "head of the line". But since pure first-in-first-out is almost good enough already, you may not need to get this fancy.)
[edited to add:]
I've implemented something very like this - a table of users, their avatars lazy-fetched from gravatar.com in the background - and this trick worked great. The former code was:
[avatarQueue addOperationWithBlock:^{
// slow code
}]; // avatarQueue is limited to 1 concurrent op
which became:
NSBlockOperation *fetch = [NSBlockOperation blockOperationWithBlock:^{
// same slow code
}];
NSArray *pendingOps = [avatarQueue operations];
for (int i = pendingOps.count - 1; i >= 0; i--)
{
NSOperation *op = [pendingOps objectAtIndex:i];
if (![op isExecuting])
{
[op addDependency:fetch];
break;
}
}
[avatarQueue addOperation:fetch];
The icons visibly populate from the top down in the former case. In the second, the top one loads, then the rest load from the bottom up; and scrolling rapidly down causes occasional loading, then immediate loading (from the bottom) of icons of the screenful you stop at. Very slick, much "snappier" feel to the app.