очень грубое решение) Этот метод вызывается в UI потоке.
2. Хорошей практикой считается запускать сервис из метода onReceive дабы не делать слишком многого в нем
3. В принципе, как вы сами говорите, решение грубое. Утверждать, что за 2 минут простоя ОС не убьет ваш процесс я бы не стал :)
Перенеся am.cancel am.set в onReceive() мы будем уверенны, что новый запуск AlarmManager будет установлен, даже если в какой-то момент андроид прибил наш AsyncTask.
Вот про это не совсем понял, кто будет устанавливать новый запуск аларм менеджера?
Судя по вашему описанию, ваш процесс убиваемый (ссылка на документацию ). Рекомендуют запускать Service из метода BroadcastReceiver.onReceive, это может отсрочить убийство системой вашего процесса. Либо использовать foreground service или service c флажком START_REDELIVER_INTENT .
При старте приложения создавал AlarmManager без повторения, который срабатывал через 2 минуты.
Если система убъет ваш процесс до того как выполнился асинхронный запрос, то следующий запуск AlarmManager не случится никогда, судя по вашему описанию или нет?
По хорошему скорее всего да, foreground service хороший кандидат, но висящая иконка в статус-баре многих раздражает (меня нет :)). Есть еще вариант со START_REDELIVER_INTENT и обычный сервис (либо IntentService). По поводу heartbeat хочу еще отметить, что проблему с ним, например, на nexus 4, nexus 5, nexus 7, 9 с чистым андроидом я не замечал, она отсутствует. А на samsung (s4, note) — да, стабильно.
Скажем, если есть девайс на котором heartbeat 8 минут поддерживает возможность мгновенного прихода соединения, а для heartbeat 10 минут — уже нет, то что именно изменяется на этой восьмой-девятой минуте?
Не совсем понял про «возможность мгновенного прихода соединения», поясните пожалуйста.
Могу сказать, что «проблем с HeartBeat» лишены те мессенджеры, которые использует помимо GCM свое собственное соединение. Думаю скоро это будут делать абсолютно все популярные мессенджеры, сейчас пока частично. Других способов решить эту проблему вроде как нет. Это я про Android. Про другие ОС ничего не могу сказать.
Спасибо за подробное объяснение. Правильно я понимаю, что notification_key следует использовать, если надо ограничить круг девайсов (клиентов), которые могут получать уведомления и кол-во которых не может превышать 20 штук? И никто кроме них пуш-уведомления получать не должен? Иначе, не очень понимаю зачем он нужен.
Интересный вопрос. Я не работал с notification_key на практике. И что-то с ходу в документации про это найти ничего не могу, кроме faled_registration_ids поля в ответе:
. Вы уверены, что пуш сервер не обязан знать registration_id каждого девайса в группе, разве не пуш-сервер должен добавлять/удалять registration_id в/из группы? Буду признателен, если расскажите как отслеживать изменение registration_id при использовании notification_key.
Спасибо за информацию про операторов сотовой связи — не знал. Согласен с обоими пунктами. Краткосрочный пинг нужен приложениям, в которых задержка длиною в heartbeat недопустима (мессенджер или клиент охранной сигнализации к примеру), а так, да, нужно конечно свое соединение держать отдельное от gmc. Но, думаю, когда каждое приложение начнет держать свое соединение, то батарейка будет тратиться врядли меньше, чем если бы величина hearbeat была, к примеру, настраиваемой.
Я в первую очередь думаю, что речь в статье о доставке обновлений с сервера на клиент
Речь в статье, в первую очередь, какие аспекты при работе с http клиентами (urlconnection и httpclient) влияют потребление трафика, безопасность и расход батареи.
Во вторую очередь я думаю о том, что для этого кейза есть сто раз описанная и обговоренная связка типа:
1) если размер обновлений невелик, то сервер пересылает все данные обновлений в самой пуш-нотификации
2) если размер обновлений велик, то сервер пересылает в пуш-нотификации только сигнал о наличии и количестве обновлений
3) клиент либо сразу обновляет контент в случае 1) либо делает запрос на сервер и получает пачку апдейтов в случае 2)
Все, других формул нет. Единственный возможный вариант — это свой long-polling для каких-либо нужд.
не соглашусь. Обычный polling — это тоже способ доставки обновлений на клиент. Далеко не все приложения используют GCM или пишут свою реализацию long-polling'a.
а при использовании HttpClient пробросить этот параметр как значение getKeepAliveDuration
вы не внимательно прочитали статью, о том как настроить keep alive duration в HttpClient в ней рассказывается.
Спасибо за замечание. Еще не успел посмотреть на Volley Library в действии, т.к. всего месяц назад ее презентовали на Google IO 2013, обязательно скоро попробую и может быть добавлю в статью.
Да, это интересно, спасибо за ссылку. Я немного слышал об этом, на практике пока не довелось попробовать. Вы, кстати, нашли уже применение этой технологии?
Был опыт использование Android annotations. @doInBackground и @UiThread — делают код запутанным и непонятным. Подход dependency injection для избавления от boilerplate кода — более менее полезен. А вот doinBackgroun и Uithread (
2. Хорошей практикой считается запускать сервис из метода onReceive дабы не делать слишком многого в нем
3. В принципе, как вы сами говорите, решение грубое. Утверждать, что за 2 минут простоя ОС не убьет ваш процесс я бы не стал :)
Вот про это не совсем понял, кто будет устанавливать новый запуск аларм менеджера?
Судя по вашему описанию, ваш процесс убиваемый (ссылка на документацию ). Рекомендуют запускать Service из метода BroadcastReceiver.onReceive, это может отсрочить убийство системой вашего процесса. Либо использовать foreground service или service c флажком START_REDELIVER_INTENT .
Если система убъет ваш процесс до того как выполнился асинхронный запрос, то следующий запуск AlarmManager не случится никогда, судя по вашему описанию или нет?
Не совсем понял про «возможность мгновенного прихода соединения», поясните пожалуйста.
Cогласен
Приму к сведению. Спасибо.
Речь в статье, в первую очередь, какие аспекты при работе с http клиентами (urlconnection и httpclient) влияют потребление трафика, безопасность и расход батареи.
согласен, много описано об этом: Google I/O 2010 — Building push applications for Android, Google I/O 2012 — Google Cloud Messaging for Android и Google I/O 2013 — Google Cloud Messaging. Поэтому в этой статье об этом ничего и не рассказывается, а просто упоминается в начале о механизме пуш-уведомлений.
не соглашусь. Обычный polling — это тоже способ доставки обновлений на клиент. Далеко не все приложения используют GCM или пишут свою реализацию long-polling'a.
вы не внимательно прочитали статью, о том как настроить keep alive duration в HttpClient в ней рассказывается.
что уйдет в небытие — согласен, насчет как скоро сказать не решусь, т.к. плафтормы <= 2.3 все еще занимают порядка 25% из всех Android OS.
Для отладки используем тоже Wireshark, также Network Traffic Tool. Еще рекомендую посмотреть в сторону новой библиотеки для работы с сетью Volley, наверняка, там есть фичи, связанные с отладкой трафика.