Страницы

Поиск по вопросам

четверг, 6 июня 2019 г.

Service или asynctask

Здравствуйте. Нужен совет. У меня в приложении регулярно нужно получать данные с сервера. И я думаю как это сделать более рационально по ресурсам и по производительности. Сейчас используется вариант, я получаю асинктаском данные с сервера загоняю их в hashMap и с ними потом работаю. Второй способ: создать сервис который будет с сервера загонять данные в базу sqlite, а потом уже с этой базой работать. Какой способ более правильный по ресурсам, быстродействию?(если надо приведу исходники) Подробнее теперь. В базе на сервере будет где-то сотни записей, по 20 атрибутов каждая запись. и каждые секунд 10 нужно будет делать такой запрос на получение всех полей и всех атрибутов в виде json массива (почти все эти значения могут изменяться, поэтому приходится постоянно подгружать все). Потом этот массив я перевожу в удобный для меня HashMap и пользуюсь им как мне угодно. Я так подумал: сервис скорее всего толще чем асинктаск, да и обращение к базе будет медленнее чем напрямую к hashMap, поэтому наверно пока оставлю асинктаски. хотя я видел довольно похожее приложение как у меня и там было реализовано сервисом. Маркеры на карте появлялись постепенно, при этом карта была активна. При асинктаске, нужно ждать пока выполнится задание. Но я не думаю, что это плюс. Например, если зайти в то приложение, то карта пустая и глупый юзер может не дождаться и просто выключить, а к асинктаску можно присобачить прогрес диалог и юзер будет ждать пока выполнится задача.(можно конечно присобачить и к сервису прогресс дайлог но это уже извращение)


Ответ

Асинк таски уже использовать не рекомендуется. В крупных банковских приложениях от низ уже ушли. Технология Сервис + Контент провайдер много лучше. Прогресс бар - что мешает прикрутить его к сервису?? У вас должен быть ServiceHelper шлющий коллбэки, по ним и стоит обновлять прогресс бар. Вот официальная спецификация Google для реализации RestAPI при помощи сервисов По быстродействию и ресурсам, даже если вы что то и потеряете, то выиграете в надежности приложения. Потому что даже при критической ошибке сервиса, ваше приложение останется работать. По материалам: Реализация колбэков и прогресс бара, а также самой модели Service + ContentProvider + Activity - Организация архитектуры взаимодействия Activity и Service Еще один пример на эту тему - Написание простого приложения для работы с RESTful API под Android От себя совет, переводите ваши апы на Service + ContentProvider + Activity за этим будущее. На Google IO был доклад на эту тему: Developing Android REST client applications. Кстати там использовалась похожая структура. P.S. Как то проходил собеседование в один крупный банк как Android разработчик, так там как услышали про возможность AsyncTask, чуть не закидали яйцами за само предложение :) :)

Комментариев нет:

Отправить комментарий