«

»

may 29 2012

C2DM – Notificaciones Push (Parte I)

Cuando creamos apps que consumen datos de la nube debemos encontrar el compromiso entre la actualización de datos y el consumo de batería. Cuanto más sincronicemos nuestros datos más actualizados estarán pero mayor será el consumo de batería y esto es un problema en terminales portátiles. Teniendo en cuenta que muchas de estas sincronizaciones serían relativamente inútiles puesto que cabe la posibilidad de que los datos no hayan cambiado y la hayamos realizado sin necesidad se plantea otra alternativa, las notificaciones push.

A diferencia de lo que explicábamos, en este caso es el servidor el que nos comunica de los cambios en los datos y por tanto solo en estos casos sincronizaríamos nuestra app. Para este menester Google nos proporciona un servicio completamente integrado con su plataforma Android, Cloud to Device Messaging (C2DM).

En este post os daremos unas pinceladas del modo de funcionamiento de este servicio para posteriormente en un siguiente post explicaros como tratar estas notificaciones desde nuestro terminales Android.

 

RESTRICCIONES

 

  • Los mensajes no pueden exceder el tamaño de 1024 bytes.
  • El usuario deberá tener instalado Google Play y configurada correctamente una cuenta de GMail.
  • Esta disponible a partir de Android 2.2 (API level 8).

 

COMPONENTES Y CREDENCIALES


Componentes

  • Dispositivo Móvil: El dispositivo en el que se ejecuta la app que usa C2DM. Este debe de ser un dispositivo Android 2.2 o superior, tener Google Play instalado y estar logado al menos con una cuenta Google.
  • Servidor de datos: Servidor encargado de gestionar el estado de los datos y comunicar el estado de los mismos. El servidor de datos envía los mensajes a la aplicación Android en el dispositivo a través del servidor de C2DM.
  • Servidor C2DM: Servidor de Google encargado de recibir los mensaje del servidor de dato y enviarlos al dispositivo móvil.

Credenciales

  • Sender ID: Email asociado a la aplicación y que sirve en el proceso de registro para identificar la aplicación que tiene permisos para mandar mensajes al dispositivo.
  • Application ID: La aplicación que esta registrada para recibir mensajes. Este identificador corresponde con el nombre de paquete indicado en manifiesto de la app.
  • Registration ID: Id proporcionado por el servidor C2DM y que permite a la app recibir mensajes. Una vez esta tiene dicho id deberá proporcionárselo al servidor de datos el cual lo usara para identificar cada dispositivo registrado para recibir mensajes. Este id esta asociado una instancia concreta de la app en un dispositivo concreto.
  • Google User Account: Para que C2DM funcione el dispositivo debe tener configurada al menos una cuenta de Google.
  • Sender Auth Token: Nuestro servidor deberá logarse con la cuenta elegida como “Sender ID” mediante una petición POST recibiendo en la respuesta el ID que la identifica para poder mandar mensajes.

 

CICLO DE VIDA


Una vez hemos dado de alta la app en los servidores de Google (https://developers.google.com/android/c2dm/signup) y tenemos implementado tanto el envío como la recepción de los mensajes (esto lo veremos en el siguiente post), este sería el ciclo de vida que seguiría dicho proceso.

Registro de la App:

 

 

Una vez nuestro servidor dispone del “Registration ID” el proceso del servidor con respecto a la App es completamente transparente.

Envío de mensajes:

Una vez disponemos del “Registration ID” y del “Sender Auth Token” el siguiente sería el flujo de envío de mensajes:

 

 

Mi Servidor: Obtencion del “Sender Auth Token”


En cuanto a la implementación de nuestro servidor no entraremos en detalle, ya que esta puede ser realizada en multitud de idiomas y plataformas. Nos limitaremos a dar unas pinceladas de los datos/parametros necesarios para implementar la misma.

Tanto el registro del servidor como el envío de los mensajes se realizan mediante peticiones POST. En concreto para el registro tendríamos que usar los siguientes parámetros:

  • URL de la petición: https://www.google.com/accounts/ClientLogin
  • Email: Sender ID con el que está dada de alta la app.
  • Passwd: Password asociado al email.
  • accountType: Con valor igual a “GOOGLE”.
  • source: Google-cURL-Example.
  • service: ac2dm.

Como respuesta recibiremos tres códigos de los cuales nos quedaremos con “Auth” que nos servirá para el envío de los mensajes.

Nota: Este método de registro está obsoleto y se recomienda migrar a OAuth 2.0 (https://developers.google.com/accounts/docs/OAuth2?hl=es-ES).

Podemos simular esta petición mediante el siguiente comando en Linux:

  • curl https://www.google.com/accounts/ClientLogin -d Email=your_user -d “Passwd=your_password” -d accountType=GOOGLE -d source=Google-cURL-Example -d service=ac2dm

 

Mi Servidor: Envío de mensajes

 

Una vez tenemos el “Registration ID” y el “Sender Auth Token” ya podemos mandar nuestros mensajes, eso sí teniendo en cuenta la limitación de que estos no pueden ocupar mas de 1024 bytes. Al igual que en el registro para el envío de mensajes usaremos una petición POST con los siguientes parámetros:

  • URL de la petición: https://android.apis.google.com/c2dm/send
  • registration_id: Id que nos proporciono el dispositivo para identificarlo.
  • collapse_key: clave que nos servirá para identificar el “tipo” de mensaje para que cuando el dispositivo este offline y los mensajes se acumulen en cola la recepción de un nuevo mensaje con key coincidente sobrescriba al antiguo.
  • data.[key]: El contenido del mensaje lo enviaremos como un conjunto de pares clave/valor que posteriormente en la app podremos recuperar a partir de estas claves.
  • delay_while_idle: Por defecto los mensajes son enviados tan pronto es posible aunque el dispositivo no este active, si seleccionamos esta opción a true podemos postergar este envio hasta el momento en que el dispositivo vuelva a estar active.

Adicionalmente deberemos incluir el header con la Google ClientLogin auth token obtenida en la peticion anterior.

Podemos simular esta petición mediante el siguiente comando en Linux:

  • curl –header “Authorization: GoogleLogin auth=your_authenticationid” “https://android.apis.google.com/c2dm/send” -d registration_id=your_registration -d “data.payload=payload” -d collapse_key=0

 

Mi Servidor: Posibles respuestas del servidor C2DM

 

A continuación os mostramos la tabla extraida de la documentación oficial en la que se nos muestra las posibles respuestas que podemos recibir del servidor de C2DM:


 
Con esto hemos terminado las primeras nociones, en un proximo post os expondremos como tratar estas notificaciones en nuestras apps para Android.
 
 
fuente | Ingens Blog
 

Acerca del autor

JMPergar

Mobile Developer at @BeRepublic & Founder of @AndroCode. Silver Speaker & Member of Core Team at @GDGBarcelona.

  • Pingback: C2DM – Notificaciones Push (Parte II) | Androcode()

  • christian

    una notificacion push requiere que la aplicacion este corriendo? o se hace de otra panera para que el usuario reciba una notificacion sin que la aplicacion este corriendo?

  • Katerine

    Buenos dìas, yo he hecho una aplicacion servidor en java y un app cliente Android. Lo que deseo es que cuando un usuario cliente Android (el publicante) escriba un nuevo anuncio, este le llegue a todos sus clientes Android suscritos, (los lectores). Quisiera saber si esta tecnologia C2DM me servirìa para el envio del mensaje push a todos los usuarios cuando el pulicante haya escrito algo nuevo? Agradecerìa mucho su opiniòn.

    • http://www.linkedin.com/in/jmpergar JMPergar | Editor Jefe

      Yo para este caso implementaría un servicio web en tu aplicación servidor para recibir los mensajes, desde tu app android llamaría a este servicio para mandar el anuncio y la aplicación servidor se encargaría de mandar las notificaciones a quien correspondiera.

  • Cristhian

    Buenas,
    me gustaría que me dieran consejos sobre implementar esta funcionalidad:
    Se tiene pensado implementar un sistema de alertas, que notifique al usuario cuando sus tareas o responsabilidades se encuentren sobre el 80% del tiempo de su asignación. Los datos de sus tareas así como su fecha de iniciación y finalización, se encuentran sobre una base de datos Oracle. Lo que tengo pensado es utilizar un web service que se comunique con la base de datos. El problema radica en el envío de peticiones sin que la aplicación este abierta, para extraer estos datos y hacer su comprobación de límites de tiempo de manera asíncrona notificando al usuario.
    Obviamente una de las delimitaciones es que la app tenga internet para su funcionamiento
    Gracias.