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

Estoy desarrollando una aplicación que muestra imágenes y reproduce sonidos desde 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 varias ventanas JFrame.

Mar 04 '12 18:03 Peddler

El enfoque múltiple JFrameha 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 muchos desarrolladores de Java más experimentados en línea, intenté alejarme del enfoque múltiple JFrame(tanto en proyectos actuales como en proyectos futuros). ) sólo para encontrarme con... escuchen esto... ¡ resistencia de mis clientes! Cuando comencé a implementar cuadros de diálogo modales para controlar ventanas "secundarias" y JInternalFrameventanas 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 suele decirse, "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.

Por lo tanto, voy a explicar los beneficios del JFrameenfoque múltiple, así como a derribar algunos de los inconvenientes que otros han presentado.

1. Máxima flexibilidad en el diseño : al permitir JFrameanuncios separados, le brinda al usuario final la capacidad de distribuir y controlar lo que hay en su pantalla. El concepto se siente "abierto" y no restrictivo. Pierdes esto cuando vas hacia uno grande JFramey 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 el 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 facilita la vida.
3. Facilita a los usuarios finales consultar 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 eran JFrames. Sin embargo, quería que la pantalla de entrada de datos fuera una JDialogcuyo padre fuera 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 visor y mantener abierto el editor mientras hacía referencia a otra parte del programa (o un sitio web, no lo hago). no lo recuerdo). No está en un monitor múltiple, por lo que necesitaba que el cuadro de diálogo de entrada estuviera primero y algo más en segundo lugar, con el visor de datos completamente oculto. Esto era imposible con a JDialogy ciertamente habría sido imposible con a JInternalFrametambién. A regañadientes lo cambié para que estuviera separado JFramespor su cordura, pero me enseñó una lección importante.
4. Mito: Difícil de codificar . Según mi experiencia, esto no es cierto. No veo por qué sería más fácil crear un archivo JInternalFrameque un archivo JFrame. De hecho, según mi experiencia, JInternalFramesofrecen mucha menos flexibilidad. He desarrollado una forma sistemática de manejar la apertura y el cierre de JFramemensajes en mis aplicaciones que realmente funciona bien. 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 llame a un método estático público open()y el método abierto, combinado con un windowClosing()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: Muchos recursos . Me gustaría ver algunos hechos detrás de esta afirmación especulativa. Aunque, quizás, se podría decir que a JFramenecesita más espacio que a JInternalFrame, incluso si abres 100 JFrames, ¿cuántos recursos más estarías consumiendo realmente? Si su preocupación son las pérdidas de memoria debido a los recursos: la llamada dispose()libera todos los recursos utilizados por el marco para la recolección de basura (y, repito, JInternalFramedebería invocar exactamente la misma preocupación).

He escrito mucho y siento que podría escribir más. De todos modos, espero que no me rechacen 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 múltiples fotogramas/documento único por fotograma ( SDI ) frente a fotograma único/múltiples documentos por fotograma ( MDI ) es Microsoft Excel. Algunos de los beneficios del 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 una segunda ventana de Excel. Con MDI, intentar escribir en una de las ventanas internas dará foco a toda la ventana de Excel, por lo que 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 sólo puede tener un único documento):

MDI (Interfaz de múltiples documentos, es decir, cada ventana puede tener múltiples documentos):

Jul 31 '2013 03:07 ryvantage

Me gustaría contrarrestar el argumento "no 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 ventana única.

Uno de los 'programas' que ejecutan presenta una lista de informes 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 las páginas A4 vertical/apaisada 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 modo, de modo que pudieran tener varios informes abiertos al mismo tiempo.

Durante algún tiempo me resistí a esta petición porque no creía que fuera una buena solución. Sin embargo, cambié de opinión cuando descubrí cómo los usuarios solucionaban 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 lectores de Acrobat ejecutándose con los distintos resultados de informes que querían ver.

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

Cuando les lanzaron la última versión la semana pasada, la respuesta abrumadora de ellos fue que les ENCANTA. Ha sido una de nuestras mejoras recientes más populares al sistema.

Así que sigue adelante y les dices 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 utilizar JDialog para estas ventanas no modelo.
• Utilice los constructores que utilizan el argumento nuevo ModalityTypeen lugar del booleano modal. Esto es lo que le da a estos cuadros de diálogo el icono de la barra de tareas.
• Para diálogos no modal, pase un padre nulo al constructor, pero ubíquelos en relación con su ventana "principal".
• La versión 6 de Java en Windows tiene un error que significa que su ventana principal puede estar "siempre visible" sin que usted se lo diga. Actualice a la versión 7 para solucionar este problema

Aug 30 '2013 03:08 DuncanKinnear