Register broadcast receiver android

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!

Источник

Android BroadcastReceiver — Tutorial

Using Broadcast receivers in Android. This tutorial describes how to create and consume broadcast receivers in Android.

1. Broadcast receiver

1.1. Definition

A broadcast receiver (receiver) is an Android component which allows you to register for system or application events. All registered receivers for an event are notified by the Android runtime once this event happens.

For example, applications can register for the ACTION_BOOT_COMPLETED system event which is fired once the Android system has completed the boot process.

1.2. Implementation

A receiver can be registered via the AndroidManifest.xml file.

Alternatively to this static registration, you can also register a receiver dynamically via the Context.registerReceiver() method.

The implementing class for a receiver extends the BroadcastReceiver class.

If the event for which the broadcast receiver has registered happens, the onReceive() method of the receiver is called by the Android system.

1.3. Life cycle of a broadcast receiver

After the onReceive() of the receiver class has finished, the Android system is allowed to recycle the receiver.

1.4. Asynchronous processing

Before API level 11, you could not perform any asynchronous operation in the onReceive() method, because once the onReceive() method had been finished, the Android system was allowed to recycle that component. If you have potentially long running operations, you should trigger a service instead.

Since Android API 11 you can call the goAsync() method. This method returns an object of the PendingResult type. The Android system considers the receiver as alive until you call the PendingResult.finish() on this object. With this option you can trigger asynchronous processing in a receiver. As soon as that thread has completed, its task calls finish() to indicate to the Android system that this component can be recycled.

1.5. Restrictions for defining broadcast receiver

As of Android 3.1 the Android system excludes all receiver from receiving intents by default if the corresponding application has never been started by the user or if the user explicitly stopped the application via the Android menu (in Manage Application ).

This is an additional security feature as the user can be sure that only the applications he started will receive broadcast intents.

1.6. Send the broadcast to your application for testing

You can use the following command from the adb command line tool. The class name and package names which are targeted via the command line tool need to be as defined in the manifest. You should send the intent you generated to your specific component, for example if you send a general ACTION_BOOT_COMPLETED broadcast, this will trigger a lot of things in an Android system.

1.7. Pending Intent

A pending intent is a token that you give to another application. For example, the notification manager, alarm manager or other 3rd party applications). This allows the other application to restore the permissions of your application to execute a predefined piece of code.

To perform a broadcast via a pending intent, get a PendingIntent via the getBroadcast() method of the PendingIntent class. To perform an activity via a pending intent, you receive the activity via PendingIntent.getActivity() .

2. System broadcasts

Several system events are defined as final static fields in the Intent class. Other Android system classes also define events, e.g., the TelephonyManager defines events for the change of the phone state.

The following table lists a few important system events.

Boot completed. Requires the android.permission.RECEIVE_BOOT_COMPLETED permission

Power got connected to the device.

Power got disconnected to the device.

Triggered on low battery. Typically used to reduce activities in your app which consume power.

Battery status good again.

3. Automatically starting Services from a Receivers

A common requirement is to automatically start a service after a system reboot, i.e., for synchronizing data. For this you can register a receiver for the android.intent.action.BOOT_COMPLETED system event. This requires the android.permission.RECEIVE_BOOT_COMPLETED permission.

The following example demonstrates the registration for the BOOT_COMPLETED event in the Android manifest file.

The receive would start the service as demonstrated in the following example code.

4. Exercise: Register a receiver for incoming phone calls

4.1. Target

In this exercise you define a broadcast receiver which listens to telephone state changes. If the phone receives a phone call, then our receiver will be notified and log a message.

4.2. Create project

Create a new project called de.vogella.android.receiver.phone . Also create an activity.

TIP:Remember that your receiver is only called if the user started it once. This requires an activity.

4.3. Implement receiver for the phone event

Create the MyPhoneReceiver class.

4.4. Request permission

Add the android.permission.READ_PHONE_STATE permission to your manifest file which allows you to listen to state changes in your receiver. Also Register your receiver in your manifest file. The resulting manifest should be similar to the following listing.

4.5. Validate implementations

Install your application and simulate a phone call via the emulator controls. Validate that your receiver is called and logs a message to the LogCat view.

5. Exercise: System services and receiver

5.1. Target

In this chapter we will schedule a receiver via the Android alert manager system service. Once called, it uses the Android vibrator manager and a popup message (Toast) to notify the user.

5.2. Implement project

Create a new project called de.vogella.android.alarm with the activity called AlarmActivity.

Create the following layout.

Create the following broadcast receiver class. This class will get the vibrator service.

Register this class as a broadcast receiver in AndroidManifest.xml and request authorization to vibrate the phone.

Change the code of your AlarmActivity class to the following. This activity creates an intent to start the receiver and register this intent with the alarm manager service.

5.3. Validate implementation

Run your application on the device. Set your time and start the alarm. After the defined number of seconds a Toast should be displayed. Keep in mind that the vibration alarm does not work on the Android emulator.

6. Dynamic broadcast receiver registration

6.1. Dynamically registered receiver

Receiver can be registered via the Android manifest file. You can also register and unregister a receiver at runtime via the Context.registerReceiver() and Context.unregisterReceiver() methods.

6.2. Using the package manager to disable static receivers

You can use the PackageManager class to enable or disable receivers registered in your AndroidManifest.xml file.

6.3. Sticky (broadcast) intents

An intent to trigger a receiver ( broadcast intent ) is not available anymore after it was sent and processed by the system. If you use the sendStickyBroadcast(Intent) method, the corresponding intent is sticky, meaning the intent you are sending stays around after the broadcast is complete.

The Android system uses sticky broadcast for certain system information. For example, the battery status is send as sticky intent and can get received at any time. The following example demonstrates that.

You can retrieve that data through the return value of registerReceiver(BroadcastReceiver, IntentFilter) `. This also works for a null `BroadcastReceiver .

In all other ways, this behaves just as sendBroadcast(Intent) .

Sticky broadcast intents typically require special permissions.

Источник