Давайте снова вернёмся к вопросу организации работы фоновых процессов в Android-приложении. В этой статье я описал, как выполнять загрузку файлов с удалённого сервера в фоне. Задача замечательно решается с помощью AsyncTask, но только в случае небольших файлов и недолгого ожидания. Что произойдёт в случае если файл будет загружаться двадцать минут? Телефон уснёт, вы воспользуетесь другим приложением и т.п. - в любом случае загрузка будет прервана. Решение тут очевидно: заменить AsyncTask сервисом, который может работать и без основонго приложения. В случае же использования WakefulIntentService мы практически гарантировано докачаем наш файл несмотря ни на что. И только одну проблему остаётся решить для получения окончательной победы разума над материей: обновлять прелоадер нам нужно в Activity, которая недоступна из сервиса. Выход: использовать внутренний механизм платформы для обмена сообщениями между отдельными компонентами нашего приложения.
Итак, давайте переработаем наше приложения для загрузки файлов так, чтобы оно могло докачать файл при любых обстоятельствах. Научимся использовать BroadcastReceiver.
Решения конкретных задач программирования. Java, Android, JavaScript, Flex и прочее... Настройка софта под Linux, методики разработки и просто размышления.
Показаны сообщения с ярлыком WakefulIntentService. Показать все сообщения
Показаны сообщения с ярлыком WakefulIntentService. Показать все сообщения
понедельник, 14 мая 2012 г.
вторник, 24 апреля 2012 г.
Оповещаем Android о событиях на сервере
Допустим, у нас есть достаточно популярное Android-приложение, в которое мы хотим добавить опцию оповещения пользователей о каких-либо событиях. Например, пользователь должен иметь возможность оперативно получить новость или персональное сообщение от другого пользователя. Как решить такую задачу?
Решение в виде сервиса на устройстве, который регулярно опрашивает сервер выглядит несовременно, да и опасно: достаточно большое количество пользователей могут задосить нам сервер. Увеличение интервала опроса в нашем случае решает проблему нагрузки с одной стороны, но снижает скорость доставки с другой.
Второй вариант: использовать Cloud to Device Messaging Framework. Действительно хорошее решение, но в ряде случаев не подходит. Во-первых, передаче сообщений через сторонние сервера могут препятствовать соображения конфиденциальности, а во-вторых, если приложение должно поддерживать версию Android 2.1 и ниже, то этот фреймворк нам не поможет.
Третий вариант - использовать свой http push сервер, например nginx + nginx push stream module. Можно поспорить, что лучше, много запросов или много коннектов а также сравнить производительность разных серверов, но цель у нас сейчас другая. Давайте рассмотрим простой вариант реализации такого оповещения.
Решение в виде сервиса на устройстве, который регулярно опрашивает сервер выглядит несовременно, да и опасно: достаточно большое количество пользователей могут задосить нам сервер. Увеличение интервала опроса в нашем случае решает проблему нагрузки с одной стороны, но снижает скорость доставки с другой.
Второй вариант: использовать Cloud to Device Messaging Framework. Действительно хорошее решение, но в ряде случаев не подходит. Во-первых, передаче сообщений через сторонние сервера могут препятствовать соображения конфиденциальности, а во-вторых, если приложение должно поддерживать версию Android 2.1 и ниже, то этот фреймворк нам не поможет.
Третий вариант - использовать свой http push сервер, например nginx + nginx push stream module. Можно поспорить, что лучше, много запросов или много коннектов а также сравнить производительность разных серверов, но цель у нас сейчас другая. Давайте рассмотрим простой вариант реализации такого оповещения.
Подписаться на:
Сообщения (Atom)