Java AWT/SWT/Swing: как планировать графический интерфейс?

Ответ 1

Я не большой поклонник разработчиков GUI: они, как правило, генерируют bucket-load кода, который затем блокирует всю вашу команду разработчиков, используя одну среду IDE. Кроме того, этот код часто не читается (проверьте код, сгенерированный при использовании Matisse под Netbeans).

Мои рекомендации по дизайну/отладке графического интерфейса:

• Добавить метод main для каждой реализации панели (или "верхнего уровня" ), позволяя другим разработчикам легко определить, как выглядит компонент.
• Благоприятствуйте использованию Action над ActionListener и зарегистрируйте эти действия с каждым JComponent ActionMap. Это позволяет их "извлекать" и добавлять к другим частям пользовательского интерфейса (например, JToolBar), но при этом их состояние контролируется "владеющим" JComponent (т.е. Свободным соединением).
• Используйте assert, чтобы убедиться, что все изменения компонентов пользовательского интерфейса происходят в потоке Dispatch Event; например assert SwingUtilities.isEventDispatchThread().
• Чтобы отладить странное поведение макета, рассмотрите окраску фона компонента красным цветом!
• Централизовать захват и отчетность событий и исключений рабочего процесса. Например, я обычно реализую класс TaskManager, который зарегистрирован в моей строке состояния пользовательского интерфейса. Любая фоновая обработка (выполняется в SwingWorker s) передается дескриптором Task, созданным TaskManager. Взаимодействие с Задачей (путем вызова setDescription(String), setThrowable(Throwable), cancel()) приводит к обновлению строки состояния. Это также вызывает отображение стеклянной панели для "глобальных" задач... но это все развязано/скрыто от отдельных SwingWorkers.
• Не используйте классы Observer/Observable, а предпочитайте ChangeListener, PropertyChangeListener или собственную собственную реализацию прослушивателя для распространения событий. Observer передает событие Object как событие, заставляя клиентский код проверять тип с помощью instanceof и выполнять downcasts, делая код нечитаемым и делая отношения между классами менее понятными.
• Благодарите за использование JTable над JList даже в ситуациях, когда ваша таблица имеет только один столбец. JList имеет некоторые неприятные функции в своем API, в том числе тот факт, что вам нужно предоставить прототип для правильного вычисления его размера.
• Никогда не используйте DefaultTableModel, поскольку это обычно приводит к тому, что вы сохраняете свои "модельные" данные в двух местах: в ваших реальных бизнес-объектах, а также внутри 2D-массива, на котором сидит DefaultTableModel. Вместо этого просто подкласс AbstractTableModel - It очень простой, чтобы сделать это, и означает, что ваша реализация может просто делегировать структуру данных (например, List) для хранения ваших данных.

Ответ 2

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

Я сохраняю все просто для себя, эмулируя стандарт кодирования, используемый Visual Age, много лет назад: я использую много JPanels для организации частей графического интерфейса, и каждый из них получает свой собственный метод makeXXX() для его создания, его и вернуть его в родительскую панель или конструктор. Таким образом, каждый makeXXX должен сосредоточиться только на небольшой части всех работ.

Некоторые компоненты должны быть доступны различными методами экземпляров; Я объявляю их как поля экземпляра. Другой материал, который просто украшает или компоновку, не должен выставляться вне методов makeXXX.

В основном это. Работает для меня.

Ответ 3

Сделайте это вручную. Разработчики GUI не очень хороши, если у вас нет концепции "частичного класса" на С#, и даже тогда они часто вызывают больше проблем, чем они решают. Используйте инструменты построения GUI, чтобы сделать прототип - конечно, но не для производственного кода.

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

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

Ответ 4

Был временно мертвый (но теперь, по-видимому, по крайней мере полуживой) плагин для Eclipse для визуального графического интерфейса и Netbeans все еще имеет поддержку для этого. Однако полученный код был меньше звездного. По крайней мере, для людей, которые вынуждены работать с этой кодовой базой, это очень больно.

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

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

Я склонен не слишком много думать о конкретном макете в Winforms и WPF из-за того, что, как вы отметили, и сильная дизайнерская поддержка. Также WPF очень легко обрабатывать даже в XAML. Частичные классы Ans делают работу с частично созданным дизайнером и частично рукописным кодом очень приятным. Увы, такого нет в мире Java.

Ответ 5

NetBeans может наилучшим образом использовать GUI в WYSIWYG, но многие разработчики java пишут свой графический интерфейс руками, так как это не так сложно. Позаботьтесь о толщине ваших границ и пробелов между элементами управления, и вы в порядке:)

Ответ 6

Помимо обсуждения инструментов, только некоторые идеи и мысли

• Прежде чем прикасаться к клавиатуре, нарисуйте элементы GUI на бумаге. Как классическая раскадровка, используемая для видеопроизводства. Если у вас есть клиенты, используйте рисованные (!) Рисунки для передачи идей (просто прочитайте, что вы уже планируете на бумаге).
• Планируйте реализовать модель-view-controller (MVC) или шаблон-представление-презентатор
• Связывание с данными - отличный способ рассмотрения. Он гарантирует синхронизацию между вашей моделью (данными) и представлением (GUI) и предлагает подтверждение ввода, преобразование "на лету" и многое другое. (При условии ссылки на привязку данных JFace, но я уверен, что существуют другие рамки для Swing/AWT)

Ответ 7

Я использую JFormDesigner для генерации gui. Он генерирует хороший чистый Java-код, и я узнал кое-что из чтения сгенерированного кода. Делает локализацию оснасткой.

Это действительно быстрый способ скомпоновать задействованный макет, особенно сложные меню и макеты сетки.

Ответ 8

Я для себя использую

Pencil

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

Ответ 9

Я предлагаю вам использовать netbeans для разработки графического интерфейса в AWT/SWING.

С уважением, Самир

Ответ 10

Хотя редактор Matisse NetBeans, по общему признанию, удобен, код, который он производит, довольно эзотеричен, а макеты хрупкие. Таким образом, я принимал лучшее из обоих миров, используя NetBeans для прототипирования WYSIWYG, а затем переписывал все это вручную.