Автор неизвестен - Платформа J2Me
В методе startApp() я добавляю эти новые объекты команд к главному экрану. Новая версия startApp() выглядит таким образом:
public void startApp()
// Создайте элемент Displayable. form = new Form("Hello World");
// Добавьте элемент строки в форму. String msg = "My first MIDlet!"; form.append(msg);
// Добавьте MyCommandListener в Form, чтобы принимать
// события нажатия клавиш, которые должны порождать
// всплывание диалогового окна уведомления, form.setCommandListener(cl);
form.addCommand(showAlert); form.addCommand(sayHi);
form.addCommand(cancel);
form.addCommand(exit};
form.addCommand(help); form.addCommand(item);
form.addCommand(ok); form.addCommand(screen);
form.addCommand(stop);
// Это приложение просто отображает одну форму, созданную выше,
display = Display.getDisplay(this); display.setCurrentfform);
}
Когда вы запустите новую версию, первое, что вы должны заметить, это то, что команда «Cancel» («Отмена») замещена командой «Exit» («Выход») на экранной клавише, как показано на рисунке 4.10. Активация меню показывает, что клавиша «Cancel» («Отмена») все еще на самом деле здесь, но теперь она в меню.
Рисунок 4.10. Реализация MIDP определяет политику размещения команд в соответствии с их типом
Размещение команд осуществляется в соответствии с их типом. Конкретная же политика, однако, зависит от реализации.
Семантика команд
Взгляните вновь на команду «Exit» («Выход»). Объект Command определяется с помощью метки «Exit» («Выход»). Но это не делает команду командой выхода! Я указал тип Command.EXIT в вызове конструктора. Это указание атрибута типа делает команду командой «Exit» («Выход»). Если бы я задал ее тип, как, скажем, Command. SCREEN, эта команда не появилась бы на экранной клавише. Вы можете попробовать проделать это самостоятельно.
Реализация выбирает такую политику размещения команд, которая пытается максимально повысить удобство и простоту использования устройства. По-видимому, хорошей идеей является расположение клавиши «Exit» в легко доступном месте, поскольку это та клавиша, которая используется для навигации между окнами. Тем самым мы еще раз возвращаемся к мысли о том, что дружественная к пользователю навигация является наиболее важным моментом при работе на устройствах с маленькими экранами и более ограниченными механизмами пользовательского ввода.
Наконец, несколько слов можно сказать о приоритетности команд. Обратите внимание, что организация команд, то есть размещение в соответствии с их типом, очень отличается от расстановки приоритетов поставки событий. Схема размещения ничего не делает с атрибутом приоритета Command, одним из трех атрибутов объектов Command. Приоритетность команд диктует приоритетность, которую реализация выдает командам при упорядочении их поставки в блок прослушивания.
Я определил различные приоритеты для каждой команды в примере HelloWorldS. Вы можете убедиться, что приоритетность не влияет на размещение команд. Если вы немного поэкспериментируете с меню, вы сможете выяснить политику размещения команд реализации каждого устройства, предоставляемого эмулятором. Вы также можете изменить приоритетность команд в исходном коде и увидеть, как это влияет на_их размещение.
В действительности расстановка приоритетов команд не является столь важной, когда вы работаете с высокоуровневыми API MIDP. Тем не менее, важно знать об этом понятии. Обычно пользователь не способен делать только одну вещь за раз, так что не будет лишним добавить высокоприоритетные события в приложение.
Выводы по главе
В этой главе вы узнали о высокоуровневом программном интерфейсе приложения (API) MIDP. Абстракции высокоуровневого API описывают следующее:
— визуализация элементов пользовательского интерфейса;
— обработка событий.
MID-леты, которые используют высокоуровневый API, не могут изменять внешний вид и впечатление от элементов, И они не могут получать информацию о реальных клавишах устройства и нажимаемых кнопках, которые служат причиной активизации команды.
Команды получают только семантическую информацию о «событии». Команда не представляет собой поведение или действие, которое осуществляется в ответ на событие. Блоки прослушивания команд задают поведение команд, определяя обработку, которая осуществляется в результате запуска команды реализацией.
Определенная политика размещения меток команд на экране зависит от реализации. MIDP устанавливает, что размещение команд в меню должно быть сделано в соответствии с типом команды.
Приоритетность команд диктуется порядком, в котором команды запускаются и посылаются в блок прослушивания команд.
Глава 5. Компоненты пользовательского интерфейса MIDP
Теперь, когда вы изучили базовые абстракции, определяемые высокоуровневым API MIDP, пришло время узнать, как использовать компоненты пользовательского интерфейса, которые встраиваются поверх этих абстракций. В этой главе вам будут показаны основы того, как использовать компоненты пользовательского интерфейса MIDP, которые реализуют высокоуровневый API MIDP. Я не собираюсь приводить всестороннее рассмотрение каждого свойства каждого элемента пользовательского интерфейса. Эту обязанность я оставляю на справочную документацию Javadoc или справочные руководства. Тем не менее, если у вас есть базовое понятие о цели каждого элемента и о том, как они работают по своей сути, вы можете легко изучить более детальные свойства каждого элемента сами.
Иерархия Компонентов пользовательского интерфейса MIDP
Диаграмма иерархии наследования MIDP, показанная на рисунке 5.1, повторяет то, что вы уже видели на рисунке 3.7 в главе 3. Вы уже видели некоторые из компонентов пользовательского интерфейса MIDP, показанные в этой иерархии, а именно Displayable, Screen, Form и Alert.
Вы знаете, что класс Displayable определяет природу основы любого компонента, который может быть отображен, и что класс Screen определяет базовую абстракцию пользовательского интерфейса MIDP — экран. Класс Screen является первым Displayable, который вы видели, a Form был первым конкретным типом используемого экрана.
В таблице 5.1 кратко описаны все компоненты пользовательского интерфейса MIDP в пакете javax.micfoedition.lcdui.
Рисунок 5.1. Компоненты пользовательского интерфейса MIDP принадлежат либо к классу объектов Displayable, либо к классу объектов Item за исключением класса Ticker, который происходит от Object.
— абстрактный класс,
— конкретный класс
Таблица 5.1. Описание всех компонентов интерфейса пользователя MIDP
Имя класса компонента, Ul MIDP — Описание — Принадлежность к- API MIDP
Alert — Информационное всплывающее окно, может быть модальным или рассчитанным по времени — Высокоуровневый
AlertType — Определяет типы объектов Alert — Высокоуровневый
Canvas — Экран, в котором вы можете рисовать графические объекты и получать низкоуровневые события ключ/перо — Низкоуровневый
ChoiceGroup — Группа выбираемых элементов, находится в Form — Высокоуровневый
Command — Семантическая инкапсуляция событий пользовательского интерфейса — Как высокоуровневый, так и низкоуровневый
DateField — Компонент, который отображает дату и время — Высокоуровневый
Display — Класс, который извлекает структуры данных дисплея устройства — Высокоуровневый
Displayable — Прародитель всех компонентов, которые могут быть отображены — Как высокоуровневый, так и низкоуровневый
Font — Класс, предоставляющий шрифты для экранного текста — Высокоуровневый
Form — Экран, который собирает элементы для отображения — Высокоуровневый
Gauge — Тип визуального измерителя — Высокоуровневый
Graphics — Отображение контекста графических элементов устройства — Низкоуровневый
Image — Отображение изображений в формате Portable Network Graphics [PNG, переносимая сетевая графика] — Как высокоуровневый, так и низкоуровневый
Imageltem — Form, размещающий отображение изображения — Высокоуровневый
List — Список выбираемых объектов — Высокоуровневый
Screen — Абстрактный прародитель всех типов экранов — Высокоуровневый
