Автор неизвестен - Платформа J2Me
Кроме того, MID-леты могут описывать необязательные зависимые от приложения атрибуты. Вы можете описать так много связанных с приложением свойств, сколько хотите. Ваше приложение будет затем получать к ним доступ с помощью метода MIDlet.getAppProperty(), показанного в листингах 3.3 и 3.4. Эта возможность является своего рода конфигурированием или механизмом настройки MID-летов. Вы увидите некоторые примеры выборочного описания атрибутов и их использования в главе 9.
Выводы по главе
В этой главе вы узнали о базовой организации и структуре приложений MIDP. Центром модели программирования MIDP является MID-лет.
Основными компонентами структуры MID-лета являются экземпляр MID-лета, экземпляр Display и одна или более «штучек» Displayable, которые являются компонентами пользовательского интерфейса.
Объекты MID-лета связаны с объектом Display. MID-леты создают элементы Displayable, которые являются компонентами пользовательского интерфейса, и требует, чтобы они отображались на экране устройства. Display управляет экраном устройства и видимостью элементов пользовательского интерфейса.
Абстрактный класс Screen является первым из двух основных типов, которые катего-ризируют все объекты Displayable. Класс Screen является центральной абстракцией дисплея. Класс Form является конкретным подклассом Screen. Только Screen видим в каждый момент жизни MID-лета.
Все MID-леты имеют связанные с ним свойства и атрибуты. Свойства являются стандартными системными свойствами, определенными спецификацией CLDC. Они относятся к платформе и поддерживаются и управляются системой управления приложениями. Атрибуты связаны с MID-летами. Существуют обязательные атрибуты, которые доступны для всех MID-летов, и необязательные атрибуты. Кроме того, существуют определяемые в зависимости от приложения атрибуты, которые могут быть определены автором MID-лета. Атрибуты существуют в файле JAD приложения и управляются программным обеспечением AMS устройства во время выполнения.
Глава 4. Высокоуровневый программный интерфейс приложения (API) в MIDP
На данный момент вы знаете, как организовать пользовательский интерфейс базового приложения MIDP. В любом MID-лете, более сложном, чем первый приведенный для вас пример, вам придется определять множество экранов. Приложение передвигается от экрана к экрану, откликаясь на команды пользователя, вводимые с клавиатуры, экранных клавиш или функциональных кнопок обычного мобильного устройства.
Чтобы создавать более сложные приложения, вам нужно изучить, как MIDP подгоняет вводимые пользователем данные и осуществляет обработку событий. В этой главе описывается высокоуровневый программный интерфейс приложения (API) MIDP, который определяет абстракции, подгоняемые к обработке высокоуровневых событий приложения.
Высокоуровневый API является одним из двух API компонентов пользовательского интерфейса MIDP. Второй — это низкоуровневый API, о котором вы узнаете в главе 5. Термин высокоуровневый соответствует API верхнего уровня, который предоставляется программисту для работы в двух областях:
— возможность манипулировать внешним видом и восприятием элементов («штучек») пользовательского интерфейса;
— уровень разбиения информации о событиях и обработке событий.
Все компоненты пользовательского интерфейса, принадлежащие иерархии класса Screen, реализуют высокоуровневый API. Эти элементы не дают вам возможность изменять их внешний вид и восприятие. Что же касается событий, информация, доступная приложению, является верхним уровнем абстракции. Приложения не имеют доступа к конкретным устройствам ввода. Например, используя абстракцию Screen, приложения не могут получить доступ к информации о том, какие физические клавиши нажимает пользователь.
Высокоуровневый API разработан для коммерческих приложений, которые должны быть переносимыми на многочисленные устройства. Поэтому реализация MIDP удаляет все детали о таких вещах, как реализация на аппаратном обеспечении.
Oбpaбoткa кoмaнд
Высокоуровневый API MIDP поддерживает обработку событий с помощью использования команд. Команда представляет из себя действие пользователя — например, что-то, что пользователь делает на экране, к примеру, нажимает функциональную клавишу. Событие — это проявление результата действия. События могут представлять собой вызов команды в ответ на действие пользователя.
Команда фиксирует семантическую информацию или отображение действия пользователя или события. Она не может, однако, определять поведение, которое вытекает из действия или события. Приложение определяет обработку — линию поведения, если хотите, — которая вытекает из появления некоторой команды.
Класс Command в пакете javax.microedition.lcdui описывает команды. Этот класс инкапсулирует информацию о:
— метке (label);
— приоритетности (priority);
— типе команды (command type).
Метка — это String, подходящая для дисплея, с условием, что она может предоставлять пользователю семантику команды. Приоритетность является int, которая отражает важность команды по отношению к другим командам. Тип команды — это внутреннее представление намеченного использования команды. Текущая спецификация определяет типы команды, перечисленные в таблице 4.1.
Таблица 4.1. Типы команд
Константа типа команды — Описание
public static int BACK — Возврат к логически предыдущему экрану
public static int CANCEL — Стандартный отрицательный ответ на запрос в диалоге
public static int EXIT — Указание на выход из приложения
public static int HELP — Запрос помощи в онлайновом режиме
public static int ITEM — Подсказки приложения для реализации, к которой команды имеют отношение, по определенному элементу на экране, возможно, по выбранному в настоящее время элементу
public static int OK — Стандартный положительный ответ на запрос в диалоге
public static int SCREEN — Программно определяемая команда, имеющая отношение к отображаемому в настоящее время экрану
public static int STOP — Остановка некоторой выполняемой в настоящее время операции
Сценарий oбработки команд
Сценарий обработки команд в MIDP является теоретически сходным с другими ин-струментариями графического пользовательского интерфейса. Блок прослушивания команд (command listener) является объектом, который получает уведомления о наличии команд. Блоки прослушивания команд регистрируются для получения уведомления о командах.
Некоторые внешние действия, такие, как нажатие пользователем на кнопку, отражаются в реализации MIDP, обнаруживая событие и связывая его с отображаемым в настоящее время экраном. Это инкапсулирует событие в объект Command. Зарегистрированный блок прослушивания команд получает уведомление о событии. Блок прослушивания затем предпринимает какое-либо действие, которое отражает поведение команды.
Команды могут быть связаны только с элементами Displayable. To есть вы можете добавлять или удалять объекты Command в и из объекта Displayable с помощью следующих методов класса Displayable:
public void addCommand(Command crad)
public void removeCoramand(Command cmd)
Объект блока прослушивания команд должен прикрепляться к Displayable для получения уведомления о команде с помощью вызова следующего метода в объекте
Displayable:
void setCommandListener(CommandListener cl)
Только один блок прослушивания команд разрешен на один Displayable. Реализация MIDP поставляет команды только в текущий Displayable. Это ограничение пришлось ввести с учетом реалистичных ожиданий от производительности современных реализаций MIDP. MIDP определяет модель одной нити для обработки событий. Поддержка многочисленных блоков прослушивания команд потребовала бы модели со множеством нитей обработки событий.
На рисунке 4.1 показана диаграмма UML связей между классами Displayable и Command и интерфейсом CommandListener.
Рисунок 4.1. Эта диаграмма UML показывает связь между несколькими ключевыми классами, которые ответственны за создание, обнаружение и передачу командных событий вашему приложению
Обратите внимание, что эта диаграмма не является всесторонним UML-представлением каждого представителя, атрибута типов и так далее. На рисунке 4.2 показана диаграмма экземпляра объекта, которая отражает взаимодействие экземпляров этих классов в работающем приложении.
Рисунок 4.2. Эта диаграмма объекта показывает, что в работающем приложении могут существовать многие отображаемые на экране объекты и более чем один может регистрировать тот же самый блок прослушивания. Однако Displayable может иметь только один командный блок прослушивания
