Комментарии 13
По мне, так выглядит как костыль. Понятно, что на самом деле все пишут макаронный код на событийной модели:
Но он хотя бы стандартен и все к нему привыкли. А тут Mutex новый поток, вообще лучше с потоками дело без надобности не иметь, а тем более wait()/notify(). Вдруг exception? Вдруг IllegalMonitorException.
Тем более что в Android для асинхронности вы использовали замечательный класс AsyncTask.
А вообще в SWT был такой замечательный метод:
Dialog a = new Dialog();
a.waitResultSyncrhonously();
…
Но что он там делал лучше было не смотреть :) в этом методе стартовал еще один цикл while обработки UI event так, как поток не менялся он оставался UI, зато менялся обработчик очередь UI сообщений.
a() {
Dialog a = new Dialog();
a.setOnYes(b());
a.setOnNo(bNo());
}
b() {
Dialog b = new Dialog();
b.setOnYes(c());
b.setOnNo(cNo());
}
....
Но он хотя бы стандартен и все к нему привыкли. А тут Mutex новый поток, вообще лучше с потоками дело без надобности не иметь, а тем более wait()/notify(). Вдруг exception? Вдруг IllegalMonitorException.
Тем более что в Android для асинхронности вы использовали замечательный класс AsyncTask.
А вообще в SWT был такой замечательный метод:
Dialog a = new Dialog();
a.waitResultSyncrhonously();
…
Но что он там делал лучше было не смотреть :) в этом методе стартовал еще один цикл while обработки UI event так, как поток не менялся он оставался UI, зато менялся обработчик очередь UI сообщений.
Приложение не может блокировать основной поток более чем на 3 секунды, иначе появляется системный диалог о том что приложение не отвечает.
Это абсолютное незнание платформы. Советую вам больше не писать подобное, пока хорошо не разберетесь.
Это абсолютное незнание платформы. Советую вам больше не писать подобное, пока хорошо не разберетесь.
А можете пояснить почему не используется стандартный функционал работы с диалогами? По мне он очень удобен, почему он для вас неудобен?
Вы имеете в виду почему неудобна событийная модель работы с диалогами?
Я попытался сформулировать чем он мне неудобен в последнем абзаце своей статьи. Моя статья не о том как правильно работать с диалогами в Android, не панацея, нет. Она всего лишь о том, как сделать ожидание реакции пользователя на диалог. Событийная работа с диалогами имеет место быть, это основной механизм работы с ними, его предлагает Android. И в своих проектах я нередко использую этот механизм.
Речь о том, что используя асинхронный подход неудобно организовывать, например, последовательное отображение диалоговых окон(как в windows когда вы пытаетесь удалить список файлов, среди которого есть файлы только для чтения — на каждый такой файл windows задаст вопрос, точно ли вы хотите его удалить). Здесь, в методе processDialogs() реализован цикл, вся логика работа с диалогами в одном месте.
Используя событийный подход приходится создавать «макаронный код», как выше выразился vics001 и представил пример такого кода. Именно этого я и пытался избежать.
Речь о том, что используя асинхронный подход неудобно организовывать, например, последовательное отображение диалоговых окон(как в windows когда вы пытаетесь удалить список файлов, среди которого есть файлы только для чтения — на каждый такой файл windows задаст вопрос, точно ли вы хотите его удалить). Здесь, в методе processDialogs() реализован цикл, вся логика работа с диалогами в одном месте.
Используя событийный подход приходится создавать «макаронный код», как выше выразился vics001 и представил пример такого кода. Именно этого я и пытался избежать.
Мне, к примеру, больше нравится своей простотой подход, основанный на callback-ах. При создании диалога передаете в него коллбек, который нужно подергать в обработчиках ивентов диалога. В вызывающей активити создаем объект этого коллбека и его инстанс передаем в диалог. Все. Никаких мьютексов и отдельных потоков.
Я только в «начале пути» но мне такой подход кажется более простым и понятным
Я только в «начале пути» но мне такой подход кажется более простым и понятным
А теперь расскажите как это все будет себя вести в циклах: onPause(), onResume(); onStop(), onCreate(). Я когда делал диалог выбора действия сделал его в итоге в отдельном Activity.
Нет, ну нет же! Неверна сама идея. Колбеки нужно использовать в такой ситуации, и только их. А использование thread.wait() в 99% случаев неоправданно. А уж тем более для главного потока!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Ожидание пользовательской реакции на Dialog в Android