Построение интерфейса на языке Java методом «жесткого кодирования»

Большинство современных языков программирования предоставляет пользователю богатый инструментарий для построения пользовательского интерфейса. Стандартизация основных его компонентов под общим названием WIMP (Windows, Icons, Menus. Pointers) дала возможность создать визуальные средства проектирования, которые позволяют конструировать интерфейс при помощи мыши и минимального вмешательства в код. Это ускоряет разработку программных средств, сводя этап создания интерфейса к чисто визуальным приемам. Именно этот метод завоевал себе наибольшую популярность среди разработчиков и ныне применяется в подавляющем большинстве сред разработки на различных языках программирования.

Между тем проектирование – не единственный способ построения интерфейса. Существует более сложный, но в то же время и более гибкий подход, который позволяет программисту создавать интерфейсы любой сложности. Впервые этот подход был применен еще в классических языках программирования – например, для среды Borland Pascal существовал пакет Turbo Vision, а для Borland C++ – Object Windows Library. Все эти библиотеки предоставляли пользователю возможность конструировать интерфейс на уровне кода, полностью отказываясь от визуального проектирования. Этот подход называется «жестким кодированием» (hard-coded user interface), поскольку пользовательский интерфейс описывается сугубо средствами языка программирования.

Каждый из этих подходов имеет свои недостатки и преимущества. Так, например, все компоненты визуально спроектированного окна по умолчанию имеют фиксированные геометрические пропорции и привязаны к координатной сетке. Это означает, что, например, при изменении пропорций этого окна либо появятся огромные «пустые» поля, либо все компоненты разъедутся в разные стороны. Другим существенным недостатком является статичность по умолчанию всех компонентов окна. Их нельзя перемещать, или изменять их пропорции во время работы программы – такой функционал программисту нужно реализовать отдельно, обрабатывая соответствующие события. Это усложняет задачу и приводит к трате существенной части времени на рутинную работу. Или же – к обеднению интерфейса, а следовательно – к снижению привлекательности и удобства использования программного обеспечения пользователем.

Кроме того, визуальное проектирование усложняет программисту задачу создания новых компонентов интерфейса или комбинирования существующих. Для некоторых сред разработки ПО этот недостаток можно устранить при помощи специальных инструментов – как, например, это сделано в Adobe Flash Catalyst. Однако для большинства языков программирования этот подход малоприменим, особенно если речь идет о создании стационарных (standalone) приложений.

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

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

В наше время подобный подход поощряет также библиотека графических компонентов QT компании TrollTech, которая является основой для такого известного пакета, как KDE. В Java средства для создания интерфейса по такому принципу включены в стандартную поставку и являются неотъемлемой частью графических библиотек AWT и Swing. В данной статье мы рассмотрим построение интерфейса методом жесткого кодирования на примере Swing.

Прежде чем рассматривать собственно основные приемы «жесткого кодирования» интерфейса на языке Java, следует дать несколько основных понятий.

Любой интерфейс состоит из отдельных компонентов, которые называются «элементами управления». Они не могут содержать в себе другие компоненты и применяются исключительно для отображения и ввода данных. В Swing элементами управления считаются следующие компоненты (в скобках указаны соответствующие им имена классов):

• Текстовая метка (JLabel):

• Кнопка (JBufton):

• Радиокнопка (JRadioButton):

• Флажок (JCheckBox);

• Комбобокс (JComboBox):

• Список (JList);

• Таблица (JTable);

• Дерево (JTree).

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

Контейнеры являются основным скрепляющим средством, поскольку именно на них ложится задача логической и визуальной организации всех компонентов в единый интерфейс. К ним относятся:

• Фрейм, или независимое окно (JFrame);

• Диалоговое окно (J Dialog):

• Панель (JPanel).

Они организуют древовидную иерархию, где верхнюю позицию всегда занимает фрейм, который одновременно является «главным» окном (или одним из нескольких «главных» окон) программы. Диалоговое окно также может находиться в корне иерархии, если речь идет о программе типа «единое диалоговое окно», в остальных случаях они подчинены главному фрейму. Далее идут последовательности панелей, каждая из которых может содержать как вложенные панели, так и элементы управления. Логически выстроенная структура панелей при помощи механизма «разметки» легко преобразуется в визуальную. Для этого нужно правильно представить себе основные схемы размещения компонентов на панели. Их всего пять:

• схема «стороны света»:

• табличная схема:

• схема «ряд»

• схема «ось»

• схема «стек».

Опишем их основных характеристики и на примере кнопочной панели покажем, как можно размещать различные компоненты таким образом.

Схема «стороны света», также называемая BorderLayout, является наиболее простой и наиболее часто используемой. В рамках этой схемы можно разместить до пяти компонентов или вложенных панелей, ориентированных (условно) на север, юг, восток, запад и центр.

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

При помощи этой схемы оптимально конструировать главное диалоговое окно. Северный компонент в этом случае будет содержать, например, линейку меню и панель быстрого доступа, южный – строку статуса, а центральный – рабочее пространство.

Табличная схема предусматривает размещение любого количества компонентов. При этом они будут автоматически подогнаны под пропорциональные размеру диалогового окна размеры ячейки. Такая схема наиболее подходит для организации кнопочных панелей.

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

В отличие от предыдущего компонента, исключение компонентов здесь не рекомендуется, иначе в разметке останется дырка. Если компонентов меньше, чем ячеек в сетке, а уменьшить ее нет возможности, тогда в неиспользуемые ячейки можно разместить пустые текстовые метки (JLabel).

Третьей схемой является ряд. Это самая простая, и в то же время самая редкоиспользуемая схема. Она попросту выстраивает все компоненты в длинную отцентрированную ленту. В качестве параметра можно передать указание, как именно следует выровнять компоненты – по левому краю, правому и отцентрировать.

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

Обратите внимание, что указание схемы разметки отличается от всех предыдущих. Это связано с необходимостью установить двойную связь между менеджером разметки и самим компонентом. А это, в свою очередь, позволяет легко исключать или добавлять компоненты «на лету», а затем обновлять панель при помощи специальной функции invalidateLayout(). То же самое, кстати, позволяют и остальные панели, но там необходимо обновить не только панель, но и само главное окно – поэтому такой функции там нет.

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

Последней схемой разметки, рассмотренной в данной статье, является схема «стек» или схема перекрывающихся панелей. Смысл этой схемы состоит в размещении нескольких панелей на одном и том же месте, при этом видимой будет только «верхняя». Смена видимости в такой схеме связана со сделанным пользователем выбором в каком-нибудь элементе управления, например, комбобоксе.

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

а) перенасытить диалоговое окно компонентами;

б) создать три перекрывающиеся панели и организовать их в стек

Описанные выше схемы можно комбинировать и более простыми способами, чем в предыдущем примере. Так, например, на верхнем уровне можно разделить окно на центральную и восточную панели (схема «стороны света»). Центральную панель можно занять полем ввода текста, а восточную – отвести под кнопочную панель. В свою очередь восточную панель разрешается при помощи той же схемы разделить на «север» и «центр». Последний позволительно оставить пустым, а в северной панели можно разместить вложенную панель. Эта вложенная панель будет содержать три кнопки, размещенные по табличной схеме.

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

Конечно, задачами и способами их решения, рассмотренными в данной статье, методы жесткого кодирования не ограничиваются. Кроме описанных схем разметки, например, существует еще так называемая «свободная табличная» разметка (GridBagLayout) – которая, увы, является настолько комплексной, что для ее изучения понадобилась бы отдельная статья. Однако ее комплексность оборачивается совершенно невероятной гибкостью, позволяющей сохранить все преимущества привязки к табличной сетке, и при этом свободно обращаться с геометрическими размерами компонентов. И на ней тема схем разметок не ограничиваются – есть схемы «групповая разметка» и «форма ввода», облегчающие создание диалоговых окон в режиме «жесткого кодирования». А можно и самому изобрести собственную схему, со своими законами изменения геометрии компонентов. Существуют специальные методы, позволяющие на лету изменять компонентный состав окон, и даже динамически конструировать диалоговые окна, основываясь на действиях пользователя в предыдущих. Можно окружать компоненты бордюрами, даже менять их внешний вид. И даже это тоже не конец, а только начало. «Жесткое кодирование» при всей своей кажущейся сложности дает программисту неограниченную свободу действий в создании пользовательского интерфейса.



Вы можете оставить комментарий, или Трекбэк с вашего сайта.

Оставить комментарий