views:

49

answers:

2

Normally we use the resignFirstResponder to hide the keyboard in the iphone apps. For example, when we use a UISearchBar, after the user click the search button, we hide the keyboard by implement the searchBarSearchButtonClicked function like this:

 -(void)searchBarSearchButtonClicked:(UISearchBar*)searchBar{   
        NSLog(@"Search Button Click, result should be show here"); 
        [searchBar setShowsCancelButton:NO animated:YES];
       [searchBar resignFirstResponder];    
        self.dictTableView.allowsSelection = YES;   
        self.dictTableView.scrollEnabled = YES;     
}

We set the searchBar as the first responder, then the keyboard will be hidden after the user click the search button.

Why it works like this? We didn't call any function that hide the keyboard, we just set the searchBar as the first responder, why the system just hide the keyboard automatically?

Could anyone explain the mechanism of this process?

Thank you very much!

A: 

The "first responder" is the UI object that's currently accepting events (keyboard or touch events). Objects that expect keyboard input (like a search bar) will cause the keyboard to appear when they become first responder.

When you tell the searchbar to stop being "first responder" ([searchBar resignFirstResponder]), the keyboard is no longer needed and goes away.

David Gelhar
Cool. What you're saying is that when the search bar become the first responder, the search bar will automatically call the show keyboard function, and when the search bar is deactivated, it will automatically call the hide keyboard function. Is it correct? So, say I have another object which is a button, if I set that button as a first responder, the keyboard will also be hidden, right?
Kevin Wu
+2  A: 

Objective-C works by sending messages to objects in the form of selectors which are names of methods belonging to the targeted object. A "responder" is an object that will respond to a message sent in by a UI event.

Responders live in an hierarchy called the responder chain. If a responder cannot understand a UI message it forwards it to the next responder in the chain all the way up to the application object itself.

In the case of a text field, tapping the field causes the field to become the first responder such that it intercepts all subsequent UI events. A text field traps UI events with the keyboard so it automatically evokes the keyboard. A text field has no interest in any input not associated with the keyboard so when it resigns as first responder, it puts the keyboard away.

This is the beauty of a highly-object oriented API. You don't have to micromanage standard behaviors. The objects themselves handle it for you. If your used to working with a more procedural API it might be a little disorienting.

(As an aside, this is old hat these days but it was fan-fricken-tastic back in the early 90s when Objective-C and NextStep were ground breaking technologies. Tim Burners-Lee invented the web browser just so he would have an excuse to buy a Next cube.)

TechZen
+1 Responder Chain documentation: http://developer.apple.com/library/ios/documentation/cocoa/Conceptual/CocoaFundamentals/CoreAppArchitecture/CoreAppArchitecture.html#//apple_ref/doc/uid/TP40002974-CH8-SW17
Dave DeLong
Thank you very much for your explanation! It helps a lot! Now I can understand the "responder" stuffs better.
Kevin Wu