UIWindow endDisablingInterfaceAutorotationAnimated error появляется в консоли, когда клавиатура отклоняется интерактивно из collectionView только в iOS9

Я получаю эту странную ошибку только в iOS9:

[UIWindow endDisablingInterfaceAutorotationAnimated:] called on UITextEffectsWindow: ...without matching
-beginDisablingInterfaceAutorotation. Ignoring.

в любое время я отключаю клавиатуру в интерактивном режиме, перетаскивая ее изнутри моего коллектора. Я не получаю ошибку, отклоняя клавиатуру жестом нажатия или нажатием клавиши ввода. Это очень расстраивает. Даже если я не наблюдаю никаких уведомлений о клавиатуре, я все равно получаю эту ошибку при отклонении этой интерактивной клавиатуры. Интересно, встретил ли кто-нибудь еще эту ошибку и нашел решение. У меня есть inputAccessoryView, состоящий из textView, установленного на клавиатуре.

Ответ 1

У меня была такая же проблема на iOS9, но с tableView. Я реализовал этот вместе с self.tableView.keyboardDismissMode = .Interactive, и это сработало для меня.

// Dismiss keyboard when scrolling
func scrollViewWillBeginDragging(scrollView: UIScrollView) {
    textView.resignFirstResponder()
}

Ответ 2

Что нужно проверить

Похоже, что несколько других пользователей SO имели аналогичный опыт в различных условиях. Проверьте поток. Поскольку может произойти много событий, которые вызывают эту проблему, вам может потребоваться просмотреть поток, предоставленный, чтобы увидеть, можно ли найти подходящий прецедент. Неясно, как вы отклоняете клавиатуру, но вы можете назвать что-то вроде этого методом или признаком распознавания жестов (а не прямым увольнением с определенного объекта):

UIApplication.sharedApplication().sendAction("resignFirstResponder", to: nil, from: nil, forEvent: nil)

Из предоставленного потока характер проблемы в большинстве случаев был дублирующим вызовом во время презентации или увольнения представления. Я также видел проблемы, связанные с подключением раскадровки segue (или в некоторых случаях она была удалена, но xml все еще находился в представлении кода раскадровки) и с помощью кода (seGue) (performSegueWithIdentifier...) для той же анимации (которая вызывает два вызова отображения/увольнения).

Я бы посмотрел журнал, чтобы узнать, какие вызовы регистрируются непосредственно перед ошибкой, а затем найдите в окне журнала, чтобы увидеть, есть ли избыточный вызов. Опять же, может быть избыточность в поведении/анимации/макетах на раскадровке и звонках, сделанных в коде.

UPDATE

Комментарии OP, напомнили мне, что в некоторых случаях, особенно в тех случаях, когда речь идет о вызовах во время презентаций/увольнений, я видел примеры, когда единственный способ успешно выполнить работу с разработчиками - это связать его с вызовом dispatch_async. Есть некоторые критические системные вызовы, которые кажутся неработоспособными, если код разработчика вводится во время одних и тех же фреймов.

Конкретным примером является этот вызов, который находится в пределах willMoveToWindow. В этом случае у меня есть ссылка weakSelf на представление и просто просматривайте значение newWindow для nil (указывает, что представление отклоняется) перед вызовом моего кода.

Итак, в этом примере, если удалять диспетчерский вызов, код разработчика приведет к сбою всего приложения. Я предполагаю, что вызовы системного перехода (связанные с транспонированием в/из окна) могут противоречить тем запросам разработчиков, которые были в то время.

 dispatch_async(dispatch_get_main_queue(), { () -> Void in

     //the saved flag is true only when user hits the done button
     if !(weakSelf!.saved) {
         weakSelf?.completeNotes(nil)
     }

 })

Ответ 3

Я столкнулся с этой проблемой, и это испортило мое мнение. Вот как я его решаю.

Я имел viewController, который был представлен на textFieldShouldBeginEditing. В viewController a textField было установлено becomeFirstResponder в viewDidLoad.

Решение для меня - переместить becomeFirstResponder в viewDidAppear.