Die Verwendung mehrerer JFrames: Gute oder schlechte Praxis? [geschlossen]

Ich entwickle eine Anwendung, die Bilder anzeigt und Töne aus einer Datenbank wiedergibt. Ich versuche zu entscheiden, ob ein separater JFrame zum Hinzufügen von Bildern zur Datenbank über die GUI verwendet werden soll oder nicht.

Ich frage mich nur, ob es empfehlenswert ist, mehrere JFrame-Fenster zu verwenden.

Ich frage mich nur, ob es eine gute Praxis ist, mehrere JFrames zu verwenden.

Schlechte (schlechte, schlechte) Praxis.

• Benutzer unfreundlich: Der Benutzer sieht mehrere Symbole in seiner Taskleiste, wenn er erwartet, nur eines zu sehen. Plus die Nebenwirkungen der Codierungsprobleme ..
• Ein Albtraum zum Codieren und Verwalten:
  • Ein modaler Dialog bietet die einfache Möglichkeit, die Aufmerksamkeit auf den Inhalt dieses Dialogs zu lenken - wählen / korrigieren / abbrechen und dann fortfahren. Mehrere Frames nicht.
  • Ein Dialog (oder eine schwebende Symbolleiste) mit einem übergeordneten Element wird angezeigt, wenn auf das übergeordnete Element geklickt wird. Wenn dies das gewünschte Verhalten wäre, müssten Sie dies in Frames implementieren.

Es gibt verschiedene Möglichkeiten, viele Elemente in einer GUI anzuzeigen, z.

• CardLayout(kurze Demo. ) Gut für:
  1. Assistentenähnliche Dialoge anzeigen.
  2. Anzeigen von Listen-, Baum- usw. Auswahlmöglichkeiten für Elemente, denen eine Komponente zugeordnet ist.
  3. Umschalten zwischen keiner Komponente und sichtbarer Komponente.
• JInternalFrame/JDesktopPane Wird normalerweise für ein MDI verwendet .
• JTabbedPane für Gruppen von Komponenten.
• JSplitPane Eine Möglichkeit, zwei Komponenten anzuzeigen, deren Wichtigkeit zwischen der einen oder der anderen (der Größe) je nach dem, was der Benutzer tut, variiert.
• JLayeredPane weit viele gut geschichtete Komponenten.
• JToolBarEnthält normalerweise Gruppen von Aktionen oder Steuerelementen. Kann je nach Benutzeranforderung über die GUI gezogen oder ganz entfernt werden. Wie oben erwähnt, wird die Wiederherstellung entsprechend dem übergeordneten Element minimiert / wiederhergestellt.
• Als Artikel in einem JList(einfaches Beispiel unten).
• Als Knoten in a JTree.
• Verschachtelte Layouts .
  

Wenn diese Strategien jedoch für einen bestimmten Anwendungsfall nicht funktionieren, versuchen Sie Folgendes. Richten Sie eine einzelne Hauptleitung ein JFrame, und dann werden JDialogoder JOptionPaneInstanzen für den Rest der frei schwebenden Elemente angezeigt, wobei der Rahmen als übergeordnetes Element für die Dialoge verwendet wird.

Viele Bilder

In diesem Fall, in dem die mehreren Elemente Bilder sind, ist es besser, stattdessen eines der folgenden Elemente zu verwenden:

1. Eine einzelne JLabel(in einem Bildlaufbereich zentriert), um das Bild anzuzeigen, an dem der Benutzer gerade interessiert ist. Wie in gesehen ImageViewer.
   
2. Eine einzelne Reihe JList. Wie in dieser Antwort zu sehen . Der Teil "einzelne Zeile" davon funktioniert nur, wenn alle die gleichen Abmessungen haben. Alternativ, wenn Sie bereit sind, die Bilder im laufenden Betrieb zu skalieren und alle das gleiche Seitenverhältnis haben (z. B. 4: 3 oder 16: 9).

Der Mehrfachansatz JFramewurde von mir implementiert, seit ich mit der Programmierung von Swing-Apps begonnen habe. Zum größten Teil habe ich es am Anfang gemacht, weil ich es nicht besser wusste. Jedoch , wie ich in meiner Erfahrung und Wissen als Entwickler gereift und begann zu lesen und zu absorbieren die Bewertungen des so viele erfahrenen Java - Online - Devs, machte ich einen Versuch, Abkehr von dem mehrfachen JFrameAnsatz (sowohl in aktuellen Projekten und zukünftigen Projekten ) nur um auf ... diesen ... Widerstand meiner Kunden zu stoßen! Als ich anfing, modale Dialoge zu implementieren, um "untergeordnete" Fenster und JInternalFrames für separate Komponenten zu steuern , begannen meine Kunden sich zu beschweren!Ich war ziemlich überrascht, als ich das tat, was ich für Best Practice hielt! Aber wie sie sagen: "Eine glückliche Frau ist ein glückliches Leben." Gleiches gilt für Ihre Kunden. Natürlich bin ich ein Auftragnehmer, sodass meine Endbenutzer direkten Zugriff auf mich, den Entwickler, haben, was offensichtlich kein alltägliches Szenario ist.

Also werde ich die Vorteile des Mehrfachansatzes erklären und JFrameeinige der Nachteile, die andere vorgestellt haben, mit Mythen zerstören.

1. Ultimative Flexibilität im Layout - Indem Sie separate JFrames zulassen, geben Sie Ihrem Endbenutzer die Möglichkeit, die Anzeige auf seinem Bildschirm zu verteilen und zu steuern. Das Konzept fühlt sich "offen" und nicht einschränkend an. Sie verlieren dies, wenn Sie sich einem großen JFrameund einem Haufen JInternalFrames nähern .
2. Funktioniert gut für sehr modularisierte Anwendungen - In meinem Fall haben die meisten meiner Anwendungen 3 - 5 große "Module", die wirklich überhaupt nichts miteinander zu tun haben. Beispielsweise kann ein Modul ein Verkaufs-Dashboard und eines ein Buchhaltungs-Dashboard sein. Sie reden nicht miteinander oder so. Die Führungskraft möchte jedoch möglicherweise beide öffnen, und sie sind separate Frames in der Taskleiste, was ihm das Leben erleichtert.
3. Erleichtert Endbenutzern das Verweisen auf externes Material - Einmal hatte ich folgende Situation: Meine App hatte einen "Daten-Viewer", über den Sie auf "Neu hinzufügen" klicken konnten, und es wurde ein Dateneingabebildschirm geöffnet. Anfangs waren beide JFrames. Ich wollte jedoch, dass der Dateneingabebildschirm ein JDialogübergeordneter Datenbetrachter ist. Ich nahm die Änderung vor und erhielt sofort einen Anruf von einem Endbenutzer, der sich stark darauf verlassen konnte, dass er den Viewer minimieren oder schließen und den Editor offen halten konnte, während er auf einen anderen Teil des Programms (oder eine Website, die ich nicht verweise, verwies) Ich erinnere mich nicht). Er ist nicht auf einem Multi-Monitor, daher musste der Eingabedialog an erster Stelle stehen und etwas anderesZweitens, mit dem Daten-Viewer völlig versteckt. Dies war mit einem unmöglich JDialogund wäre mit einem sicherlich auch unmöglich gewesen JInternalFrame. Ich änderte es widerwillig wieder, um JFramesfür seine geistige Gesundheit getrennt zu sein, aber es brachte mir eine wichtige Lektion bei.
4. Mythos: Schwer zu codieren - Dies trifft meiner Erfahrung nach nicht zu. Ich verstehe nicht, warum es einfacher wäre, ein JInternalFrameals ein zu erstellen JFrame. In der Tat JInternalFramesbieten meiner Erfahrung nach viel weniger Flexibilität. Ich habe eine systematische Methode zum Behandeln des Öffnens und Schließens von JFrames in meinen Apps entwickelt, die wirklich gut funktioniert. Ich steuere den Frame fast vollständig aus dem Code des Frames heraus. die Erstellung des neuen Frames, der SwingWorkerdas Abrufen von Daten in Hintergrundthreads und des GUI-Codes in EDT steuert, den Frame wiederherstellt / nach vorne bringt, wenn der Benutzer versucht, ihn zweimal zu öffnen usw. Alles, was Sie zum Öffnen meines Frames benötigen, JFrameist Rufen Sie eine öffentliche statische Methode open()und die offene Methode in Kombination mit a aufwindowClosing() event erledigt den Rest (ist der Frame bereits geöffnet? Ist er nicht geöffnet, sondern wird geladen? usw.) Ich habe diesen Ansatz zu einer Vorlage gemacht, damit es nicht schwierig ist, ihn für jeden Frame zu implementieren.
5. Mythos / Unbewiesen: Resource Heavy - Ich würde gerne einige Fakten hinter dieser spekulativen Aussage sehen. Obwohl Sie vielleicht sagen könnten, dass a JFramemehr Platz benötigt als a JInternalFrame, selbst wenn Sie 100 JFrames öffnen , wie viel mehr Ressourcen würden Sie wirklich verbrauchen? Wenn Ihr Problem Speicherlecks aufgrund von Ressourcen sind: Durch das Aufrufen werden dispose()alle Ressourcen freigegeben, die vom Frame für die Speicherbereinigung verwendet werden (und ich sage erneut, a JInternalFramesollte genau dasselbe Problem hervorrufen).

Ich habe viel geschrieben und ich habe das Gefühl, ich könnte mehr schreiben. Wie auch immer, ich hoffe, ich werde nicht einfach deshalb herabgestimmt, weil es eine unpopuläre Meinung ist. Die Frage ist eindeutig wertvoll und ich hoffe, ich habe eine wertvolle Antwort gegeben, auch wenn dies nicht die allgemeine Meinung ist.

Ein gutes Beispiel für mehrere Frames / ein einzelnes Dokument pro Frame ( SDI ) im Vergleich zu einem einzelnen Frame / mehreren Dokumenten pro Frame ( MDI ) ist Microsoft Excel. Einige der MDI-Vorteile:

• Es ist möglich, einige Fenster in nicht rechteckiger Form zu haben, damit sie den Desktop oder ein anderes Fenster nicht vor einem anderen Prozess (z. B. einem Webbrowser) verbergen.
• Es ist möglich, ein Fenster aus einem anderen Prozess über ein Excel-Fenster zu öffnen, während Sie in das zweite Excel-Fenster schreiben. Wenn Sie mit MDI versuchen, in eines der internen Fenster zu schreiben, wird der Fokus auf das gesamte Excel-Fenster gelegt, wodurch das Fenster vor einem anderen Prozess ausgeblendet wird
• Es ist möglich, unterschiedliche Dokumente auf unterschiedlichen Bildschirmen zu haben. Dies ist besonders nützlich, wenn Bildschirme nicht dieselbe Auflösung haben

SDI (Single-Document Interface, dh jedes Fenster kann nur ein einziges Dokument haben):

MDI (Multiple-Document Interface, dh jedes Fenster kann mehrere Dokumente enthalten):

Ich möchte dem Argument "nicht benutzerfreundlich" mit einem Beispiel begegnen, an dem ich gerade beteiligt war.

In unserer Anwendung haben wir ein Hauptfenster, in dem die Benutzer verschiedene "Programme" als separate Registerkarten ausführen. Wir haben so viel wie möglich versucht, unsere Anwendung in diesem einzigen Fenster zu belassen.

Eines der von ihnen ausgeführten Programme enthält eine Liste der vom System generierten Berichte. Der Benutzer kann in jeder Zeile auf ein Symbol klicken, um ein Dialogfeld zur Berichtsanzeige zu öffnen. Dieser Viewer zeigt das Äquivalent der A4-Seite (n) im Hoch- / Querformat des Berichts an, sodass die Benutzer dieses Fenster als ziemlich groß betrachten und fast ihre Bildschirme ausfüllen.

Vor einigen Monaten haben wir Anfragen von unseren Kunden erhalten, diese Berichts-Viewer-Fenster modelllos zu machen, damit mehrere Berichte gleichzeitig geöffnet sein können.

Einige Zeit habe ich mich dieser Bitte widersetzt, da ich dies nicht für eine gute Lösung hielt. Meine Meinung wurde jedoch geändert, als ich herausfand, wie die Benutzer diesen „Mangel“ unseres Systems umgehen konnten.

Sie öffneten einen Viewer und speicherten den Bericht mithilfe der Funktion "Speichern unter" als PDF in einem bestimmten Verzeichnis. Mit Acrobat Reader öffneten sie die PDF-Datei und machten dasselbe mit dem nächsten Bericht. Sie würden mehrere Acrobat Readers mit den verschiedenen Berichtsausgaben ausführen, die sie betrachten wollten.

Also gab ich nach und machte den Betrachter modelllos. Dies bedeutet, dass jeder Betrachter ein Taskleistensymbol hat.

Als ihnen letzte Woche die neueste Version veröffentlicht wurde, ist die überwältigende Antwort von ihnen, dass sie es lieben. Es war eine unserer beliebtesten jüngsten Verbesserungen des Systems.

Sie sagen Ihren Benutzern also, dass das, was sie wollen, schlecht ist, aber letztendlich wird es Ihnen keinen Gefallen tun.

EINIGE NOTIZEN:

• Es scheint eine bewährte Methode zu sein, JDialogs für diese modelllosen Fenster zu verwenden
• Verwenden Sie die Konstruktoren, die das neue ModalityTypeund nicht das boolesche modalArgument verwenden. Dies gibt diesen Dialogen das Taskleistensymbol.
• Übergeben Sie für modelllose Dialoge dem Konstruktor ein übergeordnetes Element null, suchen Sie sie jedoch relativ zu ihrem übergeordneten Fenster.
• Version 6 von Java unter Windows weist einen Fehler auf, der bedeutet, dass Ihr Hauptfenster "immer oben" sein kann, ohne dass Sie es mitteilen. Aktualisieren Sie auf Version 7, um dies zu beheben

Machen Sie einen jInternalFrame zum Hauptframe und machen Sie ihn unsichtbar. Dann können Sie es für weitere Ereignisse verwenden.

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

Es ist eine Weile her, seit ich das letzte Mal Swing berührt habe, aber im Allgemeinen ist es eine schlechte Praxis, dies zu tun. Einige der Hauptnachteile, die mir in den Sinn kommen:

• Es ist teurer: Sie müssen viel mehr Ressourcen zuweisen, um einen JFrame als eine andere Art von Fenstercontainer wie Dialog oder JInternalFrame zu zeichnen.

• Nicht benutzerfreundlich: Es ist nicht einfach, in eine Reihe von zusammengeklebten JFrames zu navigieren. Es sieht so aus, als ob Ihre Anwendung eine Reihe von Anwendungen ist, die inkonsistent und schlecht gestaltet sind.

• Es ist einfach, JInternalFrame zu verwenden. Dies ist eine Art Retorical. Jetzt ist es viel einfacher und andere Leute sind schlauer (oder haben mehr Freizeit), als wir bereits über das Desktop- und JInternalFrame-Muster nachgedacht haben. Daher würde ich empfehlen, es zu verwenden.

Schlechte Praxis auf jeden Fall. Ein Grund dafür ist, dass es nicht sehr "benutzerfreundlich" ist, da jedes JFrameein neues Taskleistensymbol anzeigt. Wenn Sie mehrere JFrames steuern, werden Sie sich die Haare ausreißen.

Persönlich würde ich ONE JFramefür Ihre Art von Anwendung verwenden. Es liegt an Ihnen, wie Sie mehrere Dinge anzeigen können. Es gibt viele. Canvases, JInternalFrame, CardLayout, auch JPanels möglicherweise.

Mehrere JFrame-Objekte = Schmerzen, Probleme und Probleme.

Ich denke, mehrere Jframes zu verwenden ist keine gute Idee.

Stattdessen können wir JPanels mehr als ein oder mehrere JPanelgleichzeitig verwenden JFrame.

Auch können wir zwischen diesen JPanels wechseln . Es gibt uns also die Freiheit, mehr als nur etwas in der zu zeigen JFrame.

Für jedes können JPanelwir verschiedene Dinge entwerfen und all dies JPanelkann einzeln angezeigt JFramewerden.

Zwischen diesen wechseln JPanels Verwendung JMenuBarmit JMenuItemsfür jeden JPaneloder ‚JButton for eachJPanel`.

Mehr als eine JFrameist keine gute Praxis, aber es ist nichts falsch, wenn wir mehr als eine wollen JFrame.

Aber es ist besser, eine JFramefür unsere unterschiedlichen Bedürfnisse zu ändern, als mehrere zu haben JFrame.

Wenn die Frames dieselbe Größe haben sollen, erstellen Sie den Frame und übergeben Sie ihn stattdessen als Referenz.

Wenn Sie den Frame übergeben haben, können Sie entscheiden, wie er gefüllt werden soll. Es wäre, als hätte man eine Methode zur Berechnung des Durchschnitts einer Reihe von Zahlen. Würden Sie die Methode immer und immer wieder erstellen?

Es ist keine gute Praxis, aber obwohl Sie es verwenden möchten, können Sie das Singleton-Muster als gut verwenden. Ich habe die Singleton-Muster in den meisten meiner Projekte verwendet, es ist gut.