Несовместимость ответчика текстового поля iOS4 -> iOS 5

Любопытная проблема:

Два поля UITextField, управляемые одним контроллером, поддерживают ввод с клавиатуры. Если ввести значение в поле № 1 и нажать «Далее» в базе знаний, мигающий курсор просто переместится в поле № 2, и все в порядке. Но (только в iOS 5), если кто-то касается поля №2 вместо нажатия кнопки «Далее», курсор переходит к полю №2, но не мигает, и база знаний не работает.

Пройдясь по коду, я обнаружил, что в первом случае последовательность такова:

  • textFieldShouldReturn:field#1 (которое увольняет первого ответчика для #1)
  • textFieldDidEndEditing:field#1 (которое увольняет для #1 и становится для #2)
  • textFieldShouldBeginEditing:поле#2

Во втором случае (при касании поля вместо использования «Далее») последовательность следующая:

  • textFieldShouldBeginEditing:поле#2
  • textFieldDidEndEditing:поле#1
  • textFieldShouldBeginEditing:field#2 (снова)
  • textFieldDidEndEditing:field#2 (которое отменяет ОБА №1 и №2)

Очевидно, что когда отставка для #2 завершена, это убивает KB, но ПОЧЕМУ iOS 5 вызывает DidEndEditing с полем #2??? И как можно было обойти это?

Обновлять

Добавлен хук для textFieldShouldEndEditing. Он вызывается перед textFieldDidEndEditing для поля №1, но не перед textFieldDidEndEditing для поля №1. Хотя, что любопытно, textFieldShouldBeginEditing вызывается непосредственно перед textFieldDidEndEditing для поля №2. Пахнет явной ошибкой дублирования в коде iOS.

Обновление 2

iOS 5 не обрабатывает вызовы resign/become из testFieldDidEndEditing. См. ниже для обхода.


person Hot Licks    schedule 28.11.2011    source источник


Ответы (1)


Я пришел к выводу, что iOS 5 не (правильно) обрабатывает случай наличия вызовов resignFirstResponder/becomeFirstResponder внутри textFieldDidEndEditing. Переместил логику (более или менее) на textFieldShouldReturn (сенсорный вид сам о себе позаботится), и теперь вроде работает нормально.

person Hot Licks    schedule 28.11.2011