Таймер с ручным запуском

[@BlackStream]

public class UniversalReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        Log.d("AlertTest", "Произошла смена статуса");
        MainActivity mainActivity = new MainActivity();
        mainActivity.setServiceAlarm(context);
    }
}

Вы же это не серьезно?

Рекомендую обратить внимание на реактивный вариант, чтото типа:

Observable
                .interval(REFRESH_INTERVAL, TimeUnit.SECONDS)
                .subscribeOn(Schedulers.newThread())
                .takeWhile(new Func1<Long, Boolean>() {
                    @Override
                    public Boolean call(Long aLong) {
                        return someCondition();
                    }
                })
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe...

[@Snakecatcher]

Подробнее пожалуйста. :) Для котов, попонятнее :)

[@BlackStream]

MainActivity mainActivity = new MainActivity();

нельзя создавать Activity явно, да еще и для того что бы дергать паблик метод

[@Handy]

Для начала, если Вам нужно создать и запустить новую активити, то нужно воспользоваться примерно следующим кодом:

Intent intent = new Intent(this, MainActivity.class);
startActivity(intent);

Ну и в принципе с onReceive() в BroadcastReceiver нужно быть очень осторожным, потому что у него есть жесткие ограничения, например, на время выполнения кода.

[@Snakecatcher]

Точно, это я накосячил. Спасибо. Поправлю.

[@ivazhnov]

Почему нельзя было воспользоваться SyncAdapter?

[@Snakecatcher]

Пожалуйста примеры, ссылки.
Я ж не волшебник, а только учусь. :) Всегда рад возможности улучшить код.

[@ivazhnov]

Пожалуйста
Sync Adapter делает почти все, что нужно из коробки. Правда, помимо всего прочего, придется хоть немного разобраться еще и с AccountManager и ContentProvider

[@Snakecatcher]

Понял, вы имеете в виду, для отлова ситуации с отключением/подключением сети.
Спасибо. Буду разбираться.

[@Dimezis]

Ужас, кто это плюсует? Кто-то же может воспринять всерьез.

[@Snakecatcher]

Хорошо. Было бы приятно выслушать критику специалиста.
Что бы вы посоветовали?
Какие участки кода, больше всего не нравятся?

[@Dimezis]

Создание Activity вручную. Да еще и чтобы просто вызвать паблик метод. Вы хоть представляете на сколько тяжелый это компонент и на сколько бессмысленно это делать? Не говоря уже о том, что это ужасно с точки зрения архитектуры и вообще создавать Activity — ответственность ОС?

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

Код стайл, форматирование, название переменных, классов.

Использование оберток над примитивами там, где можно обойтись примитивами. (Подозреваю, что даже автор даже не задумывался над разницей)

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

[@Snakecatcher]

Я поправил участок с вызовом Activity. Там накосячил. Сейчас через интент.
Насчет кодстайла — это тестовое приложение, где никаким образом не заморачивался с названиями переменных и классов.
Естественно, в полноценном проекте я не допускаю такого именования.

С обертками не понял, что вы имели в виду. Можно поподробнее?

С расходом батареи, спасибо ivazhnov и MetAmfetamin — разбираюсь с эффективным интструментом. Склоняюсь все-таки к GcmNetworkManager.

[@Dimezis]

Я понимаю, что приложение тестовое, но вы же все-таки статью пишите, на которую кто-то будет равняться.
Насчет оберток, я про разницу между boolean и Boolean, int и Integer и тд.

[@Snakecatcher]

Спасибо, за уделенное время.
Обязательно исправлюсь. :)

[@Alex837]

Новички пишут статьи для новичков обеспечивая круговорот плохих практик написания приложений.

Почти идеальное руководство по высаживанию батареи

<action android:name=«android.net.conn.CONNECTIVITY_CHANGE» /> в манифесте будет стартовать приложение при каждой смене вышки и человека в дороге будет согревать теплый телефон.

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

Ну а побудку телефона раз в 5 секунд оставим на совести автора, благо доз мод вырубит alarmManager и с какого-то апи оно вроде вообще не даст так часто запускать алярмы.

[@Snakecatcher]

Спасибо за конструктивную критику.
Я тот новичок, который хочет улучшить код, и уйти от плохих практик.
Задача должна подцепиться к серверу, и выполнить закачку данных. Проблема в том, что сервер даёт доступ через раз, а то и через десять Поэтому, в предыдущей версии (не за моим авторством), пользователю приходилось самостоятельно нажимать на кнопку синхронизации. Это сильно раздражало пользователей, и я подумал, что лучше убрать с глаз долой синхронизацию.
5 секунд это я для примера. Планируется около 5-10 минут.
Подскажите, пожалуйста, а как тогда действовать в нижеприведённой ситуации?
Имеем неусточивый интернет. Заполняем некую анкету. Если есть подключение к сети, то отправляем её на сервак. Если нет — то складируем в определённой папке.
На данный момент, я с помощью: <action android:name=«android.net.conn.CONNECTIVITY_CHANGE» />, отлавливаю, что сеть появилась и отправляю данные.
Но вы указали, что это неэффективно. Как быть?

[@MetAmfetamin]

На мой взгляд идея правильная, просто неправильно выбраны средства для «синхронизации». Для решения проблемы с перезапуском загрузки я бы рассмотрел варианты:

• простой — JobScheduler (Android 5+) или GcmNetworkManager (если нужна поддержка Android < 5). Проблема с GcmNetworkManager — это необходимость наличия play services на устройстве.
• более сложный — SyncAdapter

[@Snakecatcher]

Спасибо. Как раз, комментатор выше преддложил тоже SyncAdapter.
Буду его изучать. :)

[@Alex837]

Если установлен target api 24 то на андроид 7 приложении вообще не получит <action android:name=«android.net.conn.CONNECTIVITY_CHANGE» /> О такой штуке в манифесте лучше вообще забыть пока есть хоть какие-то другие способы. Правильное использование этого бродкаста подписываться перед передачей данных отписываться после.

>Как быть?

Читать developer.android.com. Там совсем плохого не советуют. В коментах уже предложили приемлемые решения с JobScheduler и SyncAdapter. К ним остается добавить, что при ошибках лучше делать таймаут и увеличивать интервал экспоненциально(exponential backoff) при каждой новой попытке (например в 2 раза до некоторого предела) и ограничить количество попыток после чего передать управление пользователю. Пользователь может находиться в условия плохой сети, и от того что приложение будет долбится бесконечно хорошего будет мало пока пользователь не найдет интернет получше. Т.е. если сервер никак нельзя починить я бы сделал пару попыток с небольшим интервалом, а потом интервал увеличивал.

[@Snakecatcher]

Понял, спасибо.
Проблема в том, что пользователью никак нельзя давать полный доступ к автоматической синхронизации. Желательно, чтобы все было «под капотом».
Насчет сети, у меня стоит проверка на доступность сети вообще, как таковой. Если подключения нет, то — попытки подключиться к серверу прекращаются.
Сделаю так: оставлю ограничение по количеству подключений (например 10 раз, с таймаутом 0,1 секунда). Если подключение инициировалось в автоматическом режиме, то никаких сообщений выводить не буду, просто буду спокойно ждать следующего тика таймера.
Если же синхронизация была запущена вручную — то выведу сообщение, об ошибке, и её причине.

[@sbnur]

Семь раз прочти — один раз напиши