Todos sabemos la importancia que ha tomado Firebase en el desarrollo de las aplicaciones móviles en los últimos años y sus numerosas aplicaciones. Sin embargo, su importancia en el mundo de los datos está, ahora, en su culmen.
Sobre todo con el nuevo lanzamiento por parte de Google de las propiedades Web+app, donde cambia drásticamente la forma de medir y analizar nuestros datos, utilizando un modelo “User first” centrado en los eventos y en los datos cross-device. Esto, ha provocado que las implementaciones en Firebase hayan cobrado una mayor relevancia en estos últimos meses y, por tanto, es importante saber cómo realizar las validaciones de forma correcta.
La forma idílica de realizar validaciones siempre será la proporcionada por la propia herramienta, es decir, utilizando StreamView y/o DebugView que son las proporcionadas por parte de Firebase. Sin embargo, en muchas ocasiones necesitamos validar implementaciones donde sólo disponemos de la app instalable y no tenemos acceso a Firebase. Entonces, ¿cómo podemos depurar en estos casos?
La respuesta es simple: utilizando un proxy debugger como Charles. Tiene una configuración simple, y en él podemos encontrar las peticiones de red que salen del dispositivo hacia Firebase con facilidad.
La ventaja de utilizar Charles reside en que éste realiza una traducción básica del formato batch de las peticiones realizadas por nuestro dispositivo, para que podamos visualizar un “texto plano”. Esta traducción no es completa debido a que el formato utilizado para su codificación, utiliza ciertos parámetros variables en función de las claves de los pares clave/valor utilizados en el contenido del mensaje para llevarla a cabo.
Sin embargo, la gran pregunta es, ¿cómo identificamos las peticiones dirigidas a Firebase?
Para ello, simplemente tenemos que filtrar por el término “app-measurement” que corresponde con el dominio al que se dirigen todas las peticiones. Puede que, debido a cómo funcionan los sistemas operativos de los distintos dispositivos móviles, estas peticiones no aparezcan instantáneamente en el momento requerido y requieran la espera de algún minuto.
Una vez tengamos nuestras peticiones visibles, iremos a la pestaña de “Contents” y dentro de ésta, al apartado “Text”. Aquí podremos ver, finalmente, el contenido de las peticiones:
Aunque el contenido no es visible al 100% pero sí que podemos sacar en claro algunos términos como el “screen name”(_sn) es “Tab1” o la “screen class” es “MainViewController”. Estos datos se disponen repetidas veces a lo largo del texto, pero los datos más importantes son informados en el párrafo final:
En este, observamos el elemento clave de la medición de Firebase, los eventos (“home_impression” en nuestro caso). Este siempre irá al comienzo del párrafo y acompañado del resto de parámetros, tanto por defecto como los personalizados. La mayoría de ellos no son visibles por la codificación pero, algunos como el sistema operativo, el dispositivo o el idioma son decodificados por la herramienta y son, fácilmente, identificables.
Con estos pasos terminamos esta guía en la que podemos depurar cualquier aplicación que utilice Firebase de forma muy básica y en tan sólo unos minutos!
