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

Mar 04 2012

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 si c'est une bonne pratique d'utiliser plusieurs fenêtres JFrame?

Réponses

456 AndrewThompson Mar 04 2012 at 18:56

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

Mauvaise (mauvaise, mauvaise) pratique.

Non convivial pour l'utilisateur: 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 à 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 ceci, puis continuez. Plusieurs cadres ne le font pas.
- Une boîte de dialogue (ou une barre d'outils flottante) avec un parent apparaîtra au premier plan lorsque le parent est cliqué - vous devrez l'implémenter dans des cadres si c'é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 de l'assistant comme des boîtes de dialogue.
2. Affichage des sélections de liste, d'arborescence, etc. pour les éléments qui ont un composant 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 en fonction de ce que fait l'utilisateur.
JLayeredPane beaucoup de composants bien .. en couches.
JToolBarcontient 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 selon le parent qui le fait.
En tant qu'éléments dans un JList(exemple simple ci-dessous).
En tant que nœuds dans un fichier JTree.
Dispositions imbriquées .

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

De nombreuses images

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

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.
Une seule ligne JList. Comme on le voit dans cette réponse . La partie «à une seule ligne» ne fonctionne que si elles ont toutes les mêmes dimensions. Alternativement, si vous êtes prêt à redimensionner les images à la volée, et qu'elles ont toutes le même rapport hauteur / largeur (par exemple 4: 3 ou 16: 9).

205 ryvantage Jul 31 2013 at 10:33

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 , au fur et à mesure que j'ai mûri dans mon expérience et mes connaissances en tant que développeur et que j'ai commencé à lire et à absorber les opinions de tant de développeurs Java plus expérimentés en ligne, j'ai tenté de m'éloigner de l' JFrameapproche multiple (à la fois dans les projets actuels et futurs. ) seulement pour être rencontré ... obtenir cette ... résistance de mes clients! Alors que je commençais à implémenter des dialogues modaux pour contrôler les fenêtres "enfants" et les 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 entrepreneur, donc 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 vous expliquer les avantages de l' JFrameapproche multiple , ainsi que la destruction des mythes, certains des inconvénients que d'autres ont présentés.

Flexibilité ultime dans la mise en page - En autorisant des JFrames séparés , vous donnez à votre utilisateur final la possibilité de répartir et de contrôler ce qui se trouve sur son écran. Le concept se sent "ouvert" et non contraignant. Vous perdez cela lorsque vous vous dirigez vers un grand JFrameet un tas de JInternalFrames.
Fonctionne bien pour les applications très modulaires - 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 un tableau de bord comptable. Ils ne se parlent pas ou quoi que ce soit. Cependant, l'exécutif voudra peut-être ouvrir les deux et les cadres séparés de la barre des tâches lui facilitent la vie.
Il est facile pour les utilisateurs finaux de référencer du matériel extérieur - Une fois, j'ai eu cette situation: mon application avait une "visionneuse de données", à partir de laquelle vous pouviez cliquer sur "Ajouter nouveau" et cela ouvrirait un écran de saisie de données. Au départ, les deux étaient l' JFrameart. Cependant, je voulais que l'écran de saisie des données soit un 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 fortement sur le fait qu'il pouvait minimiser ou fermer le spectateur 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, il avait donc besoin que la boîte de dialogue d'entrée soit le premier et que quelque chose d' autre soit le deuxième, avec le visualiseur de données complètement masqué. C'était impossible avec un JDialoget cela aurait certainement été impossible avec un JInternalFrame. Je l'ai changé à contrecœur pour devenir séparé JFramespour sa santé mentale, mais cela m'a appris une leçon importante.
Mythe: Difficile à coder - Ce n'est pas vrai d'après mon expérience. Je ne vois pas pourquoi il serait plus facile de créer un fichier qu'un JInternalFramefichier JFrame. En fait, d'après mon expérience, JInternalFramesoffrir beaucoup moins de flexibilité. J'ai développé un moyen systématique de gérer l'ouverture et la fermeture des 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, SwingWorkers qui contrôlent la récupération des données sur les threads d'arrière-plan et le code GUI sur EDT, la restauration / mise au premier plan 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 à un windowClosing()événement gère le reste (le cadre est-il déjà ouvert? n'est-il pas ouvert, mais en cours de chargement? etc.) J'ai fait de cette approche un modèle donc ce n'est pas difficile à implémenter pour chaque cadre .
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 a JFramebesoin de plus d'espace qu'un JInternalFrame, même si vous ouvrez 100 JFrames, combien de ressources consommeriez-vous réellement? Si votre problème concerne les fuites de mémoire à cause des ressources: l'appel dispose()libère toutes les ressources utilisées par le cadre pour le ramasse-miettes (et, encore une fois, je le dis, a JInternalFramedevrait invoquer exactement le même problème).

J'ai beaucoup écrit et je sens que je pourrais en écrire plus. Quoi qu'il en soit, j'espère que je ne serai pas critiqué 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 valable, même si ce n'est pas l'opinion commune.

Microsoft Excel est un excellent exemple de plusieurs cadres / document unique par image ( SDI ) par rapport à une seule image / plusieurs documents par image ( MDI ). Certains des avantages 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 à partir d'un autre processus sur une fenêtre Excel tout en écrivant dans une deuxième fenêtre Excel - avec MDI, essayer d'écrire dans l'une des fenêtres internes 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 (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):

53 DuncanKinnear Aug 30 2013 at 10:36

Je voudrais contrer l'argument "pas convivial" avec un exemple dont je viens de m'impliquer.

Dans notre application, nous avons une fenêtre principale où les utilisateurs exécutent divers «programmes» sous forme d'onglets séparés. Autant que 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 rapport. Cette visionneuse affiche l'équivalent de la ou 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'ils puissent ouvrir plusieurs rapports en même temps.

Pendant un certain temps, j'ai résisté à cette demande car je ne pensais pas que ce soit une bonne solution. Cependant, j'ai changé d'avis lorsque j'ai découvert comment les utilisateurs contournaient cette «carence» de notre système.

Ils ouvraient une visionneuse, utilisant la fonction «Enregistrer sous» pour enregistrer le rapport au format PDF dans un répertoire spécifique, utilisant Acrobat Reader pour ouvrir le fichier PDF, puis ils feraient de même avec le rapport suivant. Ils auraient plusieurs lecteurs Acrobat fonctionnant avec les diverses sorties de rapport qu'ils voulaient examiner.

Alors j'ai cédé et j'ai rendu le spectateur modeste. 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 ADORENT. Il s'agit de l'une de nos récentes améliorations les plus populaires du système.

Alors vous allez-y et dites à vos utilisateurs que ce qu'ils veulent est mauvais, mais finalement cela ne vous rendra pas service.

QUELQUES NOTES:

Il semble être la meilleure pratique d'utiliser JDialog pour ces fenêtres non modales
Utilisez les constructeurs qui utilisent l' argument new 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-les par rapport à leur 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. Passez à la version 7 pour résoudre ce problème

20 VirendraSinghRathore Oct 17 2012 at 12:25

Créez 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);

19 Necronet Mar 05 2013 at 07:55

Cela fait un moment que je n'ai pas touché au swing pour la dernière fois, mais en général, c'est 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 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 semblera que votre application est un ensemble d'applications incohérentes et mal conçues.
Il est facile d'utiliser JInternalFrame C'est un peu rétorical, maintenant c'est beaucoup plus facile et d'autres personnes plus intelligentes (ou avec plus de temps libre) que nous ne le pensons déjà à travers le modèle Desktop et JInternalFrame, donc je recommanderais de l'utiliser.

10 MattDawsey Jan 10 2013 at 17:37

Mauvaise pratique définitivement. Une des raisons est qu'il n'est pas très «convivial» car chacun JFrameaffiche une nouvelle icône dans la barre des tâches. Contrôler plusieurs JFrames vous fera vous arracher les 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.

Objets JFrame multiples = douleur, problème et problèmes.

8 Lijo Dec 18 2013 at 14:03

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 par JPanel. Cela nous donne donc la liberté d'afficher plus que sur quelque chose dans le JFrame.

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

Pour basculer entre cette JPanelutilisation de s JMenuBaravec JMenuItemspour chaque JPanelou « DButton 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.

5 KeithSpriggs Sep 04 2013 at 05:25

Si les cadres doivent être de la même taille, pourquoi ne pas créer le cadre et passer le cadre alors comme référence à celui-ci.

Lorsque vous avez dé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 arunjoseph Dec 14 2013 at 20:20

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 modèles singleton dans la plupart de mon projet, c'est bien.