Los próximos artículos del Curso de Programación Android los vamos a dedicar a describir qué es y cómo utilizar el servicio Google Cloud Messaging. En este primer artículo haremos una introducción al servicio y comentaremos la forma de registrarnos para poder utilizarlo (no preocuparos, es gratuito), y en los dos siguientes veremos cómo implementar las aplicaciones servidor (una vez más en ASP.NET) y cliente (en Android). Empecemos.
En algunas ocasiones, nuestras aplicaciones móviles necesitan contar con la capacidad de notificar al usuario determinados eventos que ocurren fuera del dispositivo, normalmente en una aplicación web o servicio online alojado en un servidor externo. Como ejemplo de esto podríamos pensar en las notificaciones que nos muestra nuestro móvil cuando se recibe un nuevo correo electrónico en nuestro servidor de correo habitual.
Para solventar este problema Google introdujo en Android, a partir de la versión 2.2 (Froyo), la posibilidad de implementar notificaciones de tipo push, lo que significa que es el servidor el que inicia el proceso de notificación, pudiendo realizarla en el mismo momento que se produce el evento, y el cliente se limita a “esperar” los mensaje sin tener que estar periodicamente consultando al servidor para ver si existen novedades, y sin tener que mantener una conexión permanentemente abierta con éste. En la arquitectura de Google, todo esto se consigue introduciendo un nuevo actor en el proceso, un servidor de mensajería push o cloud to device (que se traduciría en algo así como “mensajes de la nube al dispositivo”), que se situaría entre la aplicación web y la aplicación móvil. Este servidor intermedio se encargará de recibir las notificaciones enviadas desde las aplicaciones web y hacerlas llegar a las aplicaciones móviles instaladas en los dispositivos correspondientes. Para ello, deberá conocer la existencia de ambas aplicaciones, lo que se consigue mediante un “protocolo” bien definido de registros y autorizaciones entre los distintos actores que participan en el proceso. Veremos más adelante cómo implementar este proceso.
Este servicio de Google recibió en sus comienzos las siglas C2DM (Cloud to Device Messaging), pero coincidiendo con su salida de fase beta modificó su nombre a GCM (Google Cloud Messaging).
Lo primero que debemos comentar es la forma de darnos de alta en el servicio, que a pesar de ser gratuito requiere de un proceso previo de registro y la generación de una ApiKey, algo similar a lo que ya vimos al hablar de la utilización de mapas en Android. Para hacer esto debemos acceder a la consola de APIs de Google, en siguiente dirección:
Suponiendo que es la primera vez que accedemos a esta consola, nos aparecerá la pantalla de bienvenida y la opción de crear un nuevo proyecto.
Una vez creado el proyecto el navegador te redirige a una dirección similar a ésta:
Al número que aparece tras la etiqueta “#project:” lo llamaremos “Sender ID” y debemos anotarlo ya que nos hará falta más adelante como identificador único de la aplicación web emisora de nuestros mensajes.
Una vez creado el nuevo proyecto vamos a activar el servicio GCM accediendo al menú “Services” y pulsando el botón ON/OFF asociado al servicio llamado “Google Cloud Messaging for Android“.
Se nos puede presentar entonces una ventana donde tendremos que aceptar las condiciones del servicio y tras ésto el servicio quedará activado, aunque aún nos faltará un último paso para poder utilizarlo. Como en el caso de la utilización de la api de Google Maps, para hacer uso del servicio GCM tendremos que generar una ApiKey que nos sirva posteriormente como identificación de acceso. Para ello accedemos al menú “Api Access” y pulsaremos sobre el botón “Create new Server Key…”.
Nos aparecerá un diálogo llamado “Configure Server Key for…”, que aceptaremos sin más pulsando el botón “Create”, sin necesidad de rellenar nada.
Y ya tendríamos creada nuestra API Key, que aparecerá en la sección “Simple API Access” con el título “Key for server apps (with IP locking)”.
Con esto ya nos habríamos registrado correctamente en el servicio GCM y habríamos generado nuestra API Key para identificarnos, con lo que estaríamos en disposición de construir nuestras aplicaciones cliente y servidor, algo que veremos en los dos próximos artículos. En éste nos pararemos un poco más para hacer una descripción a grandes rasgos de la arquitectura que tendrá nuestro sistema y de cómo fluirá la información entre cada uno de los servicios y aplicaciones implicados.
Como hemos indicado antes, para asegurar la correcta comunicación entre los tres sistemas se hace necesario un protocolo de registros y autorizaciones que proporcione seguridad y calidad a todo el proceso. Este proceso se resume en el siguiente gráfico (click para ampliar), que intentaré explicar a continuación.
Comentemos brevemente cada uno de los pasos indicados en el diagrama.
El primer paso, aunque no aparece en el gráfico, sería la autenticación de nuestra aplicación web en el servicio GCM. En la anterior versión del servicio GCM (llamada C2DM) esto debía hacerse mediante la utilización de otra API de Google llamada ClientLogin, o a través del protocolo OAuth 2.0, ambas dirigidas a obtener un token de autorización que debía enviarse posteriormente en el resto de llamadas al servicio. Sin embargo, con la llegada de Google Cloud Messaging, esto se ha simplificado mediante la obtención y uso de una API Key, que es precisamente lo que hemos comentado unos párrafos más arriba. Como pasaba con el token de autorización, nuestra nueva API Key deberá acompañar a cada una de las llamadas que hagamos al servicio GCM desde nuestra aplicación web.
Los siguientes pasado, ya sí mostrados en el diagrama, serían los siguientes:
- El siguiente paso es el equivalente al ya comentado para el servidor pero esta vez desde el punto de vista de la aplicación cliente. La aplicación Android debe registrarse en los servidores GCM como cliente capaz de recibir mensajes desde dicho servicio. Para esto es necesario que el dispositivo/emulador cumplan una serie de requisitos:
- Disponer de Android 2.2 o superior.
- Tener configurada una cuenta de Google en el dispositivo o emulador. Configurable desde “Ajustes / Cuentas y sincronización”.
- Si se trata de un dispositivo real debe estar instalada la Google Play Store. Por el contrario si estamos ejecutando la aplicación desde el emulador bastará con usar un target que incluya las APIs de Google (para la nueva versión de GCM incluida con los Google Play Services se requiere Android 4.2.2 o superior para poder probar en el emulador).
- Si el registro se finaliza correctamente se recibirá un código de registro (Registration ID) que la aplicación cliente deberá conservar. Además, la aplicación Android deberá estar preparada para recibir periódicamente refrescos de este código de registro, ya que es posible que el servidor GCM invalide periódicamente este ID, genere uno nuevo y lo vuelva a notificar a la aplicación cliente.
- Este nuevo paso consiste en enviar, desde la aplicación cliente a la aplicación servidor, el código de registro GCM recibido, el cual hará las veces de identificador único del cliente en el servidor de forma que éste pueda indicar más tarde el dispositivo móvil concreto al que desea enviar un mensaje. La aplicación servidora tendrá que ser capaz por tanto de almacenar y mantener todos los ID de registro de los distintos dispositivos móviles que se registren como clientes capaces de recibir mensajes.
- El último paso será obviamente el envío en sí de un mensaje desde el servidor hasta un cliente determinado, algo que se hará a través del servidor GCM (paso 4.1) y desde éste se dirigirá al cliente concreto que debe recibirlo (paso 4.2).
Como se puede comprobar, el procedimiento es relativamente complejo, aunque bastante intuitivo. En los próximos artículos veremos cómo implementar cada uno de ellos. Una vez más, para nuestro ejemplo utilizaremos una aplicación ASP.NET como aplicación servidora, con SQL Server a modo de almacén de datos, y aprovechando que ya hemos visto como crear servicios web SOAP y llamarlos desde aplicaciones Android, vamos a utilizar uno de éstos para la comunicación entre cliente y servidor (paso 3).
No hay comentarios:
Publicar un comentario