6

I'm sifting through pre-existing code from a new job I just started, and one of the first bugs I'm being confronted with is a search bar attached to a UITableView subclass, which is dismissing the keyboard after every keystroke. After some searching I found this SO question, and it seemed I'd found my answer: the app was using reloadData to refresh the results after every keystroke, and that reload was calling resignFirstResponder and dismissing the keyboard. Frustrating, but explained and understood.

But then my boss pointed out that we use almost the exact same code elsewhere in the app, and it works perfectly. How could that be? I find myself in the unusual position of needing to explain why something DOES work, since the above link would indicate that dismissing the keyboard during reloadData is the "normal" behavior.

Below are the relevant methods from the two ViewControllers, each of which is subclassed from the same custom UITableView. (The methods have been simplified, but the differing behavior remains.) A part of me thinks that it must be something buried in difference between the two subclasses, but then if reloadData is the problem and it isn't being overridden anywhere, doesn't that mean the subclasses are irrelevant?

Lookup View: 

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

Search View:

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

As you can see, they are identical. Both are successfully called after each keystroke, and yet the former dismisses the keyboard and the latter does not.

Each of these View Controllers is over a thousand lines long, so I'm having a hard time narrowing down what might be causing the differing behavior. Can someone who understands FirstResponders and TableView reloads help give me some leads on where to look? It seems like a fairly simple process (a key is pressed > the method is called > it reloads the table > keyboard is dismissed in the process) without much room to alter that behavior, but obviously there is a way to prevent that final step because the Search View is already doing it.

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

Community
  • 1
  • 1
Nerrolken
  • 1,975
  • 3
  • 24
  • 53

3 Answers3

3

Check to see if this method has been implemented on either of the delegates for this UISearchBar.

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

If this method returns NO, it will prevent the search bar from resigning the first responder.

dfmuir
  • 2,048
  • 1
  • 17
  • 14
3

So, the answer turned out to be too convoluted and app-specific to be worth walking through in detail, but basically due to a bizarre and hack-y method of implementation, there were several custom objects related to the workings of the UISearchBar that were located within the cell of the first row (section 0, row 0) of the UITableView.

When the UITableView was reloaded, that first row got re-made, which meant that those objects got re-made, which dismissed the keyboard. When I asked my new boss why they'd done it like this, he couldn't remember.

Oof.

Nerrolken
  • 1,975
  • 3
  • 24
  • 53
  • As an idea we can try to reload UITableView section which will not container UITextField / UISearchBar object instead of whole cell – Pavel Vavilov Oct 25 '18 at 12:07
2

Maybe try subclassing UISearchBar and overriding - (BOOL)resignFirstResponder. Use your subclass instead of UISearchBar and put a breakpoint within that method and you can see where it is being called from?

davbryn
  • 7,156
  • 2
  • 24
  • 47
  • I'll give that a try, but would that explain why it works in one place and not another? I can't shake the feeling that the answer is right in front of me, I just can't put my finger on it. – Nerrolken Oct 07 '14 at 17:12
  • If you use the subclass in both places and then compare the stack traces it will hopefully become apparent - I've not seen this happen myself unfortunately – davbryn Oct 07 '14 at 17:32
  • This wasn't the answer, but I ended up finding the answer while investigating this one. So here, have a bounty! :D I've added the final cause as an answer of my own, in case anyone else encounters a situation as bizarre as this. – Nerrolken Oct 13 '14 at 16:20