Debug de aplicaciones remotas

En mi opinión uno de los cambios más significativos en el desarrollo de aplicaciones RIA que introducido Flex es el debugger. Personalmente, sin debugger, no sería nadie.

Recuerdo los tiempos en los que trabajaba en Flash, y aunque Flash ha tenido siempre un debugger la verdad es que deja mucho que desear, el código estaba lleno de instrucciones trace. El concepto de debug estaba más cercano al dejar migas de pan que a otra cosa. ¿No hemos usado todos instrucciones del estilo trace (“estoy aquí”), trace (“estoy allá”), etc?

A los que no estés acostumbrados a usar el debugger os invito a que lo probeis y os garantizo que lo llegareis a querer y no podreis vivir sin él. La clave del buen desarrollador no es sólo buscar el pragmatismo en la excelencia de las soluciones que desarrollo, sino darle sostenibilidad al desarrollo y poder acotar y solventar los errores en la mayor brevedad y con las máximas garantías posibles. Para esto tenemos que tener en nuestra caja de herramientas un buen set de herramientas.

Normalmente una aplicación la desarrollamos en local, la probamos en un servidor de test para finalmente desplegarla en un servidor de producción. ¿Qué sucede cuando una aplicación funciona a la perfección en local y en el servidor de test pero falla en producción? ¿Cómo podemos aislar las diferencias entre los entornos? Por mucho que queramos y que pongamos toda nuestra buena intención para que no suceda, es una situación que se suele dar.

Una de las herramientas que tenemos a nuestra disposición como desarrolladores es debugar la aplicación directamente sobre el servidor de producción o sobre cualquier otro entorno que no sea el entorno local.

Antes de ver el como creo que es interesante ver cómo funciona el debugger internamente tanto a nivel de Flash Player como a nivel de Flex Builder.

Flash Player cuando carga un swf compilado para debug (la compilación por defecto de Flex Builder) intenta establecer una conexión vía socket a un puerto determinado. Si dicho puerto (que podéis ver con netstat en una consola de Mac, Linux o cygwin) está abierto da comienzo un protocolo de handshake para que a posteriori Flash Player vaya mandando información a través del socket de qué código se está ejecutando y demás.

En el otro extermo de la comunicación se encuentra el debugger en sí. De esta forma cuando desde Flex Builder lanzamos el debug lo que se hace es abrir un puerto listo para escuchar la petición de Flash Player y atender a la información que le llegue. De una forma esquemática sería algo así:

  • Lanzamos un debug de una aplicación desde Flex Builder
  • Flex Builder abre un puerto para hacer el handShake con Flash Player
  • Flex Builder lanza en el navegador una aplicación
  • Flash Player detecta que está compilada en modo debug
  • Flash Player intenta establecer una conexión con el puerto de debug
  • Flex Builder responde a la petición y hacen el handshake
  • Empieza una comunicación bidireccional entre Flash Player y Flex Builder para hacer un step by step, inspeccionar el valor de propiedades, etc. que permite navegar por el código a la vez que inspeccionar los stack trace, evaluar valores, etc. a partir de un breakpoint determinado

Pues bien, volviendo al título de este post, si queremos debugar una aplicación en un entorno remoto evidentemente no la podemos lanzar directamente desde Flex Builder ya que no está en nuestra máquina. Veamos qué pasa cuando subimos una aplicación compilada en debug mode a un servidor y la cargamos desde el navegador:

  • Cargamos en el navegador la url con la aplicación
  • El navegador instancia a Flash Player
  • Flash Player detecta que es una aplicación en debug mode
  • Flash Player intenta establecer una conexión contra el puerto de debug
  • Como la aplicación no se ha lanzado desde FB, no hay nadie escuchando ese puerto y el handshake falla
  • Flash Player discrimina que no se va a debugar y procede con una ejecución normal

Viendo esto lo único que parece que tenemos que hacer es forzar a Flex Builder a que esté escuchando al puerto de debug para poder atender a la petición de Flash Player. Pues resulta que esto es posible engañándolo un poco. La diferencia real entre hacr un “run” y un “debug” dentro de Flex Builder es que FB abre el puerto o no. El problema es que si lanzamos un debug de una aplicación enseguida entrará en modo debug y no habrá forma de debugar la aplicación remota. En fin, aquí va cómo hacerlo:

  • Abrimos el diálogo: “Open Debug Dialog”.
  • Creamos un nuevo profile de debug.
  • En el nuevo profile escogemos qué proyecto queremos debugar y le cambiamos el nombre al profile.
  • Este es el punto más importante. En las urls de debug, profile y run podemos poner la url queremos debugar. Una forma directa sería poner ahí la url del servidor remoto y todo estaría perfecto. Yo personalmente no lo tengo así sino que pongo http://www.google.com o la web que os de más rabia (luego vemos por qué).
  • Ya podemos lanzar el debug

Si habeis puesto la url remota del swf ya tendreis el debug remoto funcionando sin problemas. Si habeis puesto google.com simplemente vereis que os lanza la web de google y no pasa nada más. Pero realmente lo que pasa es que FB tiene un puerto en stand by esperando la conexión de un Flash Player para hacer un debug. Si recargais la página del entorno que quereis debugar vereis que el debug se enganchará.

¿Por qué poner google.com y no la url? Uno de los motivos es que así no tengo 1001 profiles de debug remotos, no es lo habitual. De esta forma puedo utilizar el mismo profile (aunque tenga que cambiar el proyecto asociado cada vez). Pero la utilidad más grande que le encuentro es otra. Tengo aplicaciones que aceptan parámetros por url, y que justo en el momento de la inicialización y dependiendo de esos parámetros hace una cosa u otra. Cuando trabajo en local no hay forma de pasarle esos parámetros. Si le ponemos por ejemplo como ruta de debug algo del estilo de /path/to/debug/bin-debug/app.html?id=hola en el momento de lanzar la aplicación nos saltará un mensaje del estilo “File XXXXX no existe”. La solución sería lanzar un debug contra nuestro amigo google, abrir otra pestaña en firefox y cargar la ruta que nos interesa.

En fin, mucho rollo para explicar una debug, pero creo que es muy interesante ver cómo funcionan las cosas por debajo :-)cy

Xavi es un Technical Arquitect de Aplicaciones RIA basadas en la Plataforma Flash trabajando para Adobe en Londres. Especializado en aplicaciones colaborativas en tiempo real, e-learning y CMS (Content Management Systems) utiliza Flex, LCDS, BlazeDS, FMS y Java principalmente.

Sitio Web:http://www.code4net.com

7 Comentarios

  1. Pingback: » Enlaces interesantes de los últimos días « Cerebro en la Sombra

  2. eme

    pues si!
    increible pero funciona!
    He tenido que descargarme el ‘flash player debug version’ desde adobe (el mismo flex me ha avisado cuando he intentado compilar)
    mercings!

  3. David Moreno

    Simplemente magnífico

    Suele ser bastante complejo analizar los errores online, y más con objetos swf. Durante los inicios de AS recuerdo tener que crear un campo de texto como variable y enviar la misma información que envias en local por trace.

    Como bien dices el uso de un buen debug es imprescindible para un buen desarrollador. Y por supuesto, el de flash deja mucho que desear.

    Gracias.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase