Question

I am developing an iOS app with a UITableView which at some stage adds or removes a bunch of its rows. Since there are a large number of rows, this operation can take long. However, I cannot easily determine if it will take a long time or not.

I would like to display a UIActivityIndicator (spinner) only if this operation is taking a long time. The way that I’ve always done this, is to start the lengthy operation, and after some delay (say 0.5 seconds) we test if the operation is still running, and if it is, we start displaying the UIActivityIndicator.

If you can run the lengthy operation in a background thread, this is no problem. However, this particular case is tricky because the lengthy operation (deleteRowsAtIndexPaths:withRowAnimation:) must run in the main thread (if I run this method in a background thread, the app crashes occasionally when the background thread tries to update the UI).

The latest thing that I’ve tried was in the lines of this:

- (void) manipulateTableView
{
    stillBusy = YES;
    [self performSelectorInBackground:@selector(waitBeforeShowingBusyIndicatorForView:) withObject:view];
    .
    .
    .
    [self performSelectorOnMainThread:@selector(deleteRowsAtIndexPathsWithRowAnimation:) withObject:args waitUntilDone:YES];
    stillBusy = NO;
}

- (void) waitBeforeShowingBusyIndicatorForView:(UIView*) view
{
    usleep((int) (BUSY_INDICATOR_DELAY * 1000000));
    if (stillBusy)
        [self performSelectorOnMainThread:@selector(showBusyIndicatorForView:) withObject:view waitUntilDone:NO];
}

Because showBusyIndicatorForView: manipulates the UI, it must be called on the main thread, otherwise the app might crash.

When deleteRowsAtIndexPaths:withRowAnimation: takes very long, the delay in waitBeforeShowingBusyIndicatorForView: expires and the performSelectorOnMainThread:… method is called and returns immediately. But then the showBusyIndicatorForView: method is called only after the call to deleteRowsAtIndexPaths:withRowAnimation: completes, which defeats the purpose.

I think I understand why this happens. The deleteRowsAtIndexPaths:withRowAnimation: method runs in an iteration of the main loop, and while it’s running, the call to showBusyIndicatorForView: is queued as a message of the main loop. Only after main loop completes executing deleteRowsAtIndexPaths:withRowsAnimation: it polls the queue for the next message and then starts executing showBusyIndicatorForView:.

Is there any way of getting this thing to work properly. Is it perhaps possible to interrupt the main loop and make it execute showBusyIndicatorForView: immediately?

Answer 1

Rob, thanks for the advice! It helped me find a solution!

First of all, and for the record, I was calling deleteRowsAtIndexPaths only once for all the rows (several thousands of them :O!).

The key observation that I made was that only a small number of the rows are visible on the screen when the animation starts. Specifically the top rows of the section, because the removal of the rows is triggered by tapping the header of that section. Because of this, the rows need not all be part of the animation. I can remove all the non-visible rows first (without an animation), and then remove just the visible rows with an animation.

I then had two calls to deleteRowsAtIndexPaths – the first one removed all the non-visible rows, and the second one removed the visible (top) rows. Now the first call to deleteRowsAtIndexPaths took a very long time, because it had to remove thousands of rows, and again the activity indicator view could not get a chance to begin animating. I then changed the first phase of the row-removal to a loop that removed the rows 200 at a time like this:

for ( /* next range of invisible rows */ )
{
    // Compute index paths of the bottom 200 rows.
    [self performSelectorOnMainThread:@selector(deleteRowsAtIndexPathsWithRowAnimation:) withObject:args waitUntilDone:YES];
}

The method that starts the activity indicator animation would then be queued between two subsequent calls to deleteRowsAtIndexPaths…:.

Interesting to note: now that I’m removing 200 rows at a time, it takes a considerable while, but it’s still significantly faster than when I remove them all at once! 😐