UITableView rejects keyboard on reloadData in one place but not another?

I am sifting through pre-existing code from a new assignment I just started and one of the first errors I encountered is a search bar attached to a subclass UITableView

that discards the keyboard after every key press. After some searching I found this SO question and I seem to have found my answer: the app used reloadData

to update the results after every key press and that reload was causing resignFirstResponder

and rejecting the keyboard. Disappointing, but explanation and understanding.

But then my boss pointed out that we are using almost the same code elsewhere in the application, and it works great. How could this be? I'm in an unusual situation where I need to explain why something is working, as the link provided indicates that deflecting the keyboard during time reloadData

is "normal" behavior.

Following are the corresponding methods from two ViewControllers, each subclassed from the same custom one UITableView

. (The methods have been simplified, but the different behavior remains.) Part of me thinks it should be somewhat similar to the difference between the two subclasses, but if it reloadData

is a problem and it is not overridden anywhere, does that mean that subclasses are irrelevant?


- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText{
    [self.tableView reloadData];
    NSLog(@"Lookup Reloaded");



- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText{
    [self.tableView reloadData];
    NSLog(@"Search Reloaded");


As you can see, they are identical. They both get called successfully after every key press, and yet the first fires the keyboard and the second doesn't.

Each of these view controllers are over a thousand lines long, so I'm having a hard time narrowing down what might cause the different behavior. Can someone who understands FirstResponders reloading and TableView reloading help me a little bit about where to look? It looks like a pretty straightforward process (key pressed> the method is called> it reloads the table> the keyboard is rejected in the process) without having a lot of room to change this behavior, but obviously there is a way to prevent this last step because Search View already does this is.

Any idea where I should focus my search to figure out why?


source to share

3 answers

So the answer turned out to be too confusing and application-specific to look at in detail, but mainly due to the quirky and hacky method of implementation, there were several custom work-related objects UISearchBar

that were located inside the cell of the first row (section 0, line 0) UITableView


When rebooted UITableView

, that first line was redone, which meant these objects were redone, which dropped the keyboard. When I asked my new boss why they did it, he couldn't remember.




Check if this method has been implemented on any of the delegates for this UISearchBar.

- (BOOL)searchBarShouldEndEditing:(UISearchBar *)searchBar;


If this method returns NO, it will prevent the search string from being cut off from the first responder.



Maybe try subclassing UISearchBar

and overriding - (BOOL)resignFirstResponder

. Use your subclass instead UISearchBar

and put a breakpoint in this method and you can see where it is being called from?



All Articles