События

Наконец, мы перешли к наиболее важным элементам Swing - работе с событиями и реакции на взаимодействия с UI. Swing обрабатывает события, используя модель событие/прослушиватель. Эта модель работает путем разрешения некоторым классам регистрироваться на события от компонента. Такой класс называется прослушивателем (listener), поскольку он ждет возникновения событий в компоненте и выполняет действия при их возникновении. Компонент сам знает, как "активировать" событие (то есть, он знает типы взаимодействий, которые может генерировать, и как дать прослушивателям знать, когда происходят эти взаимодействия). Он передает это взаимодействие при помощи событий (event), классов, содержащих информацию о взаимодействии.

Убрав техническую болтовню, рассмотрим некоторые примеры работы событий в Swing. Я начну с простейшего примера - кнопки JButton и вывода сообщений "Hello" на консоль при ее нажатии.

JButton знает, когда на нее нажимают; это обрабатывается внутри компонента, код для обработки этого не нужен. Однако прослушиватель должен зарегистрироваться для получения этого события от JButton, для того чтобы вы могли вывести сообщение "Hello". Класс listener делает это, реализуя интерфейс listener и вызывая метод addActionListener() компонента JButton:

// Создать JButton JButton b = new JButton("Button"); // Зарегистрировать прослушиватель b.addActionListener(new HelloListener()); class HelloListener implements ActionListener { // Метод интерфейса для получения нажатий кнопки public void actionPerformed(ActionEvent e) { System.out.println("Hello"); } }

Компонент JList работает аналогично. Когда кто-то выбирает что-то в JList, вы выводите на консоли сообщение о выбранном объекте:

// myList - это JList, заполненный данными myList.addListSelectionListener(new ListSelectionListener() { public void valueChanged(ListSelectionEvent e) { Object o = myList.getSelectedItem(); System.out.println(o.toString()); } } );

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

Модели

Вы должны знать о Java Collections, наборе Java-классов, обрабатывающих данные. К этим классам относятсяArrayList, HashMap и Set. Большинство приложений использует эти классы повсюду при перемещении данных взад и вперед. Однако при необходимости использования этих данных в UI возникает одно ограничение. UI не знает, как их отображать. Подумайте об этом минутку. Если у вас есть JList и ArrayList некоторых объектов данных (например, объектов Person), как JList узнает, что отображать? Должен ли он отображать только фамилию, или фамилию и имя вместе?

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

Каждый компонент, работающий с коллекцией данных в Swing, использует концепцию модели, и это предпочтительный способ использования и управления данными. Он четко отделяет работу UI от используемых данных (вспомните пример MVC). Модель описывает компоненту, как отображать коллекцию данных. Что я имею в виду под словом "описывает"? Каждый компонент требует немного разного описания:

• JComboBox требует от своей модели описания текста для отображения в виде вариантов выбора и количества существующих вариантов.

• JSpinner требует от своей модели описания текста для отображения, а также описания предыдущего и следующего вариантов.

• JList тоже требует от своей модели описания текста для отображения как вариантов выбора и количества существующих вариантов.

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

• JTree требует от своей модели описания корневого узла, предков и дочерних элементов для всего дерева.

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