Выполнение задач в бэкграунде

[imsamurai]

Об этом уже писали

[Dreddik]

А правда, что кто-то для сетевых соединений запускает сервисы?)

[0leGG]

Кстати, запуск повторяющихся задача можно реализовать, если в Runnable, соответствующий задаче, добавить handler.postDelayed(this, TIMEOUT);

[Olegas]

Это немного другое. Это отложенный запуск а не честный запуск с повтором. Но с помощью этого метода конечно же можно сделать повторение, да.

[dukei]

Если сетевое соединение должно некоторое время поддерживаться даже если пользователь выйдет из приложения (из его UI), то нужен сервис.

[Jecky]

cовсем не обязательно, можно в отдельном потоке, просто уровень приложения поднять и в бекграунде система его не будет убивать часто

[dukei]

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

[kent44]

Например, в моем проекте критично быть онлайн и получать обновления. Информация об обновлениях показывается в области уведомлений. Приложению при этом совсем не нужно быть запущенным.

Для всех сетевых взаимодействий запущен один отдельный поток с блокирующей очередью запросов. Такой подход себя зарекомендовал в нескольких проектах (Android и Java ME).

[hamsterksu]

Парни для этих целей есть IntentService — очередь + отдельный поток выполнения. Сервис автоматом остановится как только не будет тасков.

Для переодичных задач пользуйтес alarm менеджером. Говорите ему что бы кинул вам интент в нужный сервис и выполняете таску.

[kent44]

Спасибо, скажу парням чтобы глянули)

[Jecky]

В 3-м и наверно 4-м андроиде сетевой вызов в UI потоке и не сделаешь — вылетит исключение.

[caezar]

а разве StrictMode не выключен по умолчанию?

[DimICE]

Спасибо за статью!
Как раз гуглил инфу по данной теме, потом зашёл на хабр, а тут свежеиспечённая, готовая к употреблению статья :)

[DimICE]

Кстати, хорошая и простая в использовании библиотека для асинхронных запросов:
loopj.com/android-async-http/

[DieSlogan]

Возможно это дело вкуса, но я очень не люблю эти вложенные классы. В своей задаче у меня несколько сетевых потоков, вызывающих отдельные классы реализующие Runnable и получающих в качестве аргумента конструктора экземпляр Handler. Обмен с потоком осуществляется через Message. Если в общих чертах, это выглядит так:

pastebin.com/s8FsGsEa

[serso]

Разве в 1ом варианте нельзя использовать context#runOnUiThread(Runnable)?

[Archon]

Можно.

[QtRoS]

По мне тоже рациональнее!

[h32]

Спасибо за статью, но вы помимо AsyncTask и Handler забыли упомянуть о методе runOnUiThread(… )

[Kirhgoff]

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

Помучавшись пару вечеров, я сдался и написал вопрос на stackoverflow и мне порекомендовали сделать по человечески. В смысле передавать данные от сервиса к клиенту через Intent и Listener'a.

Сделал, как написал вумный дядя и сразу все прекрасно заработало. Смотреть второй ответ, у которого меньше очков.

[Olegas]

CommonsWare — крутой чел, да.

[danikula]

Для повторяющихся задач Timer не рекомендуют использовать, для этого лучше подходит Handler.
Также можно использовать AlarmManager. Тут пример.

[Olegas]

AlarmManager слишком тяжелый для простых случаев. Он больше подойдут стартовать приложение в указанное время + будить телефон из спячки + держать его не спящим.

[almozavr]

Взгляните на WakefullIntentService — очень красивое решение бекграунд-вопросов. Не спит, выполняется в отдельном потоке, живет ровно столько, сколько нужно на выполнение поставленных в очередь задач.

[rude]

Автор забыл упомянуть о IntentService, который предназначен именно для выполнения задач в бэкграунде

[delph]

А что если в приложении нужно реализовать например счетчик подсчета СМС например через BroadcastReceiver? Если запустить его в Main Activity то в какой то момент андроид может освободить апликацию.

Была мысль сделать его через Service: Main Activity запускает сервис который запускает BroadcastReceiver.
Но почитав тут уже не уверен…

Буду рад услышать ваше мнение.

[Olegas]

А почему бы не объявить Receiver в манифесте? Он не будет зависеть ни от Activity, ни от Service.

[delph]

Написал в приват дабы не расплодить оффтоп :)

[Severovostok]

Сделаем так, чтобы AsyncTask из предыдущего примера выполнялся раз в минуту…

И после Вы привели код выполняющий не AsyncTask.