Por mucho que apliquemos buenas prácticas, escribamos tests unitarios y tratemos de hacer las cosas bien, antes o después llega un momento en que no nos va queda más remedio que mancharnos las manos y depurar las aplicaciones.

En el caso de aplicaciones desarrollados con PhoneGap/Cordova no es sencillo depurar la aplicación y tenemos que conformarnos con herramientas más básicas que las que solemos emplear en otros entornos.

Cuando estuve contando cómo crear un plugin para Cordova, decía que la arquitectura general de Cordova era algo así:

Esto quiere decir que realmente para depurar una aplicación desarrollada Cordova tenemos que poder depurar dos cosas distintas, la parte nativa y la parte HTML/JS.

Depurando la parte nativa

La parte nativa es la que menos problemas supone a la hora de depurar. Primero, porque a menos que estés desarrollando un plugin, es poco probable que necesites depurar nada. Segundo, porque para depurarla puedes utilizar las herramientas propias de cada plataforma.

En el caso de Android, para depurar la parte nativa puedes utilizar las herramientas de depuración de Eclipse y el plugin para desarrollo en Android.

Depurando la parte Javascript

Por degracia para ti cuando te toque depurar, la mayor parte de la complejidad de una aplicación Cordova reside en el código Javascript.

En un PC hay herramientas muy buenas para depurar Javascript y, en general, sólo con los propias opciones de desarrollo incluidas en los navegadores suele bastar. Sin embargo, en un dispositivo Andriod esta parte es mucho más complicada de depurar que la parte nativa, y de hecho no conozco un depurador «de verdad» que lo permita, sólo herramientas que nos pueden ser más o menos útiles.

Ya hablé en una ocasión de weinre, un sistema que nos permite inspeccionar páginas HTML de forma remota y que puede resultar bastante práctico.

Otra opción es ir mostrando en consola mensajes que nos ayuden a trazar la aplicación. Es un sistema feo, manual, tedioso y arcaico, pero a veces poder escribir un console.log(‘ha pasado algo’) es mejor que nada. Por lo menos es más cómodo que ir escribiendo alerts.

La cuestión es, ¿cómo podemos ver lo que se escribe con console.log?

En el caso de Android, existe un log global del sistema, al estilo del /var/log/messages de cualquier distribución linux. Cordova utiliza ese log para ir almacenando tanto sus propios mensajes de funcionamiento, como los mensajes que podamos escribir desde javascript usando console.log.

Para consultar el log, podemos recurrir a la herramienta adb, que está incluida en el SDK de android y nos permite ver en tiempo real el log del dispositivo usando el siguiente comando:

adb logcat

Este comando accederá al teléfono que esté conectado (o al emulador) y mostrará en pantalla el log que se va generando en tiempo real:

Como se puede ver, el log incluye todo lo que está pasando en el teléfono, lo que hace que sea un poco complicado de seguir. Aun así, en la zona marcada con el recuadro rojo aparece al parte específica de Cordova, avisando de un error en uno de los ficheros javascript de la aplicación.

Se puede obtener un log más limpio usando los filtros de adb logcat:

adb logcat Cordova:D DroidGap:D CordovaLog:D *:S

El formato de los filtros es origen:nivel. En este caso, estamos indicando que para los orígenes Cordova, DroidGap y CordovaLog se muestren todos los mensajes a partir de nivel D (DEBUG) y para el resto de logs (*), se silencien los mensajes (S). Con esto el log queda mucho más legible:

La línea marcada en rojo en la imagen anterior se corresponde con una llamada a console.log desde el código de nuestra aplicación.

Resumen

La depuración de aplicaciones desarrolladas con Cordova es un poco complicada. La parte nativa de la aplicación se puede depurar usando las herramientas normales de desarrollo para cada plataforma, pero la parte javascript requiere el uso de técnicas más enrevesadas o menos prácticas, con herramientas como weinre o el uso de adb y llamadas console.log como hemos visto en este post.