La mayoría de nosotros estamos demasiado familiarizados con los anuncios en los lugares públicos. Son claros mensajes de que están destinados a informa a grupos grandes de personas acerca de algo importante. Las aplicaciones Android, también tienen que tratar con anuncios algunas veces: los anuncios generados ya sea por otras aplicaciones o por el mismo sistema operativo Android. Tales anuncios son llamados broadcasts y son vistos como una forma importante del proceso interno de comunicación en la plataforma Android. Un receptor de mensajes es un componente que responde a los anuncios de mensajes en todo el sistema, por ejemplo, un mensaje que anuncie que se apagó la pantalla, que la batería tiene poca carga o que se tomó una foto.
Las aplicaciones también pueden iniciar mensajes; por
ejemplo, para permitir que otras aplicaciones sepan que se descargaron datos al dispositivo y están disponibles para usarlos. Si bien los receptores de mensajes no exhiben una interfaz de usuario, pueden crear una notificación de la barra de estado para alertar al usuario cuando se produzca un evento de mensaje. Aunque, comúnmente, un receptor de mensajes es simplemente una "puerta de enlace" a otros componentes y está destinado a realizar una cantidad mínima de trabajo. Por ejemplo, podría iniciar un servicio para que realice algunas tareas en función del evento. En pocas palabras… Un Broadcast Receiver puede verse como un listener que atiende a eventos del sistema, esto es, lanzados por el sistema operativo, o bien a eventos lanzados por aplicaciones. Además, el evento puede incluir información adicional en un Intent. Nos encontramos por tanto ante un mecanismo que nos permitirá integrar aplicaciones entre sí y/o con Android, pero también establecer un canal de comunicación interno entre componentes (activities, fragments…) de una misma app.
Los broadcasts de Android son enviados en la forma de objetos Intent. Por lo
tanto, antes de crear un broadcast, primero debe crear un objeto Intent. En pocas palabras… Un componente de tipo BroadcastReceiver debe ser registrado como un receptor de eventos en la aplicación a través del fichero AndroidManifest.xml.
• Cuando un evento ocurre los BroadcastReceivers son representados como un
Intent. • Estos Intents son entonces transmitidos al sistema. • Android ruta los Intents que se han registrado al BroadcastReceiver para recibirlos. • BroadcastReceiver recibe el Intent a través del método onReceive(). Casos típicos de uso • Registro de BroadcastReceiver para recibir Intents específicos. • Transmisión e Intent: algunos componentes generan un Intent y luego lo transmiten al sistema. • Android ofrece Intents para registrar receptores llamando al método onReceive(). • El evento se controla en el método onReceive(). Registro para los Intents Estáticamente en el AndroidManifest.xml. Añadiendo las etiquetas : <receiver> e <intent-filter>. Registro para los Intents Las etiquetas <intent-filter> pueden especificar cosas como acciones, datos y categorías. Esta información será leída y procesada cuando el sistema arranca o cuando el paquete de la aplicación es añadido mientras el sistema está en funcionamiento.
• Dinámicamente llamando al método onReceiver().
1. Creamos un IntentFilter. 2. Creamos un BroadcastReceiver. 3. Registramos el BroadcastReceiver usando el método registerReceiver(). 4. Usamos la clase LocalBroadcastManager. Es solo para el uso de la aplicación que estemos desarrollando. 5. Usamos la clase Context. Puede ser recibida por otra aplicación de nuestro dispositivo. 6. Llamamos al método unRegisterReceiver() para anular el registro. Los Broadcast pueden ser también sticky o non-stycky. • Sticky (pegajoso): un Sticky Intent es también un tipo de Intent que permite una comunicación entre la función y un servicio. sendStickyBroadcast() realiza un Intent Broadcast conocido como pegajoso. El Intent que estamos enviando a las estancias se completa después de la emisión y así se pueden recuperar rápidamente los datos a través del valor de retorno del registerReceiver(BroadcastReceiver, IntentFilter).
• Non-Sticky: un Non-Sticky Broadcast por el contrario se
descartan después de su emisión final. Estos Broadcasts son más adecuados, por lo tanto nos indican que un evento ha ocurrido. GESTIÓN DE EVENTOS EN ONRECEIVE() Para entregar un Broadcast, Android puede tener que iniciar el proceso de solicitud de un receptor porque en realidad podría no estar en ejecución cuando el Intent es transmitido.
El método onReceive() se ejecuta en el hilo principal del proceso y
como todo lo que hacemos en el hilo principal debe ser de corta duración y no debe bloquear al hilo principal. Si la gestión de eventos es de larga duración debemos considerar de iniciar un Service, en lugar de realizar la operación completa en el método onReceive(). MANEJO DE EVENTOS EN ONRECEIVE() Un BroadcasReceiver es considerado valido solo mientras onReceive() esta ejecutandose. De echo, una vez que onReceive() es retornado Android a menudo terminará el BroadcastReceiver subyacente.
En particular, esto significa que los BroadcastReceivers no pueden
poner en marcha operaciones, tendrán que llamar de nuevo al receptor de forma asíncrona posteriormente.