Comments 22
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...
+2
Подробнее пожалуйста. :) Для котов, попонятнее :)
0
MainActivity mainActivity = new MainActivity();
нельзя создавать Activity явно, да еще и для того что бы дергать паблик метод
0
Для начала, если Вам нужно создать и запустить новую активити, то нужно воспользоваться примерно следующим кодом:
Ну и в принципе с onReceive() в BroadcastReceiver нужно быть очень осторожным, потому что у него есть жесткие ограничения, например, на время выполнения кода.
Intent intent = new Intent(this, MainActivity.class);
startActivity(intent);
Ну и в принципе с onReceive() в BroadcastReceiver нужно быть очень осторожным, потому что у него есть жесткие ограничения, например, на время выполнения кода.
0
Почему нельзя было воспользоваться SyncAdapter?
0
Пожалуйста примеры, ссылки.
Я ж не волшебник, а только учусь. :) Всегда рад возможности улучшить код.
Я ж не волшебник, а только учусь. :) Всегда рад возможности улучшить код.
-1
Пожалуйста
Sync Adapter делает почти все, что нужно из коробки. Правда, помимо всего прочего, придется хоть немного разобраться еще и с AccountManager и ContentProvider
Sync Adapter делает почти все, что нужно из коробки. Правда, помимо всего прочего, придется хоть немного разобраться еще и с AccountManager и ContentProvider
0
Ужас, кто это плюсует? Кто-то же может воспринять всерьез.
0
Хорошо. Было бы приятно выслушать критику специалиста.
Что бы вы посоветовали?
Какие участки кода, больше всего не нравятся?
Что бы вы посоветовали?
Какие участки кода, больше всего не нравятся?
0
Создание Activity вручную. Да еще и чтобы просто вызвать паблик метод. Вы хоть представляете на сколько тяжелый это компонент и на сколько бессмысленно это делать? Не говоря уже о том, что это ужасно с точки зрения архитектуры и вообще создавать Activity — ответственность ОС?
Хардкод ключей в префах. Необходимость помнить везде что под каким ключом записал, это абсолютно не поддерживаемый код и источник кучи багов.
Код стайл, форматирование, название переменных, классов.
Использование оберток над примитивами там, где можно обойтись примитивами. (Подозреваю, что даже автор даже не задумывался над разницей)
Сам подход к задаче. Как уже написали, это может высадить батарею, да и вообще решение не выглядит элегантно. Повторять предложенные варианты не буду.
Хардкод ключей в префах. Необходимость помнить везде что под каким ключом записал, это абсолютно не поддерживаемый код и источник кучи багов.
Код стайл, форматирование, название переменных, классов.
Использование оберток над примитивами там, где можно обойтись примитивами. (Подозреваю, что даже автор даже не задумывался над разницей)
Сам подход к задаче. Как уже написали, это может высадить батарею, да и вообще решение не выглядит элегантно. Повторять предложенные варианты не буду.
+2
Я поправил участок с вызовом Activity. Там накосячил. Сейчас через интент.
Насчет кодстайла — это тестовое приложение, где никаким образом не заморачивался с названиями переменных и классов.
Естественно, в полноценном проекте я не допускаю такого именования.
С обертками не понял, что вы имели в виду. Можно поподробнее?
С расходом батареи, спасибо ivazhnov и MetAmfetamin — разбираюсь с эффективным интструментом. Склоняюсь все-таки к GcmNetworkManager.
Насчет кодстайла — это тестовое приложение, где никаким образом не заморачивался с названиями переменных и классов.
Естественно, в полноценном проекте я не допускаю такого именования.
С обертками не понял, что вы имели в виду. Можно поподробнее?
С расходом батареи, спасибо ivazhnov и MetAmfetamin — разбираюсь с эффективным интструментом. Склоняюсь все-таки к GcmNetworkManager.
-1
Новички пишут статьи для новичков обеспечивая круговорот плохих практик написания приложений.
Почти идеальное руководство по высаживанию батареи
<action android:name=«android.net.conn.CONNECTIVITY_CHANGE» /> в манифесте будет стартовать приложение при каждой смене вышки и человека в дороге будет согревать теплый телефон.
Не совсем ясно, что собственно делает задача, но в случае неуспеха она начинает делать бесконечный цикл. Одна надежда — нет вейклоков и андроид уснет не выполнив нечего, но будет садить батарейку с включенным экраном.
Ну а побудку телефона раз в 5 секунд оставим на совести автора, благо доз мод вырубит alarmManager и с какого-то апи оно вроде вообще не даст так часто запускать алярмы.
Почти идеальное руководство по высаживанию батареи
<action android:name=«android.net.conn.CONNECTIVITY_CHANGE» /> в манифесте будет стартовать приложение при каждой смене вышки и человека в дороге будет согревать теплый телефон.
Не совсем ясно, что собственно делает задача, но в случае неуспеха она начинает делать бесконечный цикл. Одна надежда — нет вейклоков и андроид уснет не выполнив нечего, но будет садить батарейку с включенным экраном.
Ну а побудку телефона раз в 5 секунд оставим на совести автора, благо доз мод вырубит alarmManager и с какого-то апи оно вроде вообще не даст так часто запускать алярмы.
+4
Спасибо за конструктивную критику.
Я тот новичок, который хочет улучшить код, и уйти от плохих практик.
Задача должна подцепиться к серверу, и выполнить закачку данных. Проблема в том, что сервер даёт доступ через раз, а то и через десять Поэтому, в предыдущей версии (не за моим авторством), пользователю приходилось самостоятельно нажимать на кнопку синхронизации. Это сильно раздражало пользователей, и я подумал, что лучше убрать с глаз долой синхронизацию.
5 секунд это я для примера. Планируется около 5-10 минут.
Подскажите, пожалуйста, а как тогда действовать в нижеприведённой ситуации?
Имеем неусточивый интернет. Заполняем некую анкету. Если есть подключение к сети, то отправляем её на сервак. Если нет — то складируем в определённой папке.
На данный момент, я с помощью: <action android:name=«android.net.conn.CONNECTIVITY_CHANGE» />, отлавливаю, что сеть появилась и отправляю данные.
Но вы указали, что это неэффективно. Как быть?
Я тот новичок, который хочет улучшить код, и уйти от плохих практик.
Задача должна подцепиться к серверу, и выполнить закачку данных. Проблема в том, что сервер даёт доступ через раз, а то и через десять Поэтому, в предыдущей версии (не за моим авторством), пользователю приходилось самостоятельно нажимать на кнопку синхронизации. Это сильно раздражало пользователей, и я подумал, что лучше убрать с глаз долой синхронизацию.
5 секунд это я для примера. Планируется около 5-10 минут.
Подскажите, пожалуйста, а как тогда действовать в нижеприведённой ситуации?
Имеем неусточивый интернет. Заполняем некую анкету. Если есть подключение к сети, то отправляем её на сервак. Если нет — то складируем в определённой папке.
На данный момент, я с помощью: <action android:name=«android.net.conn.CONNECTIVITY_CHANGE» />, отлавливаю, что сеть появилась и отправляю данные.
Но вы указали, что это неэффективно. Как быть?
0
На мой взгляд идея правильная, просто неправильно выбраны средства для «синхронизации». Для решения проблемы с перезапуском загрузки я бы рассмотрел варианты:
- простой — JobScheduler (Android 5+) или GcmNetworkManager (если нужна поддержка Android < 5). Проблема с GcmNetworkManager — это необходимость наличия play services на устройстве.
- более сложный — SyncAdapter
+1
Если установлен target api 24 то на андроид 7 приложении вообще не получит <action android:name=«android.net.conn.CONNECTIVITY_CHANGE» /> О такой штуке в манифесте лучше вообще забыть пока есть хоть какие-то другие способы. Правильное использование этого бродкаста подписываться перед передачей данных отписываться после.
>Как быть?
Читать developer.android.com. Там совсем плохого не советуют. В коментах уже предложили приемлемые решения с JobScheduler и SyncAdapter. К ним остается добавить, что при ошибках лучше делать таймаут и увеличивать интервал экспоненциально(exponential backoff) при каждой новой попытке (например в 2 раза до некоторого предела) и ограничить количество попыток после чего передать управление пользователю. Пользователь может находиться в условия плохой сети, и от того что приложение будет долбится бесконечно хорошего будет мало пока пользователь не найдет интернет получше. Т.е. если сервер никак нельзя починить я бы сделал пару попыток с небольшим интервалом, а потом интервал увеличивал.
>Как быть?
Читать developer.android.com. Там совсем плохого не советуют. В коментах уже предложили приемлемые решения с JobScheduler и SyncAdapter. К ним остается добавить, что при ошибках лучше делать таймаут и увеличивать интервал экспоненциально(exponential backoff) при каждой новой попытке (например в 2 раза до некоторого предела) и ограничить количество попыток после чего передать управление пользователю. Пользователь может находиться в условия плохой сети, и от того что приложение будет долбится бесконечно хорошего будет мало пока пользователь не найдет интернет получше. Т.е. если сервер никак нельзя починить я бы сделал пару попыток с небольшим интервалом, а потом интервал увеличивал.
0
Понял, спасибо.
Проблема в том, что пользователью никак нельзя давать полный доступ к автоматической синхронизации. Желательно, чтобы все было «под капотом».
Насчет сети, у меня стоит проверка на доступность сети вообще, как таковой. Если подключения нет, то — попытки подключиться к серверу прекращаются.
Сделаю так: оставлю ограничение по количеству подключений (например 10 раз, с таймаутом 0,1 секунда). Если подключение инициировалось в автоматическом режиме, то никаких сообщений выводить не буду, просто буду спокойно ждать следующего тика таймера.
Если же синхронизация была запущена вручную — то выведу сообщение, об ошибке, и её причине.
Проблема в том, что пользователью никак нельзя давать полный доступ к автоматической синхронизации. Желательно, чтобы все было «под капотом».
Насчет сети, у меня стоит проверка на доступность сети вообще, как таковой. Если подключения нет, то — попытки подключиться к серверу прекращаются.
Сделаю так: оставлю ограничение по количеству подключений (например 10 раз, с таймаутом 0,1 секунда). Если подключение инициировалось в автоматическом режиме, то никаких сообщений выводить не буду, просто буду спокойно ждать следующего тика таймера.
Если же синхронизация была запущена вручную — то выведу сообщение, об ошибке, и её причине.
0
Семь раз прочти — один раз напиши
0
Sign up to leave a comment.
Таймер с ручным запуском