L'utilisation de plusieurs JFrames: bonne ou mauvaise pratique? [fermé]

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

Je me demande simplement si c'est une bonne pratique d'utiliser plusieurs fenêtres JFrame?

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

Mauvaise (mauvaise, mauvaise) pratique.

• Peu convivial: l'utilisateur voit plusieurs icônes dans sa barre des tâches lorsqu'il s'attend à n'en voir qu'une. Plus les effets secondaires des problèmes de codage ..
• Un cauchemar pour coder et maintenir:
  • Une boîte de dialogue modale offre la possibilité facile de concentrer l'attention sur le contenu de cette boîte de dialogue - choisissez / corrigez / annulez cela, puis continuez. 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 le parent - vous devrez l'implémenter dans des cadres si tel était le comportement souhaité.

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

• CardLayout(courte démo. ). Bon pour:
  1. Affichage des boîtes de dialogue de type assistant.
  2. Affichage des sélections de liste, d'arborescence, etc. pour les éléments auxquels un composant est 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 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 .. superposés.
• JToolBarcontient généralement des groupes d'actions ou de contrôles. Peut être glissé autour de l'interface graphique ou entièrement en fonction des besoins des utilisateurs. Comme mentionné ci-dessus, minimisera / restaurera selon le parent qui le fait.
• Comme éléments dans un JList(exemple simple ci-dessous).
• En tant que nœuds dans a JTree.
• Dispositions imbriquées .
  

Mais si ces stratégies ne fonctionnent pas pour un cas d'utilisation particulier, essayez ce qui suit. Établissez un principal JFrame, puis faites apparaître JDialogou des JOptionPaneinstances pour le reste des éléments flottants, en utilisant le cadre comme parent pour les boîtes de dialogue.

Beaucoup d'images

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

1. Un seul JLabel(centré dans un volet de défilement) pour afficher l'image qui intéresse l'utilisateur à ce moment. Comme vu dans ImageViewer.
   
2. Une seule rangée JList. Comme on le voit dans cette réponse . La partie "une seule ligne" de cela ne fonctionne que si elles sont toutes de 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' JFrameapproche multiple est quelque chose que j'ai mis en œuvre depuis que j'ai commencé à programmer des applications Swing. Pour la plupart, je l'ai fait au début parce que je ne savais pas mieux. Cependant , à mesure que je grandissais dans mon expérience et mes connaissances en tant que développeur et que je commençais à lire et à absorber les opinions de nombreux développeurs Java plus expérimentés en ligne, j'ai essayé de m'éloigner de l' JFrameapproche multiple (à la fois dans les projets actuels et futurs). ) seulement à rencontrer ... obtenez ceci ... résistance de mes clients! Alors que je commençais à implémenter des boîtes de dialogue modales pour contrôler les fenêtres "enfants" et JInternalFrameles composants séparés, mes clients ont commencé à se plaindre!J'étais assez surpris, car je faisais ce que je pensais être les meilleures pratiques! 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 entrepreneur, donc mes utilisateurs finaux ont un accès direct à moi, le développeur, ce qui n'est évidemment pas un scénario courant.

Donc, je vais expliquer les avantages de l' JFrameapproche multiple , ainsi que briser les mythes certains des inconvénients que d'autres ont présentés.

1. Flexibilité ultime dans la mise en page - En autorisant des JFrames séparés , vous donnez à votre utilisateur final la possibilité d'étaler et de contrôler ce qui est sur son écran. Le concept semble "ouvert" et non contraignant. Vous perdez cela lorsque vous vous dirigez vers un gros JFrameet 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 gros "modules" qui n'ont vraiment rien à voir les uns avec les autres. Par exemple, un module peut être un tableau de bord des ventes et un autre peut être un tableau de bord comptable. Ils ne se parlent pas ou quoi que ce soit. Cependant, l'exécutif peut vouloir ouvrir les deux et le fait qu'ils soient séparés par des cadres sur la barre des tâches lui facilite la vie.
3. Permet aux utilisateurs finaux de faire référence à du matériel extérieur - 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. Initialement, les deux étaient JFramele par. Cependant, je voulais que l'écran de saisie des données soit celui JDialogdont le parent était le visualiseur de données. J'ai fait le changement et j'ai immédiatement reçu un appel d'un utilisateur final qui comptait beaucoup sur le fait qu'il pouvait réduire ou fermer le visualiseur et garder l' éditeur ouvert pendant qu'il faisait référence à une autre partie du programme (ou à un site Web, je ne ne me souviens pas). Il n'est pas sur un multi-moniteur, donc il avait besoin que la boîte de dialogue d'entrée soit la première et autre choseêtre deuxième, avec la visionneuse de données complètement cachée. C'était impossible avec un JDialoget aurait certainement été impossible avec un JInternalFrameaussi. Je l'ai changé à contrecœur pour être séparé JFramespour sa raison, 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 JInternalFramequ'un JFrame. En fait, selon mon expérience, JInternalFramesoffre 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 à partir du code du cadre lui-même; la création du nouveau cadre, SwingWorkerqui 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 du cadre si l'utilisateur essaie de l'ouvrir deux fois, etc. Tout ce dont vous avez besoin pour ouvrir mon JFrames est appeler une méthode statique publique open()et la méthode ouverte, combinée avec unwindowClosing() l'événement 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 donc ce n'est pas difficile à implémenter pour chaque cadre.
5. Mythe / non prouvé: ressources lourdes - J'aimerais voir quelques faits derrière cette déclaration spéculative. Bien que vous puissiez peut-être dire qu'un JFrameespace nécessite plus d'espace qu'un JInternalFrame, même si vous ouvrez 100 JFrames, combien de ressources supplémentaires consommeriez-vous vraiment? Si votre problème concerne les fuites de mémoire en raison de ressources: l'appel dispose()libère toutes les ressources utilisées par le cadre pour la collecte des ordures (et, je le répète, un JInternalFramedevrait invoquer exactement le même problème).

J'ai beaucoup écrit et j'ai l'impression de pouvoir en écrire plus. Quoi qu'il en soit, j'espère que je ne recevrai pas de vote négatif simplement parce que c'est une opinion impopulaire. La question est clairement valable et j'espère avoir fourni une réponse valable, même si ce n'est pas l'opinion commune.

Microsoft Excel est un excellent exemple de plusieurs cadres / document unique par cadre ( SDI ) par rapport à un seul cadre / plusieurs documents par cadre ( MDI ). Quelques avantages du MDI:

• 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 la deuxième fenêtre Excel - avec MDI, essayer d'écrire dans l'une des fenêtres internes donnera le focus à la fenêtre Excel entière, donc masquant 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 (Single-Document Interface, c'est-à-dire que chaque fenêtre ne peut avoir qu'un seul document):

MDI (Multiple-Document Interface, c'est-à-dire que chaque fenêtre peut avoir plusieurs documents):

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

Dans notre application, nous avons une fenêtre principale où les utilisateurs exécutent différents «programmes» sous forme d'onglets séparés. 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 qui ont été 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 dialogue de visualisation de rapports. Cette visionneuse montre l'équivalent des pages A4 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 rendre ces fenêtres de visualisation de rapports non modales, 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é quand j'ai découvert comment les utilisateurs contournaient cette «déficience» de notre système.

Ils ouvraient une visionneuse, utilisaient la fonction `` Enregistrer sous '' pour enregistrer le rapport au format PDF dans un répertoire spécifique, utilisaient Acrobat Reader pour ouvrir le fichier PDF, puis ils feraient de même avec le prochain rapport. Ils disposeraient de plusieurs lecteurs Acrobat fonctionnant avec les différentes sorties de rapport qu'ils souhaitaient consulter.

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

Lorsque la dernière version leur a été publiée la semaine dernière, la réponse écrasante de leur part est qu'ils l'adorent. Il s'agit de l'une de nos améliorations les plus récentes apportées au système.

Vous allez donc de l'avant et dites à vos utilisateurs que ce qu'ils veulent est mauvais, mais en fin de compte, cela ne vous rendra aucun service.

QUELQUES NOTES:

• Il semble préférable d'utiliser JDialog pour ces fenêtres non modales
• Utilisez les constructeurs qui utilisent le nouvel argument ModalityTypeplutôt que l' modalargument booléen . 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, transmettez un parent nul au constructeur, mais localisez-le par rapport à sa fenêtre «parent».
• La version 6 de Java sur Windows a un bogue qui signifie que votre fenêtre principale peut devenir «toujours au top» sans que vous le lui disiez. Mettre à niveau vers 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 j'ai touché le swing mais en général c'est une mauvaise pratique de le faire. Certains des principaux inconvénients qui viennent à l'esprit:

• C'est plus cher: vous devrez allouer bien plus de ressources pour dessiner un JFrame qu'un autre type de conteneur de fenêtre, comme Dialog ou JInternalFrame.

• Pas convivial: il n'est pas facile de naviguer dans un tas 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 retorique , maintenant c'est beaucoup plus facile et d'autres personnes plus intelligentes (ou avec plus de temps libre) que nous l'avons déjà pensé à travers le modèle Desktop et JInternalFrame, donc je recommanderais de l'utiliser.

Une mauvaise pratique sans aucun doute. L'une des raisons est qu'elle n'est pas très «conviviale» car chaque JFrameaffiche une nouvelle icône de barre des tâches. Contrôler plusieurs JFrames vous fera arracher vos cheveux.

Personnellement, j'utiliserais ONE JFramepour votre type d'application. Les méthodes d'affichage de plusieurs choses dépendent de vous, il y en a beaucoup. Canvases, JInternalFrame, CardLayout, même JPanels peut - être.

Plusieurs objets JFrame = douleur, problème et problèmes.

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

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

Nous pouvons également basculer entre ce JPanels. Cela nous donne donc la liberté d'afficher plus que sur chose dans le JFrame.

Pour chacun, JPanelnous pouvons concevoir différentes choses et tout cela JPanelpeut être affiché sur la seule JFrameà la fois.

Pour basculer entre cette JPanelutilisation JMenuBaravec JMenuItemspour chacun JPanelou «JButton for eachJPanel».

Plus d'un JFramen'est pas une bonne pratique, mais il n'y a rien de mal si nous en voulons plus d'un JFrame.

Mais il vaut mieux en changer un JFramepour nos différents besoins plutôt que d'avoir plusieurs JFrames.

Si les cadres vont avoir la même taille, pourquoi ne pas créer le cadre et le passer ensuite comme référence à lui à 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. Souhaitez-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 motif singleton comme bon. J'ai utilisé les motifs singleton dans la plupart de mes projets, c'est bien.