Использование нескольких JFrames: хорошая или плохая практика? [закрыто]

Question

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

Мне просто интересно, стоит ли использовать несколько окон JFrame?

Answer 1

Мне просто интересно, стоит ли использовать несколько JFrames?

Плохая (плохая, плохая) практика.

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

---

Существует множество способов отображения множества элементов в одном графическом интерфейсе, например:

• CardLayout(короткая демонстрация. ) Хорош для:
  1. Отображение диалоговых окон, подобных мастеру.
  2. Отображение списка, дерева и т. Д. Выбора для элементов, которые имеют связанный компонент.
  3. Переключение между отсутствием компонента и видимым компонентом.
• JInternalFrame/JDesktopPane обычно используется для MDI .
• JTabbedPane для групп компонентов.
• JSplitPane Способ отображения двух компонентов, важность одного из которых (размер) зависит от того, что делает пользователь.
• JLayeredPane много хорошо .. слоистых компонентов.
• JToolBarобычно содержит группы действий или элементов управления. Может быть перемещен по графическому интерфейсу или полностью отключен в соответствии с потребностями пользователя. Как упоминалось выше, будет минимизировать / восстанавливать в зависимости от того, что делает родитель.
• Как элементы в JList(простой пример ниже).
• Как узлы в JTree.
• Вложенные макеты .
  
  

Но если эти стратегии не работают для конкретного варианта использования, попробуйте следующее. Создайте единую главную JFrame, затем создайте JDialogили JOptionPaneпоявятся экземпляры для остальных свободно плавающих элементов, используя фрейм как родительский для диалогов.

Много изображений

В этом случае, когда несколько элементов являются изображениями, было бы лучше использовать любое из следующего:

1. Единичный JLabel(в центре области прокрутки) для отображения любого изображения, которое интересует пользователя в данный момент. Как видно из ImageViewer.
   
   
2. Один ряд JList. Как видно из этого ответа . «Однорядная» часть работает только в том случае, если все они имеют одинаковые размеры. В качестве альтернативы, если вы готовы масштабировать изображения на лету, и все они имеют одинаковое соотношение сторон (например, 4: 3 или 16: 9).

Answer 2

Множественный JFrameподход я реализовал с тех пор, как начал программировать приложения Swing. По большей части, я делал это вначале, потому что не знал ничего лучшего. Однако по мере того , как я созревал в своем опыте и знаниях как разработчик, и когда я начал читать и воспринимать мнения очень многих более опытных разработчиков Java в Интернете, я сделал попытку отойти от множественного JFrameподхода (как в текущих проектах, так и в будущих ) только для того, чтобы встретить ... получить это ... сопротивление от моих клиентов! Когда я начал реализовывать модальные диалоги для управления «дочерними» окнами и JInternalFrameотдельными компонентами, мои клиенты начали жаловаться! Я был очень удивлен, так как делал то, что считал лучшим! Но, как говорится, «счастливая жена - счастливая жизнь». То же самое и с вашими клиентами. Конечно, я подрядчик, поэтому мои конечные пользователи имеют прямой доступ ко мне, разработчику, что, очевидно, не является обычным сценарием.

Итак, я собираюсь объяснить преимущества множественного JFrameподхода, а также развенчать мифы о некоторых недостатках, представленных другими.

1. Максимальная гибкость в макете - разрешая отдельные JFrameэлементы, вы даете конечному пользователю возможность распределять и контролировать то, что находится на его / ее экране. Концепция кажется «открытой» и не стесняющей. Вы теряете это, когда идете к одному большому JFrameи кучке JInternalFrames.
2. Хорошо работает для очень модульных приложений - в моем случае большинство моих приложений имеют 3-5 больших «модулей», которые на самом деле не имеют никакого отношения друг к другу. Например, один модуль может быть панелью управления продажами, а другой - панелью учета. Они не разговаривают друг с другом или что-то в этом роде. Однако руководитель может захотеть открыть оба, и они, будучи отдельными фреймами на панели задач, облегчают ему жизнь.
3. Позволяет конечным пользователям ссылаться на сторонние материалы - Однажды у меня была такая ситуация: в моем приложении было «средство просмотра данных», в котором вы могли нажать «Добавить новый», и он открывал экран ввода данных. Изначально оба были JFrames. Однако я хотел, чтобы экран ввода данных был экраном JDialog, родительский элемент которого был средством просмотра данных. Я внес изменения, и сразу же мне позвонил конечный пользователь, который очень полагался на то, что он может свернуть или закрыть средство просмотра и оставить редактор открытым, пока он ссылается на другую часть программы (или веб-сайт, я не не помню). Он не работает с несколькими мониторами, поэтому ему нужно, чтобы диалоговое окно ввода было первым, а что-то еще вторым, а средство просмотра данных было полностью скрыто. Это было невозможно с a JDialogи, конечно же, было невозможно с a JInternalFrame. Я неохотно изменил его обратно на отдельный из- JFramesза его рассудка, но это преподало мне важный урок.
4. Миф: Трудно кодировать - по моему опыту, это не так. Я не понимаю, почему было бы легче создать, JInternalFrameчем JFrame. На самом деле, по моему опыту, они JInternalFramesпредлагают гораздо меньшую гибкость. Я разработал систематический способ обработки открытий и закрытий JFrameв своих приложениях, который действительно хорошо работает. Я почти полностью контролирую фрейм из самого кода фрейма; создание новых фреймов, SwingWorkerкоторые управляют извлечением данных в фоновых потоках и кодом графического интерфейса пользователя в EDT, восстанавливают / выводят на передний план фрейм, если пользователь пытается открыть его дважды, и т. д. Все, что вам нужно, чтобы открыть мои JFrameфреймы, - это вызвать общедоступный статический метод, open()а открытый метод в сочетании с windowClosing()событием обрабатывает все остальное (фрейм уже открыт? он не открыт, а загружается? и т. д.) Я сделал этот подход шаблоном, поэтому его несложно реализовать для каждого фрейма .
5. Миф / недоказанность: много ресурсов - я хотел бы увидеть некоторые факты, стоящие за этим спекулятивным заявлением. Хотя, возможно, вы могли бы сказать, что для a JFrameтребуется больше места, чем для a JInternalFrame, даже если вы откроете 100 JFrameс, сколько еще ресурсов вы действительно потребляете? Если вас беспокоит утечка памяти из-за ресурсов: вызов dispose()освобождает все ресурсы, используемые фреймом для сборки мусора (и, опять же, я говорю, что a JInternalFrameдолжен вызывать точно такую ​​же проблему).

Я много писал и чувствую, что могу написать еще. В любом случае, я надеюсь, что меня не проголосуют против только потому, что это непопулярное мнение. Это явно ценный вопрос, и я надеюсь, что дал ценный ответ, даже если это не является общепринятым мнением.

Отличным примером использования нескольких кадров / одного документа в кадре ( SDI ) по сравнению с одним кадром / несколькими документами в кадре ( MDI ) является Microsoft Excel. Некоторые из преимуществ MDI:

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

SDI (однодокументный интерфейс, т. Е. В каждом окне может быть только один документ):

MDI (Многодокументный интерфейс, т.е. в каждом окне может быть несколько документов):

Answer 3

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

В нашем приложении у нас есть главное окно, в котором пользователи запускают различные «программы» в виде отдельных вкладок. Насколько это возможно, мы пытались сохранить наше приложение в этом едином окне.

Одна из запускаемых ими «программ» представляет список отчетов, которые были созданы системой, и пользователь может щелкнуть значок в каждой строке, чтобы открыть диалоговое окно средства просмотра отчетов. Эта программа просмотра показывает эквивалент страниц отчета A4 в портретной / альбомной ориентации, поэтому пользователям нравится, что это окно довольно большое, почти заполняющее их экраны.

Несколько месяцев назад мы начали получать запросы от наших клиентов, чтобы сделать эти окна просмотра отчетов немодальными, чтобы в них можно было одновременно открывать несколько отчетов.

Некоторое время я сопротивлялся этой просьбе, так как не думал, что это хорошее решение. Однако мое мнение изменилось, когда я узнал, как пользователи обходят этот «недостаток» нашей системы.

Они открывали программу просмотра, используя функцию «Сохранить как», чтобы сохранить отчет в формате PDF в определенном каталоге, используя Acrobat Reader для открытия файла PDF, а затем они делали то же самое со следующим отчетом. У них будет несколько запущенных программ Acrobat Reader с различными выходными данными отчетов, которые они захотят просмотреть.

Так что я уступил и сделал зрителя немодальным. Это означает, что у каждого средства просмотра есть значок на панели задач.

Когда последняя версия была выпущена для них на прошлой неделе, подавляющее большинство от них ответили, что им она нравится. Это было одно из наших самых популярных недавних улучшений системы.

Итак, вы говорите своим пользователям, что то, чего они хотят, - это плохо, но в конечном итоге это не принесет вам никакой пользы.

НЕКОТОРЫЕ ЗАМЕЧАНИЯ:

• Кажется, лучше всего использовать JDialog для этих немодальных окон.
• Используйте конструкторы, которые используют новый, ModalityTypeа не логический modalаргумент. Это то, что придает этим диалогам значок на панели задач.
• Для немодальных диалогов передайте конструктору нулевой родительский элемент, но располагайте их относительно их «родительского» окна.
• Версия 6 Java в Windows содержит ошибку, которая означает, что ваше главное окно может стать «всегда наверху» без вашего ведома. Обновите до версии 7, чтобы исправить это

Answer 4

Сделайте jInternalFrame основным фреймом и сделайте его невидимым. Затем вы можете использовать его для дальнейших мероприятий.

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

Answer 5

Прошло много времени с тех пор, как я последний раз касался качелей, но в целом это плохая практика. Некоторые из основных недостатков, которые приходят на ум:

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

• Не удобно для пользователя: нелегко перейти к кучке JFrame, склеенных вместе, это будет выглядеть так, как будто ваше приложение представляет собой набор несовместимых и плохо спроектированных приложений.

• JInternalFrame легко использовать. Это своего рода реторика, теперь это намного проще, а другие люди умнее (или имеют больше свободного времени), чем мы, уже думали через шаблон Desktop и JInternalFrame, поэтому я бы рекомендовал его использовать.

Answer 6

Определенно плохая практика. Одна из причин заключается в том, что он не очень «удобен для пользователя» из-за того, что каждый JFrameпоказывает новый значок на панели задач. Управление несколькими JFrames заставит вас рвать волосы.

Лично я бы использовал ОДИН JFrameдля вашего вида приложений. Способы отображения нескольких вещей зависит от вас, их много. Canvasэс, JInternalFrame, CardLayoutдаже JPanelS возможно.

Несколько объектов JFrame = боль, проблемы и проблемы.

Answer 7

Я думаю, что использование нескольких Jframes - не лучшая идея.

Вместо этого мы можем использовать JPanelболее одного или нескольких JPanelв одном JFrame.

Также мы можем переключаться между этими JPanels. Таким образом, это дает нам возможность отображать больше, чем просто на предмете в JFrame.

Для каждого JPanelмы можем разрабатывать разные вещи, и все это JPanelможно отображать на JFrameодном по отдельности.

Для переключения между этим JPanelами использования JMenuBarс JMenuItemsдля каждого JPanelили «JButton for eachJPanel`.

Использование более одного JFrame- не лучший вариант, но нет ничего плохого, если мы хотим более одного JFrame.

Но лучше изменить один JFrameдля наших разных нужд, чем иметь несколько JFrames.

Answer 8

Если кадры будут одинакового размера, почему бы вместо этого не создать кадр и не передать его в качестве ссылки на него.

После прохождения кадра вы можете решить, как его заполнить. Это было бы похоже на метод вычисления среднего числа чисел. Вы бы создавали этот метод снова и снова?

Answer 9

Это не очень хорошая практика, но даже если вы хотите ее использовать, вы можете использовать шаблон singleton в качестве пользы. Я использовал шаблоны singleton в большинстве своих проектов, и это хорошо.