2013-03-25 2 views
0

Я обнаружил, что AsyncTask и TimerTask не ведут себя одинаково в разных версиях API.Реализация TimerTask и AsyncTask по API

Здесь мои настройки: ТаймерTare установлен в огонь каждый раз. Существует служба, метод которой вызывается при срабатывании TimerTask. Этот метод создает экземпляр AsyncTask для некоторой фоновой обработки. Обратите внимание, что AsyncTask не касается пользовательского интерфейса.

Все вышеперечисленное отлично на Android API 16 и 17 работает, но не работает на более низких API, на уровне со стандартом «Невозможно создать обработчик ... Looper.prepare) (» ошибка, например, как описано здесь Start AsyncTask in TimerTask

Я обошел это, изменив мою AsyncTask на Runnable, а затем начал новый поток в методе службы вручную. Однако интересно, что изменилось в API с версии 16? Является ли Looper.prepare() фактически вызванным в потоке TimerTask сейчас? Если это так, есть простой способ реализовать то же самое в моем коде, чтобы я мог продолжать использовать TimerTask (решение Runnable не оптимально во многих отношениях, так как я могу решить обновить интерфейс от AsyncTask позже).

Спасибо,

Veljko

+0

http://developer.android.com/reference/android/os/AsyncTask.html – Raghunandan

ответ

0

Проблема может заключаться в том, что вы не создаете первый AsyncTask в потоке пользовательского интерфейса, который повлияет на все созданные AsyncTasks. Взгляните на этот вопрос - onPostExecute not being called in AsyncTask (Handler runtime exception)

Работа вокруг - загрузить AsyncTask из класса Application.

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

Задача Async всегда необходима, если вам нужно сделать обновления пользовательского интерфейса. Это то, что для операций pre/post для класса. Использование Runnable отлично, если нет обновлений пользовательского интерфейса. Просто убедитесь, что Runnables не зависают после завершения обработки.

Вы можете использовать сигналы тревоги, такие как @ Atrix1987, но я использую их только каждый раз, когда время планирования превышает 15 минут (что может по-прежнему сохраняться для вас). Я объяснил причину этого в другом вопросе - Scheduling recurring task in Android.

+0

Благодаря Deepak я следил за предложениями и добавил «Class.forName» («android.os.AsyncTask»); в классе Application. Теперь он ведет себя одинаково в каждой версии API. Я также соглашаюсь с комментарием AlarmManager. –

0

Я хотел бы предложить, используя Alarm Service для планирования действий и Intent Service для их завершения. Поскольку вам не нужно прикасаться к пользовательскому интерфейсу, это упрощает работу.

Смежные вопросы