Предотвратить оповещение onFocus Listener после изменения конфигурации? - PullRequest
Новая
       33

Предотвратить оповещение onFocus Listener после изменения конфигурации?

4 голосов
/ 23 марта 2020

Я подключаю слушателя фокуса к EditText во время включения OnCreateView в моем Fragment. Если EditText получает фокус, слушатель получает уведомление. Пока все хорошо, но слушатель снова уведомляется после поворота экрана, когда фокус восстанавливается на новом Fragment. Любая хорошая практика различать guish между уведомлением слушателя из-за изменения конфигурации и из-за реального взаимодействия с человеком? Или чтобы вообще не уведомлять слушателя после изменения фокуса из-за изменения конфигурации?

Ответы [ 3 ]

5 голосов
/ 25 марта 2020

Скорее всего, проблема связана с восстановлением состояния фокуса при onViewStateRestored вызове: https://developer.android.com/reference/android/app/Fragment.html#onViewStateRestored (android .os.Bundle)

Чтобы не слушать это изменить просто вызов setOnFocusChangeListener в onStart вместо onCreateView.

onStart вызывается после onViewStateRestored, поэтому слушатель не получит начальное уведомление.

0 голосов
/ 04 апреля 2020

Нужно использовать onResume(). onStart() вызывается до восстановления представления, поэтому зарегистрированный здесь слушатель сработает.

0 голосов
/ 01 апреля 2020

Есть несколько моментов, которые необходимо прояснить, прежде чем я смогу ответить на вопрос. Давайте сделаем это шаг за шагом:

Если EditText получает фокус, слушатель получает уведомление.

focusListener слушает как получение фокуса, так и его потерю. 

editText.setOnFocusChangeListener { view, hasFocus ->
        if (hasFocus) toast("focus gained") else toast("focus lost")
    }

Используя hasFocus boolean, вы можете решить, что делать с каждым случаем.

слушатель снова получает уведомление после поворота экрана

Получено ли уведомление о получении или потере фокуса?

при восстановлении фокуса на новом фрагменте

Получает ли EditText фокус или теряет фокус после поворота экрана?

Есть ли полезная практика, чтобы различать guish между уведомлением слушателя из-за изменения конфигурации и из-за реального взаимодействия с человеком?

Вы можете попробовать использовать это официальное руководство для сохранения состояния и это для изменения конфигурации . Вы можете сохранить некоторое логическое значение runCodeInListener = false в Bundle. Получить это логическое значение при воссоздании фрагмента или активности. После этого измените код внутри слушателя: 

editText.setOnFocusChangeListener {view, hasFocus ->
  if (runCodeInListener) {
    if (hasFocus) toast("focus gained") else toast("focus lost")
} else {
    runCodeInListener = true
  }
}

После восстановления слушатель не будет запускать код при первом изменении фокуса EditText,

Или ли вообще запретить уведомление слушателя после изменения фокуса из-за изменения конфигурации?

Слушатель вызывается только при изменении фокуса EditText. Если мы предотвратим вышеупомянутое изменение, слушатель не будет уведомлен. Вы предполагаете, что это изменение происходит из-за изменения конфигурации: изменение фокуса из-за изменения конфигурации? Однако есть еще один момент, который необходимо уточнить. Когда этот фрагмент создается впервые, имеет ли EditText фокус? Если это так, то это первый фокусируемый вид в макете, и после изменения конфигурации он снова получает фокус .

Создайте еще один EditText в макете, установите на него нового слушателя и посмотрите если этот также вызывается после поворота экрана. Если мой ответ правильный, слушатель второго EditText не должен получать уведомления, поскольку только первый фокусируемый EditText должен иметь фокус. Чтобы предотвратить фокусировку EditText, вы также можете использовать this или this

Это требует некоторого редактирования, поэтому, если что-то не ясно, пожалуйста, спросите.

...