web-dev-qa-db-fra.com

L'utilisation de plusieurs cadres de référence: bonne ou mauvaise pratique?

Je développe une application qui affiche des images et lit les sons d'une base de données. J'essaie de décider d'utiliser ou non un JFrame séparé pour ajouter des images à la base de données à partir de l'interface graphique.

Je me demande simplement s'il est judicieux d'utiliser plusieurs fenêtres JFrame?

javaswinguser-interfacejframe
521
Peddler

Je me demande simplement si c'est une bonne pratique d'utiliser plusieurs JFrames?

Mauvaise (mauvaise, mauvaise) pratique.

  • Utilisateur désagréable: l'utilisateur voit plusieurs icônes dans sa barre de tâches lorsqu'il s'attend à n'en voir qu'une. Plus les effets secondaires des problèmes de codage.
  • Un cauchemar à coder et à maintenir:
    • Un dialogue modal offre l’opportunité simple de focaliser l’attention sur le contenu de ce dialogue - choisissez/corrigez/annulez ceci, puis continue. Plusieurs cadres ne le font pas.
    • Une boîte de dialogue (ou une barre d’outils flottante) avec un parent apparaîtra lorsque vous cliquerez sur celui-ci - vous devrez l’implémenter dans des cadres si tel était le comportement souhaité.

Il existe un grand nombre de façons d'afficher de nombreux éléments dans une interface graphique, par exemple:

  • CardLayout (court démo. ). Bon pour:
    1. Afficher un assistant comme un dialogue.
    2. Affichage des sélections de liste, d'arborescence, etc. d'éléments pour un élément associé.
    3. Basculement entre aucun composant et composant visible.
  • JInternalFrame/JDesktopPane généralement utilisé pour un MDI .
  • JTabbedPane pour les groupes de composants.
  • JSplitPane Manière d'afficher deux composants dont l'importance entre l'un ou l'autre (la taille) varie en fonction de ce que l'utilisateur fait.
  • JLayeredPane Beaucoup de composants bien superposés.
  • JToolBar contient généralement des groupes d'actions ou de contrôles. Peut être déplacé autour de l'interface graphique ou entièrement en fonction des besoins de l'utilisateur. Comme mentionné ci-dessus, minimisera/restaurera en fonction du parent.
  • En tant qu'éléments dans un JList (exemple simple ci-dessous).
  • En tant que nœuds dans un JTree .
  • Layouts imbriqués .

Mais si ces stratégies ne fonctionnent pas pour un cas d'utilisation particulier, essayez ce qui suit. Établissez une seule JFrame principale, puis ayez JDialog ou JOptionPane pour le reste des éléments flottants, à l'aide du cadre en tant que parent pour les dialogues.

Beaucoup d'images

Dans le cas où les éléments multiples sont des images, il serait préférable d'utiliser l'un des éléments suivants:

  1. Un seul JLabel (centré dans un panneau de défilement) pour afficher l’image qui intéresse l’utilisateur à ce moment. Comme on le voit dans ImageViewer .
  2. Une seule ligne JList. Comme on le voit dans cette réponse . La partie "une seule ligne" de cela ne fonctionne que si elles ont toutes les mêmes dimensions. Sinon, si vous êtes prêt à redimensionner les images à la volée, elles auront toutes le même rapport de format (par exemple, 4: 3 ou 16: 9).

438
Andrew Thompson

L'approche multiple JFrame est une chose que j'ai implémentée 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 fur et à mesure que je mûris dans mon expérience et mes connaissances de développeur et que je commençais à lire et à absorber les opinions de beaucoup plus expérimentés Java _ devs online, j’ai essayé de changer de l’approche multiple JFrame (dans les projets en cours et les projets futurs) uniquement être rencontré ... obtenir cette ... résistance de mes clients! Lorsque j'ai commencé à mettre en place des dialogues modaux pour contrôler les fenêtres "enfants" et JInternalFrames pour des composants séparés, mes clients ont commencé à se plaindre! J'ai été assez surpris, car je faisais ce que je pensais être la meilleure pratique! Mais, comme on dit, "une femme heureuse est une vie heureuse". Il en va de même pour vos clients. Bien sûr, je suis un contractant et mes utilisateurs finaux ont un accès direct à moi, le développeur, ce qui n’est évidemment pas un scénario courant.

Je vais donc expliquer les avantages de l'approche multiple JFrame, ainsi que des contre-mythes présentés ci-dessous.

  1. Souplesse maximale dans la présentation - En autorisant des JFrames séparés, vous donnez à l'utilisateur final la possibilité de répartir et de contrôler le contenu de son contenu. écran. Le concept se sent "ouvert" et non contraignant. Vous perdez cela lorsque vous vous dirigez vers un gros JFrame et un tas de JInternalFrames.
  2. Fonctionne bien pour les applications très modularisées - Dans mon cas, la plupart de mes applications ont 3 à 5 grands "modules" qui n'ont vraiment rien à faire les uns avec les autres. quoi que ce soit. Par exemple, un module peut être un tableau de bord des ventes et un autre, un tableau de bord de comptabilité. Ils ne se parlent pas ou quoi que ce soit. Cependant, l'exécutif peut vouloir ouvrir les deux et ces images étant séparées dans la barre des tâches, sa vie est plus facile.
  3. Permet aux utilisateurs finaux de faire facilement référence à des éléments extérieurs - Une fois, j’avais cette situation: mon application disposait d’un "visualiseur de données", à partir duquel vous pouviez cliquez sur "Ajouter un nouveau" et cela ouvrirait un écran de saisie de données. Initialement, les deux étaient JFrames. Cependant, je voulais que l'écran de saisie de données soit un JDialog dont le parent était le visualiseur de données. J'ai effectué le changement et j'ai immédiatement reçu un appel d'un utilisateur final qui s'est fortement appuyé sur le fait qu'il pouvait minimiser ou fermer le visualiseur et le conserver. l'éditeur s'ouvrait alors qu'il faisait référence à une autre partie du programme (ou à un site Web, je ne m'en souviens pas). Il n'est pas sur un moniteur multiple, il avait donc besoin que le dialogue de saisie soit le premier et quelque chose d'autre être deuxième, avec la visionneuse de données complètement cachée. Cela était impossible avec un JDialog et aurait certainement été impossible avec un JInternalFrame. Je l'ai changé à contrecœur pour qu'il soit séparé JFrames pour sa santé mentale, mais cela m'a appris une leçon importante.
  4. Mythe: difficile à coder - Ce n'est pas vrai selon mon expérience. Je ne vois pas pourquoi il serait plus facile de créer un JInternalFrame qu'un JFrame. En fait, d'après 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 JFrames dans mes applications, qui fonctionne vraiment bien. Je contrôle le cadre presque complètement depuis le code même du cadre; la création du nouveau cadre, SwingWorkers qui contrôlent l'extraction des données sur les threads d'arrière-plan et le code d'interface graphique sur l'EDT, la restauration/le rapprochement du cadre si l'utilisateur tente de l'ouvrir deux fois, etc. Tout ce dont vous avez besoin open my JFrames est une méthode statique publique open() et la méthode open, associée à un événement windowClosing(), gère le reste (le cadre est-il déjà ouvert? n'est-il pas ouvert, mais se charge-t-il? etc.) J'ai fait de cette approche un modèle pour que ce ne soit pas difficile à implémenter pour chaque image.
  5. Mythe/Non prouvé: ressources importantes - J'aimerais que certains faits se cachent derrière cette déclaration spéculative. Bien que vous puissiez peut-être dire qu'un JFrame a besoin de plus d'espace qu'un JInternalFrame, même si vous ouvrez 100 JFrames, combien de ressources consommeriez-vous réellement? Si votre préoccupation est une fuite de mémoire à cause de ressources: l'appel de dispose() libère toutes les ressources utilisées par le cadre pour le nettoyage de la mémoire (et, encore une fois, un JInternalFrame doit invoquer exactement le même problème).

J'ai beaucoup écrit et je sens que je pourrais écrire plus. Quoi qu'il en soit, j'espère ne pas être voté simplement parce que c'est un avis impopulaire. La question est clairement précieuse et j'espère avoir fourni une réponse valable, même si ce n'est pas l'opinion commune.

Un excellent exemple de plusieurs images/document unique par image ( SDI ) vs une seule image/plusieurs documents par image ( MDI ) est Microsoft Excel. Certains des MDI avantages:

  • il est possible d'avoir quelques fenêtres de forme non rectangulaire - afin qu'elles ne cachent pas le bureau ou une autre fenêtre d'un autre processus (par exemple, un navigateur Web)
  • il est possible d'ouvrir une fenêtre d'un autre processus sur une fenêtre Excel tout en écrivant dans une seconde fenêtre Excel - avec MDI, essayer d'écrire dans l'une des fenêtres internes donnera le focus à la fenêtre Excel entière, 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):

enter image description here

MDI (interface à plusieurs documents, c’est-à-dire que chaque fenêtre peut avoir plusieurs documents):

enter image description here

198
ryvantage

J'aimerais contrer l'argument "pas convivial" avec un exemple avec lequel je viens d'être impliqué.

Dans notre application, nous avons une fenêtre principale dans laquelle les utilisateurs exécutent divers "programmes" sous forme d'onglets distincts. Dans la mesure du possible, nous avons essayé de conserver notre application dans cette fenêtre unique.

L'un des "programmes" qu'ils exécutent présente une liste de rapports générés par le système. L'utilisateur peut cliquer sur une icône sur chaque ligne pour ouvrir une boîte de dialogue d'affichage du rapport. Ce lecteur affiche l'équivalent de la ou des pages A4 de portrait/paysage du rapport, de sorte que les utilisateurs aiment que cette fenêtre soit assez grande, remplissant presque leurs écrans.

Il y a quelques mois, nous avons commencé à recevoir des demandes de nos clients pour que ces fenêtres de visualisation de rapports soient sans modèle, afin qu'elles puissent avoir plusieurs rapports ouverts 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 changé lorsque j'ai découvert comment les utilisateurs résolvaient cette "déficience" de notre système.

Ils ouvraient une visionneuse en utilisant la fonction "Enregistrer sous" pour enregistrer le rapport en tant que PDF dans un répertoire spécifique, en utilisant Acrobat Reader pour ouvrir le fichier PDF. Faites de même avec le prochain rapport. Plusieurs lecteurs Acrobat s'exécutaient avec les différentes sorties de rapport qu'ils souhaitaient consulter.

J'ai donc cédé et j'ai rendu le spectateur sans modèle. Cela signifie que chaque visualiseur a une icône dans la barre des tâches.

Lorsque la dernière version leur a été publiée la semaine dernière, la réponse écrasante d'eux est qu'ils l'aiment. C'est l'une des améliorations les plus récentes apportées au système.

Vous dites donc à vos utilisateurs que ce qu'ils veulent est mauvais, mais que cela ne vous rendra finalement pas service.

QUELQUES NOTES:

  • Il semble que la meilleure pratique consiste à utiliser JDialog pour ces fenêtres sans modèle.
  • Utilisez les constructeurs qui utilisent le nouvel argument ModalityType plutôt que l'argument booléen modal. C'est ce qui donne à ces boîtes de dialogue l'icône de la barre des tâches.
  • Pour les boîtes de dialogue non modales, passez un parent null au constructeur, mais localisez-les par rapport à la fenêtre "parent".
  • La version 6 de Java sous Windows a un bogue , ce qui signifie que votre fenêtre principale peut devenir 'toujours visible' sans que vous le lui disiez. Passez à la version 7 pour résoudre ce problème
51
DuncanKinnear

Créez un cadre 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);
19
Virendra Singh Rathore

Cela fait longtemps que je n’ai pas touché au swing, mais c’est en général une mauvaise pratique de le faire. Certains des principaux inconvénients qui me viennent à l’esprit:

  • C'est plus cher : vous devrez allouer beaucoup plus de ressources pour dessiner un JFrame avec un 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 collés ensemble, il semblerait que votre application soit un ensemble d'applications incohérentes et mal conçues.

  • Il est facile d’utiliser JInternalFrame C’est un peu rétorique, c’est maintenant beaucoup plus facile et que les autres personnes sont plus intelligentes (ou avec plus de temps libre) que nous n’avons déjà réfléchi au modèle Desktop et JInternalFrame. utilise le.

18
Necronet

Mauvaise pratique définitivement. Une des raisons est qu’il n’est pas très convivial de voir que chaque JFrame affiche une nouvelle icône dans la barre des tâches. Contrôler plusieurs JFrames vous fera déchirer vos cheveux.

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. Canvases, JInternalFrame, CardLayout, voire JPanels éventuellement.

Plusieurs objets JFrame = Douleur, problèmes et problèmes.

10
Matt Dawsey

Je pense qu’utiliser plusieurs Jframes n’est pas une bonne idée.

Au lieu de cela, nous pouvons utiliser JPanels plus d'un ou plusieurs JPanel dans le même JFrame.

Nous pouvons aussi basculer entre cette JPanels. Cela nous donne donc la liberté d’afficher plus que dans la JFrame.

Pour chaque JPanel nous pouvons concevoir différentes choses et tout cela JPanel peut être affiché sur l'unique JFrame une à la fois.

Pour basculer entre cette JPanels, utilisez JMenuBar avec JMenuItems pour chaque JPanelou 'JButtonfor eachJPanel`.

Plus d'un JFrame n'est pas une bonne pratique, mais rien ne nous empêche de vouloir plus d'un JFrame.

Mais il vaut mieux changer une JFrame pour nos différents besoins plutôt que d’avoir plusieurs JFrames.

7
Lijo

Si les cadres ont la même taille, pourquoi ne pas le créer et le transmettre ensuite comme référence.

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. Souhaitez-vous créer la méthode, encore et encore?

5
Keith Spriggs

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

4
arunjoseph