domingo, enero 23, 2005
Un Swing de profesional
No, esta entrada no es sobre golf: es sobre Java. Swing es el entorno de programación para interfaces gráficas (GUI) de Java. Tiene bastante mala fama, de ser feo, difícil y lento. Por eso tal vez Java no ha despegado en el escritorio, y mucha gente lo recomienda sólo para el servidor (en servlets), pero últimamente estoy viendo más aplicaciones hechas en Java. De hecho, en la actualidad mi editor de texto por defecto es jEdit.
Ben Galbraith tiene dos muy buenas presentaciones. La primera trata de cómo mejorar el Look & Feel y cómo facilitar el uso de Swing. Sobre el Look & Feel (el aspecto y el comportamiento) de las aplicaciones en Java, primero dice lo que es obvio: el aspecto por defecto de las Looks & Feels que vienen con Java 1.4 es muy malo. Parece que en 1.5 han mejorado, pero de todas formas, recomienda JGoodies, un entorno libre que sí da un aspecto profesional a las aplicaciones, y Alloy L&F como entorno comercial. En javootoo.com hay más información sobre Looks & Feels.
Otra de las ventajas de Java 1.5 es que introduce Synth, una API para desarrollar nuevos Looks & Feels más fácilmente. Además también permite definir interfaces en XML, como XUL y Avalon.
Con respecto a la facilidad de uso, recomienda utilizar GridBagLayout como layout manager, pero con Packer, que lo hace mucho más fácil.
Otra alternativa que recomienda es JGoodies Forms.
Al final también habla de utilizar XUL para definir el interfaz. Dice que la ventaja es que obliga al desarrollador a separar el interfaz de la lógica, porque muchas aplicaciones acaban teniendo las típicas clases apestosas (son sus palabras) en las que todo está mezclado.
Para empezar, explica que XUL es algo genérico y que distintos desarrollos utilizan distintos dialectos de XUL, casi todos inspirados en el dialecto canónico, que es, por supuesto, el de Mozilla. Hay varios dialectos de XUL para Swing. Uno de ellos es Luxor, muy parecido al de Mozilla pero complicado y no muy bien integrado con Swing. Otro, el que recomienda, es SwiXML, que tiene justo las características contrarias al anterior: fácil de usar y centrado en Swing.
En la segunda presentación aborda la forma de hacer que las aplicaciones con Swing respondan más rápido.
El problema habitualmente es que el código de tratamiento de eventos de Swing lo realiza el AWT Event Dispach Thread, es decir, el hilo encargado de despachar eventos de interfaz de usuario. El problema es que, cuando se hace un listener (un método que responde a un evento de interfaz), si se pone ahí todo el código como respuesta a ese evento y ejecutarlo lleva más de un cuarto de segundo, el usuario notará que la aplicación deja de responder. La razón es que el hilo de despacho de eventos de interfaz está ocupado haciendo el trabajo pesado.
La solución: crear en el listener un nuevo hilo para hacer el trabajo pesado de tal manera que se puedan seguir despachando eventos de usuario. Pero el problema es que cuando queramos actualizar el interfaz después de haber acabado el trabajo, no lo podemos hacer desde el nuevo hilo, ya que el único que puede tocar el interfaz es el hilo de despacho de eventos. La solución es meter en la cola de eventos las acciones que queremos hacer. Está todo perfectamente explicado con un ejemplo en la presentación.
Por cierto, una cosa que me impresiona es que según lo estaba viendo, me decía: "Muy bien, todo muy lógico, pero está quedando un código apestoso, con clases creadas dentro de los listeners". Y va el tío y suelta: "Bueno, esto lo podemos mejorar haciendo refactoring", le da a un botón, y se supone que eso ha sacado el código de ahí y le ha creado su propia clase. No sé que IDE está utilizando (imagino que Eclipse o NetBeans), pero me ha gustado mucho.
De todas formas, crear esto sólo a partir de funciones de Swing sigue siendo tedioso, así que recomienda utilizar SwingWorker, una clase que se encarga de crear el hilo y encolar la respuesta, mucho más limpio.
Por último, habla de FoxTrot, que permite básicamente hacer lo mismo que SwingWorker pero en lugar de ser asíncrono, es síncrono.
Realmente me han gustado mucho estas presentaciones. Si alguien tiene problemas viéndolas en Linux, puede leer los comentarios en la noticia de OSNews donde las he descubierto.
Ben Galbraith tiene dos muy buenas presentaciones. La primera trata de cómo mejorar el Look & Feel y cómo facilitar el uso de Swing. Sobre el Look & Feel (el aspecto y el comportamiento) de las aplicaciones en Java, primero dice lo que es obvio: el aspecto por defecto de las Looks & Feels que vienen con Java 1.4 es muy malo. Parece que en 1.5 han mejorado, pero de todas formas, recomienda JGoodies, un entorno libre que sí da un aspecto profesional a las aplicaciones, y Alloy L&F como entorno comercial. En javootoo.com hay más información sobre Looks & Feels.
Otra de las ventajas de Java 1.5 es que introduce Synth, una API para desarrollar nuevos Looks & Feels más fácilmente. Además también permite definir interfaces en XML, como XUL y Avalon.
Con respecto a la facilidad de uso, recomienda utilizar GridBagLayout como layout manager, pero con Packer, que lo hace mucho más fácil.
Otra alternativa que recomienda es JGoodies Forms.
Al final también habla de utilizar XUL para definir el interfaz. Dice que la ventaja es que obliga al desarrollador a separar el interfaz de la lógica, porque muchas aplicaciones acaban teniendo las típicas clases apestosas (son sus palabras) en las que todo está mezclado.
Para empezar, explica que XUL es algo genérico y que distintos desarrollos utilizan distintos dialectos de XUL, casi todos inspirados en el dialecto canónico, que es, por supuesto, el de Mozilla. Hay varios dialectos de XUL para Swing. Uno de ellos es Luxor, muy parecido al de Mozilla pero complicado y no muy bien integrado con Swing. Otro, el que recomienda, es SwiXML, que tiene justo las características contrarias al anterior: fácil de usar y centrado en Swing.
En la segunda presentación aborda la forma de hacer que las aplicaciones con Swing respondan más rápido.
El problema habitualmente es que el código de tratamiento de eventos de Swing lo realiza el AWT Event Dispach Thread, es decir, el hilo encargado de despachar eventos de interfaz de usuario. El problema es que, cuando se hace un listener (un método que responde a un evento de interfaz), si se pone ahí todo el código como respuesta a ese evento y ejecutarlo lleva más de un cuarto de segundo, el usuario notará que la aplicación deja de responder. La razón es que el hilo de despacho de eventos de interfaz está ocupado haciendo el trabajo pesado.
La solución: crear en el listener un nuevo hilo para hacer el trabajo pesado de tal manera que se puedan seguir despachando eventos de usuario. Pero el problema es que cuando queramos actualizar el interfaz después de haber acabado el trabajo, no lo podemos hacer desde el nuevo hilo, ya que el único que puede tocar el interfaz es el hilo de despacho de eventos. La solución es meter en la cola de eventos las acciones que queremos hacer. Está todo perfectamente explicado con un ejemplo en la presentación.
Por cierto, una cosa que me impresiona es que según lo estaba viendo, me decía: "Muy bien, todo muy lógico, pero está quedando un código apestoso, con clases creadas dentro de los listeners". Y va el tío y suelta: "Bueno, esto lo podemos mejorar haciendo refactoring", le da a un botón, y se supone que eso ha sacado el código de ahí y le ha creado su propia clase. No sé que IDE está utilizando (imagino que Eclipse o NetBeans), pero me ha gustado mucho.
De todas formas, crear esto sólo a partir de funciones de Swing sigue siendo tedioso, así que recomienda utilizar SwingWorker, una clase que se encarga de crear el hilo y encolar la respuesta, mucho más limpio.
Por último, habla de FoxTrot, que permite básicamente hacer lo mismo que SwingWorker pero en lugar de ser asíncrono, es síncrono.
Realmente me han gustado mucho estas presentaciones. Si alguien tiene problemas viéndolas en Linux, puede leer los comentarios en la noticia de OSNews donde las he descubierto.
