Ожидание пользовательской реакции на Dialog в Android

[vics001]

По мне, так выглядит как костыль. Понятно, что на самом деле все пишут макаронный код на событийной модели:
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 сообщений.

[anoshenko]

Приложение не может блокировать основной поток более чем на 3 секунды, иначе появляется системный диалог о том что приложение не отвечает.
Это абсолютное незнание платформы. Советую вам больше не писать подобное, пока хорошо не разберетесь.

[anoshenko]

Извините, погорячился. Я вижу что вы запускаете это не в основном потоке.
Поэтому обязательно напишите, что ИЗ ОСНОВНОГО ПОТОКА ВЫЗЫВАТЬ ВАШУ ФУНКЦИЮ processDialogs НЕЛЬЗЯ

[boolivar]

Вы правы.
Eще лучше было бы переделать processDialogs в вид:

private void processDialogs(String... questions) throws ERunOnUiThreadException {
if (isUiThread())
throw new ERunOnUiThreadException();
...
}

[tum0rc0re]

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

[boolivar]

Вы имеете в виду почему неудобна событийная модель работы с диалогами?

[tum0rc0re]

ну вообще неудобен механизм работы с диалогами, ведь просто создаешь id, прописываешь в onCreateDialog и потом shodDialog. все же просто, тем более автоматом нормально работает при изменении конфигурации, ну там поворот экрана например

[boolivar]

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

Речь о том, что используя асинхронный подход неудобно организовывать, например, последовательное отображение диалоговых окон(как в windows когда вы пытаетесь удалить список файлов, среди которого есть файлы только для чтения — на каждый такой файл windows задаст вопрос, точно ли вы хотите его удалить). Здесь, в методе processDialogs() реализован цикл, вся логика работа с диалогами в одном месте.

Используя событийный подход приходится создавать «макаронный код», как выше выразился vics001 и представил пример такого кода. Именно этого я и пытался избежать.

[gshock]

Мне, к примеру, больше нравится своей простотой подход, основанный на callback-ах. При создании диалога передаете в него коллбек, который нужно подергать в обработчиках ивентов диалога. В вызывающей активити создаем объект этого коллбека и его инстанс передаем в диалог. Все. Никаких мьютексов и отдельных потоков.
Я только в «начале пути» но мне такой подход кажется более простым и понятным

[ivanrt]

А теперь расскажите как это все будет себя вести в циклах: onPause(), onResume(); onStop(), onCreate(). Я когда делал диалог выбора действия сделал его в итоге в отдельном Activity.

[tum0rc0re]

вот если делать все через правильное место с помощью стандартного oCreateDialog то нет никаких проблем с life-cycle активити

[boolivar]

Спешу заметить, очень ценное замечание. Этому вопросу стоит уделить особое внимание :-)

[ilichme]

Нет, ну нет же! Неверна сама идея. Колбеки нужно использовать в такой ситуации, и только их. А использование thread.wait() в 99% случаев неоправданно. А уж тем более для главного потока!