Com android cellbroadcastreceiver что это

Android Broadcast Receivers для начинающих

Перевод статьи на Медиуме о технологии Broadcast Receivers (широковещательные приемники). Это компоненты андроид, которые отслеживают широковещательные сообщения (broadcast messages) или события (events).

Для чего нужны Broadcast Receivers?

Допустим, у вас есть приложение, которое зависит от постоянного интернет-соединения. Вы хотите, чтобы ваше приложение получало уведомление при изменении интернет-соединения. Как это сделать? Возможным решением будет сервис, который всегда проверяет интернет-соединение. Эта реализация плоха по разным причинам, поэтому мы не будем ее рассматривать. Решением этой проблемы является широковещательный приемник (Broadcast Receiver), который прослушивает изменения, о которых вы сообщаете. Получатель трансляции всегда будет получать уведомления о трансляции, независимо от состояния вашего приложения. Неважно, работает ли ваше приложение в фоновом режиме или вообще не работает.

Теория Broadcast Receivers

Широковещательные приемники — это компоненты в вашем приложении Android, которые прослушивают широковещательные сообщения (или события) из разных точек:

• Из других приложений
• Из самой системы
• Из вашего приложения

Это означает, что они вызываются, когда происходит определенное действие, которое они запрограммированы на прослушивание, например, трансляция ( broadcast).

Трансляция ( broadcast) — это просто сообщение, заключенное в объект Intent. Трансляция может быть неявной или явной.

• Неявная широковещательная трансляция ( implicit broadcast) — это такая, которая не предназначена специально для вашего приложения, поэтому она не является эксклюзивной для вашего приложения. Чтобы зарегистрироваться, вам нужно использовать IntentFilter и объявить его в своем манифесте. Вы должны сделать все это, потому что операционная система Android просматривает все объявленные фильтры намерений (IntentFilter) в вашем манифесте и проверяет, есть ли совпадение. Из-за этого поведения неявные широковещательные сообщения не имеют целевого атрибута. Примером неявной трансляции может быть действие входящего SMS-сообщения.
• Явная трансляция ( explicit broadcast) — это то, что предназначено специально для вашего приложения на заранее известном компоненте. Это происходит из-за атрибута target, который содержит имя пакета приложения или имя класса компонента.

Есть два способа объявить приемник:

1.Объявив его в файле AndroidManifest.xml с тегом (также называемый статическим способом):

Вы заметите, что заявленный широковещательный приемник имеет свойство exported = ”true”. Этот атрибут сообщает получателю, что он может принимать широковещательные сообщения вне области приложения.

2. Или динамически путем регистрации экземпляра с помощью registerReceiver (так называемый зарегистрированный контекст):

Реализация Broadcast Receivers

Чтобы создать собственный широковещательный приемник, вы должны сначала расширить родительский класс BroadcastReceiver и переопределить обязательный метод onReceive:

Собрав все вместе, получим:

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

Если выполняется долгий процесс, система может завершить процесс после возврата метода. Чтобы обойти это, рассмотрите возможность использования goAsync или планировщиков заданий (scheduling a job). Вы можете прочитать больше об этом в нижней части этой статьи.

Пример динамической регистрации

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

Затем вы можете зарегистрировать его в зависимости от конкретного контекста, который вы хотите:

Первый параметр для IntentFilter — это строка, представляющая действие.

Не забудьте отменить регистрацию вашего вещательного приемника, когда он вам больше не нужен

Трансляция события

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

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

1. Метод sendOrderedBroadcastобеспечивает одновременную отправку широковещательных сообщений только одному получателю. Каждая широковещательная трансляция может, в свою очередь, передавать данные той, которая следует за ней, или останавливать распространение широковещательной трансляции для следующих получателей.
2. Метод sendBroadcastпохож на метод, упомянутый выше, с одним отличием. Все широковещательные приемники получают сообщение и не зависят друг от друга.
3. Метод LocalBroadcastManager.sendBroadcast отправляет широковещательные сообщения только получателям, определенным в вашем приложении, и не выходит за рамки вашего приложения.

На что обратить внимание

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

Изменения в новых версиях

Следующие пункты относятся к изменениям в широковещательных приемниках, относящихся к каждой версии ОС Android (начиная с 7.0). Для каждой версии были установлены определенные ограничения, а также изменилось поведение. Помните об этих ограничениях, думая об использовании Broadcast Receivers.

• 7.0 и выше (уровень API 24) — две системные трансляции были отключены, Action_New_Picture и Action_New_Video (но они были возвращены в Android O для зарегистрированных получателей)
• 8.0 и выше (уровень API 26). Большинство неявных трансляций необходимо регистрировать динамически, а не статически (в вашем манифесте). Вы можете найти трансляции, которые были внесены в белый список по этой ссылке.
• 9.0 и выше (уровень API 28) — Меньше информации, получаемой при трансляции системы Wi-Fi и Network_State_Changed_Action.

Изменения в Android O — это те, о которых вам нужно знать больше всего. Причина, по которой эти изменения были внесены, заключалась в том, что они приводили к проблемам с производительностью, разрядке аккумулятора и ухудшали работу пользователя. Это произошло из-за того, что многие приложения (даже те, которые в данный момент не запущены) прослушивали общесистемные изменения, и когда это изменение произошло, возник хаос. Представьте, что каждое приложение, зарегистрированное на действия, ожило, чтобы проверить, нужно ли что-то делать из-за трансляции. Примите во внимание что-то вроде состояния Wi-Fi, которое часто меняется, и вы начнете понимать, почему произошли эти изменения.

Альтернативы Broadcast Receivers

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

• LocalBroadcastManager — Как я уже упоминал выше, это действительно только для трансляций в вашем приложении
• Scheduling A Job (Планирование задания) — задание может быть запущено в зависимости от полученного сигнала или триггера, поэтому вы можете обнаружить, что прослушиваемая трансляция может быть заменена заданием. Кроме того, JobScheduler гарантирует, что ваша работа будет завершена, но он будет учитывать различные системные факторы (время и условия), чтобы определить, когда он должен работать. При создании задания вы переопределите метод с именем onStartJob. Этот метод выполняется в основном потоке, поэтому убедитесь, что он завершает свою работу за ограниченное время. Если вам нужно выполнить сложную логику, подумайте о запуске фоновой задачи. Кроме того, возвращаемое значение для этого метода является логическим, где true означает, что определенные действия все еще выполняются, а false означает, что задание выполнено.

Ссылки на исходники

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

Источник

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

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

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

Конкретная подзадача такого рода программ: получать уведомления о смене состояний мобильного интернета, Wi-Fi, Bluetooth и блокировать их в зависимости от степени параноидальности опекающего. Как известно, такого рода оповещения в андроиде реализованны через BroadcastReceiver ‘ы. Также, не секрет, что зарегистрировать receiver можно двумя способами: в файле AndroidManifest.xml и непосредственно в Activity (или Service , как вариант). Рассмотрим оба способа.

AndroidManifest.xml

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

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

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

Application	Tag	Text
com.habr	MyActivity	onCreate

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

Application	Tag	Text
com.habr	WiFiReceiver	onReceive

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

Программно.

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

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

Application	Tag	Text
com.habr	MyActivity	onCreate
com.habr	WiFiReceiver	onReceive
com.habr	DataReceiver	onReceive

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

Вывод

Представьте себе простую ситуацию: задача приложения оборвать интернет. В момент установки приложения, он может быть как включенным так и выключенным. Если он уже включен, и вы регистрируетесь через AndroidManifest.xml , то вам, just to be sure, придется вызвать код блокировки из receiver‘a самостоятельно, т.к. системой вы оповещены не будете и это правильно, потому что вы опоздали на обед, соответствующее оповещение пробросилось, когда вас с вашим приложением в системе еще не было. Если же вы все сделали программно, то делать отдельный вызов не придется. Опять же, при условии, что дело не касается Bluetooth. Если задаться вопросом «А, собсна, какого почему?», то ответ скорее всего будет «Потому что могем!». Как по мне, так это чистой воды баг и логики никакой не просматривается. Надеюсь эта статья сэкономит кому-то тот день, который я убил, чтобы понять в чем причина непослушания адской машины.

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

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

Источник

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

Broadcast Receiver — это механизм для отсылки и получения сообщений в Android. Другими словами — это почта, через которую мы можем отправить письмо, а также можем попросить эту почту, доставлять нам письма определенного содержания (как буд-то купили подписку на журнал).

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

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

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

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

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

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

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

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

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

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

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

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

by.kiparo.test.MyBroadcastReceiver — это класс который мы создали для получения уведомления. Этой строчкой мы говорим Андроиду, куда необходимо присылать уведомления. То есть, теперь Андроид знает, что необходимо отсылать уведомления в класс MyBroadcastReceiver, а в нем уже будет вызван метод onReceive().

Дальше в теге прописывается идентификатор(ы) (почтовый адрес) того, какие уведомления мы хотим получать. В данном случае, мы хотим получать уведомления с адресом: android.net.conn.CONNECTIVITY_CHANGE — это уведомления, которые происходят при изменении состояния сети (например отключился или включился интернет).

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

Если вы заметили, тут еще приписан пермишен , в котором мы говорим Андроиду, что нам необходим доступ к состоянию сети. Это разрешение необходимо, если мы хотим проверять состояние сети, что мы и делаем в нашем MyBroadcastReceiver.

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

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

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

• мы не можем остановить получение уведомлений
• из метода onReceive() мы не имеем доступа к интерфейсу, так как приложение может быть не запущено в момент, когда пришло уведомление, да и у нас нет никакой ссылки на Activity

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

• только тогда, когда нам необходимо получать уведомления всегда и всюду, даже если приложение не запущено.

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

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

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

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

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

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

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

myBroadcastReceiver — это мы создали объект класса в который хотим получать уведомление (мы уже создали его выше). IntentFilter — это системный класс (в Android библиотеке), в котором мы указываем, какие уведомления мы хотим получать. В этот класс записывается идентификатор (почтовый адрес), того какие уведомления мы хотим получать. В данном случае мы указываем ConnectivityManager.CONNECTIVITY_ACTION, это переменная в которой хранится название уведомления. Мы указывали это название (android.net.conn.CONNECTIVITY_CHANGE) в AndroidManifest.xml в первом способе.

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

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

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

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

Этот способ применяется крайне редко, даже реже чем способ .

• мы получаем уведомления только тогда, когда нам необходимо
• мы сами контролируем, когда включить уведомления, а когда отключить

• из метода onReceive() мы по прежнему не имеем доступа к интерфейсу, так как у нас нет никакой ссылки на Activity в классе MyBroadcastReceiver. Конечно, мы можем отправить в этот класс ссылку на нашу Activity в момент создания объекта MyBroadcastReceiver, но есть более удобный способ для этого. Об этом в способе 3.

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

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

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

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

Это должно быть внутри класса Активити. Методы onResume() и onPause() остались без изменения. Отдельный класс MyBroadcastReceiver нам не нужен — его можно удалить.

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

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

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

• необходимо обязательно отписываться от уведомлений, иначе будет утечка памяти

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

• тогда, когда нам необходимо самим контролировать включение и отключение уведомлений, а также изменять интерфейс

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

Источник