Non-Blocking NSString-search using e.g. UITextField & UISearchViewController

Doing search is difficult. Usually you start to search for something if the stuff you have has reached an amount you cannot recognize any longer easily. You spend hours searching and finding the right things or do not even try searching for it because it is too much work.

Totally unrelated by @mattetti:

That is what search was made for… theoretically. Nowadays „Search“ often means you have to type into a $textInputField somewhere and as soon as you start typing this damn thing starts searching EVEN ON THE FUCKING FIRST CHARACTER and blocks the UI i.e. the keyboard.

There are thousands of examples of this kind of behaviour but the worst thing at all is that these INSTANT-SEARCH-AS-YOU-TYPE consumes so much CPU on the MAIN THREAD (which usually is needed to drive the User Interface) that everything literally comes to a halt… EVEN THE FUCKING KEYBOARD. You simply cannot type the next character until the search comes back and has finished computing. I could kill developers for this kind of behaviour.

But whose fault is this? I would say Apple could definitely improve it’s own apps in this regard. So to ask Apple to fix this is asking a blind to see the colors. No! You need to fix it yourself! Get to know THREE small things, it is actually really only three (in numbers „3“):

You need to know 3 things

1. MAIN THREAD
   Nearly 99% of your written code runs here. It drives also the UI. Computing intensive stuff like instant-search-on-typing placed here will degrade UXP dramatically.
2. THREADS YOU CREATED
   The 1% of your code which does very computing intensive search runs here and NOT on the MAIN THREAD and IF YOU DO NOT TAKE CARE it consumes ALL THE CPU it can get. You need to teach it to make pauses.
3. PAUSING WORK
   The 200 milliseconds you will definitely pause regularly in your computing intensive code to allow others (i.e. the MAIN THREAD) to get stuff done, too.

Things are not that complicated as you might think. But a lot of people post code that does not work and/or is wrong and has no easily understandable explanation why this is the right code and how it works in the details. If you read one piece of code to learn from, please read this answer on StackOverflow explaining how to avoid blocking the keyboard while you do searches.

Step 1: It boils down to YOU first giving MAIN THREAD some CPU-cycles before you even start with your computing intensive stuff. THIS IS IMPORTANT DO NOT EVER LEAVE OUT THIS STEP!!!

Step 2: Directly after you gave away some cycles to the MAIN THREAD you DISPATCH (other word for starting something, that continues to do stuff on its own afterwards) YOUR CREATED THREAD which will do computing intensive work.

Think about YOUR THREAD as a separate app that has nothing else to to with your app anymore. Since this separate computation starts within the blink of an eye it is so important you give some CPU-cycles to the other threads BEFORE you start your work, because your threads will be started FROM THE MAIN THREAD, and the MAIN THREAD wants to immediately continue with its work after you DISPATCHED YOUR THREAD. In this case (keyboard events) the computing intensive operation gets started over and over again. This is the second reason you need to add PAUSES.

Step 3: Inside YOUR THREAD you will hit a point (hopefully!) where all computation is done and finished. Usually something should happen with the result now. You now need to communicate from YOUR THREAD (…again, that is best thought of as a separate app) to your real app aka the MAIN THREAD. There is only one recommended way to do this, you have to tell the MAIN THREAD that it should do something now for you. You just give the MAIN THREAD a job ticket from within YOUR THREAD, so it knows what to do with your results.

Sample Code that works!

Here come some sample code I actually use successfully on the iDevices. Recognize that the simulator is not really the place you test this. Please recognize the highlighted lines 52,60,63 and 77, where all the thread-related magic happens.

/* YourViewController.h */
@interface YourViewController : UIViewController <UITextFieldDelegate> {

    BOOL isSearchInProgress;
    BOOL wantsAnotherSearch;
    NSString *stringToSearchForWhenCompleted;
}

@property ( nonatomic, assign ) BOOL isSearchInProgress;
@property ( nonatomic, assign ) BOOL wantsAnotherSearch;
@property ( nonatomic, retain ) NSString *stringToSearchForWhenCompleted;

@end

/* YourViewController.m */
@implementation YourViewController

// SOME STATUS VARIABLES WE NEED TO SYNTHESIZE
@synthesize isSearchInProgress;
@synthesize wantsAnotherSearch;
@synthesize stringToSearchForWhenCompleted;

- (void) refreshUiWithItemsFound:(NSArray*)itemsFound {
    // UPDATE YOUR UI HERE!
}

- (void) searchForStringAsync:(NSString*)string {
    if( !string || [string length] == 0 ) {
        [self refreshUiWithItemsFound:[NSArray array]];
        return;
    }
    
    if( isSearchInProgress ) {
        // IF ONE SEARCH-THREAD IS ALREADY IN PROGRESS DO NOT TRIGGER ANOTHER
        // INSTEAD STORE THE STRING AND REMEMER WE NEED ANOTHER SEARCH
        wantsAnotherSearch = YES;
        self.stringToSearchForWhenCompleted = string;
        return;
    }
    stringToSearchForWhenCompleted = nil;
    // REMEMBER WE HAVE OFFICIALLY HAVE A COMPUTING INTENSIVE
    // ACTION RUNNING ALREADY
    isSearchInProgress = YES;
    
    // USUALLY YOU HAVE SOME DATA SOMEWHERE ALREADY
    // THIS IS JUST DEMO/EXAMPLE DATA HERE...
    NSArray *itemsToSearch = @[@"The",@"quick",@"brown",@"fox",@"jumps",@"over",@"the",@"lazy",@"dog"];
    
    // STEP 0: CREATE YOUR THREADS QUEUE
    //         (THINK PACKAGING FOR YOUR JOB TICKET)
    dispatch_queue_t searchTextQueue;
    searchTextQueue = dispatch_queue_create("myFancySearchTextQueueJobId", DISPATCH_QUEUE_CONCURRENT);

    // CPU-CYCLES MEASURE NANOSECONDS SO WE
    // NEED TO BE VERY PRECISE HERE, D'OH!
    double pauseTimeInMilliseconds = 200.0;
    int64_t pauseTimeInNanoseconds = (int64_t)( pauseTimeInMilliseconds * NSEC_PER_MSEC );
    
    // STEP 1: GIVE SOME TIME TO MAIN THREAD FIRST (!!) I.E. KEYBOARD UI
    dispatch_time_t pauseTime = dispatch_time( DISPATCH_TIME_NOW, pauseTimeInNanoseconds );
    
    // STEP 2: SEND/DISPATCH OUR JOBTICKET TO OUR OWN THREAD QUEUE
    dispatch_after( pauseTime, searchTextQueue, ^(void) {
        NSMutableArray *myItemsFound = [NSMutableArray array];
        for( NSString* currentItem in itemsToSearch ) {
            NSString *stringToSearch = ((YourCustomObjectYouIterateOver*)currentItem).someStringProperty;
            if( [stringToSearch rangeOfString:string options:(NSCaseInsensitiveSearch|NSDiacriticInsensitiveSearch)].location != NSNotFound ) {
                [myItemsFound addObject:currentItem];
            }
            if( wantsAnotherSearch ) {
                // CANCEL SEARCH-FOR-LOOP BECAUSE WE HAVE NEW REQUEST
                break;
            }
        }
        if( !wantsAnotherSearch ) { // SKIP UI REFRESH
            // STEP 3: COMMUNICATE RESULTS TO MAIN THREAD TO UPDATE THE UI
            dispatch_async(dispatch_get_main_queue(), ^{
                [self refreshUiWithItemsFound:myItemsFound];
            });
        }
        // STEP 4: DO SOME CLEANUP AND CHECK IF WE NEED TO
        //         TRIGGER NEXT SEARCH IMMEDIATELY
        isSearchInProgress = NO;
        if( wantsAnotherSearch ) {
            wantsAnotherSearch = NO;
            [self searchForStringAsync:stringToSearchForWhenCompleted];
        }
    });
}

The sample code shows two methods I implemented in my own code of an app that features an instant-search-as-you-type-inputfield. It searches items for some matching string and returns the matching items, then it updates the UI. It works like a charme.

I have bound my searchForStringAsync: to a value-changed-event I got from a UITextField, but you can take any other event you like. Usually each keystroke while typing is ONE SUCH EVENT. So events are coming in quite often while typing. The method refreshUiWithItemsFound: is just an example to update the UI after the result is ready, you can call whatever you like. You could also decide to not refresh the UI immediately at all but instead wait until the results have consolidated (i.e. typing events stopped for some time).

Though this is a pretty fine working approach, it is not perfect yet. You may need to adjust the pauseTimeInMilliseconds-value to achieve good results depending on the amount of processing going on on the MAIN THREAD.

Known issue: Working with objects coming from MAIN THREAD in a different Thread (i.e. OUR CREATED THREAD) is only allowed/recommended read-only. As soon as you start writing/manipulating stuff/objects across threads you need to find ways the BOTH THREADS do not interfere accessing objects concurrently.

CREDITS

I want to thank someone here for the valuable insights I got from his understandable SO-post. Thanks Mathieu!

Have some fun!

And please implement searches this way in the future!

Update & Enhancement on SEP, 8th 2014:

Talking to @arepty (Alexander Repty) and @ortwingentz (Ortwin Gentz) to reassure myself, that I am not talking total rubbish here, I want to add the following thing.

1. Ortwin pointed out that an option to cancel stuff would be valuable. So I added a cancel option to the THREAD CREATED because as soon as another search should be triggered, we do not need to wait until the running search is ready. We solve this with the already existing BOOL-flag wantsAnotherSearch. You cannot easily cancel a YOUR THREAD from outside, but you can check inside the loop if you better should stop useless work going on. An even better solution propagated by Ortwin is to actually monitor typing on the keyboard more closely and wait several milliseconds until we detect some USER-STOPPED-TYPING situation and only THEN start searching. This is e.g. very important if your search requests are very costly e.g. network-search-queries.
2. Alex pointed out that even if you give the MAIN THREAD some time before you start, you have to be aware that we did run our iOS-code in a CPU-Single-Core-Environment for some time, but this time came to an end when the A5 chip was introduced, followed by A6, A7, and soon A8. That means, we only get some kind of „pseudo“-threads to dispense CPU-time in slices a bit better between different jobs going „kinda fake-parallel“ on single cores (read WP-entry for Multitasking and WP-entry for Multithreading). There was no second CPU in your iDevice some time ago which was able to execute the thread, so even running our own CREATED THREAD did not protect us against UI blocking. If we used too much CPU-cycles stuff got BLOCKED/DEGRADED even with threads. BUT since we have Dual-Core-CPUs since the A5 chip, you will need to do a lot of work now to bring current iDevices down. Read more about this in WP-entry about Apple System on a Chip.
3. My conclusion from Alex pointing out the CPU-Single-Core-issue is to make even more PAUSES. So maybe it is a good idea to let our THREAD make PAUSES using dispatch_time in conjunction with dispatch_after every 100 iterations in the search-loop. I think this is a viable option, though your code will then look even more fragmented, d`oh!

Oh, and Oliver Jones aka @orj has also the same thing using NSOperation and NSOperationQueue, so pls give it a try if you dislike this code, but don’t do search without threads anymore, okay?

Ray Wenderlich aka @rwenderlich has another nice piece on Grand Central Dispatch (GCD), too.

Update

Together with Alex I setup a small demo app on github to demonstrate also the use of NSOperation. Have fun with it and make use of it!

Why do I blog this? Because I am angry about all those input-fields I have to use which have UI-blocking searches going on. Even Apple’s own Apps like the AppStore app are annoyingly blocking the UI when doing searches or other things. It’s an awful UXP! People can do nothing but wait until the blocking computing intensive task ended. In the meantime the keyboard is NOT working anymore. I want a lot of people to just copy this code and use it, so I do not need to use crappy search-/input-textfields anymore in the future.