Сценарий:

Публикация на сервере для получения новых данных в фоновом режиме каждые 30 секунд в течение длительного периода времени, то есть 12 часов. Данные о местоположении должны быть отправлены вместе с этим.

Текущая реализация;

Класс обслуживания;

Прослушиватель местоположения с интервалом 30 секунд, который устанавливает значения долготы и широты для двух локальных переменныхДиспетчер тревог срабатывает в ожидании намерения каждые 30 секунд для приемника вещания.Приемник широковещания запускает IntentService с переменными местоположения в дополнениях.Http IntentService публикует местоположение и запрашивает новые данные с сервера.

IntentService отправляет ответ сервера обратно в основной класс обслуживания через широковещательный приемник.

Сервисный класс start_sticky для обеспечения перезагрузки ОС.

Я пробовал несколько разных вариантов;

Я попытался использовать Handler и runnable для обработки механизма синхронизации для отправки на сервер, однако, время postDelay увеличилось с 2 минут до 7 минут, когда устройство спит.

Кроме того, попытался запустить IntentService непосредственно из диспетчера аварийных сигналов, но не смог изменить дополнения PendingIntent с самыми последними переменными местоположения.

Вопросов;

Является ли текущая реализация подходом?

Будет ли гораздо более выгодным идти по GCM-маршруту от Google?

Как вы можете энергично протестировать класс обслуживания, особенно в отношении восстановления из ОС, убивающей его?

Заранее спасибо.