Charla en la Universidad de Murcia

Hace unas semanas tuve la oportunidad de dar una charla a los alumnos de la Facultad de Informática de la Universidad de Murcia, a los llamados fiumers. En esta facultad y universidad es donde yo hice todos mis estudios, incluyendo el doctorado, por lo que fue todo un honor poder contarles mi experiencia.

La charla es parte de un ciclo de charlas de antiguos alumnos, a los que llaman Fiumers Pro, para hablar de sus carreras en el mundo profesional. Aquí podéis encontrar más información.

Ciclo de Charlas de antiguos alumnos

El título de mi charla fue “De Murcia a Silicon Valley”, en la que conté mi camino hasta Silicon Valley y cómo se trabaja, desde mi perspectiva de ingeniera española. Di además consejos y recomendaciones específicos para ir a Silicon Valley, pero también para cualquier carrera profesional sin importar el lugar.
 

 

Me gustaría enseñar algunas de las transparencias aquí como muestra de lo que fue la charla.

Charla

Charla

Charla

Charla

Piktochart.

Por último, agradecer de nuevo a la facultad por esta oportunidad y a todo el mundo que asistió la charla. Se hicieron preguntas muy interesantes.

 

Share Button

Leer Más

Entrevista en la 7 TV Murcia

En este nuevo post dejo la entrevista que hice en directo en la 7 TV de la Región de Murcia.

Aprovechando mi visita a Murcia (España), di una charla a los alumnos de la Facultad de Informática de la Universidad de Murcia, universidad donde yo estudié e hice mi doctorado.

A raíz de la charla, acudí también a la 7 Televisión Región de Murcia a dar una rápida entrevista en directo para el informativo matinal.

¿Cómo ha sido el recorrido de Murcia a Silicon Valley?¿Qué te encuentras allí?¿Cómo es tu día a día en Silicon Valley?

Share Button

Leer Más

Mi experiencia en la F8

F8 es la conferencia para desarrolladores celebrada cada año por Facebook. En esta conferencia se anuncian las últimas novedades de la compañía. Este año 2018 repite localización en el McEnery Convention Center de San José.

Yo tuve la oportunidad de asistir este año a los dos días de la conferencia y aquí os cuento mi experiencia.

Keynote

La conferencia arranca con la keynote, la cual es retransmitida en directo y vista por miles de personas de todo el mundo. Este año el foco caía sobre los problemas que recientemente ha tenido la compañía sobre la privacidad de los datos de sus usuarios. Durante los primeros minutos de la keynote, Mark Zuckerberg se centra en hablar cómo Facebook está trabajando en solucionar estos problemas. Aquí podéis ver el vídeo completo de la keynote.

 

F8 Keynote

 

Destaco dos momentos. Primero, el que provocó más risas entre los asistentes, cuando Mark Zuckerberg puso su propio video declarando en el Congreso de EEUU. Y el segundo momento, cuando los asistentes más aplaudimos, que fue cuando Mark Zuckerberg dijo que todos los asistentes recibiríamos unas Oculus Go gratis.

Tras la keynote, la sala “Festival Hall” quedó abierta. En esta sala podemos encontrar diferentes zonas donde probar las novedades anunciadas, como las Oculus Go o la realidad aumentada en messenger.

 

F8 Festival Hall

 

Sesiones

También hay que hablar de las sesiones, que para eso se trata de una conferencia. Yo asistí a un total de unas 10-12 sesiones. De todas ellas, solamente en 2 se mostró algo de código. Con esto quiero decir que el nivel técnico de las sesiones es bajo. Más aún teniendo cuenta que ésta es una conferencia para desarrolladores. La mayoría de ellas parece estar más enfocada a producto o a management, que a ingeniería.

Una sesión interesante fue la de “How React Native Helps Companies Build Better Mobile Apps”, que aunque en formato de panel, se debatió sobre cómo React Native ha sido utilizado en varias empresas (Microsoft, TaskRabbit, Vogue.com y Postlight), y cómo esto ha influido en la distribución de los equipos de ingeniería y en la forma de trabajar de la empresa. De nuevo, nada técnico, pero da una buena vision del uso de esta tecnología.

 

La conferencia es una buena fuente de inspiración de lo que viene en el futuro.

 

F8 Session
 

“Networking” y demás eventos

Finalmente, como cualquier conferencia de este tipo, hubieron varios eventos informales para conocer gente y pasar el rato, con comida, bebida y música. El evento principal, fue la correspondiente fiesta After Party consistente en un concierto. Este año fue Logic el performer de esta fiesta.

 

F8 After Party

 

PD: Ya solo me queda llegar a casa y probar mis nuevas Oculus Go!

Share Button

Leer Más

Talento y tecnología

Esta semana tuvo lugar el evento de Jóvenes con Futuro, talento y tecnología, en el cual participé de forma remota desde San Francisco.

Yo fui participante del programa de Jóvenes con Futuro en Estados Unidos de la pasada edición, y gracias a ello pude comenzar a trabajar en Silicon Valley. El propósito del evento era dar a conocer el programa y así animar a los futuros candidatos. Aquí tenéis la web con información del programa.

Jóvenes con Futuro talento y tecnología

¡Hasta el 20 de diciembre!

Actualmente se encuentra abierto el plazo para participar en la nueva edición de Jóvenes con Futuro España. Este programa te permite vivir la experiencia de trabajar en una startup en España, entrar en la comunidad de Jóvenes con Futuro, y quizá en un futuro ¡poder dar el salto a Silicon Valley!

Dejo aquí el vídeo completo del evento que tuvo lugar en Madrid:

También están disponibles las imágenes de la charla:

Acto Presentación Programa de Becas Jóvenes con Futuro

Share Button

Leer Más

Ser becario en Silicon Valley

En este post quiero mostrar un poco cómo se trabaja en Silicon Valley y cómo es ser becario aquí.

Hace un año vine a trabajar como becaria gracias al programa de Jóvenes con futuro. Podéis ver la info en este post que escribí entonces. En relación a esto, tuve la oportunidad de grabar algunos vídeos y de hacer una entrevista para Antena 3. Este pequeño reportaje se emitió hace unas semanas en las noticias de la cadena: A FONDO: BECARIOS DE ÉLITE.

Se grabaron varias preguntas para la entrevista, de las cuales sólo se ha publicado una mínima parte. Lo que quiero mostrar aquí es la entrevista entera que se realizó.

¿Cómo está siendo la experiencia en Silicon Valley?

La experiencia está siendo muy positiva, tanto en lo personal como en lo profesional. En los 9 meses que llevo aquí, he aprendido un montón. Dedicándome al mundo de la tecnología, aquí te sientes en el centro de todo lo relacionado con la informática.

¿Cómo están considerados los becarios?

Aquí los becarios están considerados como un empleado más. Tienen las mismas responsabilidades y es común que te ofrezcan quedarte en la empresa. En mi caso, llevo menos de un año trabajando y ya en un par de meses voy a pasar a ser empleada normal de la plantilla.

¿Cuánto puede llegar a cobrar un becario?

El sueldo de un becario varía según la empresa. Depende de si estás en una startup o en una compañía grande. Yo cuando pasé de la startup en la que empecé a trabajar, a una compañía grande, el sueldo me lo doblaron. En una compañía grande, un becario, el sueldo puede rondar entre los $50,000 y $80,000 al año.

Además la empresa te suele ofrecer muchas ventajas. Por ejemplo, nos dan de comer en la oficina y tenemos una cocina a nuestra disposición para hacernos el café o para tomar bebidas. También hay una zona de ocio en la oficina. A parte de eso, pueden llegar a pagar parte del transporte, se puede tener una política de vacaciones ilimitadas, o un horario completamente flexible.

¿Cuál es el nivel de vida en San Francisco?

Aquí los sueldos son muy altos porque también el nivel de vida es muy alto. San Francisco es una de las ciudades más caras de Estados Unidos, especialmente el tema del alojamiento. Por ejemplo, una habitación en un piso compartido te puede costar $1000 como mínimo, y un estudio entero suele rondar los $3000 al mes.

¿Qué normas existen respecto al horario o a las normas de vestimenta?

El horario es muy flexible, tenemos total libertad. Lo importante es que al final vayas cumpliendo tus objetivos.

No hay normas de vestimenta tampoco, especialmente en las empresas tecnológicas donde es muy raro que alguien vaya a trabajar en traje de chaqueta.

¿Es un mundo muy masculino?

Es cierto que el mundo de la informática sigue siendo muy masculino, pero cada vez somos más mujeres. En mi experiencia personal, no he sentido ningún tipo de discriminación, ni por ser mujer, ni tampoco por venir del extranjero.

¿Cómo se valora a los españoles?

Aquí trabaja gente de todo el mundo y por tanto no se hace ningún tipo de distinción por tu país de origen. En mi experiencia, los españoles estamos muy bien preparados, y todos los que hemos venido con el programa de Jóvenes con Futuro estamos muy valorados por nuestras empresas.

¿Qué es lo que más se echa de menos de España?

Lo que más se echa de menos es la familia y los amigos, más aún con la gran diferencia horaria de 9 horas. Es más difícil poder hablar y coincidir con ellos.

¿Piensas quedarte?

De momento no tengo planes inmediatos de volver porque aquí las condiciones laborales son geniales. Me encuentro en un ambiente tecnológico inigualable a otro sitio.

Share Button

Leer Más

Análisis de la batería del Apple Watch

Uno de los factores clave para la adopción de los dispositivos conocidos como “wearables”, es la duración de su batería.

Usamos portátiles, smartphones y tablets que necesitamos cargar casi a diario. Tener un wearable, como un smartwatch, lleva consigo un dispositivo más a cargar. Si tu smartphone está casi sin batería, puedes buscar un lugar donde cargarlo mientras tanto. Con un smartwatch necesitamos quitarlo de nuestra muñeca. No podemos mirar la hora mientras se está cargando, al menos no mirando nuestra muñeca directamente.

La duración de la batería es una característica importante que debemos tener en cuenta cuando elegimos un smartwatch, por eso he medido cómo se consume la batería del Apple Watch. En esta entrada quiero mostrar los resultados.

Estas son las especificaciones del Apple Watch que he usado para los tests:

Apple Watch Sport
Alto: 42.0mm
Ancho: 35.9mm
Grosor: 10.5mm
Caja: 30g
Color blanco.

Consumo de batería

El análisis del consumo de la batería del Apple Watch corresponde a un uso básico del reloj.

Esto quiere decir que las acciones con el reloj fueron mirar la hora de vez en cuando y leer algunas notificaciones. No pasé tiempo explorando las aplicaciones, ni miré mapas ni registré actividad física.
Como resultado, la duración de la batería del Apple Watch es de aproximadamente unas 50 horas: algo más de 2 días.
Por tanto, si realizas más acciones con el reloj que las de mirar la hora o leer notificaciones, la batería durará menos de 2 días, por lo que necesitarás cargarlo todos los días.

La siguiente gráfica muestra el gasto de batería a lo largo de la horas.

Nivel de batería

Ahorro de batería

Cuando el nivel de batería del Apple Watch es muy bajo, en torno al 10%, el modo de ahorro de batería se activa automáticamente. También puedes activar este modo en cualquier momento desde la pantalla de Batería o desde el menu de apagado del reloj.
En el modo de ahorro de batería solamente puedes ver la hora junto a un icono rojo de batería. El reloj ya no reacciona cuando tocas la pantalla por lo que necesitas pulsar el botón físico lateral para ver la hora.

Low power
Apple Watch no battery

Cuando el Apple Watch está en ahorro de batería, el consumo es mucho menor. Esto puede observarse en la siguiente gráfica, donde el modo de ahorro de batería estuvo activado durante varias horas.

Nivel de batería con ahorro de energía

Otros resultados

Apple Watch charging
Tiempo de carga 
El Apple Watch tarda aproximadamente unos 120 minutos en cargarse por completo. Son unas 2 horas.

Tiempo de arranque 
El Apple Watch tarda aproximadamente 1 minuto y 10 segundos en encenderse.

Share Button

Leer Más

Primer análisis del Apple Watch

En este post quiero mostrar las primeras impresiones del Apple Watch. Este post incluye: enlazar el reloj con tu iPhone, el cargador y qué ocurre cuando el reloj no puede conectar con el iPhone enlazado.

Mi experiencia es que Apple Watch is dispositivo curioso de llevar, pero al final he terminado usando el teléfono para todo y el reloj sólo para mirar la hora. El Apple Watch no es realmente bueno para mirar la hora, ya que la pantalla se enciente automáticamente cuando realizas el movimiento de girar la muñeca. Hay veces en las que nos haces ese movimiento o que el reloj no lo detecta correctamente. En estos casos, tienes que tocar la pantalla del reloj con tu dedo. A pesar de esto, la detección del movimiento de tu muñeca funciona realmente bien.

Estas son las especificaciones del Apple Watch que he usado para este post:

Apple Watch Sport
Alto: 42.0mm
Ancho: 35.9mm
Grosor: 10.5mm
Caja: 30g
Color blanco.

La siguiente imagen muestra la caja que contiene el Apple Watch. Se incluyen dos correas de tamaños diferentes, una más grande que la otra.

Apple Watch in box

 

Enlazando el Apple Watch

Necesitarás el Apple Watch (obvio) y la app de Apple Watch para iPhone.
La app de Apple Watch para iPhone está disponible desde la versión 8.2. Primero asegúrate de tener actualizado tu dispositivo con la versión de iOS 8.2 o posterior. Deberías ver la siguiente app de Apple Watch en tu móvil.

Apple Watch app icon

Una vez enciendas el Apple Watch, te pedirá que lo configures y lo enlaces con tu iPhone.
Abre la app del Apple Watch desde tu iPhone y sigue los pasos del asistente. Finalmente pulsa desde tu reloj el botón para comenzar a enlazar.

Apple Watch start pairing

Tanto el reloj como el iPhone muestran una pantalla indicando el proceso de sincronización.

Apple Watch pairing

Una vez ha terminado la sincronización, ¡ya está todo listo!

Apple Watch ready
Apple Watch apps

 

Cargando el Apple Watch

El cargador es un cargador magnético. Sólo necesitas situar tu reloj sobre él.
Apple Watch charger

Cuando el nivel de batería del Apple Watch es muy bajo, en torno al 10%, el modo de ahorro de batería se activa automáticamente. También puedes activar este modo en cualquier momento desde la pantalla de Batería or desde el menu de apagado del reloj.
En el modo de ahorro de batería, sólo puedes ver la hora junto a un icono rojo de batería. El reloj ya no reacciona cuando tocas la pantalla por lo que necesitas pulsar el botón físico lateral para ver la hora.
La siguiente imagen de la izquierda muestra el reloj con nivel de batería bajo. La imagen derecha muestra el reloj mientras está cargando.

Apple Watch no battery
Apple Watch charging

 

Desconectado de tu iPhone

El Apple Watch necesita tu iPhone para que la mayoría de sus características funcionen. Si el reloj no se puede comunicar con el iPhone enlazado, se muestra un icono rojo en la parte superior de la pantalla, tal y como muestra la siguiente imagen.

Apple Watch out of range

Cuando el teléfono está fuera de alcance, algunas aplicaciones no funcionarán en el reloj.
Como se ve en la siguiente imagen de la izquierda, un mensaje en rojo advierte al usuario que la información que se muestra fue actualizada hace varios días. El icono rojo que indica que el iPhone no está dentro del rango del reloj, se muestra en la parte superior derecha de la pantalla. La imagen derecha muestra una aplicación sin ninguna información.

Apple Watch weather
Apple Watch stock

 

Este post ha explicado los primeros pasos para poder usar tu Apple Watch. Si quieres aprender más, comprueba mis siguientes posts y aquí dejo el link al Manual del usuario del Apple Watch..

Share Button

Leer Más

Google Cloud Messaging. Parte VI: Respuesta al envío de mensajes

The Google Cloud Messaging (GCM) guide can be found here and is available in English, therefore I am writing these related posts in Spanish.

Esta es la parte VI de un conjunto de entradas sobre Google Cloud Messaging (GCM).


Cuando desde nuestro servidor enviamos una solicitud de envío de mensaje al sistema de GCM, éste nos envía un mensaje de respuesta. Es muy importante que leamos e interpretemos este mensaje y no asumir que nuestro mensaje fue enviado correctamente.

Encontramos dos niveles de errores: un primer nivel donde el error se produce en el envío de nuestra solicitud a los servidores GCM, y un segundo nivel donde el error se produce en el propio contenido de la solicitud. La siguiente figura representa de forma esquemática cómo puede ser una respuesta del sistema de GCM. Se toma como base que la solicitud se construye en formato JSON, y por tanto, la respuesta también se recibe en este formato. Existe la posibilidad de que este mismo proceso se realice en texto plano.
Message response

Código HTTP

El código del estado de la respuesta HTTP puede tener los siguientes valores:

  • 200
    La solicitud ha sido recibida correctamente. En este caso debemos examinar el cuerpo de la respuesta tal y como vemos en la figura anterior.
  • 400
    La solicitud no pudo ser interpretada como JSON, o la estructura del JSON era incorrecta. En el contenido de la respuesta se incluye la descripción detallada del error ocurrido.
  • 401
    Error autenticando a nuestro servidor. Revisa que la API Key sea la correcta.
  • 5xx
    Error interno del sistema de GCM. No tenemos que hacer nada en este caso, tendremos que intentarlo más tarde.

Contenido JSON

Si la solicitud fue correcta y obtenemos el código 200, el contenido vendrá estructurado en formato JSON con los siguientes campos:

  • multicast_id.
    Identificador único de la solicitud.
  • success.
    Número de mensajes procesados correctamente. Hay que recordar que en una solicitud podemos indicar una lista de receptores.
  • failure.
    Número de mensajes con error.
  • canonical_ids.
    Número de resultados que incluyen identificadores canónicos. Un identificador canónico es el identificador de registro que debemos usar para un dispositivo concreto. Esto quiere decir que el identificador de registro que tenemos almacenado en nuestro servidor es incorrecto por existir otro más reciente. Puede producirse esta situación si por mal funcionamiento de nuestra aplicación cliente, se solicitan dos registros del mismo dispositivo al sistema de GCM.
  • results.
    Listado del estado concreto de cada uno de los mensajes (cada uno de los identificadores de registro enviados en la solicitud) con los siguientes posibles campos:

    • message_id.
      Si existe este campo, es porque el mensaje es correcto. Representa su identificador.
    • registration_id.
      Si existe este campo, quiere decir que este mensaje es uno de los que se han contado para el campo “canonical_ids”. Contiene el identificador de registro válido.
    • error.
      Tipo de error.

Tipos de error

Estos son los tipos de errores que pueden producirse para un receptor concreto:

  • NotRegistered.
    El identificador ya no está registrado en GCM. Debe ser borrado de tu servidor.
  • MessageTooBig.
    El tamaño del mensaje no puede exceder los 4096 bytes.
  • MismatchSenderId.
    El grupo de emisores de los mensajes que puede recibir el identificador de registro no coincide con tu servidor.
  • MissingRegistration.
    No se encontraron identificadores de registro a quienes enviar el mensaje.
  • InternalServerError.
    Error en GCM, por lo que podemos intentar enviar la solicitud de nuevo. Puede producirse también como código HTTP 500.
  • InvalidDataKey.
    Los datos del mensaje contienen una clave que no puede ser usada debido a que es una clave que se usa internamente por GCM. Tendrás que cambiar el nombre de tu clave.
  • InvalidPackageName.
    El nombre del paquete asociado el identificador de registro no se corresponde con el de nuestra API key.
  • InvalidRegistration.
    El identificador de registro es incorrecto. Comprueba que se están enviando, guardando y recuperando correctamente.
  • InvalidTtl.
    El campo del tiempo de vida del mensaje no es válido. Recuerda que debe ser un entero entre 0 y 2.419.200 que representa segundos, el máximo son 4 semanas.
  • Unavailable.
    El servidor GCM tardó mucho tiempo en procesar la solicitud, por lo que podemos intentar enviar la solicitud de nuevo. Puede producirse también como código HTTP 500.

 

Share Button

Leer Más

Google Cloud Messaging. Parte V: Envío de mensajes

The Google Cloud Messaging (GCM) guide can be found here and is available in English, therefore I am writing these related posts in Spanish.

Esta es la parte V de un conjunto de entradas sobre Google Cloud Messaging (GCM).


En esta parte vamos a ver el funcionamiento de la parte del servidor. Partimos de la base de que conocemos el Registration ID de los dispositivos a los que vamos a enviar notificaciones. El comportamiento estándar sería aquel en el cual nuestra aplicación cliente manda una petición a nuestro servidor cuando recibe su Registration ID y el servidor lo almacena en una base de datos para recuperarlo posteriormente.

Para enviar una notificación tendremos que enviar una petición POST a la siguiente dirección:

https://android.googleapis.com/gcm/send

El contenido de la petición debe ir en formato JSON (como alternativa también se puede usar texto plano). En la cabecera debemos especificar que el tipo de contenido es JSON: “Content-Type: application/json” e indicar nuestra API Key: “Authorization: key=YOUR_API_KEY”.

Formato del contenido JSON

El contenido JSON puede contener los siguientes campos:

  • registration_ids.
    Es el único campo obligatorio. Es un array de cadenas (o strings) que representan los registration IDs de los dispositivos que van a recibir la notificación. Mínimo debe contener un valor.
  • collapse_key.
    Cadena de texto que se usa para unificar varios mensajes en una sola notificación. Este mecanismo se usa cuando un dispositivo pasa de estar desconectado a conectado, y recibe demasiados mensajes de golpe. Para evitar este molesto resultado, tan sólo le llegaría la última notificación junto con el texto especificado en este campo.
  • data.
    Objeto JSON que representa los pares de clave-valor de la información del mensaje. Estos pares clave-valor serán pasados en el Intent que se reciba en la aplicación. Se recomienda el uso de cadenas de texto para los valores, ya que de todas formas serán convertidos a este tipo. La única limitación es que el tamaño total del mensaje no exceda los 4kb.
  • delay_while_idle.
    Valor booleano (por defecto es falso) que indica si la entega del mensaje debe retrasarse hasta que el dispositivo esté activo.
  • time_to_live.
    Valor numérico que indica cuántos segundos debe mantenerse el mensaje en los servidores de GCM si el dispositivo no está activo. El valor por defecto son 4 semanas.
  • restricted_package_name.
    Cadena de texto que contiene el nombre del paquete de nuestra aplicación. Si se especifica este valor, sólo se enviarán los mensajes a los registration IDs que concuerden con el paquete.
  • dry_run.
    Valor booleano (por defecto es falso) que indica si el mensaje es de prueba, es decir, el mensaje no va a ser enviado realmente a los dispositivos.

Un ejemplo sencillo de un mensaje sería este:

{ "data": {
    "mensaje": "Nueva oferta",
    "id": "16044"
  },
  "registration_ids": ["1", "2", "3"]
}

Envío en PHP

El envío de mensajes puede realizarse desde cualquier tecnología que nos permita realizar una petición de tipo POST.
A continuación se muestra el código para enviar el mensaje del ejemplo anterior en lenguaje PHP.

$apiKey = 'xxxxxxxxx_xx_xxxxxxx';

// Cabecera
$headers = array('Content-Type:application/json',
                 "Authorization:key=$apiKey");

// Datos
$payload = array('mensaje' => utf8_encode('Nueva oferta'),
                 'id' => '16044');
$registrationIdsArray = array('1', '2', '3');

$data = array(
   'data' => $payload,
   'registration_ids' => $registrationIdsArray
);

// Petición
$ch = curl_init();
curl_setopt( $ch, CURLOPT_HTTPHEADER, $headers );
curl_setopt( $ch, CURLOPT_URL, "https://android.googleapis.com/gcm/send" );
curl_setopt( $ch, CURLOPT_SSL_VERIFYHOST, 0 );
curl_setopt( $ch, CURLOPT_SSL_VERIFYPEER, 0 );
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );
curl_setopt( $ch, CURLOPT_POSTFIELDS, json_encode($data));

// Conectamos y recuperamos la respuesta
$response = curl_exec($ch);

// Cerramos conexión
curl_close($ch);
Share Button

Leer Más

Google Cloud Messaging. Parte IV: Aplicación cliente

The Google Cloud Messaging (GCM) guide can be found here and is available in English, therefore I am writing these related posts in Spanish.

Esta es la parte IV de un conjunto de entradas sobre Google Cloud Messaging (GCM).


En la publicación anterior comenzamos a ver la aplicación Android cliente: la instalación de la librería GCM y la configuración del fichero AndroidManifest.xml. En esta parte vamos a terminar de mostrar la aplicación cliente viendo la parte de programación.
Necesitamos implementar básicamente tres acciones:

  • Registro del servicio GCM
  • Borrado del registro del servicio
  • Recepción de los mensajes

Registro y borrado del servicio

Lo más normal es que queramos que nuestra aplicación se registre al comienzo de su ejecución, sin que sea necesaria interacción por parte del usuario. Por este motivo, el código necesario para el registro de la aplicación a GCM lo insertaremos en el método onCreate de nuestra Activity principal. Según los requerimientos de cada aplicación, puede realizarse el registro de forma diferente.

import com.google.android.gcm.GCMRegistrar;
...

try{

   GCMRegistrar.checkDevice(this);
   GCMRegistrar.checkManifest(this);

   final String regId = GCMRegistrar.getRegistrationId(this);

   if (regId.equals("")) {
      GCMRegistrar.register(this, SENDER_ID);
   } else {
      Log.v(TAG, "Ya estoy registrado");
   }

} catch (UnsupportedOperationException e) {
   Log.e(TAG, "El dispositivo no soporta GCM.", e);
} catch (IllegalStateException e) {
   Log.e(TAG, "El manifest no está bien configurado.", e);
}

En la línea 6 comprobamos si el dispositivo soporta GCM, de lo contrario saltará una excepción que debemos capturar.
En la línea 7 se comprueba si el archivo AndroidManifest.xml está bien configurado, por lo que una vez sepamos que está correcto, podemos quitar esta llamada. Igualmente debemos tratar la posible excepción que nos saltará si la configuración está mal.
En la línea 9 buscamos el Registration ID. En el caso de que no exista, es porque aún no nos hemos registrado.
El registro se realiza en la línea 12 donde pasamos como parámetro nuestro Sender ID.

Si recordamos el proceso del servicio de GCM, en el registro debíamos indicar el Sender ID y el Application ID. El Sender ID está contenido en la constante SENDER_ID y el Application ID es tomado automáticamente por la librería de GCM. El Sender ID se obtiene desde la consola de Google APIs tal y como expliqué en la parte II.


Para borrar el registro, llamamos al método unregister.

GCMRegistrar.unregister(this);

Podemos crear una vista de configuración donde el usuario pueda desactivar las notificaciones.

Servicio receptor

Finalmente tenemos que implementar la lógica de nuestro cliente cuando le lleguen los eventos. Con el uso de la librería GCM para Android tan sólo tenemos que crear el servicio que declaramos en el manifest llamado GCMIntentService. Esta clase tiene que extender la clase base que nos proporciona la librería GCM, GCMBaseIntentService. Al extenderla podemos añadir automáticamente los métodos a implementar.

import com.google.android.gcm.GCMBaseIntentService;

public class GCMIntentService extends GCMBaseIntentService {

   @Override
   protected void onError(Context context, String errorId){
      // Error en el registro: tratamiento del error
   }

   @Override
   protected void onMessage(Context context, Intent intent){
      // Notificación recibida: informo al usuario u otra acción	
   }

   @Override
   protected void onRegistered(Context context, String regId){
      // Registro correcto: envío el regId a mi servidor	
   }

   @Override
   protected void onUnregistered(Context context, String regId){
      // Borrado correcto: informo a mi servidor
   }
}

Es tan sencillo como añadir la lógica de nuestra aplicación a estos cuatro métodos:

  • onError.
    Este método es llamado cuando intentamos registrarnos o borrarnos del servicio de GCM pero se recibe un error.
  • onMessage.
    Este método es llamado cuando los servidores de GCM envíen un mensaje al dispositivo (previo envío del mensaje de nuestro servidor a los servidores de GCM). Si el mensaje contiene datos, éstos están contenidos como extras en el intent:

    String mensaje = intent.getStringExtra("mensaje");
    
  • onRegistered.
    Este método es llamado cuando tras una solicitud de registro, se recibe el Registration ID asignado por GCM. Recordamos que este identificador debe ser enviado y almacenado en nuestro servidor.
  • onUnregistered.
    Este método es llamado cuando el dispositivo se da de baja del servicio de GCM. Debe informarse a nuestro servidor para que también lo elimine.

Los errores que pueden recibirse en el método onError se encuentran como constantes en la clase GCMConstants de la librería GCM:

  • ERROR_ACCOUNT_MISSING.
    No hay cuenta de Google asociada en el dispositivo. Nuestra aplicación debería pedir al usuario que añada una cuenta desde el gestor de cuentas en los ajustes del dispositivo.
  • ERROR_AUTHENTICATION_FAILED.
    La contraseña de la cuenta de Google es incorrecta. Nuestra aplicación debería pedir al usuario que introdujese su contraseña desde el gestor de cuentas.
  • ERROR_INVALID_PARAMETERS.
    La petición enviada por el dispositivo no contiene los parámetros que eran esperados. El dispositivo no soporta GCM.
  • ERROR_INVALID_SENDER.
    No se reconoce el Sender ID. En este caso debemos revisar bien el Sender ID que estamos usando en nuestra aplicación, y comprobar que coincide con el que obtuvimos en la consola de Google APIs.
  • ERROR_PHONE_REGISTRATION_ERROR.
    Registro incorrecto del dispositivo. El dispositivo no soporta GCM.
  • ERROR_SERVICE_NOT_AVAILABLE.
    El dispositivo no pudo leer la respuesta, o el servidor GCM devolvió un código 500/503. No es un error de nuestra aplicación, por lo que deberemos reintentarlo más tarde.
Share Button

Leer Más