Використання декількох фреймів JF: хороша чи погана практика? [зачинено]

Я розробляю програму, яка відображає зображення та відтворює звуки з бази даних. Я намагаюся вирішити, використовувати чи не використовувати окремий JFrame для додавання зображень до бази даних із графічного інтерфейсу.

Мені просто цікаво, чи правильно використовувати декілька вікон JFrame?

Мені просто цікаво, чи правильно використовувати декілька JFrames?

Погана (погана, погана) практика.

• Непривітний для користувачів: Користувач бачить кілька значків на панелі завдань, коли очікує побачити лише одну. Плюс побічні ефекти проблем кодування ..
• Кошмар, щоб кодувати і підтримувати:
  • Модальний діалог пропонує легку можливість зосередити увагу на зміст цього діалогу - вибрати / виправити / скасувати це, потім продовжити. Кілька кадрів цього не роблять.
  • Діалогове вікно (або плаваюча панель інструментів) з батьком вийде на перший план при натисканні на батьків - вам доведеться реалізувати це у кадрах, якби це було бажане поведінка.

Існує будь-яка кількість способів відображення багатьох елементів в одному графічному інтерфейсі, наприклад:

• CardLayout(коротка демонстрація. ) Добре для:
  1. Показ майстра на зразок діалогів.
  2. Відображення вибору списку, дерева тощо для елементів, які мають пов'язаний компонент.
  3. Переміщення між відсутністю компонента та видимим компонентом.
• JInternalFrame/JDesktopPane зазвичай використовується для ІРС .
• JTabbedPane для груп компонентів.
• JSplitPane Спосіб відображення двох компонентів, значення яких між тим чи іншим (розмір) змінюється залежно від того, що робить користувач.
• JLayeredPane набагато багато .. шаруватих компонентів.
• JToolBarзазвичай містить групи дій або елементів управління. Можна перетягувати навколо GUI або виключати його повністю відповідно до потреб користувача. Як було сказано вище, мінімізувати / відновити відповідно до батьків.
• Як елементи в JList(простий приклад нижче).
• Як вузли в а JTree.
• Вкладені макети .
  

Але якщо ці стратегії не працюють для конкретного випадку використання, спробуйте наступне. Встановіть єдине головне JFrame, потім з'явіться JDialogабо JOptionPaneекземпляри для решти вільно плаваючих елементів, використовуючи кадр як батьківський діалог.

Багато зображень

У цьому випадку, коли декілька елементів є зображеннями, було б краще використовувати один із наведених нижче:

1. Єдиний JLabel(в центрі області прокрутки) для відображення того зображення, яке зацікавило б користувача в цей момент. Як видно в ImageViewer.
   
2. Єдиний ряд JList. Як видно з цієї відповіді . Частина "єдиного ряду" працює лише тоді, коли вони мають однакові розміри. Крім того, якщо ви готові масштабувати зображення під час руху, і всі вони мають однакове співвідношення сторін (наприклад, 4: 3 або 16: 9).

Багаторазовий JFrameпідхід - це те, що я реалізував з моменту початку програмування додатків Swing. Здебільшого я це робив на початку, тому що не знав нічого кращого. Однак , як я дорослий у своєму досвіді та знаннях як розробник, і коли почав читати та поглинати думки багатьох більш досвідчених Java-розробників в Інтернеті, я зробив спробу відійти від багаторазового JFrameпідходу (як у поточних проектах, так і в майбутніх проектах ) тільки для того, щоб зустрітися з ... отримати цей ... опір моїх клієнтів! Коли я почав впроваджувати модальні діалоги для управління «дочірніми» вікнами та JInternalFrames для окремих компонентів, мої клієнти почали скаржитися!Я був дуже здивований, як робив те, що вважав найкращим практиком! Але, як кажуть, "Щаслива дружина - це щасливе життя". Те саме стосується і ваших клієнтів. Звичайно, я підрядник, тому мої кінцеві користувачі мають прямий доступ до мене, розробника, що, очевидно, не є загальним сценарієм.

Отже, я збираюся пояснити переваги багаторазового JFrameпідходу, а також міф про перенапруження деяких мінусів, які представили інші.

1. Кінцева гнучкість у компонуванні - Дозволяючи окремим JFrames, ви даєте кінцевому користувачеві можливість розповсюджуватись та контролювати те, що на його / її екрані. Концепція відчуває себе "відкритою" і не обмежує. Ви втрачаєте це, коли йдете назустріч одній великій JFrameі купі JInternalFrames.
2. Добре працює для дуже модульованих програм - У моєму випадку більшість моїх додатків мають 3–5 великих «модулів», які насправді не мають нічого спільного між собою. Наприклад, один модуль може бути інформаційною панеллю продажів, а один - інформаційною панеллю бухгалтерського обліку. Вони не розмовляють між собою чи ні про що. Однак виконавчий директор може захотіти відкрити і те, і це, оскільки окремі кадри на панелі завдань полегшують його життя.
3. Кінцевим користувачам полегшується посилання на зовнішній матеріал - Одного разу у мене виникла така ситуація: у моєму додатку було "переглядач даних", з якого можна було натиснути "Додати нове", і це відкриє екран для введення даних. Спочатку обидва були JFrameс. Однак я хотів, щоб на екрані введення даних JDialogбув батько, чиїм батьком був переглядач даних. Я вніс зміни, і одразу отримав дзвінок від кінцевого користувача, який сильно покладався на те, що він може мінімізувати або закрити глядача та тримати редактор відкритим, поки він посилається на іншу частину програми (або веб-сайт, я не хочу не пам’ятаю). Він не на мультимоніторі, тому йому потрібен був діалог вступу, щоб бути першим та чимось іншимпо-друге, із засобом перегляду даних повністю прихованим. Це було неможливо з a, JDialogі, звичайно, було б неможливо і з JInternalFrame. Я зневажливо змінив його назад, щоб він був відокремленим JFramesза його розум, але це навчило мене важливого уроку.
4. Міф: Важко кодувати - Це не так у моєму досвіді. Я не розумію, чому було б легше створити, JInternalFrameніж а JFrame. Насправді, на мій досвід, JInternalFramesпропонуйте набагато меншу гнучкість. Я розробив систематичний спосіб роботи з відкриттям і закриттям JFrames у своїх додатках, який справді добре працює. Я керую кадром майже повністю з самого коду кадру; створення нового кадру, SwingWorkerякий контролює пошук даних у фонових потоках та GUI-коді на EDT, відновлення / виведення на фронт кадру, якщо користувач намагається відкрити його двічі і т. д. Все, що вам потрібно, щоб відкрити мій JFrames - це виклик публічного статичного методу open()та відкритого методу в поєднанні з awindowClosing() подія обробляє решту (чи вже кадр відкритий? він не відкритий, але завантажується? тощо). Я зробив цей підхід шаблоном, тому його не важко реалізувати для кожного кадру.
5. Міф / недоведений: ресурс важкий - я хотів би побачити деякі факти, що стоять за цим умоглядним твердженням. Хоча, можливо, ви могли б сказати, що JFrameпотрібно більше місця, ніж а JInternalFrame, навіть якщо ви відкриєте 100 JFrameс, скільки ще ресурсів ви б насправді споживали? Якщо ваше занепокоєння є витоком пам’яті через ресурси: виклик dispose()звільняє всі ресурси, які використовує кадр для збору сміття (і, знову ж таки, я кажу, a JInternalFrameповинен викликати саме таку проблему).

Я багато писав і відчуваю, що можу написати більше. У будь-якому випадку, я сподіваюся, що я не отримаю голосу просто тому, що це непопулярна думка. Питання явно цінне, і я сподіваюся, що я дав цінну відповідь, навіть якщо це не є загальною думкою.

Чудовим прикладом декількох кадрів / одного документа на кадр ( SDI ) проти одного кадру / декількох документів на кадр ( MDI ) є Microsoft Excel. Деякі переваги MDI:

• можливо мати кілька вікон у прямокутній формі - щоб вони не приховували робочий стіл чи інше вікно від іншого процесу (наприклад, веб-браузера)
• можливо відкрити вікно з іншого процесу над одним вікном Excel під час запису у другому вікні Excel - за допомогою MDI, намагаючись записати в одне із внутрішніх вікон, буде зосереджено все вікно Excel, отже, приховування вікна від іншого процесу
• можна мати різні документи на різних екранах, що особливо корисно, коли екрани не мають однакової роздільної здатності

SDI (інтерфейс з одним документом, тобто кожне вікно може мати лише один документ):

MDI (Інтерфейс з декількома документами, тобто кожне вікно може мати декілька документів):

Я хотів би протиставити аргумент "непривітний до користувачів" із прикладом, з яким я щойно брав участь.

У нашому додатку у нас є головне вікно, де користувачі виконують різні 'програми' як окремі вкладки. Наскільки це можливо, ми намагалися зберегти наше додаток до цього єдиного вікна.

Одна з «програм», яку вони виконують, представляє список звітів, створених системою, і користувач може натиснути на піктограму в кожному рядку, щоб відкрити діалогове вікно перегляду звітів. Цей глядач показує еквівалент портретної / альбомної сторінки формату A4 у звіті, тому користувачам подобається, що це вікно є досить великим, майже заповнюючи свої екрани.

Кілька місяців тому ми почали отримувати запити від наших клієнтів, щоб зробити ці вікна перегляду звітів без режиму, щоб у них було відкрито кілька звітів одночасно.

Якийсь час я протистояв цьому запиту, оскільки не вважав, що це вдале рішення. Однак мій погляд змінився, коли я дізнався, як користувачі подолали цей «недолік» нашої системи.

Вони відкривали програму перегляду, використовуючи інструмент "Зберегти як", щоб зберегти звіт як PDF у певний каталог, використовуючи програму Acrobat Reader, щоб відкрити файл PDF, і тоді вони зробили б те саме з наступним звітом. У них було б кілька читачів Acrobat, які працюють із різними результатами звітів, які вони хотіли переглянути.

Тож я поступився і зробив глядача без режиму. Це означає, що кожен глядач має значок панелі завдань.

Коли остання версія була випущена їм минулого тижня, переважна відповідь від них полягає в тому, що вони ЛЮБИТЬ її. Це одне з найпопулярніших останніх удосконалень у системі.

Тож ви продовжуєте і кажете своїм користувачам, що те, що вони хочуть, є поганим, але в кінцевому рахунку це не принесе вам ніяких прихильностей.

ДЕЯКІ ПРИМІТКИ:

• Здається, найкраща практика використовувати JDialog для цих безмобільних вікон
• Використовуйте конструктори, які використовують новий, ModalityTypeа не булевий modalаргумент. Саме це дає цим діалогам значок панелі завдань.
• Для діалогових діалогових режимів переведіть конструктор нульових батьків, але знайдіть їх відносно вікна "батьків".
• У версії 6 Java для Windows є помилка, що означає, що ваше головне вікно може стати "завжди зверху", не повідомляючи про це. Перейдіть до версії 7, щоб виправити це

Зробіть jInternalFrame в основний кадр і зробіть його невидимим. Тоді ви можете використовувати його для подальших подій.

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

Минуло час, коли я останній раз торкаюся гойдалки, але загалом це погана практика. Деякі основні недоліки, які виникають на увазі:

• Це дорожче: вам доведеться виділити набагато більше ресурсів, щоб намалювати JFrame такий інший тип віконного контейнера, як Dialog або JInternalFrame.

• Не зручно для користувачів: Непросто орієнтуватися на купу злитого JFrame, це буде виглядати так, що ваша програма - це набір програм, несумісних та погано оформлений.

• Використовувати JInternalFrame дуже просто. Це дуже просто, але тепер простіше, а інші люди розумніші (або з більшим вільним часом), ніж ми вже продумували шаблон робочого столу та JInternalFrame, тому я рекомендую використовувати його.

Погана практика, безумовно. Однією з причин є те, що це не дуже "зручно" для того, що кожен JFrameпоказує новий значок панелі завдань. Якщо керувати кількома JFrameелементами, ви змурите волосся.

Особисто я хотів би використовувати ОДИН JFrameдля вашого типу додатків. Методів відображення кількох речей залежить від вас, існує багато. Canvasес, JInternalFrame, CardLayoutнавіть JPanelS можливо.

Кілька об'єктів JFrame = Біль, неприємності та проблеми.

Я думаю, що використовувати кілька Jframes - це не дуже гарна ідея.

Натомість ми можемо використовувати JPanels більше ніж одне чи більше JPanelв одному і тому ж JFrame.

Також ми можемо перемикатися між цим JPanels. Таким чином, це дає нам свободу відображати більше, ніж на речі в JFrame.

Для кожного JPanelми можемо розробити різні речі, і все це JPanelможе відображатися по одній окремо JFrame.

Для перемикання між цим JPanelами використання JMenuBarз JMenuItemsдля кожного JPanelабо «JButton for eachJPanel`.

Більше одного JFrameне є хорошою практикою, але немає нічого поганого, якщо ми хочемо більше одного JFrame.

Але краще змінити один JFrameдля наших різних потреб, а не мати кілька JFrames.

Якщо кадри будуть однакового розміру, чому б не створити кадр і передати кадр тоді як посилання на нього.

Після проходження кадру ви можете вирішити, як його заповнити. Це було б як би мати метод для обчислення середнього набору цифр. Чи створювали б ви метод знову і знову?

Це не є хорошою практикою, але, хоча ви хочете скористатись нею, ви можете використовувати однотонний зразок як свою корисну. Я використовував одиночні моделі в більшості своїх проектів.