“Universidad Nacional de Trujillo”
Escuela Académica-Profesional:
Ingeniería de Sistemas
Curso:
Temas Avanzados de Ingeniería de Sistemas II
Tema:
Broadcast receiver
Integrantes:
1. Aranda Carranza, Jean Piero
2. Pastor Varas, Pitter
3. Rodríguez Lázaro, Héctor Eduardo
4. Sucre Gamboa, Carlos Andrés
5. Yoplac Torres Miguel Humberto
Docente:
Ing. Robert Sanchez Ticona
Ciclo:
Decimo Ciclo
2019-Trujillo
BroadcastReceiver
Un Broadcast Receiver es el componente que está destinado a recibir y responder ante eventos
globales generados por el sistema, como un aviso de batería baja, un SMS recibido, un SMS enviado,
una llamada, un aviso de la tarjeta SD, etc. y también a eventos producidos por otras aplicaciones.
Un BroadcastReceiver es básicamente un mecanismo para transmitir intenciones a través del
sistema operativo para realizar acciones específicas. Una definición clásica siendo
"Un receptor de difusión es un componente de Android que le permite registrarse para eventos del
sistema o de la aplicación".
Intent
Un intent sirve para invocar componentes, en android entendemos por componentes
las activities, Que son componentes de UI [Interfaz gráfica], services, Código ejecutándose en
segundo plano, broadcast receivers, Código que responde a un mensaje de transmisión [Broadcast
messages] y proveedores de contenido, código que abstráe los datos.
Básicamente nos permiten llamar a aplicaciones externas a la nuestra, lanzar eventos a los que otras
aplicaciones puedan responder, lanzar alarmas etc.
IntentFilter
Cuando creamos una nueva actividad, servicio o receptor broadcast, podemos informar al sistema
del tipo de intenciones implícitas que se pueden resolver con nuestro componente. Para ello
utilizaremos un filtro de intenciones mediante la etiqueta <intent-filter> de [Link].
Cuando desarrollamos una aplicación, lo habitual es utilizar intenciones explicitas, que se resuelven
utilizando el nombre de la clase. Por lo tanto, si vamos a llamar a nuestro componente de forma
explícita, no tiene sentido crear un filtro de intenciones.
LocalBroadcastManager es una forma de enviar o recibir transmisiones dentro de un proceso de
solicitud. Este mecanismo tiene muchas ventajas.
1. Ya que los datos permanecen dentro del proceso de la aplicación, los datos no se pueden
filtrar.
2. Las transmisiones locales se resuelven más rápido, ya que la resolución de una transmisión
normal ocurre en el tiempo de ejecución en todo el sistema operativo.
¿Qué es Broadcast receiver?
Un receptor puede ser registrado a través del archivo [Link] o por el método
[Link]().
public class MyReceptor extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
Aquí he tomado un ejemplo de ACTION_BOOT_COMPLETED que es disparado por el sistema una
vez que Android ha completado el proceso de arranque.
Ejemplo a través del archivo “manifest”.
<application
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<receiver android:name="MyReceiver">
<intent-filter>
<action android:name="[Link].BOOT_COMPLETED">
</action>
</intent-filter>
</receiver>
</application>
USANDO ORDERED BROADCASTS
Ordered broadcasts son usados cuando necesitas especificar una prioridad para un broadcast
listeners.
En este ejemplo el primerReceptor recibirá un broadcast mucho antes que el segundoReceptor:
final int highPriority = 2;
final int lowPriority = 1;
final String action = "action";
// intent filter para el primer receptor con alta prioridad
final IntentFilter primerFilter = new IntentFilter(action);
first [Link](highPriority);
final BroadcastReceiver primerReceptor = new MyReceiver();
// intent filter para el segundo receptor con prioridad baja
final IntentFilter segundoFilter = new IntentFilter(action);
[Link](lowPriority);
final BroadcastReceiver segundoReceptor = new MyReceiver();
// Registrar nuestros receptores
[Link](primerReceptor, primerFilter);
[Link](segundoReceptor, segundoFilter);
// enviar un ordered broadcast
[Link](new Intent(action), null);
Sticky broadcast
Antes se definió broadcast como un disparador de información soltado por el sistema Android, la
diferencia de los sticky broadcast sobre un broadcast común es que son estáticos, pueden ser
consultados regularmente mientras los otros son volátiles.
El ejemplo clásico de un sticky broadcast es el nivel de batería, si una aplicación busca conocer el
nivel de la batería, puede ser accedido en cualquier momento mientras tenga el permiso para ello.
Mientras no es recomendable enviar sticky broadcast debido a consideraciones de seguridad, estas
son muy útiles para obtener datos del equipo.
Como habilitar/deshabilitar “Broadcast Receiver”
Los receptores de eventos o acciones del equipo no tienen que estar siempre activos, ya que como
es natural consumen recursos, asi que es necesario que solo estén activo en los momentos debidos,
para poder tener un control de cuando activarlo y desactivarlo se debe hacer uso de la clase
PacketManager a la cual se referencia un componente que en nuestro caso es el “Broadcast
receiver”
ComponentName componentName = new ComponentName(context,
[Link]);
PackageManager packageManager = [Link]();
Una vez se tiene abstraídas estas entidades se aplican códigos simples de cambio de estado de
componente como se ve abajo.
[Link](
componentName,
PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
PackageManager.DONT_KILL_APP);
[Link](
componentName,
PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
PackageManager.DONT_KILL_APP);
Comunica dos actividades a través del Broadcast Receiver personalizado
• Puede comunicar dos actividades para que la Actividad A pueda ser notificada de un evento
que ocurre en la Actividad B.
BroadcastReceiver para manejar eventos BOOT_COMPLETED
• El siguiente ejemplo muestra cómo crear un BroadcastReceiver que puede recibir eventos
BOOT_COMPLETED. De esta manera, puede iniciar un Servicio o iniciar una Actividad tan
pronto como se encienda el dispositivo.
• Además, puede usar los eventos BOOT_COMPLETED para restaurar sus alarmas, ya que se
destruyen cuando el dispositivo se apaga.
• NOTA: El usuario debe haber iniciado la aplicación al menos una vez antes de que pueda
recibir la acción BOOT_COMPLETED.
