El Uso de Múltiples JFrames: ¿Buenas o Malas Prácticas? [cerrado]
Estoy desarrollando una aplicación que muestra imágenes y reproduce sonidos de una base de datos. Estoy tratando de decidir si usar o no un JFrame separado para agregar imágenes a la base de datos desde la GUI.
Me pregunto si es una buena práctica utilizar múltiples ventanas JFrame?
9 answers
Me pregunto si es una buena práctica usar múltiples JFrames.
Mala (mala, mala) práctica.
- Usuario hostil: El usuario ve varios iconos 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 diálogo modal ofrece la fácil oportunidad de centrar la atención en el contenido de ese diálogo-elija / fix / cancel this, luego proceda. Múltiples marcos no lo hacen.
- Un diálogo (o barra de herramientas flotante) con un padre aparecerá al frente cuando se haga clic en el padre; tendría que implementarlo en marcos si ese fuera el comportamiento deseado.
Hay muchas maneras de mostrar muchos elementos en una interfaz gráfica de usuario, por ejemplo: {[17]]}
-
CardLayout
(breve demo.). Bueno para:- Mostrando diálogos como el asistente.
- Mostrando la lista, árbol, etc. selecciones para elementos que tienen un componente asociado.
- Cambiando entre ningún componente y componente visible.
-
JInternalFrame
/JDesktopPane
normalmente se usa para un MDI . -
JTabbedPane
para grupos de componentes. -
JSplitPane
Una forma de mostrar dos componentes de los cuales la importancia entre uno u otro (el tamaño) varía de acuerdo a lo que el usuario está haciendo. -
JLayeredPane
lejos muchos bien ..componentes en capas. -
JToolBar
normalmente contiene grupos de acciones o controles. Se puede arrastrar alrededor de la interfaz gráfica de usuario, o fuera de ella completamente de acuerdo a las necesidades del usuario. Como se mencionó anteriormente, minimizará / restaurará de acuerdo con el padre que lo hace. - Como elementos de una
JList
(ejemplo simple a continuación). - Como nodos en una
JTree
. -
diseños Anidados.
Pero si esas estrategias no funcionan para un caso de uso, intente lo siguiente. Establecer un único main JFrame
, luego tener JDialog
o JOptionPane
las instancias aparecen para el resto de los elementos flotantes, usando el marco como el padre para los diálogos.
Muchas imágenes
En este caso donde los múltiples elementos son imágenes, sería mejor usar cualquiera de los siguientes en su lugar:
- Un único
JLabel
(centrado en un panel de desplazamiento) para mostrar cualquier imagen que le interese al usuario momento. Como se ve enImageViewer
.
- Una sola fila
JList
. Como se ve en esta respuesta. La parte de "fila única" 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).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 11:55:07
El enfoque múltiple JFrame
ha sido algo que he implementado desde que empecé a programar aplicaciones Swing. En su mayor parte, lo hice al principio porque no sabía nada mejor. Sin embargo , a medida que maduraba en mi experiencia y conocimiento como desarrollador y a medida que comenzaba a leer y absorber las opiniones de muchos desarrolladores Java más experimentados en línea, hice un intento de alejarse del enfoque múltiple JFrame
(tanto en proyectos actuales como en proyectos futuros) con... escucha esto... resistencia de mis clientes! Cuando comencé a implementar diálogos modales para controlar ventanas "secundarias" y JInternalFrame
s para componentes separados, mis clientes comenzaron a quejarse! Me sorprendió bastante, 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, que obviamente no es un escenario común.
So, Voy a explicar los beneficios de la múltiple JFrame
enfoque, así como mito-busto algunos de los contras que otros han presentado.
-
Máxima flexibilidad en el diseño - Al permitir
JFrame
s separados, le das a tu usuario final la capacidad de extenderse y controlar lo que está en su pantalla. El concepto se siente "abierto" y no restrictivo. Pierdes esto cuando vas hacia un granJFrame
y un montón deJInternalFrame
s. - Funciona bien para muy modularizados aplicaciones - En mi caso, la mayoría de mis aplicaciones tienen 3 - 5 grandes "módulos" que realmente no tienen nada que ver entre sí en absoluto. 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, el ejecutivo podría querer abrir ambos y ser marcos separados en la barra de tareas le hace la vida más fácil.
-
Hace que sea fácil para los usuarios finales hacer referencia a material externo - Una vez, tuve esto situación: Mi aplicación tenía un "visor de datos", desde el que se podía hacer clic en" Agregar nuevo " y se abriría una pantalla de entrada de datos. Inicialmente, ambos eran
JFrame
s. Sin embargo, quería que la pantalla de entrada de datos fuera unJDialog
cuyo padre era el visor de datos. Hice el cambio, e inmediatamente recibí una llamada de un usuario final que dependía en gran medida del hecho de que podía minimizar o cerrar el visor y mantener abierto el editor mientras hacía referencia a otra parte del programa (o un sitio web, no recordar). Él es no en un multi-monitor, por lo que necesitaba que el diálogo de entrada fuera el primero y algo más para ser el segundo, con el visor de datos completamente oculto. Esto era imposible con unJDialog
y ciertamente habría sido imposible con unJInternalFrame
también. A regañadientes lo cambié de nuevo a estar separadoJFrames
por su cordura, pero me enseñó una lección importante. -
Mito: Difícil de codificar - Esto no es cierto en mi experiencia. No veo por qué sería cualquier es más fácil crear un
JInternalFrame
que unJFrame
. De hecho, en mi experiencia,JInternalFrames
ofrecen mucha menos flexibilidad. He desarrollado una forma sistemática de manejar la apertura y el cierre deJFrame
s en mis aplicaciones que realmente funciona bien. Controlo el marco casi completamente desde el código del marco en sí; la creación del nuevo marco,SwingWorker
s que controlan la recuperación de datos en subprocesos de fondo y el código GUI en EDT, restaurando/trayendo al frente el marco si el usuario intenta abrirlo dos veces, etc. Todo tú necesidad de abrir miJFrame
s es llamar a un método estático públicoopen()
y el método abierto, combinado con un eventowindowClosing()
maneja el resto (es el marco ya abierto? ¿no está abierto, sino cargando? sucesivamente.) Hice de este enfoque una plantilla para que no sea difícil de implementar para cada marco. -
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 que un
JFrame
necesita más espacio que unJInternalFrame
, incluso si se abren 100JFrame
s, ¿cuántos recursos más consumirías realmente? Si su preocupación son las fugas de memoria debido a los recursos: llamandodispose()
libera todos los recursos utilizados por el marco para la recolección de basura (y, de nuevo digo, unJInternalFrame
debe invocar exactamente la misma preocupación).
He escrito mucho y siento que podría escribir más. De todos modos, espero que no me voten simplemente porque es una opinión impopular. La pregunta es claramente valiosa y espero haber proporcionado una respuesta valiosa, incluso si no es la opinión común.
Un gran ejemplo de fotogramas múltiples/documento único por fotograma ( SDI) vs 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 desde otro proceso sobre una ventana de Excel mientras se escribe en segunda ventana de Excel-con MDI, tratar de escribir en una de las ventanas internas dará enfoque a toda la ventana de Excel, por lo tanto, ocultar la ventana de otro proceso
- es posible tener diferentes documentos en diferentes pantallas, lo que es especialmente útil cuando las pantallas no tienen la misma resolución
SDI (Interfaz de un solo documento, es decir, cada ventana solo puede tener un solo documento):
MDI (Interfaz de múltiples documentos, es decir, cada ventana puede tener varios documentos):
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-03-17 11:15:21
Me gustaría contrarrestar el argumento "no fácil de usar" con un ejemplo con el que acabo de estar involucrado.
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 tratado de mantener nuestra aplicación en esta ventanilla única.
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 diálogo de visor de informes. Este visor muestra el equivalente de la página vertical/horizontal A4 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 del visor de informes no tuvieran forma, de modo que pudieran tener varios informes abiertos al mismo tiempo.
Durante algún tiempo me resistí a esta petición, ya que no pensé que esta fuera una buena solución. Sin embargo, mi mente cambió cuando descubrí cómo los usuarios estaban sorteando esta 'deficiencia' de nuestro sistema.
Estaban abriendo un visor, usando la función 'Guardar como' para guardar el informe como un PDF en un directorio específico, usando Acrobat Reader para abrir el archivo PDF, y luego harían lo mismo con el siguiente informe. Tendrían varios lectores de Acrobat ejecutándose con las diversas salidas de informes que querían ver.
Así que cedí y dejé al espectador sin modales. Esto significa que cada espectador tiene una barra de tareas icono.
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 dile a tus usuarios que lo que quieren es malo, pero al final no te hará ningún favor.
ALGUNAS NOTAS:
- Parece ser una buena práctica usar JDialog para estas ventanas modeless
- Use los constructores que usan el nuevo
ModalityType
en lugar que el argumento booleanomodal
. Esto es lo que da a estos diálogos el icono de la barra de tareas. - Para los diálogos sin modelo, pase un padre nulo al constructor, pero ubíquelo en relación con su ventana 'padre'.
- La versión 6 de Java en Windows tiene un error lo que significa que su ventana principal puede convertirse en 'siempre en la parte superior' sin que usted se lo diga. Actualizar a la versión 7 para arreglar esto
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-08-30 05:14:44
Hacer un JInternalFrame en el marco principal y hacerlo invisible. Luego puede usarlo para otros eventos.
jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-10-17 05:33:04
Ha pasado un tiempo desde la última vez que toco swing, pero en general es una mala práctica hacer esto. Algunas de las principales desventajas que vienen a la mente:
Es más caro: tendrá que asignar muchos más recursos para dibujar un JFrame que otro tipo de contenedor de ventana, como Dialog o JInternalFrame.
No es fácil de usar: No es fácil navegar en un montón de JFrame pegados juntos, se verá como su aplicación es un conjunto de aplicaciones inconsistentes y mal diseño.
Es fácil de usar JInternalFrame Esto es un poco retórico, ahora es mucho más fácil y otras personas más inteligentes ( o con más tiempo libre) de lo que ya hemos pensado a través del patrón de escritorio y JInternalFrame, por lo que recomendaría usarlo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-03-05 00:55:13
Mala práctica definitivamente. Una razón es que no es muy 'fácil de usar' por el hecho de que cada JFrame
muestra un nuevo icono de barra de tareas. Controlar múltiples JFrame
s te hará arrancarte el cabello.
Personalmente, usaría UNO JFrame
para su tipo de aplicación. Métodos de mostrar múltiples cosas depende de usted, hay muchos. Canvas
es, JInternalFrame
, CardLayout
, incluso JPanel
es posible.
Múltiples objetos JFrame = Dolor, problemas y problemas.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-02-08 10:32:55
Creo que usar múltiples Jframe
s no es una buena idea.
En su lugar podemos usar JPanel
s más de uno o más JPanel
en el mismo JFrame
.
También podemos cambiar entre este JPanel
s. Por lo que nos da libertad para mostrar más que en la cosa en el JFrame
.
Para cada JPanel
podemos diseñar diferentes cosas y todo esto JPanel
se puede mostrar en el único JFrame
uno a la vez.
Para cambiar entre este JPanel
v JMenuBar
con JMenuItems
para cada JPanel
o "JButton for each
JPanel".
Más de uno JFrame
no es una buena práctica, pero no hay nada malo si queremos más de uno JFrame
.
Pero es mejor cambiar uno JFrame
para nuestras diferentes necesidades en lugar de tener múltiples JFrame
s.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-01-18 07:49:22
Si los marcos van a ser del mismo tamaño, ¿por qué no crear el marco y pasar el marco entonces como una referencia a él en su lugar.
Cuando haya pasado el marco, puede decidir cómo rellenarlo. Sería como tener un método para calcular el promedio de un conjunto de figuras. ¿Crearías el método una y otra vez?
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-09-03 22:25:46
No es una buena práctica, pero a pesar de que desea utilizarlo puede utilizar el patrón singleton como su buena. He utilizado los patrones de singleton en la mayor parte de mi proyecto es bueno.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-12-14 13:20:30