Я разрабатываю приложение, которое отображает изображения и воспроизводит звуки из базы данных. Я пытаюсь решить, использовать ли отдельный JFrame для добавления изображений в базу данных из графического интерфейса.
Мне просто интересно, полезно ли использовать несколько окон JFrame?
Мне просто интересно, полезно ли использовать несколько JFrames?
Плохая (плохая, плохая) практика.
Существует несколько способов отображения многих элементов в одном графическом интерфейсе, например:
CardLayout (короткая демонстрация.). Хорош для:
JInternalFrame/JDesktopPane обычно используется для MDI.JTabbedPane для групп компонентов.JSplitPane Способ отображения двух компонентов, значение которых между тем или другим (размером) изменяется в зависимости от того, что пользователь делает.JLayeredPane далеко не все хорошо.. слоистые компоненты.JToolBar обычно содержит группы действий или элементов управления. Его можно перетаскивать по графическому интерфейсу или полностью выполнять в соответствии с потребностями пользователя. Как упоминалось выше, минимизируется/восстанавливается в соответствии с родителем, выполняющим это.JList (простой пример ниже).JTree.Но если эти стратегии не работают для конкретного случая использования, попробуйте следующее. Установите один основной JFrame, затем JDialog или JOptionPane для остальных элементов с плавающей запятой, используя фрейм как родительский для диалогов.
В этом случае, когда множественные элементы являются изображениями, было бы лучше использовать одно из следующих:
JLabel (с центром в области прокрутки), чтобы отобразить любое изображение, которое пользователь интересует в данный момент. Как видно из ImageViewer. 
JList. Как видно в этом ответе. Часть "одной строки" работает только в том случае, если они имеют одинаковые размеры. Альтернативно, если вы готовы масштабировать изображения "на лету", и они имеют одинаковое соотношение сторон (например, 4: 3 или 16: 9). 
Множественный подход JFrame был тем, что я реализовал с тех пор, как начал программировать Swing-приложения. По большей части я сделал это в начале, потому что я не знал ничего лучшего. Однако, когда я созрел в своем опыте и знаниях как разработчик и начал читать и воспринимать мнения многих более опытных разработчиков Java, я сделал попытку сменить от множественного подхода JFrame (как в текущих проектах, так и в будущих проектах) только для удовлетворения... получить это... сопротивление от моих клиентов! Когда я начал внедрять модальные диалоги для управления "дочерними" окнами и JInternalFrame для отдельных компонентов, мои клиенты начали жаловаться!. Я был очень удивлен, так как я делал то, что считал лучшим. Но, как говорится, "счастливая жена - счастливая жизнь". То же самое касается ваших клиентов. Конечно, я являюсь подрядчиком, поэтому мои конечные пользователи имеют прямой доступ ко мне, разработчику, что явно не является общим сценарием.
Итак, я собираюсь объяснить преимущества множественного подхода JFrame, а также миф-бюст некоторых из минусов, которые другие представили.
JFrame s, вы предоставляете конечному пользователю возможность распространять и контролировать, что на его экране. Концепция чувствует себя "открытой" и не сжимающей. Вы теряете это, когда идете на один большой JFrame и кучу JInternalFrame s.JFrame s. Тем не менее, я хотел, чтобы экран ввода данных был JDialog, родителем которого был просмотрщик данных. Я внес изменения, и сразу же я получил звонок от конечного пользователя, который в значительной степени полагался на то, что он мог свести к минимуму или закрыть просмотрщик и сохранить редактор открытым, пока он ссылался на другую часть программы (или на веб-сайт, я не помню). Он не на мультимониторе, поэтому ему нужно было, чтобы диалог ввода был первым, а что-то еще вторым, а просмотрщик данных полностью скрыт. Это было невозможно при JDialog и, конечно же, было бы невозможно с JInternalFrame. Я с неохотой изменил его на то, чтобы быть отдельным JFrames за его здравомыслие, но он научил меня важному уроку.JInternalFrame, чем a JFrame. На самом деле, по моему опыту, JInternalFrames предлагают гораздо меньшую гибкость. Я разработал систематический способ обработки открытия и закрытия JFrame в моих приложениях, которые действительно хорошо работают. Я управляю рамкой почти полностью из самого кода фрейма; создание нового фрейма SwingWorker, который управляет извлечением данных по фоновым потокам и графическим интерфейсом на EDT, восстанавливает/выводит на передний план фрейм, если пользователь пытается открыть его дважды, и т.д. Все, что вам нужно открыть JFrame вызывает общедоступный статический метод open(), а метод open в сочетании с событием windowClosing() обрабатывает остальное (уже открыт фрейм? он не открыт, но загружается? и т.д.). Я сделал такой подход шаблон, поэтому для каждого кадра не сложно реализовать.JFrame требуется больше места, чем JInternalFrame, даже если вы откроете 100 JFrame s, сколько еще ресурсов вы действительно будете потреблять? Если ваша проблема связана с утечками памяти из-за ресурсов: вызов dispose() освобождает все ресурсы, используемые фреймом для сбора мусора (и, опять же, я говорю, JInternalFrame должен ссылаться на ту же проблему).Я написал много, и я чувствую, что могу написать больше. В любом случае, я надеюсь, что я не уйду - проголосовали просто потому, что это непопулярное мнение. Вопрос явно ценный, и я надеюсь, что предоставил ценный ответ, даже если это не общее мнение.
Отличный пример нескольких фреймов/одного документа на кадр (SDI) против одного кадра/нескольких документов на кадр (MDI) - это Microsoft Excel. Некоторые преимущества MDI:
SDI (интерфейс одного документа, то есть каждое окно может иметь только один документ):
MDI (интерфейс с несколькими документами, то есть каждое окно может иметь несколько документов):
Я бы хотел встретить аргумент "не дружественный пользователю" с примером, с которым я только что занимался.
В нашем приложении у нас есть главное окно, где пользователи запускают различные "программы" в виде отдельных вкладок. Насколько это возможно, мы пытались сохранить наше приложение в этом одиночном окне.
Одна из запущенных "программ" представляет список отчетов, которые были сгенерированы системой, и пользователь может щелкнуть по значку в каждой строке, чтобы открыть диалог просмотра отчетов. Этот просмотрщик показывает эквивалент страницы (-ов) портрета/пейзажа A4, поэтому пользователям нравится это окно, чтобы быть довольно большим, почти заполняя их экраны.
Несколько месяцев назад мы начали получать запросы от наших клиентов, чтобы сделать эти окна просмотра отчетов немыслимыми, чтобы они могли одновременно открывать несколько отчетов.
Некоторое время я сопротивлялся этому запросу, так как не думал, что это хорошее решение. Тем не менее, мой ум был изменен, когда я узнал, как пользователи обошли этот "недостаток" нашей системы.
Они открывали средство просмотра, используя средство "Сохранить как", чтобы сохранить отчет в формате PDF в определенном каталоге, используя Acrobat Reader для открытия PDF файла, а затем они будут делать то же самое со следующим отчетом. У них будет несколько Acrobat Readers, работающих с различными выходами отчета, которые они хотели бы посмотреть.
Итак, я смягчился и сделал зрителя немодальным. Это означает, что у каждого зрителя есть значок панели задач.
Когда последняя версия была выпущена им на прошлой неделе, подавляющий ответ от них заключается в том, что они ЛЮБЯТ это. Это было одно из наших самых популярных последних усовершенствований системы.
Итак, вы говорите своим пользователям, что то, что они хотят, плохо, но в конечном итоге это не принесет вам никакой пользы.
НЕКОТОРЫЕ ПРИМЕЧАНИЯ:
ModalityType, а не логический аргумент modal. Это то, что дает этим диалогам значок панели задач.Сделайте jInternalFrame в основной фрейм и сделайте его невидимым. Затем вы можете использовать его для дальнейших событий.
jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
Прошло некоторое время, так как в последний раз я прикасаюсь к качелям, но в целом это плохая практика для этого. Некоторые из основных недостатков, которые приходит на ум:
Это более дорого: вам придется выделять больше ресурсов, чтобы рисовать JFrame в другом виде контейнера окна, например Dialog или JInternalFrame.
Не является дружественным пользователю: Нелегко перейти в кучу JFrame, сложенного вместе, это будет выглядеть так, как ваше приложение представляет собой набор приложений, непоследовательных и плохо оформленных.
Легко использовать JInternalFrame. Это своего рода реторика, теперь это намного проще, а другие люди умнее (или с большим количеством свободного времени), чем мы уже рассмотрели рабочий стол и шаблон JInternalFrame, поэтому я бы рекомендовал его использовать.
Плохая практика. Одна из причин заключается в том, что он не очень удобен для пользователя, поскольку каждый JFrame показывает новый значок панели задач. Управление несколькими JFrame приведет к удалению ваших волос.
Лично я использовал бы ONE JFrame для вашего вида приложения. Способы отображения нескольких вещей зависит от вас, их много. Canvas es, JInternalFrame, CardLayout, даже JPanel возможно.
Несколько объектов JFrame = боль, проблемы и проблемы.
Я думаю, что использование нескольких Jframe не является хорошей идеей.
Вместо этого мы можем использовать JPanel более одного или более JPanel в том же Jframe.
Также мы можем переключаться между этими JPanel s. Это дает нам свободу отображать больше, чем на вещи в Jframe.
Для каждого JPanel мы можем создавать разные вещи, и все это JPanel может отображаться на одном Jframe по одному за раз.
Для переключения между этим JPanel используйте JMenuBar с JMenuItems для каждого JPanel или 'JButton for each JPanel`.
Более одного Jframe не является хорошей практикой, но нет ничего плохого, если мы хотим больше одного Jframe.
Но лучше изменить один Jframe для наших разных потребностей, а не иметь несколько Jframe s.
Если кадры будут иметь одинаковый размер, почему бы не создать кадр и передать кадр, а затем вместо него ссылаться на него.
Когда вы прошли кадр, вы можете решить, как его заполнить. Это было бы похоже на метод вычисления среднего числа фигур. Не могли бы вы создать метод снова и снова?
Это не очень хорошая практика, но даже если вы хотите ее использовать, вы можете использовать одноэлементный паттерн как хороший. Я использовал шаблоны singleton в большинстве своих проектов, это хорошо.