it-swarm.com.ru

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

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

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

516
Peddler

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

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

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

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

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

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

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

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

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

435
Andrew Thompson

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

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

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

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

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

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

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

enter image description here

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

enter image description here

197
ryvantage

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

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

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

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

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

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

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

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

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

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

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

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

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
19
Virendra Singh Rathore

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

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

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

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

18
Necronet

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

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

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

10
Matt Dawsey

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

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

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

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

Для переключения между этим JPanels используйте JMenuBar с JMenuItems для каждого JPanelor 'JButtonfor eachJPanel`.

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

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

7
Lijo

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

Когда вы прошли кадр, вы можете решить, как его заполнить. Это было бы похоже на метод расчета среднего числа фигур. Будете ли вы создавать метод снова и снова?

5
Keith Spriggs

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

4
arunjoseph