Actualizando a Android Studio 0.5.1

Hoy he arrancado Android Studio y… ¡Sorpresa, una nueva actualización!. Poseía la versión 0.4.6 y está que indicaba era la 0.5.1. Parece que es más o menos importante, ya que pasa de las versión 0.4.x a la versión 0.5.x y tal como actualiza Android Studio pues es evidente que trae muchas mejoras.

Una de esas ‘mejoras’ es la actualización de Gradle, por omisión si actualizas Android Studio a la versión 0.5.1, a la versión 0.9. Hasta ahora usaba Gradle 0.7. Así que hacía pensar que no era un cambio significativo… pero … ERROR!.  Al parecer de la versión 0.8 de Gradle a la versión 0.9, hay que hacer ciertas tareas de migración para que todo siga funcionando igual… o sea… no es RETROCOMPATIBLE. Esto nunca lo entenderé, que en versiones de este calibre, actualizaciones que parece que no son importantes, te manden a revisar toda tu configuración de Gradle para migrar todo aquello que han cambiado. ¡Que puñeteros!.

Obviamente, no compilaba el proyecto, por lo que poseía configuraciones que tenía que migrar a la nueva versión de Gradle. Así que con un cabreo bastante grande, me fui a la documentación oficial y me lei los cambios y como hacer las migraciones oportunas: VER AQUÍ COMO MIGRAR DE GRADLE 0.8 A 0.9. Todo ello es aplicado a los ficheros ‘build.gradle’ (digo ficheros, porque puede haber varios módulos dentro del proyecto que son independientes y con su propio fichero de configuración de Gradle)

Una vez hecho esto ¡y lo peor de todo! no solo en ‘mi codigo’ sino también tuve que revisar aquel código de terceros que añado a mi proyecto como módulo mediante su código fuente (vease librerias como la de DateTimePicker o Facebook), ya que no era cuestión de esperar a la nueva versión de estas, más que nada porque Facebook seguro que la saca rapido, pero librerias de terceros que no se dedican a tiempo completo a esto, pues tardaran bastante más. Tras realizar todas estas comprobaciones… sigue sin compilar… ¡Maldito Gradle y maldito Android Studio! ¡Cuidad más a vuestros desarrolladores leñe!. Tras investigar el fallo y surfear por stackoverflow (¡Eso si que es una pedazo de comunidad <3!), encontré el fallo (y su solución) en un post que tan sólo llevaba un par de horas posteado.  Pero el fallo no lo solucioné con la solución que habían marcado como buena (borrando toda la dependencia que daba el error), sino que lo solucioné con la primera solución que habían dado al problema y que decía que se debía cambiar el nombre de la dependencia ‘aild’ por ‘aidl’. Así que una vez modificado esto… ¡Tachán! Volvía a funcionar como antes. Aquí os dejo el post de stackoverflow. Y para colmo, no era problema de mi archivo de configuración, sino que era problema del archivo de configuración de una de esas librerias que uso a través de todo su código fuente importado como un módulo. La libreria en cuestión es la del DateTimePicker, que a esta hora en concreto, todavía el autor no la ha actualizado para su funcionamiento con Gradle 0.9, por eso es mejor hacerlo por ti mismo, si se puede.

Esto es todo, aquí tenéis todos los cambios que conllevó actualizar a Android 0.5.1, es este COMMIT.

Anuncios

Mezclando Back-End con Front-End del Servidor

Una vez que tuve un Front-End totalmente estilizado y que, por el momento, no iba a tocar más, me dispuse a unirlo junto al backend para no tener dos aplicaciones Node.js independientes innecesariamente. Por lo que el Frontend (que de momento sólo abarca la Landing Page) y el Backend (todo el sistema de APIs REST y base de datos en MongoDB) los fusioné en una única app Node. A continuación os dejo con una figura que he confeccionado para que se vea como está estructurado el Proyecto Qdemos.

Estructura del Proyecto Qdemos

Estructura del Proyecto Qdemos

Para ello, tome como aplicación de referencia, la del Front-End. Sólo tuve que modificar el fichero de Rutas (Routes.js) para indicar que a parte del home.ejs (Landing Page), también hay rutas para las APIs definidas en otros ficheros. Y copie todas las carpetas propias del backend bajo el directorio raiz del Frontend. De manera que con una simple modificación de un fichero (el de las rutas) y un copy+paste de las carpetas propias del backend, me ha servido para integrar ambas partes en una sola, y poder deshacerme de una de ellas, estando todo ahora en una misma app.

Esto es todo, referente a esto, el commit como siempre lo teneis aqui: COMMIT.

Nueva Rama: AppWeb

Pues en estos días he estado haciendo una Landing Page del Proyecto (colocada en una nueva rama: AppWeb)  que sirve en un futuro como la página de inicio de la web que permita a los usuarios que quieran acceder mediante interfaz web a toda la herramienta que proporciona Qdemos, ahora mismo sólo para Android. De esta manera, usuarios que no sean de Android, podrán usar Qdemos mediante esta AppWeb.

Eslogan de Qdemos!

Eslogan de Qdemos!

El trabajo de hacer la Landing Page de la AppWeb, basicamente ha llevado quebraderos de cabeza en lo referente al diseño, que al fin y al cabo es lo que debe predominar en una Landing Page. Antes de explicar la estructura que he decidido crear en esta Landing Page para reflejar la temática de Qdemos, diré algunas tecnologías y librerias usadas para llevar a cabo esto. Cabe destacar que esta AppWeb con su Landing Page, en un futuro se mimetizará con el back-end que ya está creado donde se definen todas las APIs de tipo REST que utiliza la app Android. Por ello la tecnología que debería usar no es otra que Node.js para despues integrarlo todo en una solo Web que tenga el Front-End, y el Back-End que sirva tando de APIs para Android como de AppWeb.

Dicho esto, en esta rama he utilizado, entre otras librerias/frameworks:

  • Para el BackEnd:
    • Node.js, que define el servidor en JavaScript, que no hace falta para la LandingPage, pero que lo introduzco ya para después mimetizarlo con el Back-End.
    • Express.js, para resolver las Rutas, y por el mismo motivo que he descrito arriba.
  • Para el FrontEnd:
    • Angular.js, de momento no se usa, ni está incluido, pero está pensado para que en un futuro resulte sencillo y rápido crear toda la WebApp.
    • BootStrap, para el diseño de la web y todos sus elementos.
    • Textillate, libreria muy chula para ‘dar vida’ a textos dinámicos.

Y ya está. Una vez descrito esto, pasaré a explicar cómo está confeccionada la Landing Page, que aún no está ‘live’ porque quiero que sea una sopresa para más adelante, pero que ya está totalmente operativa… en mi ordenador en local ^.^

Lo que he querido representar es dos aspectos fundamentales:

  • Cuál es la funcionalidad de Qdemos que la diferencia del resto
  • Dónde ha sido elaborado Qdemos

Con estas dos premisas lo que he hecho ha sido poner de background en la Landing Page, un TimeLapse espectacular de Tenerife para reflejar que Qdemos! es un producto ‘Made in Canarias’. Y de hecho así lo refleja el Footer que le he creado para la wen que dice:

Hecho desde Canarias con mucho ♥

En lo referente a la funcionalidad de Qdemos he querido representarlo con el hecho de expresar lo fácil que es su utilización. De hecho ya he creado la tipica caja de Login de la WebApp del futuro, que está incluida en esta Landing Page y que es minimalista a más no poder. Un simple botón (que permite el Login de momento con Facebook). Ya está eso es todo. Junto a esto he acompañado el logo de Qdemos!, incrustado en la misma palabra. Debajo de este elemento de Login muy sencillo, he colocado un banner con frases que explican lo que representa Qdemos!. Estas frases, gracias a la librería Textillate, van cambiando de forma dinámica haciendo efectos de entrada y salida muy chulos. ¡Vaya vida que le da a la Landing Page!. Entre esas frases podemos encontrar:

  • Menos Whatsapp y Más Ven a Verme (Esta será el lema de Qdemos!, una frase vista en un cartel (el típico cartel) de la Autopista del Norte (Altura Puerto De La Cruz-Cuesta de La Villa) que sirvió de inspiración para crear Qdemos!)
  • Quedar con tus amig@s nunca fue tan fácil
  • Encuentra la fecha exacta para quedar con ell@s
  • Un Proyecto hecho en Canarias
  • De Código Totalmente Libre
  • Es hora de desvirtualizar a quién tú y yo sabemos
  • Un abrazo vale más que 1000 emoticonos
  • Organiza las quedadas de tu grupo de amig@s
  • Propón visitar a tus amig@s ese rincón tan especial
  • Queda con ese grupito de amig@s que llevas tanto tiempo sin ver
  • Da el primer paso y organiza la Quedada
  • Qdemos es la herramienta que estabas buscando

Y ya está, esto es todo, la Lading Page así es como la pensé y así es como la materialicé. Cualquier sugerencia será bienvenida :).

Y como siempre os dejo con el commit de todo esto: COMMIT.

Refactorizando Servicios Web y Muchas Pruebas.

Desde la última entrada a la de hoy he estado inmerso en la mejora de las peticiones de datos de la app Android al servidor… y aún queda por mejorar y darle una nueva pensada a todo esto, ya que quiero que sea lo más ligero posible.

Lo que he modificado es la forma de pedir la info actualizada de las Qdadas que un usuario tiene almacenadas en local (en caché, por así decirlo). Antes lo que hacía era enviar una petición por cada Qdada. Esto nunca me llegó a gustar del todo, pero lo había hecho así para ir avanzando en el código e ir viendo y probando como se comportaba el resto de la app. Así que en estos días he estado modificando esto y probando el funcionamiento normal de toda la app.

Ahora lo que se realiza es una única consulta donde la app envía todos los identificadores de Qdadas que quiere actualizar y el servidor le devuelve en un JSON todas la info actual en el servidor acerca de esas Qdadas. Esta consulta puede ser útil para cuando sólo se requiera saber la información actualizada de un grupo de Qdadas, así que por eso lo he implementado.

El proyecto se ha complicado más de lo que intuía xD

El siguiente paso será que a través del Identificador de Usuario (que de momento es el IDFacebook) el servidor nos devuelva la info de todas las Qdadas en las que esté involucrado este. Filtrándolas por fechas (para no enviar las Qdadas ya pasadas, ya que estas no se modificarán más). Esto parece el funcionamiento correcto, pero el anterior está pensado para descarga la info de Qdadas progresivamente, ya que si un usuario tiene un número considerable, el peso de la respuesta de la petición puede ser bastante grande, por lo que habrá que pensar en alguna política de actualización.

Otra opción de actualización, es que sea el servidor el que notifique a los usuarios, a través de notificaciones PUSH, el cambio en la Qdada. Es decir, si algunos de los usuarios involucrados modifica la Qdada (por ahora lo que podrá modificar es su elección sobre esa Qdada), pues que el servidor se encargue de mandar notificaciones PUSH a todos los usuarios que participen en esa Qdada, y así en background la app se encargue de actualizar dicha Qdada. Se puede, incluso, implementar una opción que permite a la app avisar al usuario (si este quiere) de que alguien a modificado su elección en la Qdada. Eso no lo tengo del todo claro, ya que me surgen muchas dudas en lo correspondiente a usuarios que usen del tingo al tango la app, por falta de conexión a internet. De manera que habría también que implementar un sistema eficiente de colas, para que cuando tiene conexión a internet y le llegan 15 notificaciones distintas de la misma Qdada, actuar en consecuencia de manera ligera, y que no le afecte a la experiencia de usuario. ¿Alguien tiene alguna opinión al respecto?… es una de esas funcionalidades que parece obvia, pero que hay que pensarla muy mucho antes de implementarla, ya que sino, cuando se implemente, lo más seguro es que surjan nuevos problemas que hagan que todo el trabajo anterior haya sido en balde.

También he conseguido probar la aplicación en un uso normal. Con una tablet y un smartphone y dos usuarios distintos. Un usuario crea una Qdada e invita a otro usuario. Ese otro usuario recibe la notificación y responde con las fechas en las que mejor le venga. Ese ciclo de uso, funciona correctamente, así que pasito a pasito la app va cogiendo cuerpo :-).

El problemas de probar un uso normal de la app, es el tiempo que se tarda. Se tiene que tener conectado los dos dispositivos por USB para cargar los cambios que se vayan haciendo de la app, y establecer un ciclo completo de uso normal. Además esto va mucho más allá, ya que esto se podría incluso automatizar con Test. Pero existen dependencias como la instalación de la app de Facebook, la sesión iniciada por parte de usuarios distintos en terminales distintos en esta red social. Probar cosas más rocambolescas, como que ocurra algo inesperado durante el transcurso de utilización de la app (que se pierda la conexión, que lleguen otras notificaciones, que el usuario ponga la app en segundo plano, etc.). Por lo que realizar estas pruebas se puede convertir en algo realmente tedioso e insano para el desarrollador.  Además que siempre es bueno que lo pruebe una personas externa al desarrollo y al que no se le explique en detalle su funcionamiento, para ver que sería lo que haría por naturaleza. Como los desarrolladores sabemos como funciona, pues en ocasiones tener el punto de vista de alguien externo, puede ayudarnos a detectar bugs que no se nos hubieran ocurrido, y que seguramente hubieran salido a la luz con la app en fase beta, o incluso en fase de lanzamiento. También es verdad que esto se suele dejar para la fase beta, o alfa incluso, darle una app ya cuasi finalizada a usuarios externos para que trasteen. Pero esto tiene el inconveniente de que cuanto más funcionalidades tenga la app, más bugs van a ocurrir, y hay que intentar que el usuario de pruebas final se encuentre con los menos bugs posibles, para su comodidad. Así que yo soy de la mentalidad de ir probando poco a poco todas las funcionalidades con diferentes usuarios externos (que suelen ser la familia en estas etapas de desarrollo, jeje), y ya cuando esté todo testeado por partes y empaquetado en la app final, pues sacar una beta y darle la app a usuarios de prueba finales para que detecten nuevos fallos. De esta manera, se genera un filtrado de bugs previos, bastante importante, consiguiendo que el usuario probador final (que serán los amigos, jeje) no les cause apatía probar la app, ya que los bugs con los que se encontrarán estarán minimizados.

Como siempre, aquí os dejo con el commit de lo que he hablado: COMMIT

Parseando Notificaciones Push

Todos estos últimos días los he dedicado a la rama WebServices en la que sigo trabajando duro. El código cada vez se complica más y realizar las pruebas oportunas cada vez es más lento debido a que tengo que simular peticiones al servidor, respuestas, etc. Pero bueno, aunque no esté avanzando al ritmo que quisiera, voy resolviendo los problemas que van surgiendo, que no es poco.

En lo último destacable que he estado trabajando es en probar toda la infraestructura de la recepción de una notificación. Desde que nos llega al smartphone proveniente de la Nube GCM de Google, hasta que se la mostramos al usuario en forma de notificación latente en la Barra de Notificaciones de Android.

Durante este proceso, los pasos que se siguen son los siguientes:

  1. Recibimos la notificación en la función que en su momento definimos para ello, dentro del código de nuestra aplicación.
  2. Comprobamos el tipo de Notificación que es. Android, más concretamente GCM, cuando te envía una notificación te dice el tipo que es, si es de Error, de Eliminación o Normal y corriente, como es nuestro caso.
  3. Procesamos esa notificación:
    1. La notificación llegará en formato JSON (que es como la enviamos al servidor GCM desde nuestro servidor propio de Node.js)
    2. Convertimos esa estructura JSON en varias entradas en nuestra BBDDs Local. Esto es debido porque no sólo se creará la fila dentro de la tabla de Qdadas, correspondiente, sino que además se creará una fila por cada fecha propuesta para la realización de la Qdada en la tabla FechasQdada. Hay que tener en cuenta que viene todo en crudo, por lo que habrá que crear los Usuarios en Local, si no existen, que representen al Creador e Invitados de la Qdada. Convertir las fechas al objeto Date de Java, etc, etc.
    3. Finalmente actualizamos todos los datos de la BBDD Local, una vez parseada y estructurada la información que nos llega en el JSON de la Notificación Push
  4. Si el paso anterior ha ido con éxito, procedemos a Mostrar la Notificación en el Área de Notificaciones de Android (falta personalizarla un poco, texto a mostrar, icono, etc.)
  5. Hacemos sonar un sonido para alertar al usuario que tiene una nueva notificación.

Cuando el usuario haga click en dicha notificación, la idea es que le lleve directamente al Fragment que permite seleccionar los días que podemos asistir de la Qdada. De momento está simplemente que lleve al Home de la Aplicación.

Y esto es todo. En cuestión de contenido para rellenar un post no es mucho, pero el trabajo ha llevado lo suyo, más que nada, por realizar las pruebas y tener que comunicar a la app Android con el servidor Node.js para crear toda la lógica real necesaria de un envío de Notificación Push, todo esto con un sólo usuario, por lo que he tenido que emular muchas partes del proceso.

El siguiente paso es probarlo ya en un entorno real con varios usuarios y un funcionamiento cotidiano para ver como se desenvuelve la app y si hay algún problema. Como he dicho he probado distintas partes del proceso por separado, pero no el ciclo de vida completo de un uso normal de la app.

Como siempre, aquí teneis el Commit de lo explicado: COMMIT

Definiendo la Comunicación Pasiva entre el Servidor y la App

En los últimos días, y lo que todavía me queda, he estado y estoy trabajando en la comunicación de la BBDD del Cliente (La App Android) y la BBDD del Servidor (BackEnd Node.js). Me refiero a la comunicación pasiva, la que el usuario no debería darse cuenta.

Por un lado me refiero a comunicación activa, la que está en primer plano y el usuario se puede dar cuenta que está ocurriendo. Por ejemplo, cuando crea una Qdada y la guarda. En ese momento se abre un Progress Dialog y hasta que esa comunicación entre el SmartPhone y el Servidor no termine (para bien o para mal debido a los timeOuts que he configurado) el usuario no podrá seguir usando la app. Estas comunicaciones en primer plano, suelen durar muy poco, casi tan poco que al usuario no le da tiempo de ver el Progress Dialog que aparece. Pero por si en un determinado momento algún fallo ocurre en la comunciación, pues lo he configurado para que aparezca estos Progress Dialog no cancelables, como dije antes. Esta labor ya la realice, y así la expliqué en Post pasados del blog.

Este tipo de comunicaciones, que se hagan ad-hoc en primer plano, también se pueden trasladar a la demás información. Por ejemplo, para cargar la información de los Fragments de la Activity del Home (que como recordareis son los que muestran las listas de las Qdadas en las que estamos involucrados), se podría también tirar de comunicaciones en primer plano. Me refiero en primer plano para representar el hecho de que hasta que no se han terminado las comunicaciones, no se recoge ninguna información para mostrar en los fragments. Esto no quiere decir que las llamadas a los web services se hagan en hilos independientes, que de hecho se hacen así para no sobrecargar y saturar el hilo principal. Pues bien, se podría configurar todo para que hasta que no llegue la información almacenada, y totalmente actualizada, del servidor, no se mostrara nada en la app (en lo referente a la información de las Qdadas). Esta es una práctica también habitual, y con la que suelen trabajar la mayorías de aplicaciones. En local poseen muy poca información, y se basa casi siempre en tener la BBDD del servidor que es la que nutre a las aplicaciones clientes mediante llamadas o servicios propios.

Pues bien, en esta app lo que quise hacer es implementar un protocolo distinto al que estaba habituado a usar, y a ver. La idea es que la información que se almacene en el servidor, esté replicada en local (con la salvedad que en el servidor estará toda, y en local sólo lo referente a el usuario de ese smartphone). De esta manera, si se quiere usar la app cuando no hay conexión o lo que sea, sea posible visualizar las Qdadas (aunque estas igual no estas actualizadas al 100%). Así que el protocolo me gustó bastante y lo decidí implementar en la app. Es algo más complejo que esto, que iré evolucionando con el paso del tiempo, pero para que os hagais una idea clara, básicamente es esto, lo que de momento quiero hacer. Esta idea me surgió tras hablar con el encargado de desarrollo de una empresa Tinerfeña (no diré el producto ni el nombre de la compañia por temas de privacidad) que me comentaba como habían elaborado el diseño interno de su última app (para móviles) que tanta repercusión ha tenido en los últimos meses en Tenerife. Era un paradigma que yo había pensado, porque la idea es la ideal de hacer para toda app, pero que siempre tenía algún inconveniente que desechaba su implantación. Pues bien, tras preguntarle sobre ese paradigma, y tras responderme siempre con buenas propuestas, me decidí a realizarlo.

La idea es que exista un hilo que cada cierto tiempo (configurable, ahora le he puesto 5 minutos, habría que analizar y estudiar este tiempo) se comunicara con el servidor para actualizar toda la información de la BBDD Local de la app Android. Por otro lado, todo lo que el usuario hiciera en la app, tiraría de la BBDD Local, por lo que la fluidez de la misma siempre sería la mejor posible. Y así es como lo he implementado, y estoy implantándolo. Esto hace que toda la parte del front-end de la app, tire directamente de la BBDD de MySQL de Android, y que las actualizaciones de esta BBDD se haga totalmente de forma pasiva para el usuario, que no se enterará. Esto tiene sus pros y contras. Por ejemplo, evita diversos problemas que el usuario se de cuenta cuando no hay conexión. En cambio no siempre tiene la info 100% actualizada, pero el tiempo de refresco creo que es adecuado para que ‘los pros’ pesen más que ‘los contras’.

Modelo de Sincronización entre BBDD Local y BBDD Servidor de manera transparente a la App. (Imagen cogida de un producto de IBM)

Y hasta aquí en esta entrada, a ver si termino pronto esto de la comunicación pasiva, y ya sólo quedaría el tema de enviar las Qdadas mediante las notificaciones push (que ya configuré), recibirlas en Android y mostrarselas al usuario en la app. Y probar que todo, absolutamente todo, funcione como debería, jeje.

Y como siempre os dejo con el commit de esto que comento: COMMIT.

Google Cloud Messaging… DONE!

Para las notificaciones siempre he tenido en mente hacer uso del servicio que ofrece el propio Android con la Nube Interna que tiene para ello denominada Google Cloud Messaging. De hecho ya he trabajdo y hecho alguna aplicación que otra usando este servicio, así que he tenido buenas experiencias y es una auténtica pasada lo eficaz que es.

Para el que no le sepa, Google Cloud Messaging (GCM) es el servicio que Google ofrece para desarrollar Notificaciones Push en Android. Las notificaciones push tienen un gran incoveniente, si la queremos desarrollar por nuestra cuenta, y es que nos tenemos que cerciorar cuando el usuario al que va dirigida está operativo (hablando en temas de conexión a internet) para hacerle llegar la notificación. Esto inmiscuye, forzosamente, que quien quiera desarrollar este servicio deba comunciar de forma eficiente al móvil con su servidor (porque si no la batería y los recursos lo achacarían). Y ¿cuál sería la politica a determinar?… esa es otra, estaria el móvil constantemente solicitando si hay cambios al servidor, algo asi como preguntando si tiene algún paquete para él. O sería más bien al contrario que el servidor intentara comunicarse con el móvil sólo cuando le llegara el paquete que el debe entregar. Si es así, de la última forma que parece más eficiente… ¿Qué pasaria si el móvil no tiene internet en ese momento? ¿Cuantas veces se reintentaria? ¿Y en que periodo de tiempo?…

Pues para evitar todas estas cuestiones que se abrirían al intentar implementar un servicio de notificaciones push propio, existen diferentes plataformas que te abstraen de este problema y lo implementan por ti. A parte de la de Google, su GCM, hay startups dedicadas últimamente a crear este tipo de nubes, con diferentes SDKs para las diferentes plataformas móviles, creando incluso compatibilidad entre ellas. De momento GCM sólo está operativo para Android, así que una plataformas externas de esta sería un buena solución si trabajamos con el desarrollo multipltaforma (ya sea nativamente o no). De las mejorcitas plataformas externa, yo recomiendo: Parse, te simplifica al máximo las labores a realizar y es realmente rápida. Lo único malo que en su versión gratuita, te pone un límite de mensajes que puedes enviar con él, pero bueno, para hacer pruabas y demás, es más que suficiente. El problema de todas estas plataformas externas, es que nunca llegarán a ser más fiables, rápidas, seguras y eficientes que la nativa. GCM es la más rápida y efectiva que he usado yo, y es auténticamente increíble con la rapidez que te llega al notificación, si tienes intenet o si no tienes (a posteriori cuando tengas). Esta implementada por desarrolladores internos de Android, por lo que el código más optimizado es imposible que esté.

Como he dicho, ya había trabajado con ella, hará menos de 1 año, pero en vez de tirar del código que ya tenía, busqué a en la página de desarrolladores de Android, oficial, para ver si el tutorial seguía igual o había cambiado. Y en efecto, el servicio se había actualizado a una nueva versión, y las labores para su uso desde Android se han simplificado considerablemente desde que yo lo usé. Ahora es realmente sencillo usarla, y es una gozada como te lo explican en el tutorial, incluso dandote el código de una aplicación de ejemplo que te facilita en demasía saber dónde hay que poner el qué y por qué.

Podeis encontrar el tutorial aquí: Tutorial GCM, y el código fuente de una aplicación demo en Google Code, aquí: Demo Google Code

¿Pero como funciona este Servicio integrado con Qdemos?… pues abajo teneis una imagen (de autoría propia ^.^) que lo explica, pero a grande rasgos es:

  • El usuario crea una Qdada y manda la información a nuestro servidor de Node.js para su almacenamiento.
  • El servidor la guarda en su BBDD en MongoDB, y a los invitados de la misma le manda un mensaje, a cada uno, con los datos de la Qdada a través de la nube de Google (GCM).
  • El servicio de Google (GCM) se encarga de ver cuando el usuario tiene conexión a internet y notificarle en su móvil que ha sido invitado a una nueva Qdada.
  • La aplicación de Qdemos (que tiene un broadcast receiver implementando para capturar las notificaciones de GCM que sean para él) mostrará al usuario el tipico mensaje de nueva notificación push en la barra de estado del smartphone.
  • El usuario puede desplegar la barra y ver la notificación, que si pincha en ella le llevará a la aplicación de Qdemos, abriendo la Activity encargada de mostrar la info de la Qdada y poder responer a las fechas propuestas en esta.
Funcionamiento de GCM para Android usando un servidor propio.

Funcionamiento de GCM para Android usando un servidor propio.

Para la parte del servidor, al usar Node.js, pues tenía que buscar algún módulo que me permitiría comunicar mi servidor con la nube de Google. Y afortunadamente, y gracias a la comunidad, hay uno realmente bueno, que podeis encontrar aquí: Modulo GCM para Node.js De manera que podeis ver en la imagen de abajo qué fácil es enviar algo por GCM a nuestra app desde nuestro servidor. El código ya está implementado para enviar esa Qdada a todos los invitados, así que esto va viento en popa a toda vela. 🙂

Código para enviar una Qdada desde el servidor nuestro al móvil de los invitados

Código para enviar una Qdada desde el servidor nuestro al móvil de los invitados

Como siempre el commit de esto que os explico lo podeis ver aquí: Commit.

¡Sed Felices!