Что такое receiver android

Использование Broadcast Receiver на наглядном примере

Broadcast Receivers – один из компонентов приложения для операционной системы Android. В данной статье мы попытаемся нагляднее объяснить «что это такое и с чем его едят», написав приложение, отслеживающее состояние соединения посредством Wi-Fi и уведомляющее пользователя о любых его изменениях.

С тем, что такое Broadcast receivers, и с другими компонентами Android-приложения мы уже ознакомились в другом материале. В данной статье мы подойдем к данному компоненту с практической точки зрения. Поэтому создаем новый проект и принимаемся за работу.

Вначале описываем приложение в AndroidManifest.xml. Нам нужно объявить компонент Broadcast receiver для слежения за состоянием Wi-Fi соединения, и дать программе права получать информацию о состоянии этого соединения. Компонент Activity мы также опишем, но на данный момент он не будет иметь никакой функциональной нагрузки. Что должно получится в AndroidManifest.xml:

В целом основная часть работы сделана. Даже без запуска приложения нужный нам Broadcast receiver будет в системе, и при включении/выключении Wi-Fi появится соответствующее оповещение:

Теперь рассмотрим, что же собственно мы сделали. Вот так задается Broadcast receiver в «манифесте» (AndroidManifest.xml):

Каждому из Broadcast receivers нужно присвоить своё имя (например android:name=».WiFiStatusReceiver»). Указанное имя должно соответствовать классу, который будет обрабатывать поступившие Intents от соответствующего Broadcast receiver.

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

Перейдем к классу WiFiStatusReceiver.java. Нужно помнить, что наследовать классы java нужно от класса BroadcastReceiver. Далее применяем весьма удобный системный класс WiFiManager для того, чтобы определить текущее состояние Wi-Fi соединения и сравниваем полученное значение с константами, которые отвечают за включенный или выключенный Wi-Fi. Если константы и состояния совпадают, то пользователю выводится сообщение. Для вывода сообщения используются Toast-уведомления (всплывающие полупрозрачные надписи).

Вот мы и создали наглядный и достаточно простой пример работы Broadcast receivers. Сохраняем проект и запускаем его на Android-устройстве или через эмулятор и радуемся проделанной работе.

Источник

Broadcast (Широковещательные сообщения)

В Android существует понятие широковещательных сообщений, которые можно отправлять или принимать. Оба процесса между собой не связаны и их можно использовать по отдельности.

Передача сообщений

Для начала научимся отправлять сообщения. В одном из уроков мы учились запускать другую активность с помощью намерения Intent. Но намерения можно использовать для отправки сообщений, предназначенные не какому-то отдельному приложению, объекту или компоненту, а всем. И любая программа, оборудованная специальным приёмником, может поймать это сообщение и предпринять свои шаги на основе полученной информации.

Любой человек, имеющий специальный оборудованный радиоприёмник, может принять это сообщение. Так же поступают и программы. Они обзаводятся приёмниками и прослушивают определённый тип сообщений.

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

Передача сообщений весьма проста в реализации. В вашем приложении необходимо создать сообщение, которое вы хотите передать. Установите при необходимости поля action, data и category (действие, данные и категорию) вашего сообщения и путь, который позволяет приёмникам широковещательных сообщений точно определять «своё» сообщение. В этом сообщении строка действия ACTION должна быть уникальной, чтобы идентифицировать передаваемое действие. В таких случаях создают строку-идентификатор действия по правилам именования пакетов Java. Например, для обнаружения кота в большом здании:

Далее вы создаёте объект Intent, загружаете в него нужную информацию и вызываете метод sendBroadcast(), передав ему в качестве параметра созданный объект Intent. Дополнительные данные можно использовать в extras как необязательные параметры.

Виртуальный код для обнаружения кота:

В этом примере мы создали намерение с уникальной строкой, передали дополнительные данные (имя кота и его координаты), отправили сообщение. Другое приложение, связанное с картами, может принять сообщение и показать кота на карте.

Существуют также родственные методы sendStickyBroadcast() и sendOrderedBroadcast().

Для старых устройств этого было вполне достаточно, но начиная с Android 3.0, в целях безопасности сообщения будут игнорироваться остановленными приложениями, чтобы они не запускались. Поэтому следует добавлять дополнительный флаг, разрешающий запуск активности.

Мы напишем простой пример, который будет отправлять сообщения и также создадим приёмник для его получения. О приёмнике мы поговорим подробно во второй части урока. А пока получим первое представление о нём.

Создайте новый проект и разместите на экране кнопку с надписью «Отправить сообщение». Присвойте атрибуту onClick название метода, в котором будет происходит отправка широковещательного сообщения.

Запустив пример, вы можете нажать на кнопку и отправлять сообщение. Только ваше сообщение уйдёт в никуда, так как ни одно приложение не оборудовано приёмником для него. Исправим ситуацию и создадим приёмник в своём приложении. Мы будем сами принимать свои же сообщения.

Приёмник представляет собой обычный Java-класс на основе BroadcastReceiver. Вы можете создать вручную класс и наполнить его необходимыми методами. Раньше так и поступали. Но в студии есть готовый шаблон, который поможет немного сэкономить время.

Щёлкаем правой кнопкой мыши на названии пакета и выбираем New | Other | Broadcast Receiver

В диалоговом окне задаём имя приёмника, остальные настройки оставляем без изменений.

Студия создаст изменения в двух местах. Во-первых, будет создан класс MessageReceiver:

Во-вторых, в манифесте будет добавлен новый блок.

В него следует добавить фильтр, по которому он будет ловить сообщения.

Вернёмся в класс приёмника и модифицируем метод onReceive().

Снова запустим пример и ещё раз отправим сообщение. Так как наше приложение теперь оборудовано не только передатчиком, но и приёмником, то оно должно уловить сообщение и показать его нам.

Вы можете создать другое приложение с приёмником, чтобы одно приложение посылало сообщение, а другое принимало.

Приёмники широковещательных сообщений

Вот плавно мы перешли к приёмникам широковещательных сообщений. На самом деле вам не так часто придётся рассылать сообщения, гораздо чаще встречается потребность принимать сообщения. В первую очередь, сообщения от системы. Примерами таких сообщений могут быть:

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

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

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

Рассмотрим пример периодического срабатывания приёмника каждую минуту с помощью системного намерения android.intent.action.TIME_TICK. Приёмник будет создан программно. Добавим на экран активности две кнопки для регистрации и отмены регистрации широковещательного сообщения.

Создадим вручную новый класс TimeBroadcastReceiver, наследующий от BroadcastReceiver:

Вы можете создать класс приёмника и через шаблон, как мы это сделали в предыдущем примере. Но в этом случае удалите запись о нём в манифесте, так как нам он не понадобится. Но если вы забудете сделать это, то ничего страшного не произойдёт, так как там не прописаны фильтры.

Откроем код главной активности и зарегистрируем (а также снимем регистрацию) приёмник:

Запускаем проект и нажимаем на первую кнопку, чтобы включить рассылку широковещательного сообщения. Теперь каждую минуту будет срабатывать запуск всплывающего сообщения с текущим временем. Даже если вы переключитесь на другое приложение, то всё равно будете видеть сообщения.

Это один из примеров, когда приёмник следует регистрировать программно. Я видел часто на форумах вопросы, почему не работает данное намерение android.intent.action.TIME_TICK. А не надо было его регистрировать в манифесте.

В нашем примере мы устанавливали и снимали регистрацию через нажатия кнопок. Обычно включают регистрацию в методе onResume(), а снимают регистрацию в методе onPause().

Необходимо помнить, что программная регистрация широковещательного сообщения создаётся в основном потоке приложения и это может послужить источником ошибок, если операции в BroadcastReceiver занимают длительное время. Как вариант, используйте сервисы. Почитайте на эту тему статью (en).

TIME_TICK на Kotlin

Напишем похожий пример на Kotlin. Разместите на экране TextView, в котором будет отображаться время. Код для активности ниже. Обратите внимание, что мы не создаём отдельный класс для BroadcastReceiver, включаем регистрацию в onResume() и снимаем регистрацию в onPause().

Автостарт Activity или Service при загрузке (перезагрузке) девайса

Ещё один полезный пример, который часто используется приложениями.

Если ваше приложение (сервис) должно запускаться сразу после перезагрузки устройства, то используйте намерение android.intent.action.BOOT_COMPLETED:

Мы создали отдельный класс для широковещательного сообщения. Также нужно создать разрешение и зарегистрировать приёмник в манифесте.

Следим за питанием

Нет, речь пойдёт не о правильном питании кота. Имеется в виду питание от электричества. Если ваше устройство отключить от зарядки, то система оповещает об этом событии через широковещательное намерение android.intent.action.ACTION_POWER_DISCONNECTED.

Не станем заводить новый приёмник, а откроем манифест и добавим дополнительный фильтр к приёмнику сообщений от радистки Кэт.

А в классе MessageReceiver добавим код для метода.

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

Источник

Эти забавные BroadcastReceiver’ы

Небольшое наблюдение о различном поведении BroadcastReceiver ‘ов при регистрации через AndroidManifest.xml и непосредственно в коде. Данная заметка не является пошаговым руководством для новичков, а всего лишь призвана сэкономить время тем, кому еще не довелось наступить на похожие грабли.

Так уж вышло, волею project manager судьбы, довелось мне писать программу, блокирующую все и вся во благо беззащитных деток. Оставим в стороне этическую составляющую вопроса и психическую адекватность родителей, которые выкидывают сотни три-четыре евро на смартфон для дитяти, а потом с завидным упорством ищут софт, который превратит это высокотехнологичное устройство в кирпич десятилетней давности: без интернета, без смс, без звонков, без приложений… без надежды на будущее. Попытка заменить воспитание тотальным контролем – верный способ вырастить безвольного имбецила, но чукча здесь не решатель, чукча кодо-писатель, так что предлагаю сосредоточиться на технической стороне дела.

AndroidManifest.xml

Соответствующие им классы выглядят не намного сложнее и в общем виде соответствуют следующему шаблону:

Нас интересует хронология вызовов, поэтому будем вести лог наступления основных событий.
Результат на лицо в LogCat:

и при каждом вкл/выкл соответсвующей опции получим к примеру:

Все довольно предсказуемо.

Программно.

Сначала проделаем этот нехитрый трюк на примере Bluetooth.

Поведение будет идентично предыдущим запускам и у многих в голове уже наверняка не первый раз пронеслась мысль «зачем, таки, он делает нам доктора и кого он здесь вообще лечит?», но попробуйте запустить тот же код, изменив action на WifiManager.WIFI_STATE_CHANGED_ACTION или ConnectivityManager.CONNECTIVITY_ACTION и тут, привет ребятам из андроид, вы обнаружите, что LogCat показывает следующее:

Фактически, это означает, что onReceive обоих receiver‘ов вызвался сразу, вообще вне зависимости от состояния соответствующих опций и только Bluetooth повел себя корректно.

Вывод

Все вышеописанное воспроизводится на всех версиях Android, начиная с Gingerbread и выше(ниже просто не тестировал).

Что касается непосредственно методов фильтрации звонков, смс, интернета и т.д., то, если не ошибаюсь, тема уже частично освещалась, например здесь. Но, если это интересно, то я мог бы попробовать внести свою лепту так, чтобы никого не дублировать.

Источник

Broadcast (Широковещательные сообщения)

Практическая часть показана в отдельной статье.

Широковещательные сообщения делают приложение более открытым; передавая события, использующие сообщения, вы открываете компоненты своего приложения для сторонних приложений, и сторонние разработчики реагируют на события без необходимости изменять ваше оригинальное приложение. В своём приложении вы можете прослушивать широковещательные сообщения других приложений, заменить или улучшить функциональность собственного (или стороннего) приложения или реагировать на системные изменения и события приложений.

Вы тоже можете организовать отправку широковещательных сообщений, а другие приложения могут обзавестись приёмниками для обработки ваших сообщений.

Приёмник широковещательных сообщений — это компонент для получения внешних событий и реакции на них. Инициализировать передачи могут:

Широковещательные сообщения можно разделить на две группы:

Класс BroadcastReceiver является базовым для класса, в котором должны происходить получение и обработка сообщений, посылаемых клиентским приложением с помощью вызова метода sendBroadcast().

Зарегистрировать экземпляр класса BroadcastReceiver можно динамически в коде или статически в манифесте.

Для статической регистрации в файле манифеста в секции application следует создать секцию receiver и указать класс приёмника. Атрибут android:exported=»true» сообщает получателю, что он может принимать широковещательные сообщения вне области приложения. Внутри секции указывается фильтр намерений в виде строки, чтобы определить, какие сообщения приёмник должен прослушивать.

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

Динамическая регистрация происходит с помощью метода Context.registerReceiver().

Перед этим создаётся класс, расширяющий базовый класс BroadcastReceiver и реализуется метод обратного вызова onReceive() обработчика событий.

Метод onReceive() будет выполнен при получении широковещательного намерения, если полученное намерение соответствует фильтру. Приложения с зарегистрированными приёмниками широковещательных намерений будут запущены автоматически при получении соответствующего намерения. Метод должен быть завершён в течение пяти секунд, иначе появится диалоговое окно о принудительном закрытии.

Когда широковещательное сообщение прибывает для получателя сообщения, Android вызывает его методом onReceive() и передаёт в него объект Intent, содержащий сообщение. Приёмник широковещательных сообщений является активным только во время выполнения этого метода. Процесс, который в настоящее время выполняет BroadcastReceiver, т. е. выполняющийся в настоящее время код в методе обратного вызова onReceive(), как полагает система, является приоритетным процессом и будет сохранён, кроме случаев критического недостатка памяти в системе.

Когда программа возвращается из метода onReceive(), приёмник становится неактивным и система полагает, что работа объекта BroadcastReceiver закончена. Процесс с активным широковещательным получателем защищён от уничтожения системой. Однако процесс, содержащий неактивные компоненты, может быть уничтожен системой в любое время, когда память, которую он потребляет, будет необходима другим процессам.

Это представляет проблему, когда ответ на широковещательное сообщение занимает длительное время. Если метод onReceive() порождает отдельный поток, а затем возвращает управление, то полный процесс, включая и порождённый поток, система Android считает неактивным (если другие компоненты приложения не активны в процессе), и считает этот процесс кандидатом на уничтожение.

В частности, вы не можете отобразить диалог или осуществить связывание со службой внутри экземпляра BroadcastReceiver. Для первого случая необходимо вместо этого использовать методы класса NotificationManager. Во втором случае можно использовать вызов метода Context.startService(), чтобы послать команду для запуска службы.

Решение этой проблемы возможно, если запустить в методе onReceive() отдельную службу вместе с BroadcastReceiver и позволить службе выполнять задание, чтобы сохранить содержание процесса активным в течение всего времени вашей операции.

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

Это может быть полезным, когда приёмник используется для обновления элементов пользовательского интерфейса внутри активности, запуска служб или уведомления через NotificationManager. В таких случаях вы можете отменять регистрацию широковещательного приёмника, если активность не отображается на экране или находится в неактивном состоянии.

В коде программы можете написать приблизительно такой код (обычно используют метод onResume()):

Для отмены регистрации используется метод unregisterReceiver() в контексте приложения, передавая ему в качестве параметра экземпляр широковещательного приёмника (обычно в методе onPause()):

Для объекта BroadcastReceiver нет никаких возможностей видеть или фиксировать намерения, используемые в методе startActivity(). Аналогично, когда вы передали намерение для запуска активности через объект BroadcastReceiver, вы не сможете найти или запустить требуемую активность. Эти две операции семантически полностью различаются: запуск активности через намерение является приоритетной операцией для системы, изменяющей содержимое экрана устройства, с которым в настоящее время взаимодействует пользователь. Передача широковещательных сообщений для системы является фоновой работой, о которой обычно не знает пользователь и которая, соответственно, имеет более низкий приоритет.

Приёмники системных событий

Android использует широковещательные сообщения для системных событий, таких как уровень зарядки батареи, сетевые подключения, входящие звонки, изменения часового пояса, состояние подключения данных, входящие сообщения SMS или обращения по телефону. Вы можете использовать эти сообщения, чтобы добавлять к вашим собственным проектам новые функциональные возможности, основанные на системных событиях.

Следующий список показывает некоторые из встроенных действий, представленных как константы в классе Intent, которые используются для того, чтобы проследить изменения состояния устройства:

Типы трансляций

Есть три способа отправки трансляций

Если важно, чтобы приёмники получали намерения в определённом порядке или могли влиять на транслируемое намерение, можно использовать метод sendOrderedBroadcast():

С помощью этого метода ваше намерение дойдёт до всех зарегистрированных приёмников, обладающих необходимым доступом (если он был указан), в порядке их приоритета. Приоритет задаётся с помощью атрибута android:priority внутри узла фильтра намерений в манифесте. Чем больше значение, тем выше приоритет.

Производить упорядоченные трансляции с использованием приоритетов рекомендуется только для тех приёмников, которым необходим конкретный порядок приёма сообщений.

Ограничения в Android 8.0 Oreo (API 26)

Часть неявных (implicit) широковещательных сообщений, задаваемых через манифест, запретили. Теперь нужно регистрировать их программно. Существует список исключений, которые будут работать как прежде без ограничений.

В качестве замены для некоторых случаев подойдёт JobScheduler.

Примерами устаревшего способа работы с приёмником является android.net.conn.CONNECTIVITY_CHANGE, ACTION_POWER_CONNECTED и др.

Ограничения в Android 9.0 Pie (API 28)

Стало доступно меньше информации, получаемой при трансляции системы Wi-Fi и Network_State_Changed_Action.

Источник

Android BroadcastReceiver, реализации

Например: мы можем попросить BroadcastReceiver уведомлять нас обо всех изменениях с сетью интернет. И как только у нас пропадет интернет или включится, мы получим соответствующее уведомление.

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

Пересылка сообщений и их получение происходит с помощью определенного идентификатора (почтового адреса). Об этом я расскажу подробнее чуть ниже.

Итак, есть несколько способов, как работать с BroadcastReceiver. Каждый способ удобен в своей ситуации, которая зависит от поставленных задач.

Способ номер 1

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

Это удобно, если необходимо получать уведомления даже в тех случаях, кода приложение не запущено (т. е. мы будем выполнять некоторый код и пользователь даже ничего не узнает хе-хе:) ).

Итак, во первых мы должны создать получателя сообщений. Это будет метод, который будет срабатывать, как только мы получим уведомление от BroadcastReceiver. Для этого необходимо создать реализацию абстрактного класса BroadcastReceiver и переопределить метод onReceive.
Вот так:

Мы создали свой класс MyBroadcastReceiver.java и наследовались от BroadcastReceiver в котором находится абстрактный метод onReceive(), его мы должны обязательно реализовать. В данном примере мы просто выводим в консоль LogCat сообщение.

Метод onReceive() будет срабатывать, как только к нам придет уведомление на которое мы зарегестрировались (купили подписку журнала:) ).

Теперь нам необходимо как-то сообщить BroadcastReceiver какие сообщения мы хотим получать и куда присылать уведомление (т. е. нам надо указать, что-бы уведомления приходили в наш класс MyBroadcastReceiver.java, который мы создали выше).

Для этого необходимо сделать дополнительную запись в файле AndroidManifest.xml. Внутри тега — там, где у нас прописаны наши Активити, необходимо дописать следующие строки:

На этом все. Вот полный код AndroidManifest.xml, что-бы видеть куда вписать MyBroadcastReceiver.

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

На практике этот способ не распростанен, так как это не самое лучшее решение, постоянно быть подписанным на уведомления. Это отжирает ресурсы системы, да и не очень хорошо все таки делать что-либо в неведении пользователя.

КОГДА ИСПОЛЬЗОВАТЬ ДАННЫЙ МЕТОД

Способ номер 2

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

Хорошим вариантом будет включать уведомления, когда пользователь открывает Activity и отключать, как только он закрывает Activity.

Сперва, как и в предыдущем способе нам необходим метод, который будет срабатывать, как только к нам придет уведомление:

Подробнее об этом классе почитайте в способе 1, если пропустили или забыли.

А вот теперь самое интересное. Если мы хотим включать и отключать уведомления самостоятельно, нам не нужно прописывать их в AndroidManifest.xml. Так что, если у вас остался код с предыдущего способа, удалите его или закомментируйте.

Теперь идем в нашу Activity в которой мы хотим включать и останавливать уведомления. Для этого отлично подойдут методы onResume(), который срабатывает на старте Activity и метод onPause(), который срабатывает когда мы уходим с Activity. Напишем в этих методах код для включения и отключения уведомлений:

Далее мы вызываем метод registerReceiver() и указываем в нем объект класса, в который мы хотим получать уведомления + указываем объект класса IntentFilter, который говорит Андроиду, какие уведомления мы хотим получать

Метод registerReceiver() доступен в Activity, так как находится в классе Context от которого наследуется стандартный класс Activity.

Что-бы отписаться от уведомлений используется метод unregisterReceiver(), в который подаем объект нашего класса MyBroadcastReceiver. Т. e. мы говорим Андроиду, что мы больше не хотим получать уведомления в класс MyBroadcastReceiver.

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

Способ номер 3

Задача: Предположим, что мы хотим что-то поменять в интерфейсе в момент, когда пришло уведомление. Нам необходимо иметь доступ к интерфейсу (Activity).

Этот способ почти не отличается от способа номер 2, просто тут мы разместили код для получения уведомлений прямо в классе Activity т. е. мы перенесем MyBroadcastReceiver в класс Activity.

Сделаем это с помощью анонимного класса вот так:

Теперь все уведомления будут приходить в наш анонимный класс, в котором будет вызываться метод onReceive(). Код внутри метода onReceive() выполняется в том же потоке, что и интерфейс, так что у нас нет никаких проблем поменять что-то в интерфейсе прямо из метода onReceive().

Этот способ самый распространенный в Андроид.

КОГДА ИСПОЛЬЗОВАТЬ ДАННЫЙ МЕТОД

Спасибо, что дочитали до конца! Успехов вам в изучении реально крутой платформы Android!

Источник