0

I am seeing a very weird UI bug with the ABPeoplePickerNavigationController on iPad (in landscape) where when a user clicks the search bar in the PeoplePicker then subsequently cancels out, the keyboard is not resigned and the UI of the people picker gets all messed up. Here is a photo of the bug:

enter image description here

The ABPeoplePickerNavigationController is presented in a modal form sheet using the following code:

- (void) openAddressBook
{
    ABPeoplePickerNavigationController *picker = [[ABPeoplePickerNavigationController alloc] init];
    picker.peoplePickerDelegate = self;
    picker.delegate = self;
    [picker setModalPresentationStyle: UIModalPresentationFormSheet];
    [self presentViewController:picker animated:YES completion: nil];
}

The UI is as expected until a user taps on the search field, which brings up the keyboard, then cancels out of the search field, which does not resign the keyboard as it does on iPhone. Also, when the user scrolls the contacts list in this mode, all of the letter headers (i.e. the A header) are pinned where the A header is currently, not at the top of the view directly under the search bar.

Is there a reason that the keybaord is not being resigned here?

I am having difficulty debugging this as the ABPeoplePickerNavigationController is not subclassable, so any help would be greatly appreciated!

Glavid
  • 1,071
  • 9
  • 19

2 Answers2

0

That is how UIModalPresentationFormSheet works: by default, it does not dismiss the keyboard when first responder is resigned. Clearly ABPeoplePickerNavigationController is not expecting to be used this way. My suggestion: don't do that. Use a popover or a normal presented view. (My experience is that a popover looks better.)

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • Hmm for asthetic purposes it would be best to present this in a modal form sheet, is there no way to intercept this event and force a resignFirstResonder or something like that? – Glavid Apr 25 '14 at 18:15
  • Read what I said. You _are_ getting `resignFirstResponder`. But with `UIModalPresentationFormSheet`, that doesn't dismiss the keyboard. If that isn't the behavior you want, don't do that. Really, you're just making me repeat myself. – matt Apr 25 '14 at 18:23
  • Fair enough, here is some more info for anyone else that comes across this question: http://stackoverflow.com/questions/3372333/ipad-keyboard-will-not-dismiss-if-modal-viewcontroller-presentation-style-is-uim – Glavid Apr 25 '14 at 18:29
  • Update: The issue (UI bug, not the keyboard dismissal which can seemingly be solved by catagorizing the ABPeooplePickerNavigationController to implement the - (BOOL)disablesAutomaticKeyboardDismissal method) persists when presenting both in a modal popover and by presenting a normal view – Glavid Apr 25 '14 at 19:51
  • Fair enough (so I'm just wrong about the cause), but then we have to explain why you see this and others apparently do not... – matt Apr 25 '14 at 20:59
  • Could you show more of your code? How's your implementation of `peoplePickerNavigationControllerDidCancel:`? – matt Apr 25 '14 at 21:02
  • Also, I notice you are messing with the `autoresizingMask` - how about if you don't do that? I'm just trying to pick out possible oddities in your implementation here. – matt Apr 25 '14 at 21:03
  • Certainly agree about the autoresizingMask, was something I was testing from a different SO post. In terms of the peoplePickerNavigationControllerDidCancel: method, isn't that somewhat irrelevant in this case because that is the cancel delegate method called from the ABPeoplePickerNavigationController, not the nav controllers child view controller in which the search bar is implemented? I should have noted earlier (apologies here) though that the [self presentViewController: picker animated:] code is being called from a MyNavigationControllerClass child view controller MyViewController.. – Glavid Apr 25 '14 at 21:56
0

use [self.view endEditing:YES]; when you are done

Tanuj Jagoori
  • 309
  • 3
  • 9