В моем приложении я использую экземпляры AlertDialog с настраиваемыми представлениями, которые содержат текстовые поля, чтобы позволить пользователю вводить значения в модальном диалоговом окне.
Проблема в том, что, похоже, нет чистой,простой, надежный способ убедиться, что клавиатура всплывает при отображении AlertDialog и снова исчезает при закрытии диалогового окна.
До сих пор я использовал для отображения клавиатуры следующее:
// 'dialog' is the AlertDialog instance
Window window = dialog.getWindow();
if (window != null) {
window.setSoftInputMode(SOFT_INPUT_STATE_VISIBLE);
}
dialog.show();
Это уже немного грязно, но работает последовательно, поэтому я не могу жаловаться.Однако снова спрятать клавиатуру сложно.Для начала у меня есть следующий служебный метод:
public static void hideKeyboard(Activity activity) {
InputMethodManager imm = getIMM(activity);
IBinder windowToken = activity.getWindow().getDecorView().getWindowToken();
imm.hideSoftInputFromWindow(windowToken, HIDE_IMPLICIT_ONLY);
}
Простой вызов этого (с самым верхним действием в качестве аргумента activity
) в функции обратного вызова кнопки моего AlertDialog не работает.Чтобы служебный метод выполнял то, для чего он предназначен, я должен вызывать его после небольшой задержки.
Util.runAfterTimeout(5, () -> Util.hideKeyboard(activity));
(Метод runAfterTimeout
вызывает заданный Runnable в петлителе основного потока с заданным временем ожидания вмиллисекунды.)
В этот момент код действительно начинает вонять.Однако становится все хуже.
С одним из моих вариантов AlertDialog работает тайм-аут в 5 миллисекунд.Это достаточно коротко, чтобы показаться человеку немедленным.
Еще один из моих AlertDialogs нуждается в более высоком тайм-ауте.Кажется, он начинает работать около 100 мс, после чего задержка начинает становиться заметной.
(Возможно, причина в том, что один из диалоговых окон использует свои собственные кнопки ok / cancel в своей пользовательской компоновке, тогда как другой используетsetPositiveButton
и setNegativeButton
. Причины связаны с компоновкой.)
Я не знаю, будут ли эти значения работать на всех устройствах / во всех ситуациях.Что если другой процессор или даже другая нагрузка на тот же процессор заставляет планировщик работать по-разному, и мой хак снова начинает проваливаться?Должен ли я увеличить задержку до 200 мс, чтобы быть в безопасности?Может быть, до 500 мс для очень медленных устройств?(Это очень заметно в тот момент.) Кто знает!
Я не могу представить, чтобы этот сценарий был настолько редким, чтобы оправдывать такие взломы.Я просто хочу показать всплывающее диалоговое окно и позволить пользователю ввести в него некоторые значения.
Кто-нибудь знает чистое решение?Дитч AlertDialog целиком и возможно использовать что-то еще?Или использование DialogFragment, возможно, решит мои проблемы?
Заранее спасибо.