![\"caution_rant_450\"](\"\/wp-upload\/caution_rant_450.png\")
<\/center>\nDoing 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.<\/p>\n
Totally unrelated by @mattetti<\/a>:<\/strong> 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.<\/p>\n There are thousands of examples of this kind of behaviour but the worst thing at all is that these INSTANT-SEARCH-AS-YOU-TYPE<\/strong> 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.<\/p>\n 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“<\/strong>):<\/p>\n 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<\/strong><\/a> explaining how to avoid blocking the keyboard while you do searches.<\/p>\n Step 1:<\/strong> 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!!!<\/p>\n 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.<\/p>\n Step 3:<\/strong> 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.<\/p>\n 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<\/strong>, where all the thread-related magic happens.<\/p>\n 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.<\/p>\n I have bound my Though this is a pretty fine working approach, it is not perfect yet. You may need to adjust the Known issue:<\/strong> 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.<\/p>\n I want to thank someone here for the valuable insights I got from his understandable SO-post. Thanks Mathieu!<\/p>\n And please implement searches this way in the future!<\/em><\/p>\n Talking to @arepty (Alexander Repty)<\/a> and @ortwingentz (Ortwin Gentz)<\/a> to reassure myself, that I am not talking total rubbish here, I want to add the following thing.<\/p>\n Oh, and Oliver Jones<\/strong> aka @orj<\/a> has also the same thing<\/a> using NSOperation<\/strong> and NSOperationQueue<\/strong>, so pls give it a try if you dislike this code, but don’t do search without threads anymore, okay?<\/p>\n Ray Wenderlich<\/strong> aka @rwenderlich<\/a> has another nice piece<\/a> on Grand Central Dispatch (GCD)<\/strong>, too.<\/p>\n Together with Alex I setup a small demo app on github<\/strong><\/a> to demonstrate also the use of NSOperation. Have fun with it and make use of it!<\/p>\n Why do I blog this?<\/strong> 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.<\/small><\/p>\n","protected":false},"excerpt":{"rendered":" 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 … \u201eNon-Blocking NSString-search using e.g. UITextField & UISearchViewController\u201c <\/span>weiterlesen<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[88,67,59,4],"tags":[],"class_list":["post-4130","post","type-post","status-publish","format-standard","hentry","category-coding","category-english","category-iphone","category-learning"],"_links":{"self":[{"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=\/wp\/v2\/posts\/4130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4130"}],"version-history":[{"count":0,"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=\/wp\/v2\/posts\/4130\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thetawelle.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n![\"tweet_mattetti\"](\"\/wp-upload\/tweet_mattetti.png\")
<\/p>\nYou need to know 3 things<\/h3>\n
\n
\nNearly 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.<\/code><\/li>\n
\nThe 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.<\/code><\/li>\n
\nThe 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.<\/code><\/li>\n<\/ol>\n![\"make_it_3d\"](\"\/wp-upload\/make_it_3d.png\")
Step 2:<\/strong> 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. <\/p>\nSample Code that works!<\/h3>\n
\r\n\/* YourViewController.h *\/\r\n@interface YourViewController : UIViewController <UITextFieldDelegate> {\r\n\r\n BOOL isSearchInProgress;\r\n BOOL wantsAnotherSearch;\r\n NSString *stringToSearchForWhenCompleted;\r\n}\r\n\r\n@property ( nonatomic, assign ) BOOL isSearchInProgress;\r\n@property ( nonatomic, assign ) BOOL wantsAnotherSearch;\r\n@property ( nonatomic, retain ) NSString *stringToSearchForWhenCompleted;\r\n\r\n@end\r\n\r\n\/* YourViewController.m *\/\r\n@implementation YourViewController\r\n\r\n\/\/ SOME STATUS VARIABLES WE NEED TO SYNTHESIZE\r\n@synthesize isSearchInProgress;\r\n@synthesize wantsAnotherSearch;\r\n@synthesize stringToSearchForWhenCompleted;\r\n\r\n- (void) refreshUiWithItemsFound:(NSArray*)itemsFound {\r\n \/\/ UPDATE YOUR UI HERE!\r\n}\r\n\r\n- (void) searchForStringAsync:(NSString*)string {\r\n if( !string || [string length] == 0 ) {\r\n [self refreshUiWithItemsFound:[NSArray array]];\r\n return;\r\n }\r\n \r\n if( isSearchInProgress ) {\r\n \/\/ IF ONE SEARCH-THREAD IS ALREADY IN PROGRESS DO NOT TRIGGER ANOTHER\r\n \/\/ INSTEAD STORE THE STRING AND REMEMER WE NEED ANOTHER SEARCH\r\n wantsAnotherSearch = YES;\r\n self.stringToSearchForWhenCompleted = string;\r\n return;\r\n }\r\n stringToSearchForWhenCompleted = nil;\r\n \/\/ REMEMBER WE HAVE OFFICIALLY HAVE A COMPUTING INTENSIVE\r\n \/\/ ACTION RUNNING ALREADY\r\n isSearchInProgress = YES;\r\n \r\n \/\/ USUALLY YOU HAVE SOME DATA SOMEWHERE ALREADY\r\n \/\/ THIS IS JUST DEMO\/EXAMPLE DATA HERE...\r\n NSArray *itemsToSearch = @[@"The",@"quick",@"brown",@"fox",@"jumps",@"over",@"the",@"lazy",@"dog"];\r\n \r\n \/\/ STEP 0: CREATE YOUR THREADS QUEUE\r\n \/\/ (THINK PACKAGING FOR YOUR JOB TICKET)\r\n dispatch_queue_t searchTextQueue;\r\n searchTextQueue = dispatch_queue_create("myFancySearchTextQueueJobId", DISPATCH_QUEUE_CONCURRENT);\r\n\r\n \/\/ CPU-CYCLES MEASURE NANOSECONDS SO WE\r\n \/\/ NEED TO BE VERY PRECISE HERE, D'OH!\r\n double pauseTimeInMilliseconds = 200.0;\r\n int64_t pauseTimeInNanoseconds = (int64_t)( pauseTimeInMilliseconds * NSEC_PER_MSEC );\r\n \r\n \/\/ STEP 1: GIVE SOME TIME TO MAIN THREAD FIRST (!!) I.E. KEYBOARD UI\r\n dispatch_time_t pauseTime = dispatch_time( DISPATCH_TIME_NOW, pauseTimeInNanoseconds );\r\n \r\n \/\/ STEP 2: SEND\/DISPATCH OUR JOBTICKET TO OUR OWN THREAD QUEUE\r\n dispatch_after( pauseTime, searchTextQueue, ^(void) {\r\n NSMutableArray *myItemsFound = [NSMutableArray array];\r\n for( NSString* currentItem in itemsToSearch ) {\r\n NSString *stringToSearch = ((YourCustomObjectYouIterateOver*)currentItem).someStringProperty;\r\n if( [stringToSearch rangeOfString:string options:(NSCaseInsensitiveSearch|NSDiacriticInsensitiveSearch)].location != NSNotFound ) {\r\n [myItemsFound addObject:currentItem];\r\n }\r\n if( wantsAnotherSearch ) {\r\n \/\/ CANCEL SEARCH-FOR-LOOP BECAUSE WE HAVE NEW REQUEST\r\n break;\r\n }\r\n }\r\n if( !wantsAnotherSearch ) { \/\/ SKIP UI REFRESH\r\n \/\/ STEP 3: COMMUNICATE RESULTS TO MAIN THREAD TO UPDATE THE UI\r\n dispatch_async(dispatch_get_main_queue(), ^{\r\n [self refreshUiWithItemsFound:myItemsFound];\r\n });\r\n }\r\n \/\/ STEP 4: DO SOME CLEANUP AND CHECK IF WE NEED TO\r\n \/\/ TRIGGER NEXT SEARCH IMMEDIATELY\r\n isSearchInProgress = NO;\r\n if( wantsAnotherSearch ) {\r\n wantsAnotherSearch = NO;\r\n [self searchForStringAsync:stringToSearchForWhenCompleted];\r\n }\r\n });\r\n}\r\n<\/pre>\nsearchForStringAsync:<\/code> 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:<\/code> 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).<\/p>\npauseTimeInMilliseconds<\/code>-value to achieve good results depending on the amount of processing going on on the MAIN THREAD.<\/p>\nCREDITS<\/h3>\n
![\"thank_you_250\"](\"\/wp-upload\/thank_you_250.png\")
<\/center>
A huge thank you to Matt D’Amours <\/a> (other website<\/a>, github<\/a>) from Canada for his excellent explanation<\/a> on StackOverflow, which made me learn the PAUSE-Feature<\/strong> of threads.<\/div>\nHave some fun!<\/h3>\n
Update & Enhancement on SEP, 8th 2014:<\/h3>\n
\n
wantsAnotherSearch<\/code>. 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.<\/li>\ndispatch_time<\/code> in conjunction with dispatch_after<\/code> 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!<\/li>\n<\/ol>\nUpdate<\/h3>\n