Użycie wielu ramek JFr: dobra czy zła praktyka? [Zamknięte]

Tworzę aplikację, która wyświetla obrazy i odtwarza dźwięki z bazy danych. Próbuję zdecydować, czy użyć osobnej ramki JFrame, aby dodać obrazy do bazy danych z GUI.

Zastanawiam się tylko, czy dobrą praktyką jest używanie wielu okien JFrame?

Zastanawiam się tylko, czy dobrą praktyką jest używanie wielu ramek JFrame?

Zła (zła, zła) praktyka.

• Nieprzyjazny dla użytkownika: użytkownik widzi wiele ikon na pasku zadań, gdy oczekuje tylko jednej. Plus skutki uboczne problemów z kodowaniem.
• Koszmar do kodowania i utrzymania:
  • Modalne okno dialogowe oferuje łatwą okazję do skupienia uwagi na treść tego okna - Wybierz / fix / anulować to, następnie kontynuować. Wiele klatek nie.
  • Okno dialogowe (lub ruchomy pasek narzędzi) z rodzicem pojawi się na pierwszym planie po kliknięciu rodzica - musiałbyś zaimplementować to w ramkach, jeśli było to pożądane zachowanie.

Istnieje wiele sposobów wyświetlania wielu elementów w jednym GUI, np .:

• CardLayout(krótkie demo. ). Dobre dla:
  1. Pokazywanie okien dialogowych podobnych do kreatora.
  2. Wyświetlanie listy, drzewa itp. Dla elementów, które mają powiązany komponent.
  3. Przerzucanie między brakiem komponentu a widocznym komponentem.
• JInternalFrame/JDesktopPane zwykle używany do MDI .
• JTabbedPane dla grup komponentów.
• JSplitPane Sposób wyświetlania dwóch składników, których znaczenie między jednym a drugim (rozmiarem) różni się w zależności od tego, co robi użytkownik.
• JLayeredPane wiele dobrze dobranych komponentów.
• JToolBarzazwyczaj zawiera grupy działań lub kontroli. Może być przeciągany wokół GUI lub całkowicie zgodnie z potrzebami użytkownika. Jak wspomniano powyżej, zminimalizuje / przywróci zgodnie z postępowaniem rodzica.
• Jako elementy w JList(prosty przykład poniżej).
• Jako węzły w JTree.
• Układy zagnieżdżone .
  

Ale jeśli te strategie nie działają dla konkretnego przypadku użycia, spróbuj wykonać następujące czynności. Ustanów pojedynczy element główny JFrame, a następnie wyświetl JDialoglub JOptionPanewystąpień dla pozostałych elementów swobodnych, używając ramki jako elementu nadrzędnego dla okien dialogowych.

Wiele zdjęć

W tym przypadku, gdy wiele elementów jest obrazami, lepiej byłoby użyć jednego z poniższych:

1. Pojedynczy JLabel(wyśrodkowany w panelu przewijania) do wyświetlenia dowolnego obrazu, który użytkownik jest zainteresowany w danym momencie. Jak widać w ImageViewer.
   
2. Jeden rząd JList. Jak widać w tej odpowiedzi . Część „pojedynczego rzędu” działa tylko wtedy, gdy wszystkie mają takie same wymiary. Alternatywnie, jeśli jesteś przygotowany do skalowania obrazów w locie, a wszystkie mają ten sam współczynnik kształtu (np. 4: 3 lub 16: 9).

Wielokrotne JFramepodejście jest czymś, co wdrożyłem, odkąd zacząłem programować aplikacje Swing. W większości zrobiłem to na początku, ponieważ nie wiedziałem nic lepszego. Jednak w miarę dojrzewania mojego doświadczenia i wiedzy jako programisty oraz gdy zacząłem czytać i wchłaniać opinie tak wielu bardziej doświadczonych programistów Java, podjąłem próbę odejścia od wielorakiego JFramepodejścia (zarówno w bieżących, jak i przyszłych projektach) ) tylko po to, by spotkać się z ... uzyskać ten ... opór od moich klientów! Gdy zacząłem wdrażać modalne okna dialogowe do kontrolowania okien potomnych JInternalFrameoddzielnych komponentów, moi klienci zaczęli narzekać!Byłem dość zaskoczony, ponieważ robiłem to, co uważałem za najlepszą praktykę! Ale, jak mówią: „Szczęśliwa żona to szczęśliwe życie”. To samo dotyczy twoich klientów. Oczywiście jestem wykonawcą, więc moi użytkownicy końcowi mają bezpośredni dostęp do mnie, programisty, co oczywiście nie jest częstym scenariuszem.

Wyjaśnię więc korzyści płynące z wielorakiego JFramepodejścia, a także obalę niektóre z wad przedstawionych przez innych.

1. Najwyższa elastyczność w układzie - Pozwalając osobnym JFrames, dajesz użytkownikowi końcowemu możliwość rozłożenia i kontrolowania tego, co jest na jego ekranie. Koncepcja wydaje się „otwarta” i niewiążąca. Tracisz to, gdy zbliżasz się do jednego dużego JFramei kilku JInternalFrames.
2. Działa dobrze w przypadku bardzo modularnych aplikacji - w moim przypadku większość moich aplikacji ma 3–5 dużych „modułów”, które tak naprawdę nie mają ze sobą nic wspólnego. Na przykład jeden moduł może być pulpitem sprzedaży, a drugi może być pulpitem rachunkowości. Nie rozmawiają ze sobą ani nic. Jednak kierownictwo może chcieć otworzyć oba, a ich oddzielne ramki na pasku zadań ułatwiają mu życie.
3. Ułatwia użytkownikom końcowym odwoływanie się do materiałów zewnętrznych - Kiedyś miałem taką sytuację: moja aplikacja miała „przeglądarkę danych”, w której można kliknąć „Dodaj nowy” i otworzyć ekran wprowadzania danych. Początkowo oba były JFrames. Chciałem jednak, aby ekran wprowadzania danych JDialogbył tym, którego rodzicem była przeglądarka danych. Dokonałem zmiany i natychmiast otrzymałem telefon od użytkownika końcowego, który w dużej mierze polegał na tym, że mógł zminimalizować lub zamknąć przeglądarkę i pozostawić otwarty edytor, podczas gdy odwoływał się do innej części programu (lub strony internetowej, nie nie pamiętam). Nie ma go na wielu monitorach, więc najpierw potrzebował okna dialogowego wejścia i czegoś innegona drugim miejscu, z całkowicie ukrytą przeglądarką danych. To było niemożliwe z, JDialoga na pewno byłoby niemożliwe z JInternalFramerównież. Niechętnie zmieniłem to z powrotem na oddzielne JFramesdla jego zdrowia psychicznego, ale nauczyło mnie to ważnej lekcji.
4. Mit: trudny do zakodowania - z mojego doświadczenia nie jest to prawdą. Nie rozumiem, dlaczego łatwiej byłoby stworzyć JInternalFrameniż JFrame. Z mojego doświadczenia wynika, że JInternalFramesoferują znacznie mniejszą elastyczność. Opracowałem systematyczny sposób obsługi otwierania i zamykania JFrames w moich aplikacjach, który naprawdę działa dobrze. Kontroluję ramkę prawie całkowicie z poziomu samego kodu ramki; tworzenie nowych ramek, SwingWorkerktóre kontrolują pobieranie danych w wątkach w tle i kod GUI w EDT, przywracanie / przybliżanie ramki, jeśli użytkownik spróbuje otworzyć ją dwukrotnie, itp. Wszystko, co musisz otworzyć, JFrameto wywołać publiczną metodę statyczną open()i metodę otwartą w połączeniu zwindowClosing() wydarzenie obsługuje resztę (czy ramka jest już otwarta? czy nie jest otwarta, ale ładowanie? itd.) Ustawiłem to podejście jako szablon, więc nie jest trudno wdrożyć dla każdej ramki.
5. Mit / niesprawdzony: ciężkie zasoby - chciałbym zobaczyć kilka faktów za tym spekulacyjnym stwierdzeniem. Chociaż być może możesz powiedzieć, że JFramepotrzebujesz więcej miejsca niż a JInternalFrame, nawet jeśli otworzysz 100 JFrames, o ile więcej zasobów tak naprawdę byś zużył? Jeśli twoim problemem jest wyciek pamięci z powodu zasobów: wywołanie dispose()uwalnia wszystkie zasoby używane przez ramkę do zbierania elementów bezużytecznych (i ponownie mówię, że JInternalFramepowinieneś wywołać dokładnie ten sam problem).

Dużo napisałem i czuję, że mógłbym pisać więcej. W każdym razie mam nadzieję, że nie zostaniesz odrzucony po prostu dlatego, że jest to niepopularna opinia. Pytanie jest oczywiście cenne i mam nadzieję, że udzieliłem cennej odpowiedzi, nawet jeśli nie jest to powszechna opinia.

Doskonałym przykładem wielu ramek / pojedynczego dokumentu na ramkę ( SDI ) vs. pojedynczej ramki / wielu dokumentów na ramkę ( MDI ) jest Microsoft Excel. Niektóre zalety MDI:

• możliwe jest posiadanie kilku okien w kształcie innym niż prostokątny - aby nie ukrywały pulpitu lub innego okna przed innym procesem (np. przeglądarką internetową)
• możliwe jest otwarcie okna z innego procesu na jednym oknie programu Excel podczas pisania w drugim oknie programu Excel - przy pomocy MDI próba pisania w jednym z wewnętrznych okien spowoduje skupienie się na całym oknie programu Excel, stąd ukrywanie okna przed innym procesem
• możliwe jest posiadanie różnych dokumentów na różnych ekranach, co jest szczególnie przydatne, gdy ekrany nie mają tej samej rozdzielczości

SDI (interfejs jednego dokumentu, tzn. Każde okno może mieć tylko jeden dokument):

MDI (interfejs wielu dokumentów, tzn. Każde okno może zawierać wiele dokumentów):

Chciałbym odeprzeć argument „nieprzyjazny dla użytkownika” przykładem, w który właśnie byłem zaangażowany.

W naszej aplikacji mamy okno główne, w którym użytkownicy uruchamiają różne „programy” jako osobne zakładki. W miarę możliwości staraliśmy się zachować naszą aplikację w tym pojedynczym oknie.

Jeden z uruchamianych przez nich programów przedstawia listę raportów wygenerowanych przez system, a użytkownik może kliknąć ikonę w każdym wierszu, aby otworzyć okno dialogowe podglądu raportów. Ta przeglądarka pokazuje ekwiwalent pionowej / poziomej strony A4 w raporcie, więc użytkownicy lubią to okno, które jest dość duże, prawie wypełniając ekrany.

Kilka miesięcy temu zaczęliśmy otrzymywać żądania od naszych klientów, aby te okna przeglądarki raportów były modelowe, aby mogły mieć jednocześnie otwartych wiele raportów.

Przez pewien czas opierałem się tej prośbie, ponieważ nie sądziłem, że to dobre rozwiązanie. Jednak zmieniłem zdanie, gdy dowiedziałem się, jak użytkownicy radzą sobie z tym „brakiem” naszego systemu.

Otwierali przeglądarkę, używając funkcji „Zapisz jako”, aby zapisać raport jako plik PDF w określonym katalogu, używając Acrobat Reader do otwarcia pliku PDF, a następnie zrobiliby to samo z następnym raportem. Mają wiele czytników Acrobat działających z różnymi danymi wyjściowymi raportów, które chcieli przejrzeć.

Więc ustąpiłem i uczyniłem widza modelką. Oznacza to, że każda przeglądarka ma ikonę paska zadań.

Kiedy najnowsza wersja została im wydana w zeszłym tygodniu, przytłaczającą odpowiedzią jest to, że UWIELBIAJĄ to. To jedno z naszych najpopularniejszych najnowszych ulepszeń systemu.

Więc mów dalej i powiedz użytkownikom, że to, czego chcą, jest złe, ale ostatecznie nie zrobi ci żadnych przysług.

NIEKTÓRE UWAGI:

• Wydaje się, że najlepszą praktyką jest używanie JDialog w tych modelowych oknach
• Użyj konstruktorów, które używają argumentu nowego ModalityTypezamiast logicznego modal. Dzięki temu w tych oknach dialogowych pojawia się ikona paska zadań.
• W przypadku dialogów niemodalnych przekaż konstruktorowi zerowy element nadrzędny, ale zlokalizuj je względem okna „nadrzędnego”.
• Wersja 6 Java na Windows ma błąd, który oznacza, że ​​twoje główne okno może stać się „zawsze na wierzchu” bez twojej wiedzy. Zaktualizuj do wersji 7, aby to naprawić

Zrób jInternalFrame w ramce głównej i uczyń ją niewidoczną. Następnie możesz użyć go do dalszych wydarzeń.

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

Minęło trochę czasu od ostatniego dotknięcia huśtawki, ale generalnie jest to zła praktyka, aby to zrobić. Niektóre z głównych wad, które przychodzą na myśl:

• Jest to droższe: będziesz musiał przydzielić znacznie więcej zasobów, aby narysować JFrame niż inny rodzaj kontenera okien, taki jak Dialog lub JInternalFrame.

• Nie jest przyjazny dla użytkownika: Nie jest łatwo nawigować w grupie JFrame sklejonych razem, będzie wyglądać, jakby twoja aplikacja była zbiorem niespójnych i źle zaprojektowanych aplikacji.

• Jest łatwy w użyciu JInternalFrame Jest to rodzaj retoryczny, teraz jest o wiele łatwiejszy i inni ludzie mądrzejsi (lub z więcej wolnego czasu) niż my już przemyśleli wzorzec Desktop i JInternalFrame, więc polecam go użyć.

Zdecydowanie zła praktyka. Jednym z powodów jest to, że nie jest zbyt „przyjazny dla użytkownika”, ponieważ każdy JFramepokazuje nową ikonę paska zadań. Kontrolowanie wielu JFrames sprawi, że wyrwiesz włosy.

Osobiście użyłbym JEDNEJ JFramedla twojego rodzaju aplikacji. Metody wyświetlania wielu rzeczy zależą od Ciebie, jest ich wiele. CanvasES JInternalFrame, CardLayoutnawet JPanels ewentualnie.

Wiele obiektów JFrame = Ból, kłopoty i problemy.

Myślę, że używanie wielu Jframes nie jest dobrym pomysłem.

Zamiast tego możemy użyć JPanelwięcej niż jednego lub więcej JPanelw tym samym JFrame.

Możemy również przełączać się między tymi JPanel. Daje nam to swobodę wyświetlania więcej niż rzeczy na stronie JFrame.

Dla każdego z nich JPanelmożemy zaprojektować różne rzeczy, a wszystko to JPanelmoże być wyświetlane pojedynczo JFrame.

Aby przełączać się między tym JPanel, a korzystanie JMenuBarz JMenuItemsdla każdego JPanellub „JButton for eachJPanel`.

Więcej niż jeden JFramenie jest dobrą praktyką, ale nie ma nic złego, jeśli chcemy więcej niż jednego JFrame.

Ale lepiej jest zmienić jeden JFramedla naszych różnych potrzeb niż mieć wiele JFrames.

Jeśli ramki będą tego samego rozmiaru, dlaczego nie utworzyć ramki i przekazać ją jako odniesienie do niej.

Po przejściu ramki możesz zdecydować, jak ją wypełnić. To tak, jakby mieć metodę obliczania średniej z zestawu liczb. Czy tworzysz tę metodę w kółko?

Nie jest to dobra praktyka, ale nawet jeśli chcesz jej użyć, możesz użyć wzorca singletonu jako dobrego. Używałem wzorców singletonów w większości moich projektów, które są dobre.