Mecanismos para el envío de notificaciones a los usuarios de nuestra aplicación (parte I)

lunes, junio 18, 2012 at 9:21PM
rmontero in Artículos Android, notificaciones PUSH

1. Introducción

 Está clara la tendencia de las empresas que tratan de proporcionar un valor añadido a sus servicios ofertados, creando aplicaciones instalables en los terminales móviles de sus clientes.  Desde este tipo de aplicaciones un cliente podrá acceder a sus pedidos, facturas y demás servicios ofrecidos por la compañía. Lo que se pretende es tener una relación más cercana de la compañía con sus clientes. Esta concordancia entre cliente y proveedor debería promover una comunicación bidireccional: 

•  Del usuario hacia la empresa: Comunicación que proporciona un “feedback” por el cual el usuario podrá exponer a la empresa sus sugerencias o valoraciones, permitiendo así a la compañía realizar una mejora evolutiva de sus servicios, adaptándolos a las realidades de sus clientes. La implementación de esta comunicación es sencilla, basta con añadir formularios de envío de sugerencias y sistemas de valoración a la aplicación instalada en el cliente.
• De la empresa hacia el usuario: Hasta hace poco tiempo este canal había evolucionado desde el servicio postal ordinario o las llamadas telefónicas hacia el envío de correos electrónicos y SMS. En la actualidad, este tipo de comunicación se está dirigiendo hacia los sistemas de notificación PUSH. Es decir, una vez que un cliente se ha instalado nuestra aplicación, podremos hacerle llegar mensajes asociados a dicha aplicación, tanto de carácter personal o de tipo generalizado (a un cliente en concreto o a todos los usuarios que dispongan de la aplicación). Este mecanismo resulta de gran utilidad si queremos promocionar un nuevo producto o servicio entre nuestros clientes o si  por ejemplo, deseamos mantener informado a un consumidor de los cambios de estado en su pedido.

En este artículo nos centraremos en el último caso expuesto, ya que Android nos presenta un amplio abanico de posibilidades a la hora implementar este tipo de notificaciones. Para elegir la más adecuada debemos tener en cuenta los siguientes factores: 

• Precio del servicio: En los tiempos que corren este parece ser uno de los factores más importantes. Por ejemplo, en la actualidad el servicio de notificación PUSH por excelencia es el envío de SMS, que por supuesto, conlleva un gasto considerable a pagar a la compañía de telefonía contratada.
• Periodo de recepción de mensaje: Debemos valorar la necesidad o no de que el cliente sea notificado en tiempo real.
• Consumo de batería de los dispositivos cliente: Como cualquier otra acción llevada a cabo sobre un terminal móvil, debemos procurar minimizar el impacto sobre la batería del mismo. Por ejemplo, mantener un canal de comunicación  continuamente abierto con el servidor, conlleva un gasto de energía considerable.
• Dependencia de servicios de terceros: Este factor podríamos asegurar que influye o tiene en cuenta los tres puntos anteriores, es decir, existen empresas especializadas que proporcionan servicios de notificaciones de manera que un usuario puede ser notificado en tiempo real, con un mínimo impacto energético en el dispositivo cliente y un determinado coste dependiente del volumen de notificaciones a realizar. También  debemos de considerar que la información a enviar a un cliente, pasará siempre por los servidores de otra compañía, y por lo tanto, debemos de prestar especial atención a las políticas de privacidad y protección de datos. 

  2.   Mecanismos de Notificación

 Una vez vistos los factores a tener en cuenta a la hora de elegir nuestro sistema de notificaciones, realizaremos un breve resumen de las tecnologías o metodologías disponibles, tratando de asentar una base de conocimientos que llevaremos a la práctica en las próximas entregas.

 2.1  SMS

 Tal y como hemos mencionado anteriormente, todavía sigue siendo la forma de envío de notificaciones PUSH por excelencia. Aunque conlleva un coste relativamente elevado para la compañía notificadora, nos aseguramos de que la notificación será recepcionada por el cliente prácticamente en tiempo real e indiferentemente del tipo de terminal del que disponga el usuario (Android, iPhone, BlackBerry,etc).

 2.2  Mecanismos PULL

 Si el factor de la comunicación en tiempo real no es un requisito indispensable, nos podríamos plantear utilizar mecanismos de tipo PULL, es decir, nuestra aplicación lanzaría una consulta periódica al servidor en busca de novedades o mensajes especialmente dirigidos al usuario.  Contra mayor sea el número de consultas al servidor, mayor será el consumo de batería del terminal.

 2.3  Conexiones persistentes

 Esta metodología será la que  mayor penalización de consumo energético conlleve. Consiste en dejar abierto un canal de comunicación con el servidor, mediante el cual poder enviar notificaciones en tiempo real a sus clientes. Este mecanismo es prácticamente inviable, ya que probablemente el sistema operativo Android,  terminará cortando el canal, si no prestamos especial atención a su implementación. No solo requiere de un mayor consumo energético de lado cliente, sino que el servidor requerirá de más hardware o software para mantener abiertas un elevado número de conexiones con sus clientes.

 2.4  Mecanismos PUSH

 Los mecanismos PUSH se consiguen gracias a alguno de los dos puntos anteriores, a través de consultas periódicas al servidor o manteniendo un canal abierto con el mismo. Generalmente la metodología utilizada para implementar estos mecanismos es transparente para el desarrollador ya que suelen ser proporcionados por terceros a través de librerías instaladas en el cliente y productos o servicios del lado servidor.

 A continuación detallamos algunas de implementaciones de este tipo de mecanismos.

 2.4.1        Notificaciones basadas en productos MQTT (Message Queue Telemetry Transport)

 Message Queue Telemetry Transport (MQTT) es un protocolo abierto de mensajería que habilita la transferencia de datos a través de red. La principal característica de este protocolo es su ligeraza, que provoca que pueda ser aplicado a diferentes ámbitos, desde las pequeñas redes de sensores hasta los grandes servidores ubicados en Internet, pasando por supuesto por los sistemas empotrados en los terminales móviles:

 “MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios. It is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers”

 En el sitio oficial de este estándar (http://mqtt.org) podemos encontrar interesantes implementaciones tanto del lado cliente como del lado servidor (http://mqtt.org/software).

 En la siguiente imagen se puede apreciar una típica arquitectura MQTT donde existe una implementación cliente que recibirá las notificaciones y un servidor que será quien las envíe. Generalmente delante del “message broker” suele existir un servidor de aplicaciones que se comunicará con él (en este caso PHP):

Figura 1

Entre las diferentes implementaciones existentes destacamos las de IBM, que fue el principal promotor de esta tecnología y que recientemente liberó parte de su código fuente a la fundación Eclipse. Otra implementación interesante a destacar, es la del servidor OpenSource Mosquito (http://mosquitto.org/).

 Para aquellos que quieran ahondar un poco más en esta interesante tecnología, recomendamos la entrada del blog http://tokudu.com/2010/how-to-implement-push-notifications-for-android/ donde podemos ver como se construye un cliente de este tipo. Desde la página http://tokudu.com/demo/android-push/ podremos enviar notificaciones PUSH a nuestro terminal a través del broker de IBM. También existe la posibilidad de enviar notificaciones a través del broker Mosquitto desde la página: http://test.mosquitto.org/push-demo/.

  2.4.2        Notificaciones basadas en servicios de terceros

 Tal vez la mejor solución para implementar un servicio de notificaciones sea utilizar alguno de los servicios online de terceros existentes. Alguna de las ventajas de usarlos son: 

•  Implementación cliente perfectamente encapsulada (generalmente se proporciona como una librería .jar).  La comunicación de la aplicación con el servidor es totalmente transparente al desarrollador, es decir, no necesitaremos conocer como está implementada. Generalmente está preparada para optimizar el consumo de batería. Tal y como refleja la figura 2, el minimizar el consumo energético estará basado en que varias aplicaciones usen un mismo canal para sus notificaciones.
• Servicios de alta disponibilidad y bajo coste. Generalmente se trata de servicios de alta disponibilidad, baja latencia y de bajo coste o gratuitos, dependiendo del volumen de notificaciones/día. 

 Figura 2

En este artículo contemplaremos dos servicios de notificaciones:

• C2DM - Android Cloud to Device Messaging: Servicio de notificaciones específico para el sistema Android  y ubicado en la nube  de Google
• Urban AirShip: Servicio de notificaciones no ligado únicamente a Android.

   2.4.2.1       C2DM – Android Cloud to Device Messaging

Android Cloud to Device Messaging (C2DM) es un servicio que ayuda a los desarrolladores a enviar datos desde sus servidores a sus aplicaciones móviles instaladas en terminales móviles Android.  Se trata de un servicio gratuito, siempre y cuando no sobrepasemos los volúmenes de tráfico de datos establecidos por Google. En la mayoría de los casos no será necesario contratar una ampliación de estas cuotas de tráfico, ya que son bastante altas (Aproximadamente 200.000 notificaciones/día).

 La siguiente figura refleja bastante bien la arquitectura aplicada comúnmente a este servicio de notificaciones:

Figura 3

En la imagen anterior podemos distinguir al menos tres actores, cuatro si contamos con el navegador web: 

• Dispositivo móvil: En el terminal Android se instalará la aplicación que desea recibir las notificaciones. Tal y como veremos mas adelante, una aplicación que desee recibir notificaciones C2DM, se registrará automáticamente ante dicho servicio al ser instalada.
• Servidores C2DM de Google: A través de estos servidores se llevará a cabo el propio proceso de notificación.
• Servidor de aplicaciones propio: Este será un servidor gestionado por el propio proveedor de la aplicación. Su funcionalidad será manejar los dispositivos que se han instalado nuestra aplicación y desean ser notificados.
• Navegador Web o interfaz de administración del servidor de aplicaciones:  Tal y como se representa en la imagen anterior, se considera que podría existir algun tipo de consola de administración implementada por el desarrollador, desde la cual gestionar el envío de notificaciones.

 Una vez conocidos los actores que intervienen en el proceso de notificación PUSH del servicio C2DM,  trataremos de estudiarlo un poco mas a fondo, repasando la secuencia de acciones necesarias para que una aplicación reciba una notificación, tal y como se encuentran enumeradas en la imagen anterior:

1. La aplicación se instala en el dispositivo. Automáticamente la aplicación se identificará ante el servidor C2DM.
2. En respuesta al punto1, el servidor C2DM le retornará un “registration id” que identificará a un único dispositivo.
3. El identificador retornado por el servicio C2DM será enviado a “nuestro” servidor de aplicaciones, junto con algún dato que identifique al usuario de la aplicación. Será labor de cada desarrollador programar la gestión de estos datos enviados por los dispositivos. Por ejemplo, se podría guardar en una tabla de base de datos (REGISTRATION_ID,USER_ID, DEVICE_UID).
4. Desde un navegador se accederá a la aplicación Web que gestiona los datos del punto 3. Desde una página de administración podríamos definir el texto de la notificación y a que usuarios queremos notificar.
5. El servidor de aplicaciones invocará al servidor C2DM para indicarle los usuarios a los que se quiere notificar junto con el texto a enviar.
6. El servidor C2DM realiza las notificaciones a cada uno de los dispositivos indicados en el paso anterior. La aplicación instalada en el dispositivo cliente será la encargada de recoger estas notificaciones y tratarlas.

   2.4.2.2       Urban AirShip

 Urban AirShip es una empresa especializada en servicios online basados en  notificaciones PUSH. Provee a los desarrolladores de aplicaciones móviles un conjunto de herramientas (no gratuitas), tanto del lado cliente como del servidor, para gestionar un completo sistema de notificaciones PUSH.

Figura 4

En versiones previas de Urban Airship se usaba un programa llamado “AirMail Control Panel” que era necesario instalar en el dispositivo cliente para que las aplicaciones pudiesen recibir notificaciones de este servicio. Es decir, este programa era el que mantenía el canal abierto con el servidor y enlazaba el sistema de notificaciones con las demás aplicaciones.

 En la actualidad el sistema de notificaciones push para Android de Urban Airship ha sido renovado, eliminando la aplicación “AirMail Control Panel” convirtiéndola en una librería embebida en los aplicativos. Actualmente soporta al completo el sistema C2DM, además de implementar un canal propio de comunicación end-to-end denominado Helium.

 Además del soporte a un sistema push end-to-end, Urban Airship aporta otra importantísima ventaja que puede convencernos del uso de este servicio en vez del C2DM ofrecido por Google: soporta otros sistemas operativos además de Android. Es decir, si nuestra aplicación está disponible también para iPhone podremos implementar un sistema de notificaciones PUSH basado en Urban Airship, en vez del servicio de notificaciones de Apple (Apple Push Notification Service.). Este servicio de notificaciones Urban Airship estará disponible hasta para el famoso eBook reader de Amazon: Kidle.

  3.     Resumen

 A lo largo de este artículo hemos visto algunas de las opciones de las que disponemos a la hora de enviar notificaciones a los usuarios de nuestras aplicaciones. De momento nos hemos centrado en la parte teórica, dejando para las próximas entregas la parte práctica, donde experimentaremos con el servicio de Urban AirShip y C2DM.

 

Article originally appeared on javaHispano (http://www.javahispano.org/).