Заметки о ProgressDialog или как правильно показать прогресс выполнения

[dzigoro]

Хорошая статья, спасибо.
Единственное, я бы отметил, что код решений номер 2 и 4 надо запускать из Activity, а вот номер 3 — из Service.

Ну и да, Main.class — имя ни о чем не говорит. Activity это или Service — не понятно)

[NevRA]

В примерах Main везде одинаковый, т.е. всегда запускается из Activity.

[Hoorsh]

Расскажите, если знаете как сделать анимированный Progress в виджете :)

[w32blaster]

Присоединяюсь. Я тоже сделал анимированный прелоадер в виджете, а он не анимированный :( Гуглил много, так пришёл к выводу, что в виджете вообще не поддерживается никакая анимация. Кто-то может что-то сказать и посоветовать по этому поводу?

[w32blaster]

«то можно увидеть прогрессы выполнения текущих тасок.»
Тасков, наверно?

И да, статья приятная к прочтению. Совсем недавно задумывался на эту тему, тоже пришёл к тем же мыслям.

[NevRA]

Да, исправил.

[Fury]

Вывод довольно логичный :)
Действительно, каждый вид диалогов подходит для своего круга задач.
Сам использую 0й вариант для блокирующих операций (логин, операции с деньгами) и 4 для остальных. Когда придётся работать с большими объёмами, то, думаю, воспользуюсь 3м вариантом.

Кстати про проблему 4го варианта:

3. Подобное решение подходит только для title'ов со стандартным набором стилей. Т.е. на Activity внутри TabHost его приделать не получится.

У меня все активити наследуются от базовой AbstractActivity, в которой все основные методы. А для тех активити, который могут запускаться внутри табов, есть ещё AbstractTabbedActivity, которая наследуется от AbstractActivity и как раз таки получает доступ к прогрессбару (да и вообще всему, что расположено в title) через родительскую активити — получается, что для конечной активити вообще неважно, в табе она запустилась или нет.

[NevRA]

Спасибо за информацию, не знал.

[Fury]

Да не за что. Я сам потратил довольно много времени, пытаясь решить проблему доступа из активити внутри TabHost к экшенбару, который находится снаружи TabHost'а, прежде, чем узнал про метод getParent(). Даже была мысль в Intent каждой активити в табах положить в экстра сам экшенбар :) Но это невозможно, так как View не Serializable и не Parcelable.

[caezar]

4е решение можно реализовать значительно проще, так как это «стандартная возможность»
сначала
requestWindowFeature(Window.FEATURE_INDETERMINATE_PROGRESS);
потом
setProgressBarIndeterminateVisibility(true);
setProgressBarIndeterminateVisibility(false);

[caezar]

Ну или FEATURE_PROGRESS для детерминированного прогресса
P.S. очень полезный документ developer.android.com/resources/faq/commontasks.html

[NevRA]

Да, вы правы, но я хотел показать общей случай, т.к. на пользовательском layout'е мог находиться не только ProgressBar, а и любые другие виджеты. Т.е. из приведенного примера можно понять, что в title может находится произвольное содержимое (т.к. указываем пользовательский layout). Но если нужно добавить только Progress тогда ваш пример самое то.

[caezar]

Стоит добавить в статью, а то побегут копипастить сложное не зная о существовании простого ;)

[NevRA]

:) Добавил

[Alexx_ps]

Мне кажется или в любом решении минусов больше, чем плюсов? В 3-м усложнение логики работы можно считать за 2 минуса.

[NevRA]

Усложнение логики работы есть во всех решениях кроме нулевого. ) Логика имелась в виде программная, про это написано в решении №1.
В зависимости от задачи вес минуса не будет равен весу плюса, т.е. если, например, вы хотите написать крайне дружелюбное приложение вам может быть все равно насколько там, что усложнилось и один плюс перекроет все минусы.