El uso de múltiples JFrames: ¿buena o mala práctica?

Hola usuario de nuestra página, encontramos la respuesta a tu pregunta, desplázate y la encontrarás a continuación.

Solución:

Me pregunto si es una buena práctica utilizar varios JFrames.

Mala (mala, mala) práctica.

• No amigable para el usuario: el usuario ve varios íconos en su barra de tareas cuando espera ver solo uno. Además de los efectos secundarios de los problemas de codificación.
• Una pesadilla para codificar y mantener:
  • Un cuadro de diálogo modal ofrece la fácil oportunidad de centrar la atención en el contenido de ese cuadro de diálogo: elija / corrija / cancele esto, luego Continuar. Varios fotogramas no lo hacen.
  • Un cuadro de diálogo (o barra de herramientas flotante) con un padre aparecerá al frente cuando se haga clic en el padre; tendrías que implementar eso en marcos si ese fuera el comportamiento deseado.

---

Hay varias formas de mostrar muchos elementos en una GUI, por ejemplo:

• CardLayout (demostración corta). Bueno para:
  1. Se muestran cuadros de diálogo similares a los de un asistente.
  2. Visualización de selecciones de lista, árbol, etc. para elementos que tienen un componente asociado.
  3. Pasando entre sin componente y componente visible.
• JInternalFrame/JDesktopPane normalmente se utiliza para un MDI.
• JTabbedPane para grupos de componentes.
• JSplitPane Una forma de mostrar dos componentes cuya importancia entre uno u otro (el tamaño) varía según lo que esté haciendo el usuario.
• JLayeredPane muchos componentes bien … en capas.
• JToolBar normalmente contiene grupos de acciones o controles. Se puede arrastrar por la GUI o desactivarla por completo según las necesidades del usuario. Como se mencionó anteriormente, minimizará / restaurará de acuerdo con el padre que lo haga.
• Como elementos en un JList (ejemplo sencillo a continuación).
• Como nodos en un JTree.
• Diseños anidados.
  

Pero si esas estrategias no funcionan para un caso de uso particular, intente lo siguiente. Establecer un solo principal JFrame, entonces ten JDialog o JOptionPane Aparecen instancias para el resto de los elementos flotantes, utilizando el marco como padre para los diálogos.

Muchas imágenes

En este caso, donde los elementos múltiples son imágenes, sería mejor usar cualquiera de los siguientes en su lugar:

1. Un solo JLabel (centrado en un panel de desplazamiento) para mostrar cualquier imagen que le interese al usuario en ese momento. Como se vio en ImageViewer.
   
2. Una sola fila JList. Como se ve en esta respuesta. La parte de ‘una sola fila’ de eso solo funciona si todas tienen las mismas dimensiones. Alternativamente, si está preparado para escalar las imágenes sobre la marcha, y todas tienen la misma relación de aspecto (por ejemplo, 4: 3 o 16: 9).

El múltiple JFrame El enfoque ha sido algo que he implementado desde que comencé a programar aplicaciones Swing. En su mayor parte, lo hice al principio porque no sabía nada mejor. Sin embargo, a medida que maduré en mi experiencia y conocimiento como desarrollador y comencé a leer y absorber las opiniones de tantos desarrolladores de Java más experimentados en línea, hice un intento de alejarse de lo múltiple JFrame enfoque (tanto en proyectos actuales como en proyectos futuros) solo para cumplir con … obtén esto … resistencia de mis clientes! Cuando comencé a implementar diálogos modales para controlar las ventanas “secundarias” y JInternalFrames para componentes separados, mis clientes empezaron a quejarse! ¡Estaba bastante sorprendido, ya que estaba haciendo lo que pensé que era la mejor práctica! Pero, como dicen, “una esposa feliz es una vida feliz”. Lo mismo ocurre con sus clientes. Por supuesto, soy un contratista, por lo que mis usuarios finales tienen acceso directo a mí, el desarrollador, lo que obviamente no es un escenario común.

Entonces, voy a explicar los beneficios de las múltiples JFrame enfoque, así como el mito-reventar algunas de las desventajas que otros han presentado.

1. Máxima flexibilidad en el diseño – Permitiendo separar JFrames, le da a su usuario final la capacidad de expandirse y controlar lo que está en su pantalla. El concepto se siente “abierto” y no restrictivo. Pierdes esto cuando vas hacia uno grande JFrame y un montón de JInternalFrames.
2. Funciona bien para aplicaciones muy modularizadas – En mi caso, la mayoría de mis aplicaciones tienen de 3 a 5 “módulos” grandes que realmente no tienen nada que ver entre sí. Por ejemplo, un módulo podría ser un panel de ventas y otro podría ser un panel de contabilidad. No se hablan ni nada. Sin embargo, es posible que el ejecutivo quiera abrir ambos y que sean marcos separados en la barra de tareas le hace la vida más fácil.
3. Facilita a los usuarios finales la consulta de material externo – Una vez, tuve esta situación: mi aplicación tenía un “visor de datos”, desde el cual se podía hacer clic en “Agregar nuevo” y se abría una pantalla de entrada de datos. Inicialmente, ambos fueron JFrames. Sin embargo, quería que la pantalla de entrada de datos fuera un JDialog cuyo padre fue el visor de datos. Hice el cambio e inmediatamente recibí una llamada de un usuario final que confiaba en gran medida en el hecho de que podía minimizar o cerrar el espectador y mantener el editor open mientras hacía referencia a otra parte del programa (o un sitio web, no lo recuerdo). Él es no en un monitor múltiple, por lo que necesitaba que el diálogo de entrada fuera el primero y algo más en segundo lugar, con el visor de datos completamente oculto. Esto era imposible con un JDialog y ciertamente hubiera sido imposible con un JInternalFrame así como. A regañadientes lo cambié de nuevo a estar separado JFrames por su cordura, pero me enseñó una lección importante.
4. Mito: difícil de codificar – Esto no es true en mi experiencia. No veo por qué sería más fácil crear un JInternalFrame que un JFrame. De hecho, en mi experiencia, JInternalFrames ofrecen mucha menos flexibilidad. He desarrollado una forma sistemática de manejar la apertura y el cierre de JFrames en mis aplicaciones que realmente funciona bien. Yo controlo el marco casi por completo desde el propio código del marco; la creación del nuevo marco, SwingWorkers que controlan la recuperación de datos en subprocesos en segundo plano y el código GUI en EDT, restaurar / traer al frente el marco si el usuario intenta abrirlo dos veces, etc. Todo lo que necesita para abrir mi JFrames es llamar a un público static método open() y el método abierto, combinado con un windowClosing() El evento maneja el resto (¿el marco ya está abierto? ¿No está abierto, pero se está cargando? etc.) Hice de este enfoque una plantilla para que no sea difícil de implementar para cada marco.
5. Mito / No probado: recursos pesados – Me gustaría ver algunos hechos detrás de esta declaración especulativa. Aunque, tal vez, se podría decir JFrame necesita más espacio que un JInternalFrame, incluso si abres 100 JFrames, ¿cuántos recursos más consumirías realmente? Si su preocupación son las pérdidas de memoria debido a los recursos: llamando dispose() libera todos los recursos utilizados por el marco para la recolección de basura (y, de nuevo digo, un JInternalFrame debe invocar exactamente la misma preocupación).

He escrito mucho y siento que podría escribir más. De todos modos, espero no ser rechazado simplemente porque es una opinión impopular. La pregunta es claramente valiosa y espero haber brindado una respuesta valiosa, incluso si no es la opinión común.

Un gran ejemplo de varios fotogramas / documento único por fotograma (SDI) frente a fotograma único / documentos múltiples por fotograma (MDI) es Microsoft Excel. Algunos de los beneficios de MDI:

• es posible tener algunas ventanas en forma no rectangular, para que no oculten el escritorio u otra ventana de otro proceso (por ejemplo, navegador web)
• es posible abrir una ventana de otro proceso en una ventana de Excel mientras se escribe en la segunda ventana de Excel; con MDI, intentar escribir en una de las ventanas internas dará foco a toda la ventana de Excel, por lo tanto, se ocultará la ventana de otro proceso
• es posible tener diferentes documentos en diferentes pantallas, lo cual es especialmente útil cuando las pantallas no tienen la misma resolución

SDI (interfaz de documento único, es decir, cada ventana solo puede tener un documento):

MDI (Interfaz de varios documentos, es decir, cada ventana puede tener varios documentos):

Me gustaría contrarrestar el argumento de que “no es fácil de usar” con un ejemplo en el que acabo de participar.

En nuestra aplicación tenemos una ventana principal donde los usuarios ejecutan varios ‘programas’ como pestañas separadas. En la medida de lo posible, hemos intentado mantener nuestra aplicación en esta única ventana.

Uno de los ‘programas’ que ejecutan presenta una lista de informes que han sido generados por el sistema, y ​​el usuario puede hacer clic en un icono en cada línea para abrir un cuadro de diálogo del visor de informes. Este visor muestra el equivalente a la (s) página (s) A4 vertical / horizontal del informe, por lo que a los usuarios les gusta que esta ventana sea bastante grande, casi llenando sus pantallas.

Hace unos meses, comenzamos a recibir solicitudes de nuestros clientes para que estas ventanas de visor de informes no tuvieran modo, de modo que pudieran tener varios informes abiertos al mismo tiempo.

Durante algún tiempo me resistí a esta solicitud porque no creía que fuera una buena solución. Sin embargo, mi mente cambió cuando descubrí cómo los usuarios estaban solucionando esta “deficiencia” de nuestro sistema.

Abrían un visor, usaban la función “Guardar como” para guardar el informe como PDF en un directorio específico, usaban Acrobat Reader para abrir el archivo PDF y luego hacían lo mismo con el siguiente informe. Tendrían varios Acrobat Reader ejecutándose con las distintas salidas de informes que querían ver.

Así que cedí e hice al espectador sin modelo. Esto significa que cada visor tiene un icono en la barra de tareas.

Cuando se les lanzó la última versión la semana pasada, la respuesta abrumadora de ellos es que les ENCANTA. Ha sido una de nuestras mejoras recientes más populares en el sistema.

Así que sigue adelante y les dices a tus usuarios que lo que quieren es malo, pero que al final no te hará ningún favor.

ALGUNAS NOTAS:

• Parece ser una buena práctica usar JDialog para estas ventanas sin modo
• Usa los constructores que usan el nuevo ModalityType en lugar del booleano modal argumento. Esto es lo que le da a estos cuadros de diálogo el icono de la barra de tareas.
• Para los diálogos no modales, pase un null parent al constructor, pero ubíquelos en relación con su ventana ‘parent’.
• La versión 6 de Java en Windows tiene un error que significa que su ventana principal puede estar “siempre en la parte superior” sin que usted se lo diga. Actualice a la versión 7 para solucionar este problema

Nos puedes animar nuestro ensayo exponiendo un comentario y dejando una valoración te damos la bienvenida.

---

---

Utiliza Nuestro Buscador