L’utilisation de plusieurs JFrames: bonne ou mauvaise pratique?

Je développe une application qui affiche des images et lit les sons d’une firebase database. J’essaie de décider d’utiliser ou non un JFrame distinct pour append des images à la firebase database à partir de l’interface graphique.

Je me demande si l’utilisation de plusieurs fenêtres JFrame est une bonne pratique?

Je me demande si l’utilisation de plusieurs JFrames est une bonne pratique?

Mauvaise (mauvaise, mauvaise) pratique.

  • Utilisateur non sympathique: l’utilisateur voit plusieurs icons dans sa barre des tâches lorsqu’il s’attend à en voir une seule. Plus les effets secondaires des problèmes de codage ..
  • Un cauchemar à coder et à entretenir:
    • Une boîte de dialog modale offre la possibilité de concentrer l’attention sur le contenu de cette boîte de dialog – choisissez / corrigez / annulez, puis continuez. Plusieurs frameworks ne le font pas.
    • Une boîte de dialog (ou une barre d’outils flottante) avec un parent apparaîtra lorsque vous cliquerez sur le parent – vous devrez l’implémenter dans les frameworks si c’était le comportement souhaité.

Il existe de nombreuses manières d’afficher de nombreux éléments dans une interface graphique, par exemple:

  • CardLayout (courte démonstration ). Bon pour:
    1. Affichage de dialogs similaires à ceux d’un assistant.
    2. Affichage des sélections de liste, d’arborescence, etc. pour les éléments ayant un composant associé.
    3. Flipping entre aucun composant et composant visible.
  • JInternalFrame / JDesktopPane généralement utilisé pour un MDI .
  • JTabbedPane pour les groupes de composants.
  • JSplitPane Une manière d’afficher deux composants dont l’importance entre l’un ou l’autre (la taille) varie selon ce que fait l’utilisateur.
  • JLayeredPane beaucoup de composants bien stratifiés.
  • JToolBar contient généralement des groupes d’actions ou de contrôles. Peut être déplacé sur l’interface graphique, ou entièrement selon les besoins de l’utilisateur. Comme mentionné ci-dessus, minimisera / restaurera selon le parent qui le fait.
  • Comme éléments dans une JList (exemple simple ci-dessous).
  • En tant que nœuds dans un JTree .
  • Dispositions nestedes

Mais si ces stratégies ne fonctionnent pas pour un cas d’utilisation particulier, essayez ce qui suit. Établissez un seul JFrame principal, puis les instances JDialog ou JOptionPane apparaissent pour le rest des éléments flottants, en utilisant le cadre comme parent pour les boîtes de dialog.

Beaucoup d’images

Dans ce cas où les éléments multiples sont des images, il serait préférable d’utiliser l’une des méthodes suivantes:

  1. Un seul JLabel (centré dans un panneau de défilement) pour afficher l’image qui intéresse l’utilisateur à ce moment. Comme vu dans ImageViewer .
  2. Une seule ligne JList . Comme vu dans cette réponse . La partie «simple rangée» ne fonctionne que si elles ont toutes les mêmes dimensions. Alternativement, si vous êtes prêt à mettre à l’échelle les images à la volée et qu’elles ont toutes le même rapport d’aspect (par exemple 4: 3 ou 16: 9).

L’approche multiple de JFrame a été quelque chose que j’ai mis en place depuis que j’ai commencé à programmer des applications Swing. Pour la plupart, je l’ai fait au début parce que je ne connaissais pas mieux. Cependant , au fil de mon expérience et de mes connaissances en tant que développeur, j’ai commencé à lire et à assimiler les opinions de tant de développeurs Java expérimentés en ligne. projets) seulement à rencontrer … obtenir ceci … résistance de mes clients! Alors que je commençais à implémenter des boîtes de dialog modales pour contrôler les fenêtres “enfants” et JInternalFrame pour les composants séparés, mes clients ont commencé à se plaindre! J’ai été très surpris car je faisais ce que je pensais être la meilleure pratique! Mais, comme ils le disent, “une femme heureuse est une vie heureuse”. Même chose pour vos clients. Bien sûr, je suis un entrepreneur pour que mes utilisateurs finaux aient un access direct à moi, le développeur, ce qui n’est évidemment pas un scénario courant.

Je vais donc vous expliquer les avantages de l’approche multiple de JFrame , ainsi que certains des inconvénients que certains ont présentés.

  1. Flexibilité ultime dans la mise en page – En autorisant des JFrame séparés, vous donnez à votre utilisateur la possibilité d’étaler et de contrôler ce qui se trouve sur son écran. Le concept semble “ouvert” et non contraignant. Vous perdez cela quand vous allez vers un grand JFrame et un groupe de JInternalFrame .
  2. Fonctionne bien pour les applications très modularisées – Dans mon cas, la plupart de mes applications comportent 3 à 5 gros “modules” qui n’ont rien à voir avec les autres. Par exemple, un module peut être un tableau de bord des ventes et un autre peut être un tableau de bord de comptabilité. Ils ne se parlent pas ou quoi que ce soit. Cependant, le dirigeant peut vouloir ouvrir les deux et les séparer de la barre des tâches lui facilite la vie.
  3. Facilite la référence des utilisateurs externes aux utilisateurs finaux – Une fois, j’ai eu cette situation: Mon application avait un “visualiseur de données”, à partir duquel vous pouviez cliquer sur “Ajouter un nouveau” et cela ouvrirait un écran de saisie de données. Au départ, les deux étaient des JFrame . Cependant, je voulais que l’écran de saisie des données soit un JDialog dont le parent était le visualiseur de données. J’ai apporté le changement et j’ai immédiatement reçu un appel d’un utilisateur final qui comptait fortement sur le fait qu’il pouvait minimiser ou fermer le visualiseur et garder l’ éditeur ouvert lorsqu’il faisait référence à une autre partie du programme (ou à un site Web). souviens pas). Il n’est pas sur un multi-moniteur, il a donc besoin que le dialog de saisie soit le premier et qu’il y ait une autre solution, avec le visualiseur de données complètement masqué. C’était impossible avec un JDialog et cela aurait certainement été impossible avec un JInternalFrame également. Je suis JFrames à JFrames un JFrames distinct pour sa santé mentale, mais cela m’a appris une leçon importante.
  4. Mythe: Difficile à coder – Ce n’est pas vrai dans mon expérience. Je ne vois pas pourquoi il serait plus facile de créer un JInternalFrame qu’un JFrame . En fait, selon mon expérience, JInternalFrames offre beaucoup moins de flexibilité. J’ai développé un moyen systématique de gérer l’ouverture et la fermeture de JFrame dans mes applications, ce qui fonctionne vraiment bien. Je contrôle le cadre presque complètement depuis le code du cadre lui-même; la création de la nouvelle trame, SwingWorker qui contrôle la récupération des données sur les threads d’arrière-plan et le code GUI sur EDT, la restauration / mise en avant de l’image si l’utilisateur tente de l’ouvrir deux fois, etc. s s’appelle une méthode statique publique open() et la méthode open, associée à un windowClosing() gère le rest (le frame est-il déjà ouvert? n’est-il pas ouvert, mais le chargement? etc.) ce n’est pas difficile à mettre en œuvre pour chaque image.
  5. Mythe / Unproven: Ressource lourde – J’aimerais voir quelques faits derrière cette déclaration spéculative. Bien que vous puissiez peut-être dire qu’un JFrame besoin de plus d’espace qu’un JInternalFrame , même si vous ouvrez 100 JFrame , combien de ressources supplémentaires consumriez-vous réellement? Si vous craignez des memory leaks à cause des ressources: l’appel de dispose() libère toutes les ressources utilisées par le cadre pour la récupération de la mémoire (et, encore une fois, un JInternalFrame doit invoquer exactement le même problème).

J’ai beaucoup écrit et j’ai l’impression que je pourrais écrire plus. Quoi qu’il en soit, j’espère que je n’aurai pas le droit de vote simplement parce que c’est une opinion impopulaire. La question est clairement une question précieuse et j’espère avoir fourni une réponse utile, même si ce n’est pas l’opinion commune.

Microsoft Excel est un bon exemple de plusieurs images / document unique par image ( SDI ) contre une seule image / plusieurs documents par image ( MDI ). Quelques avantages du MDI:

  • il est possible d’avoir quelques fenêtres de forme non rectangular – elles ne masquent donc pas le bureau ou toute autre fenêtre d’un autre processus (par exemple, un navigateur Web)
  • il est possible d’ouvrir une fenêtre à partir d’un autre processus sur une fenêtre Excel tout en écrivant dans une seconde fenêtre Excel – avec MDI, essayer d’écrire dans une fenêtre interne donnera le focus à toute la fenêtre Excel, masquant ainsi la fenêtre d’un autre processus
  • il est possible d’avoir différents documents sur différents écrans, ce qui est particulièrement utile lorsque les écrans n’ont pas la même résolution

SDI (interface à document unique, c’est-à-dire que chaque fenêtre ne peut contenir qu’un seul document):

entrer la description de l'image ici

MDI (Multiple-Document Interface, c.-à-d. Chaque fenêtre peut avoir plusieurs documents):

entrer la description de l'image ici

Je voudrais contrer l’argument «pas facile à utiliser» avec un exemple auquel je viens de participer.

Dans notre application, nous avons une fenêtre principale dans laquelle les utilisateurs exécutent différents «programmes» sous forme d’tabs distincts. Dans la mesure du possible, nous avons essayé de conserver notre application dans ce guichet unique.

L’un des “programmes” qu’ils exécutent présente une liste de rapports générés par le système, et l’utilisateur peut cliquer sur une icône sur chaque ligne pour ouvrir une boîte de dialog de visualisation de rapport. Ce visualiseur affiche l’équivalent de la ou des pages A4 portrait / paysage du rapport, de sorte que les utilisateurs qui aiment cette fenêtre soient assez gros, remplissant presque leurs écrans.

Il y a quelques mois, nous avons reçu des demandes de nos clients pour rendre ces fenêtres de modèles de visionneuse de rapports désuètes, afin qu’elles puissent ouvrir plusieurs rapports en même temps.

Pendant un certain temps, j’ai résisté à cette demande car je ne pensais pas que c’était une bonne solution. Cependant, mon esprit a été changé quand j’ai découvert comment les utilisateurs contournaient cette «déficience» de notre système.

Ils ouvraient un visualiseur en utilisant la fonction «Enregistrer sous» pour enregistrer le rapport au format PDF dans un répertoire spécifique, en utilisant Acrobat Reader pour ouvrir le fichier PDF, puis ils feraient de même avec le prochain rapport. Ils disposeraient de plusieurs lecteurs Acrobat exécutant les différents rapports qu’ils souhaitaient consulter.

J’ai donc cédé et rendu le spectateur modèle. Cela signifie que chaque utilisateur dispose d’une icône représentant une barre des tâches.

Lorsque la dernière version leur a été publiée la semaine dernière, la réponse écrasante est qu’ils l’AIMENT. C’est l’une des améliorations les plus récentes du système.

Donc, vous allez de l’avant et dites à vos utilisateurs que ce qu’ils veulent est mauvais, mais en fin de compte, cela ne vous rendra pas service.

QUELQUES NOTES:

  • Il semble préférable d’utiliser JDialog pour ces fenêtres modélisées.
  • Utilisez les constructeurs qui utilisent le nouveau ModalityType plutôt que l’argument modal booléen. C’est ce qui donne à ces dialogs l’icône de la barre des tâches.
  • Pour les boîtes de dialog non modales, passez un parent nul au constructeur, mais localisez-les par rapport à leur fenêtre «parent».
  • La version 6 de Java sous Windows a un bogue qui signifie que votre fenêtre principale peut devenir «toujours au premier plan» sans que vous le disiez. Passez à la version 7 pour résoudre ce problème

Faites un jInternalFrame dans le cadre principal et rendez-le invisible. Ensuite, vous pouvez l’utiliser pour d’autres événements.

 jInternalFrame.setSize(300,150); jInternalFrame.setVisible(true); 

Cela fait un moment depuis la dernière fois que je touche le swing, mais en général, c’est une mauvaise pratique pour le faire. Certains des principaux inconvénients qui viennent à l’esprit:

  • C’est plus cher: vous devrez allouer plus de ressources pour dessiner un JFrame que l’autre type de conteneur de fenêtre, tel que Dialog ou JInternalFrame.

  • Pas convivial: il n’est pas facile de naviguer dans un groupe de JFrame coincés, il semblerait que votre application soit un ensemble d’applications incohérentes et mal conçues.

  • Il est facile à utiliser JInternalFrame C’est un peu récursif, maintenant c’est beaucoup plus facile et d’autres personnes plus intelligentes (ou avec plus de temps libre) que nous avons déjà pensé au bureau et au modèle JInternalFrame, alors je vous recommande de l’utiliser.

Mauvaise pratique définitivement. Une des raisons est qu’elle n’est pas très conviviale pour le fait que chaque JFrame affiche une nouvelle icône de barre des tâches. En contrôlant plusieurs JFrame , vous vous JFrame .

Personnellement, j’utiliserais ONE JFrame pour votre type d’application. Les méthodes d’affichage de plusieurs choses sont à vous, il y en a beaucoup. Canvas es, JInternalFrame , CardLayout , même JPanel s éventuellement.

Objets JFrame multiples = Douleur, problèmes et problèmes.

Je pense que l’utilisation de plusieurs Jframe n’est pas une bonne idée.

Au lieu de cela, nous pouvons utiliser plusieurs JPanel dans le même JFrame .

Aussi, nous pouvons basculer entre ce JPanel s. Donc, cela nous donne la liberté d’afficher plus que ce qu’il ya dans le JFrame .

Pour chaque JPanel nous pouvons concevoir différentes choses et tout ce JPanel peut être affiché sur le même JFrame un par un.

Pour passer de ce JPanel utilisez JMenuBar avec JMenuItems pour chaque JPanel ou «JButton for each JPanel».

Plus d’un JFrame n’est pas une bonne pratique, mais il n’y a rien de mal à vouloir plus d’un JFrame .

Mais il est préférable de changer un JFrame pour nos différents besoins plutôt que d’avoir plusieurs JFrame .

Si les frameworks doivent avoir la même taille, pourquoi ne pas créer le cadre et passer le cadre à la place.

Lorsque vous avez passé le cadre, vous pouvez alors décider comment le remplir. Ce serait comme avoir une méthode pour calculer la moyenne d’un ensemble de chiffres. Voulez-vous créer la méthode encore et encore?

Ce n’est pas une bonne pratique mais même si vous souhaitez l’utiliser, vous pouvez utiliser le modèle singleton comme bon. J’ai utilisé les singleton patterns dans la plupart de mes projets.