framework - Java AWT/SWT/Swing: ¿cómo planificar una GUI?

set border java (10)

Además de la discusión de herramientas, solo algunas ideas y pensamientos

Antes de tocar el teclado, dibuje los elementos de la GUI en papel. Como el guión gráfico clásico utilizado para la producción de videos. Si tiene clientes, use los diseños dibujados a mano (!) Para comunicar las ideas (solo lea, que ya planea en papel)
Plan para implementar un modelo-vista-controlador (MVC) o un patrón de modelo-vista-presentador
Databinding es una gran técnica a considerar. Garantiza la sincronización entre su modelo (datos) y la vista (GUI) y ofrece validación de entrada, conversión sobre la marcha y muchas cosas más útiles (Proporcionó el enlace para el enlace de datos de JFace, pero estoy seguro de que hay otros marcos para Swing / AWT también)

Ya me he dado cuenta de algunas aplicaciones con una pequeña interfaz gráfica de usuario. Nada complejo, pero me he encontrado con varios problemas de que los componentes no se muestran o simplemente no se comportan como se esperaba.

Ahora mi pregunta:

¿Cómo planificas esas interfaces de usuario? ¿Qué haces cuando necesitas hacer cambios? ¿Cómo depurar comportamientos extraños?

Esto se aplica a casi todos los tipos de diseño de gui. Claro, con Microsofts Visual Studio tiene una gran ventaja porque casi obtiene lo que ve en el diseñador.

¿Existe un diseñador bueno y de código abierto (o freeware) para AWT? Ya miró alrededor y no encontró nada realmente inteligente.

EDITAR: Hasta ahora, también he creado todas mis GUI a mano. Claro que es un código más limpio, pero a veces es muy difícil encontrar los errores de diseño. Si Visual Studio by MS puede crear código aproximadamente limpio, ¿por qué los otros no?

He oído hablar de algún diseñador visual de Eclipse. ¿Ya está listo para producción?

Hágalo a mano. Los constructores de GUI no son buenos a menos que tenga el concepto de "clase parcial" en C #, e incluso entonces a menudo causan más problemas de los que resuelven. Utilice las herramientas de construcción de la GUI para crear un prototipo, claro, pero no para el código de producción.

Además, otro pequeño truco que he usado a lo largo de los años para obtener buenos resultados al intentar depurar el diseño o "¿qué panel estoy viendo realmente aquí?" Es dar a cada panel "contenedor" un color de fondo realmente llamativo (amarillo, azul, etc. ) Algo lo suficientemente obvio como para verlo incluso si tiene solo un píxel de ancho.

Y mi diseño favorito para diálogos simples es BoxLayout. No es genial, tienes que escribir un montón de repeticiones, pero al menos generalmente funciona de la manera que esperarías en tu cabeza. No pienses demasiado en los diseños hasta que tengas que hacerlo.

Ha habido un complemento temporalmente muerto (pero ahora aparentemente al menos medio vivo) para Eclipse para el diseño visual de GUI y Netbeans todavía tiene soporte para él. Sin embargo, el código resultante fue menos que estelar. Al menos para las personas que tienen que trabajar con esa base de código después, es bastante doloroso.

En cuanto a mí, tiendo a planear en papel de antemano y trato de obtener todas las agrupaciones de paneles con sus diseños en el primer intento. El código GUI de Java es intrínsecamente de solo escritura en mi experiencia.

La última vez que hice tal cosa, primero creé todos los controles que necesitaba y luego los ensamblé en múltiples paneles y diseños, etc. De esa forma al menos fue manejable y funcionó sin demasiado dolor cuando hubo que hacer cambios.

Tiendo a no pensar demasiado sobre el diseño particular en Winforms y WPF debido a, como notó también, un fuerte soporte de diseñador. Además, WPF es muy fácil de manejar incluso en XAML. Las clases parciales de Ans hacen que trabajar con un código parcialmente generado y parcialmente escrito a mano sea muy agradable. Por desgracia, no hay tal cosa en el mundo de Java.

Le sugiero que use netbeans para el desarrollo de GUI en AWT / SWING.

Saludos, Sameer

NetBeans podría ser la mejor opción para construir GUI de manera WYSIWYG, pero muchos desarrolladores de Java escriben su GUI con las manos, ya que no es tan difícil. Cuida el grosor de tus bordes y las brechas entre tus controles y estás bien :)

No soy un gran admirador de los constructores de GUI: por lo general, generan automáticamente un montón de código que luego bloquea a todo su equipo de desarrollo para usar un IDE. Además, este código a menudo no se puede leer (verifique el código generado al usar Matisse en Netbeans).

Mis recomendaciones para el diseño / depuración de GUI serían:

Agregue un método main a cada implementación de panel (o componente de "nivel superior"), permitiendo a otros desarrolladores determinar fácilmente cómo se ve un componente.
Favorezca el uso de Action s sobre ActionListener y registre estas acciones con cada JComponent de ActionMap . Esto les permite ser "extraídos" y agregados a otras partes de la UI (por ejemplo, JToolBar ) mientras que su estado sigue siendo controlado por el JComponent "propietario" (es decir, el acoplamiento flojo).
Use assert para asegurarse de que todas las modificaciones del componente de la interfaz de usuario se estén produciendo en la cadena de distribución de eventos; por ejemplo, assert SwingUtilities.isEventDispatchThread() .
Para depurar el comportamiento de diseño extraño, ¡considere pintar el fondo de un componente en rojo!
Centralice la captura e informe de eventos y excepciones del flujo de trabajo. Por ejemplo, normalmente implemento una clase TaskManager que está registrada en la barra de estado de mi UI. Cualquier procesamiento en segundo plano (realizado dentro de SwingWorker s) pasa un manejador a una Task creada por el TaskManager . La interacción con la tarea (llamando a setDescription(String) , setThrowable(Throwable) , cancel() ) hace que la barra de estado se actualice. También hace que el panel de cristal se muestre para tareas "globales" ... pero todo esto está desacoplado u oculto de los SwingWorkers individuales.
No utilice las clases Observer / Observable , sino que ChangeListener , PropertyChangeListener o su propia implementación de escucha personalizada para la propagación de eventos. Observer pasa un Object como su evento, obligando al código del cliente a verificar el tipo usando instanceof y realizar downcasts, haciendo que el código sea ilegible y haciendo que las relaciones entre clases sean menos claras.
Favorece el uso de JTable sobre JList , incluso en situaciones en las que su tabla solo tiene una columna. JList tiene algunas características desagradables en su API, incluido el hecho de que debe proporcionar un valor de prototipo para que pueda calcular su tamaño correctamente.
Nunca utilice DefaultTableModel ya que normalmente guardará sus datos de "modelo" en dos lugares: en sus objetos comerciales reales y también dentro de la matriz 2D en la que se encuentra DefaultTableModel . En su lugar, simplemente subclase AbstractTableModel : es muy fácil de hacer y significa que su implementación simplemente puede delegar a través de la estructura de datos (por ejemplo, List ) almacenando sus datos.

Si bien el editor Matisse de NetBeans es realmente útil, el código que produce es bastante esotérico y los diseños son frágiles. Así que he estado sacando lo mejor de ambos mundos, usando NetBeans para prototipos WYSIWYG y luego recodificando todo a mano.

Soy uno de esos tipos arcaicos que hacen el diseño de GUI a mano. ¡Tampoco le temo al infame GridBagLayout !

Mantengo las cosas simples al emular el estándar de codificación utilizado por Visual Age, hace años: uso muchos JPanels para organizar partes de la GUI, y cada uno obtiene su propio método makeXXX() para crearlo, makeXXX() y devolverlo a un panel principal o al constructor. De esta forma, cada makeXXX solo tiene que concentrarse en una pequeña parte de las obras completas.

Algunos componentes deben ser accesibles por varios métodos de instancia; Declaro esos como campos de instancia. Las otras cosas, eso es solo decoración o diseño, no necesitan exponerse fuera de los métodos de makeXXX .

Eso es principalmente eso. Funciona para mi.

Yo para mi uso

Pencil

para algunos prototipos primero, luego comience a codificar "a mano" (es decir, sin utilizar ningún editor de GUI).

Yo uso JFormDesigner para la generación de GUI. Genera un bonito código Java, y he aprendido algunas cosas al leer el código generado. Hace que la localización sea muy fácil.

Es una manera muy rápida de armar un diseño involucrado, especialmente barras de menú complejas y diseños de cuadrícula.