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


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 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?


482
2018-03-04 11:53


origine


Réponses:


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

Mauvaise (mauvaise, mauvaise) pratique.

  • Utilisateur hostile: l'utilisateur voit plusieurs icônes dans sa barre des tâches lorsqu'il s'attend à n'en voir qu'un seul. Plus les effets secondaires des problèmes de codage ..
  • Un cauchemar à coder et à entretenir:
    • UNE dialogue modal offre l'opportunité facile de focaliser l'attention sur le contenu de cette boîte de dialogue - choisissez / réparez / annulez ceci, puis procéder. Plusieurs images 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 les cadres si c'était le comportement souhaité.

Il existe un certain nombre de manières d'afficher de nombreux éléments dans une interface graphique, par exemple:

  • CardLayout (court démo.). Bon pour:
    1. Affichage de dialogues similaires à ceux d'un assistant.
    2. Affichage des sélections de liste, d'arborescence, etc. pour les éléments ayant un composant associé.
    3. Retourner 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 ..layered.
  • JToolBar contient généralement des groupes d'actions ou des 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 articles dans un JList (exemple simple ci-dessous).
  • En tant que nœuds dans un JTree.
  • Dispositions imbriquées.

Mais si ces stratégies ne fonctionnent pas pour un cas d'utilisation particulier, essayez ce qui suit. Établir une seule principale JFrame, alors JDialog ou JOptionPane les instances apparaissent 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 l'un des éléments suivants à la place:

  1. Un célibataire ou Individual 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 rangée JList. Comme on le voit dans cette réponse. La partie 'une rangée' ne fonctionne que si elles ont toutes les mêmes dimensions. Sinon, si vous êtes prêt à mettre à l'échelle les images à la volée et qu'elles présentent toutes le même rapport d'aspect (par exemple 4: 3 ou 16: 9).


403
2017-07-31 03:33



Le multiple JFrame l'approche a été 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. toutefoisAprès avoir mûri mon expérience et mes connaissances en tant que développeur et commencé à lire et à assimiler les opinions de tant de développeurs Java expérimentés en ligne, j'ai tenté de se éloigner du multiple JFrame approche (à la fois dans les projets en cours et futurs projets) seulement à rencontrer ... obtenir ceci ... résistance de mes clients! Comme j'ai commencé à mettre en œuvre des boîtes de dialogue modales pour contrôler les fenêtres "enfants" et JInternalFrames pour des 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". Idem 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 commun.

Donc, je vais expliquer les avantages du multiple JFrame approche, ainsi que mythe-bust certains des inconvénients que d'autres ont présentés.

  1. Flexibilité ultime dans la mise en page - En permettant séparé JFrames, vous donnez à votre utilisateur final la possibilité d'étaler et de contrôler ce qui est sur son écran. Le concept se sent "ouvert" et non-contraignant. Vous perdez ceci quand vous allez vers un grand JFrame et un tas de JInternalFrames.
  2. 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 l'un avec l'autre. Par exemple, un module peut être un tableau de bord de vente et un autre peut être un tableau de bord de comptabilité. Ils ne se parlent pas ou quoi que ce soit. Cependant, l'exécutif pourrait vouloir ouvrir les deux et les étant des cadres séparés sur la barre des tâches lui facilite la vie.
  3. Permet aux utilisateurs finaux de référencer le matériel externe - Une fois, j'ai eu cette situation: Mon application avait une "visionneuse de données", à partir de laquelle vous pouvez cliquer sur "Ajouter un nouveau" et il ouvrirait un écran de saisie de données. Au départ, les deux étaient JFrames. Cependant, je voulais que l’écran de saisie soit un JDialog dont le parent était le visualiseur de données. J'ai fait le changement, et immédiatement j'ai reçu un appel d'un utilisateur final qui comptait énormément sur le fait qu'il pouvait minimiser ou fermer le téléspectateur et gardez le éditeur ouvert alors qu'il référencé une autre partie du programme (ou un site Web, je ne me souviens pas). il est ne pas sur un multi-moniteur, il avait donc besoin de la boîte de dialogue d'entrée pour être premier et autre chose être deuxième, avec le visualiseur de données complètement caché. C'était impossible avec un JDialog et certainement aurait été impossible avec un JInternalFrame ainsi que. Je suis à contrecoeur changé à être 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 dans 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 offrir beaucoup moins de flexibilité. J'ai développé une manière 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, 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 en avant du cadre si l'utilisateur tente de l'ouvrir deux fois, etc. Tout ce dont vous avez besoin pour ouvrir mon JFrames appelle une méthode statique publique open() et la méthode ouverte, combinée à une windowClosing() event gère le reste (est-ce que le cadre est déjà ouvert? n'est-il pas ouvert, mais charge-t-il? etc.) J'ai fait de cette approche un modèle afin qu'il ne soit pas difficile à implémenter pour chaque image.
  5. Mythe / Unproven: Ressource lourde - Je voudrais voir quelques faits derrière cette déclaration spéculative. Bien que, peut-être, vous pourriez dire 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 problème est une fuite de mémoire à cause des ressources: appel dispose() libère toutes les ressources utilisées par le cadre pour la collecte des ordures (et, encore une fois, je dis, un JInternalFrame devrait invoquer exactement le même souci).

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 valable 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 image unique / plusieurs documents par image (MDI) est Microsoft Excel. Quelques avantages du MDI:

  • il est possible d'avoir quelques fenêtres de forme non rectangulaire - elles ne masquent donc 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 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):

enter image description here

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

enter image description here


186
2017-08-30 03:36



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'onglets distincts. Autant que possible, nous avons essayé de garder notre application à 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 dialogue 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 étaient en train de contourner cette «déficience» de notre système.

Ils ouvraient une visionneuse, en utilisant la fonction «Enregistrer sous» pour enregistrer le rapport sous forme de fichier 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 de nos améliorations récentes les plus populaires 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 aidera pas.

QUELQUES NOTES:

  • Il semble être la meilleure pratique à utiliser JDialog pour ces fenêtres non modales
  • Utilisez les constructeurs qui utilisent le nouveau ModalityType plutôt que le booléen modal argument. C'est ce qui donne à ces dialogues l'icône de la barre des tâches.
  • Pour les boîtes de dialogue 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 punaise ce qui signifie que votre fenêtre principale peut devenir «toujours visible» sans que vous le disiez. Passez à la version 7 pour résoudre ce problème

46
2017-10-17 05:25



Faire un jInternalFrame dans le cadre principal et le rendre invisible. Ensuite, vous pouvez l'utiliser pour d'autres événements.

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

16
2018-03-05 00:55



Cela fait un moment que la dernière fois que je touche au swing, c'est une mauvaise pratique. 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 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 plutôt répétitif, maintenant c'est beaucoup plus facile et d'autres personnes plus intelligentes (ou avec plus de temps libre) que nous avons déjà réfléchi à travers le pattern Desktop et JInternalFrame, donc je recommanderais de l'utiliser.


16
2018-01-10 10:37



Mauvaise pratique définitivement. Une raison est que ce n'est pas très "convivial" pour le fait que chaque JFrame affiche une nouvelle icône de barre des tâches. Contrôler plusieurs JFrames vous allez 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, même JPanels éventuellement.

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


9
2017-12-18 07:03



Je pense en utilisant 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.

Aussi, nous pouvons basculer entre cette JPanels. Donc, cela nous donne la liberté de montrer plus que sur la chose dans le JFrame.

Pour chaque JPanel nous pouvons concevoir différentes choses et tout cela JPanel peut être affiché sur le single JFrameun à la fois.

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

Plus d'un JFrame n'est pas une bonne pratique, mais il n'y a rien de mal si l'on veut plus d'un JFrame.

Mais c'est mieux de changer un JFrame pour nos différents besoins plutôt que d'avoir plusieurs JFrames.


6
2017-09-03 22:25



Si les images doivent avoir la même taille, pourquoi ne pas créer le cadre et passer le cadre alors comme une référence à la place.

Lorsque vous avez passé le cadre, vous pouvez décider comment le peupler. 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?


4
2017-12-14 13:20