Конфигурации и профили

Конфигурация включает три базовых элемента:

набор свойств языка программирования Java;

набор свойств виртуальной машины Java;

набор поддерживаемых библиотек Java и программных интерфейсов приложения (API).

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

личные, не стационарно подключаемые мобильные устройства - поддерживаемые конфигурацией Connected, Limited Device Configuration (CLDC, конфигурация для подключенных ограниченных устройств);

постоянно соединенные сетевые устройства - поддерживаемые конфигурацией Connected Device Configuration (CDC, конфигурация для подключенных устройств).

Теоретически конфигурация может устанавливать такую же поддержку, как и библиотеки платформы J2SE. Но на самом деле это маловероятно, потому что, как вы знаете, J2ME предназначена для устройств, которые намного менее мощны, чем настольные компьютеры.

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

Конфигурация Connected Device Configuration (CDC)

Конфигурация Connected Device Configuration (CDC) предназначена лишь для фиксирования основных возможностей каждого вида устройств в категории устройств, для которой она предназначена, а именно, устройств с 2МБ или более полной памяти, включая как RAM, так и ROM.

Как вы видели на рисунке 1.1, конфигурация задает как набор поддерживаемых свойств виртуальной машины Java, так и набор библиотек классов. В CDC определено использование виртуальной машины полной платформы Java 2, которая, в этом контексте, называется компактной виртуальной машиной (Compact Virtual Machine (CVM)).

CVM. Хотя CVM поддерживает те же свойства, что и J2SE VM, она создана для потребительских и встраиваемых устройств. Это означает, что стандарт VM J2SE был модернизирован, чтобы соответствовать ограничениям устройств с ограниченными ресурсами. Сюда включены следующие свойства получившегося в результате продукта CVM:

улучшенная запоминающая система;

небольшие временные интервалы сборки мусора в среднем;

полное отделение виртуальной машины от системы памяти;

модульные сборщики мусора;

сборка мусора по поколениям.

В частности, CVM была спроектирована с учетом предоставления следующих свойств:

портативность;

быстрая синхронизация;

выполнение классов Java отдельно от постоянной памяти (ROM);

поддержка естественных потоков;

зоны обслуживания малых классов;

предоставление интерфейсов и поддержка служб операционной системы реального времени (RTOS);

преобразование потоков Java непосредственно в естественные потоки;

поддержка всех свойств и библиотек виртуальной машины версии 1.3, Java 2: безопасность, слабые ссылки, Java Native Interface (JNI, собственный интерфейс Java), Remote Method Invocation (RMI, интерфейс вызова удаленных методов), Java Virtual Machine Debugging Interface (JVMDI, интерфейс отладки виртуальной машины Java).

Библиотеки классов в CDC. CDC устанавливает минимальный набор библиотек классов и API. Она поддерживает следующие стандартные пакеты Java:

java.lang — системные классы виртуальной машины Java;

java.util — базовые утилиты Java;

java.net — дейтаграмма Universal Datagram Protocol (UDP) и ввод/вывод (I/O);

java.io — файловый ввод/вывод Java;

Java.text — самая минимальная поддержка интернационализации (I18N — смотри главу 9);

Java.security — минимальная защита на мелком уровне и шифрование сериализации объекта.

Как вы можете видеть, эти API не включают полный набор пакетов набора инструментальных средств разработки программного обеспечения (software development kit (SDK)) Java 2. В некоторых случаях эти пакеты и классы являются подгруппами пакетов и классов Java 2 SDK. Также убраны все устаревшие API J2SE. В таблице 1.1 перечислен полный набор пакетов, поддерживаемых CDC.

Конфигурация Connected, Limited Device Configuration (CLDC)

Вторая из двух конфигураций J2ME, Connected, Limited Device Configuration (CLDC), поддерживает персональные мобильные устройства, которые составляют значительно менее мощный класс устройств, чем тот, который поддерживает CDC. Спецификация CLDC распознает устройства этой категории по следующим характеристикам:

от 160 до 512 KB полной памяти, доступной для платформы Java;

16-битный или 32-битный процессор;

низкое потребление электроэнергии, часто питание от батарей;

нестационарная сетевая связь (часто беспроводная) с потенциально ограниченной пропускной способностью.

Цель CLDC заключается в том, чтобы установить стандартную платформу Java для этих устройств. Из-за широкого выбора системного программного обеспечения на различных персональных устройствах CLDC исходит из минимальных предположений о среде, в которой она существует. Например, одна ОС может поддерживать множественные параллельные процессы, другая может или не может поддерживать файловую систему и тому подобное.

CLDC отличается от CDC и представляет из себя ее подгруппу. Однако эти конфигурации независимы друг от друга, так что они не должны использоваться вместе при описании платформы. На рисунке 1.2 показана связь между двумя конфигурациями и платформой J2SE.

Рисунок 1.2. CLDC является подгруппой CDC. Ни CLDC, ни CDC, однако, не являются полностью подгруппами платформы J2SE, поскольку обе эти конфигурации добавляют новые классы, необходимые для создания служб в соответствующих семействах устройств

Как и CDC, CLDC определяет требуемый уровень поддержки языка программирования Java, требуемую функциональную поддержку соответствующей требованиям виртуальной машины Java и требуемый набор библиотек классов.

Поддержка языка Java. Спецификация CLDC не включает поддержку следующих свойств языка Java:

вычисления с плавающей точкой;

финализация объекта;

иерархия класса Java.lang.Error во всей его полноте.

Конечно, эти свойства включают также VM и описаны в главе 5 о спецификации CLDC («Adherence to Java Virtual Machine Specification» - «Соблюдение спецификации виртуальной машины Java»).
Я, однако, ссылаюсь на них здесь, поскольку они проявляются на уровне языка, что затрагивает программистов.

Отсутствие поддержки плавающей точки является основным отличием на языковом уровне виртуальной машины Java, которая поддерживает CLDC, от стандартной VM J2SE, что очевидно для программистов. Это означает, что программы, предназначенные для запуска на CLDC, не могут использовать константы, типы и величины с плавающей точкой. Вы не можете использовать встроенный тип float и класс Java.lang.Float был удален из библиотек CLDC. Это свойство не присутствует из-за отсутствия аппаратного или программного обеспечения с плавающей точкой на большинстве мобильных устройств.

Финализация объекта также отсутствует. Это означает, что метод Object.finalized был удален из библиотек CLDC.

Иерархия исключений Java.lang.Error также была удалена из библиотек CLDC и поэтому недоступна для приложений. Основная причина того, что обработка ошибок отсутствует, заключается в ограниченной памяти мобильных устройств. Это обычно не создает никаких неудобств при разработке приложений, как-никак, приложения не рассчитаны на восстановление из ошибочных состояний. И ресурсная цена реализации обработки ошибок высока и лежит за пределами возможностей сегодняшних мобильных устройств. Кроме того, нейтрализация ошибок на портативных устройствах, таких, как мобильные телефоны, зависит от конкретного устройства. И, наконец, не имеет смысла оговаривать механизм восстановления, который устройства должны использовать. Этот механизм легко может находиться за пределами встроенной виртуальной машины.

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

Свойства, перечисленные в этом списке, были исключены как из-за изменения библиотек, так и из-за соображений безопасности:

Java Native Interface (JNI, собственный интерфейс Java);

загрузчики определяемых пользователем классов;

отражение (reflection);

группы нитей и демоны нитей (thread daemons);

финализация (отсутствие метода Object.finalizeQ в библиотеках CLDC);

слабые ссылки (weak references);

ошибки (поддерживается небольшая подгруппа ошибок J2SE);

проверка класса файла.

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

Виртуальная машина, которая устанавливается вместе с внедрением CLDC, называется Kilobyte Virtual Machine (KVM), названа она таким образом потому, что использует всего лишь несколько килобайт рабочей памяти. KVM не является полнофункциональной J2SE VM.

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

Как вы знаете, конфигурация является базой для одного или более профилей. CLDC -это конфигурация, поверх которой встраиваются один или более профилей таким же образом, как профиль Foundation встраивается поверх CDC Смысл заключается в том, что АРГи в профиле CLDC поддерживают разработку приложений для рынка персональных устройств массового потребления. Поэтому CLDC предназначена для разработчиков отдельных комплектующих приложений. Вот чем она отличается от CDC, которая предназначена для разработчиков OEM (комплектного оборудования).

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

Табпииа 1.4. Пакеты CLDC

Название пакета СШС	Описание
Java. io	Стандартные классы и пакеты ввода/вывода Java, подмножество пакета J2SE
Java . lang	Классы и интерфейсы VM, подмножество пакета J2SE
Java .util	Классы и интерфейсы стандартных утилит, подмножество пакета J2SE
javax.microedition. io	Классы и интерфейсы структуры общих соединений CLDC

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

Профиль Mobile Information Device Profile. Поскольку категория, обслуживаемая CLDC, включает в себя такое множество различных типов персональных устройств, потенциально для их поддержки необходимо множество различных профилей. Наиболее популярным и хорошо известным из них является профиль Mobile Information Device (MIDP), иногда называемый MID Profile. MIDP лежит поверх CLDC и задает набор API пользовательского интерфейса (UI), созданного для современных беспроводных устройств.

Следуя традициям языка Java, MIDP-приложения называются MID-леты. МГО-лет является приложением Java, которое использует профиль MIDP и конфигурацию CLDC. Эта книга делает акцент на обучении вас тому, как писать MID-леты, поскольку подавляющее большинство программистов на J2ME будут сталкиваться с платформой CLDC/MIDP намного чаще, чем с другими платформами J2ME. И, с практической точки зрения, MIDP является единственным профилем, доступным на сегодняшний день.

Другой профиль, профиль PDA, в настоящее время находится на стадии описания. Профили PDA также принадлежат к общей категории мобильных информационных устройств. Однако профиль PDA, возможно, никогда не будет внедрен, поскольку сомнительно, предлагает ли он достаточно отличий и улучшений к спецификации MIDP, чтобы оправдать его разработку. Профиль PDA также ставит задачи портативности перед разработчиками.

Спецификация MIDP, как и профиль Foundation конфигурации CDC, была создана экспертной группой, в этом случае экспертной группой профиля Mobile Information Device Profile, которая является международным форумом, включающим представителей нескольких компаний со сферой деятельности в области мобильных устройств. MIDP предназначен для мобильных информационных устройств (mobile information device, MID), таких, как мобильные телефоны, двусторонние пейджеры и тому подобного, которые приблизительно соответствуют следующим характеристикам:

размер экрана примерно (как минимум) 96x54 пикселей;

глубина экрана 1 бит;

клавиатура для работы одной или двумя руками, устройство ввода с сенсорного экрана;

128 Кб энергонезависимой памяти для MIDP-компонентов;

8 Кб энергонезависимой памяти для данных постоянного хранения;

32 Кб энергозависимой оперативной памяти для области динамической памяти Jra:

двусторонняя беспроводная связь.

Поскольку диапазон возможностей MID столь широк, MIDP устанавливает рабочую величину минимального общего знаменателя возможностей устройств. MIDP поэтому определяет следующие API:

приложения (семантика и управление приложениями MIDP);

пользовательский интерфейс;

постоянное хранение;

организация сетей;

таймеры.

В таблице 1.5. перечислены пакеты, которые содержит MIDP.

Таблица 1.5. Пакеты MIDP

Название пакета MIDP	Описание
javax.microedition. Icdui	Классы и интерфейсы интерфейса пользователя
javax.microedition.rms	Система организации ведения записей (Record management system, RMS], поддерживающая постоянное хранение устройства
javax.microedition.midlet	Типы классов поддержки определения приложений МЮР
javax.microedition . io	Классы и интерфейсы структуры общих соединений МЮР
java.io	Классы и интерфейсы стандартного ввода/ вывода Java
Java. lang	Классы и интерфейсы виртуальной Java машины
Java .util	Классы и интерфейсы стандартных утилит

Вы узнаете больше о деталях программирования API, перечисленных в таблице 1.5, в главах 3-9.

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

На рисунке 1.3 сопоставляются структуры данных платформ CDC и CLDC. Как в CDC, так и в CLDC нет ничего такого, что препятствует производителю подключать любую из платформ к данному семейству устройств. Тем не менее, структуры платформ - особенно свойства конфигураций и профилей - были определены для работы с практическими ограничениями различных семейств аппаратных устройств.

Название пакета МIDР	Описание
javax.microedition.midlet	Типы классов поддержки определения приложений МЮР
javax.microedition . io	Классы и интерфейсы структуры общих соединений МЮР
java.io	Классы и интерфейсы стандартного ввода/ вывода Java
Java. lang	Классы и интерфейсы виртуальной Java машины
Java .util	Классы и интерфейсы стандартных утилит

Рисунок 1.3. CDC предназначена для стационарных устройств с фиксированным соединением и общим доступом. CLDC предназначена для персональных мобильных устройств с ограниченным соединением

Определение платформы Java для портативных устройств

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

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

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

Другой строительный блок J2ME, профиль, определяет программный интерфейс для определенного класса устройств. Реализация профиля состоит из набора библиотек классов Java, которые обеспечивают интерфейс программного уровня. Таким образом, профиль теоретически должен определять все виды функциональных возможностей и служб.

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

Например, профиль может поддерживать возможность сетевой коммуникации для популярного стандарта Short Message Service (SMS), широко используемого в мобильных телефонах. Поскольку стандарт SMS является повсеместно распространенным свойством в сотовой телефонии, имеет смысл задать эту службу в профиле, который предназначен для мобильных телефонов, вместо того чтобы встраивать ее в конфигурацию.

Профиль внедряется поверх конфигурации, на одну ступень ближе к выполнению практических приложений. Обычно профиль включает библиотеки, которые соответствуют более специфичным характеристикам категории устройств, которую они представляют, чем библиотеки, которые содержат конфигурации. Приложения затем встраиваются поверх конфигурации и профиля, они могут использовать только библиотеки классов, предоставляемые этими двумя низкоуровневыми спецификациями. Профили могут быть встроены поверх друг друга. Конечный продукт платформы J2ME, однако, может содержать только одну конфигурацию. На рисунке 1.1 показаны схематичные уровни, из которых состоит платформа J2ME.

Системы управления приложениями устройств

Все приложения J2ME - MID-леты и другие - являются настоящими приложениями Java, которые запускаются под контролем Java VM. Но что контролирует Java VM, например, на мобильном телефоне? Не существует командного процессора, с которого вы можете активизировать ваши любимые приложения Java, как вы можете сделать на рабочей станции. Запуск, остановка и управление приложениями Java контролируется программами управления приложениями {application management software, AMS), которые находятся на этом устройстве. В действительности AMS контролирует весь жизненный цикл приложения от установки, обновления и управления версиями до удаления программного обеспечения.

Производители устройств обычно предоставляют программное обеспечение AMS. Это самый логичный сценарий, потому что программное обеспечение AMS должно работать вместе с программным обеспечением родной системы устройства, которую, по всей видимости, производитель знает лучше всего. Тем не менее, производители комплектующего оборудования также могут разрабатывать системы AMS для определенных устройств. Программное обеспечение AMS может быть написано, например, в Java или некоторых других машинных языках, таких, как С. Понимание вопросов, связанных с управлением приложениями, важно для разработчика на J2ME. Управление приложениями описывается в главе 10. Вы должны знать о последствиях вашего выбора в отношении упаковки, лицензирования, загрузки для использования и так далее, и как эти решения повлияют на удобство, простоту использования и жизнеспособность вашего программного обеспечения.

Пакеты CDC

Название пакета CDC		Описание
java.io		Стандартные классы и интерфейсы ввода/вывода
java.lang		Классы виртуальной машины
java.lang.ref		Классы для работы с ссыпками на объекты
Java . lang. reflect		Классы и интерфейсы, поддерживающие отражение (динамическую информацию о классах)
Java .math		Математический пакет
Java .net		Сетевые классы и интерфейсы
Java. security		Классы и интерфейсы безопасности
Java . security .cert		Классы сертификации безопасности
Java . text		Текстовой пакет
Java . util		Классы стандартных утилит
Java .util . jar		Классы утилиты архиватора Java (JAR)
Java .util . zip		Классы утилиты ZIP
javax.microedition.io		Классы и интерфейсы структуры общих соединений CDC

Профиль Foundation Profile. Конфигурация вместе с профилем формирует исполняемую среду J2ME. Свойства и службы системного уровня, поддерживаемые конфигурацией, более или менее спрятаны от разработчика приложений. В действительности разработчику приложения запрещен прямой доступ к ним. Если это не было соблюдено, приложение не будет считаться соответствующим требованиям J2ME.

С точки зрения программиста профиль необходим для «полезной» работы. Профиль определяет уровень, который содержит АРГи, с которыми программист обычно имеет дело. Создатели J2ME в начале задали один профиль CDC, профиль Foundation, который основан на выпуске J2SE версии 1.3. Он был разработан стандартным комитетом Java Community Process, экспертной группой компаний, работающих в сфере потребительских электронных товаров. Профиль Foundation содержит в себе пакеты J2SE, перечисленные в таблице 1.2.

Таблица 1.2. Пакеты профиля Foundation

Название пакета профиля Foundation		Описание
java.lang		Дополняет поддержку языка Java пакета java.lang.* J2SE (Compiler, UnknownError)
java.util		Добавляет полную поддержку zip и другие утилиты J2SE (java.util. Timer)
Java .net		Добавляет TCP/IP Socket и соединения HTTP
java.io		Дополняет поддержку ввода/вывода языка Java пакета Java , io . * J2SE (классы Reader и Writer)
Java .text		Дополняет поддержку интернационализации пакета Java. text.* J2SE (I18N): Annotation, Collator, Iterator
Java. security		Добавляет подпись и сертификацию кодов

<
Вышеуказанный список пакетов выглядит точно так, как список, который включает в себя CDC. В действительности они одинаковы. Говоря, что профиль Foundation заключает в себе эти пакеты, мы на самом деле имеем в виду, что они доступны профилю Foundation. Замысел заключается в том, что профиль Foundation используется с CDC. Различие между профилем и конфигурацией заключается в понятиях, но не в физическом отношении.
Отметьте, что вся иерархия java.awt Abstract Window Toolkit (AWT, абстрактного оконного инструментария) и Java.swing пакета Swing, которая определяет API графического пользовательского интерфейса (GUI), отсутствует в поддерживаемых пакетах. Если приложению необходим GUI, потребуется дополнительный профиль. Профили могут быть внедрены поверх друг друга. Продукт платформы J2ME, однако, может содержать только одну конфигурацию.
Отсутствие поддержки GUI в профиле Foundation имеет меньшее воздействие на семейство постоянно подключенных сетевых устройств с общим доступом, таких, как компьютерные приставки к телевизору, чем оно влияет на персональные мобильные устройства, с которыми работают при помощи второй конфигурации J2ME, CLDC.
В общем, решение включать или не включать свойства и библиотеки в конфигурацию или профиль основано на их зонах обслуживания, требованиях к статическим и динамическим ресурсам и к безопасности.
Профиль Personal Profile. Спецификация профиля Personal была разработана в Java Community, конечным результатом которой стал JSR-62. Профиль Personal обеспечивает среду с полной поддержкой AWT. Замысел его создателей заключался в том, чтобы обеспечить платформу, подходящую для Web-апплетов. Он также предоставляет способ перемещения J2ME для приложений Personal Java.
Профиль Personal версии 1.0 требует внедрения профиля Foundation версии 1.0. Это расширенный набор профиля Personal Basis Profile версии 1.0. Однако профиль Personal является подгруппой платформы J2SE версии 1.3.1, которая дает приложениям, созданным в профиле Personal, большую совместимость снизу вверх с J2SE версии 1.3.1.

В таблице 1. 3 перечислены пакеты, которые включены в профиль Personal версии 1.0.
Таблица 1.3. Пакеты профиля Personal

Название пакета профиля Personal	Описание
Java. applet	Классы, необходимые для создания апплетов, и используемые апплетами
Java .awt	Классы AWT для создания пользовательского интерфейса программ
Java . awt . data transfer	Классы и интерфейсы для пересылки данных внутри и между приложениями
]ava .awt .event	Классы и интерфейсы для обработки событий AWT
Java. awt . font	Классы и интерфейсы для работы со шрифтами
Java. awt . im	Классы и интерфейсы для описания редакторов методов ввода
Java .awt. im. spi	Интерфейсы, которые помогают в разработке редакторов методов ввода для любой среды исполнения Java
Java .awt . image	Классы для создания и изменения изображений
Java. beans	Классы, которые поддерживают разработку компонентов JavaBean
javax.microedition.xlet	Интерфейсы, используемые приложениями и диспетчерами приложений профиля J2ME Personal для коммуникации

Профиль RMI. Профиль RMI является профилем, созданным для платформ, которые поддерживают конфигурацию CDC. Он был задан JSR-66 и определен различными компаниями, принимавшими участие в Java Community Process.
Профиль RMI требует внедрения профиля Foundation и внедряется поверх него. Продукты профиля RMI должны поддерживать следующие свойства:
полную семантику RMI вызовов;
поддержку объектов маршалинга;
RMI проводного протокола;
экспорт удаленных объектов через API UnicastRemoteObject;
распределенную сборку мусора и интерфейсы еборщика мусора как для клиента, так и для сервера;
интерфейс активатора и протокол активации для клиента;
интерфейсы реестра RMI и экспорт реестра удаленных объектов.
Профиль RMI поддерживает подгруппу RMI API J2SE в. 1.3. Следующие интерфейсы и свойства являются частью спецификации RMI J2SE в. 1.3 и публичных API, но поддержка этих интерфейсов и функциональных возможностей исключена из технических требований профиля RMI из-за ограниченности вычислительных мощностей устройств, сетевой производительности и пропускной способности:
RMI через брандмауэры и прокси;
RMI мультиплексный протокол;
модель реализации «активизируемого» («activatable») удаленного объекта;
нерекомендуемые методы, классы и интерфейсы;
поддержка протокола скелетона/заглушки для RMI в. 1.1;
компилятор скелетона и заглушки.
Поддержка следующих свойств J2SE RMI в. 1.3 не включена:
Java. rmi. server. disableHttp;
Java.rmi.activation.port;
Java.rmi.loader.packagePrefix;
Java.rmi.registry.packagePrefix;
java.rmi.server.packagePrefix.

Выводы по главе

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

Различные комбинации конфигураций и профилей J2ME поддерживают эти классы устройств. Конфигурация CDC и профиль Foundation поддерживают первый класс устройств, а конфигурация CLDC и профиль MIDP поддерживают второй класс. Конфигурация стремится предоставлять интерфейсы для служб системного уровня. Профиль стремится предоставлять стандартные интерфейсы для служб уровня приложений. Конфигурация дает возможность работы профиля, предоставляя необходимые средства и механизмы. Устройства должны иметь некую систему управления приложениями (AMS), чтобы «самозапустить» процесс инициализации приложений J2ME на устройствах. Производитель устройства обычно предоставляет AMS.

Использование J2ME Wireless Toolkit

Этот раздел покажет вам, как использовать J2SE Wireless Toolkit, разработанный в отделе «Java Software» компании «Sun», для выполнения всех этапов цикла разработки, который вы выполнили вручную. Вы можете загрузить J2ME Wireless Toolkit бесплатно с Web-страницы Java Software на сайте Sun Microsystems, http://java.sun.com. Загрузите версию, соответствующую вашей операционной системе, и следуйте инструкциям по установке, предоставляемым при загрузке.

Компиляция

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

Общая форма строки компиляции представляет из себя следующее:

S javac -d <tmpclasses dir> -bootclasspath <midpapi.zip location> \

Указание -d сообщает компилятору директорию, в которую нужно записывать непроверенные откомпилированные классы. Указание -bootclasspath указывает местоположение файла midpapi.zip, который поставляется вместе с инструментарием J2ME Wireless Toolkit, разработанным «Java Software», и содержит все классы MIDP, которые вам необходимы для написания приложений на J2ME. Среды разработки коммерческих производителей также включают этот файл. Указание -bootclasspath также сообщает компилятору о превосходстве над любой спецификацией CLASSPATH, которую вы, возможно, установили в среде своей оболочки. Заметьте, что это должен быть относительный маршрут доступа к файлу (relative pathname,) - относительный к корневой директории проекта. Наконец, вы указываете имена путей исходных файлов Java, которые вы компилируете.

Чтобы откомпилировать набор MID-летов HelloWorld из директории apps/HelloWorld/, используйте следующую команду:

$ javac -d tmpclasses \

-bootclasspach ../../lib/midpapi.zip src/HelloWorld.Java

Указание -d сообщает компилятору записать непроверенные компилированные классы в директорию tmpclasses, которая является поддиректорией каталога HelloWorld/. Указание -bootclasspath определяет путевое имя относительно данного каталога. Наконец, последний параметр указывает относительное путевое имя исходного файла HelloWorld.Java.

Вы узнали, что библиотеки MIDP и CLDC определяют полную платформу для создания приложений на MIDP. Следовательно, вам не придется включать путь для любой J2SE установки в CLASSPATH вашей среды при компилировании ваших приложений. В действительности вы не можете включить его. Если вы это сделаете, вы получите ошибку компиляции, поскольку компилятор найдет конфликтующие определения в библиотеках J2SE и J2ME.

После завершения компиляции ваших файлов директория tmpclasses будет содержать непроверенные файлы .class:

$ Is -I tmpclasses/

total 0

-rw-r--r-- 1 vartan None 922 HelloWorld.class

Компиляция пpoeктa

Теперь вы готовы к компиляции. Нажмите на кнопку Build (Создать) на панели кнопок главного окна KToolbar. Wireless Toolkit откомпилирует исходный файл HelloWorld.java и выдаст результат диагностики в главном окне KToolbar, которое показано на рисунке 2.7. Конечно, если ваша компиляция не удастся, обычный благоприятный результат компиляции появится на этой панели.

Рисунок 2.7. Компиляция вашего проекта выведет дополнительные результаты диагностики в главном окне KToolbar

Если результаты вашей компиляции кажутся вам неубедительными, вы можете использовать ваш командный процессор для подтверждения наличия файлов .class в директориях tmpclasses/ и classes/:

$ pwd

/cygdrive/с/J2mewtk/apps/HelloWorId/tmpclasses

$ Is -1

total 8

-rw-r--r— 1 vartan None 2036 HelloWorld.class

? cd ../classes/

5 pwd

/cygdrive/с/J2mewtk/apps/HelloWorld/classes

$ Is -1

total 8

-rw-r--r-- 1 vartan None 2036 HelloWorld.class

Как вы уже знаете, директория tmpclasses/ содержит файлы .class, созданные в самом процессе компиляции. Директория classes/ содержит предварительно проверенные файлы, созданные утилитой preverifу. J2ME WTK запускает утилиту preverify автоматически, когда вы нажимаете на кнопку Build (Создать) KToolbar.

Pacкpытиe u выполнение

К настоящему моменту мы уже прошли этапы редактирования (создания программы), компилирования, предварительной проверки и упаковки. Наконец, вы готовы к распаковке и запуску вашего приложения. В действительности разработчик MID-лета загрузил бы файл JAR на какую-либо систему инициализации приложений (системы инициализации приложений описываются в главе 10). Системы инициализации предлагают распаковку приложения вслед за его загрузкой. Пользователи загружают файл JAR набора MID-летов на свои устройства и запускают его с помощью программного обеспечения системы управления приложениями устройства.

В этой главе распаковка означает размещение файлов под управлением эмулятора инструментария J2ME Wireless Toolkit. Вы можете затем запустить приложение в эмуляторе, имитируя его выполнение на реальном устройстве.

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

Pacкрытие приложения

Фактически при использовании Wireless Toolkit нет разграничения этапов разработки. Инструментарий создает компоненты, которые вам нужно будет раскрыть в реальной системе, а именно файл дескриптора приложения и файл JAR приложения. В главе 10 описывается, что вы будете делать с этими файлами в реальной системе, которая предлагает приложения MIDP для загрузки на реальные устройства.

Предварительная проверка

Следующим этапом после компиляции является предварительная проверка файлов .class, которые вы только что откомпилировали. Чтобы провести ее, запустите следующую команду:

$ preverify -classpath "../../lib/midpapi.zip;tmpclasses" -d classes \

tmpclasses

Если вы используете J2ME Wireless Toolkit, вы должны отделить элементы пути классов точками с запятой, или заключить их в кавычки, если вы используете оболочку Unix, чтобы избежать того, что оболочка начнет интерпретировать точки с запятой. Элементы путей классов представляют собой директории, из которых должны загружаться классы. Разделитель элемента пути класса - точка с запятой в данном случае -зависит от платформы.

Параметр -d указывает директорию, в которую должны быть записаны предварительно проверенные выходные классы, генерируемые с помощью этой команды. Наконец, имя замыкающей директории, tmpclasses, показывает местонахождение, из которого можно получить непроверенные файлы классов, которые были созданы на предыдущем этапе компиляции.

Запуск вышеуказанной команды preverify создает предварительно проверенные файлы . class в директории классов в соответствии с вашими указаниями:

S Is -I classes/

total 0

-rw-r--r-- 1 vartan None 922 HelloWorld.class

Команда preverify является инструментом предварительной проверки файлов классов, который используется в процессе проверки файлов классов. Проверка файлов классов в CLDC, как и в J2SE, является процессом проверки истинности файлов классов Java и отклоняет неправильные файлы. Однако в отличие от процесса проверки в J2SE проверка файлов классов в CLDC включает два этапа:

Этап 1 - предварительная проверка вне устройства;

Этап 2 - проверка на устройстве.

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

Причина появления этого нового процесса проверки заключается в том, что обычный верификатор файлов классов J2SE требует больше памяти и возможностей по обработке данных, чем стандартные мобильные устройства могут реально предоставлять. Он использует около 50 Кб места под двоичный код и от 30 до 100 Кб динамической памяти при работе. Новый верификатор CLDC требует намного меньше RAM и является при этом намного более эффективным. Для стандартных файлов классов верификатор CLDC использует только около 10 Кб кодового пространства и требует только 100 байт динамической памяти при работе.

Новый верификатор может достигать такой высокой производительности благодаря новому алгоритму, который он использует. Этот новый алгоритм, однако, требует наличия специальных атрибутов в каждом файле классов Java. Верификатор предварительной проверки записывает эти новые атрибуты в каждый файл классов Java. Верификатор затем использует атрибуты, созданные верификатором предварительной проверки. Новые файлы классов приблизительно на 5 процентов больше, чем их немодифицированные версии.

Верификатор предварительной проверки выполняет две задачи:

Он делает все запросы подпрограммы «линейными», замещая каждый запрос метода, который содерркит байтовые коды jsr, jsr_w, ret и wide ret, семантически эквивалентными кодами, которые не содержат этих команд.

Он вставляет атрибуты стековой карты в то, что иначе является нормально форматированным файлом классов Java.

Эти новые файлы классов все еще являются действующими файлами классов J2SE. То есть новые атрибуты стековой карты просто игнорируются верификатором J2SE. Добавление атрибутов стековой карты было внедрено вместе с механизмом наращиваемых атрибутов, который поддерживается форматом файлов классов Java, определяемым стандартной виртуальной машиной Java. Это означает, что файлы классов CLDC являются совместимыми снизу вверх с виртуальной машиной J2SE.

Атрибуты, которые верификатор предварительной проверки записывает в файлы классов CLDC, называются атрибутами стековой карты. Атрибуты стековой карты определяются структурой данных StackMap_attribute. Эти атрибуты являются субатрибутами атрибута Code, определяемого и используемого обычной виртуальной машиной J2SE. Имя стековая карта отражает природу атрибута как описания типа локальной переменной или элемента стека операндов. Такое имя выбрано потому, что эти элементы всегда находятся в стеке интерпретатора.

Тип Code_attribute является другим типом, определяемым стандартной виртуальной машиной. Он определяет атрибут Code, используемый стандартной виртуальной машиной J2SE. Для получения полного описания этих структур, пожалуйста, смотрите спецификацию виртуальной машины Java «Java Virtual Machine Specification», которая отмечена в разделе ссылок в конце этой книги. Верификатор предварительной проверки CLDC определяет следующую структуру Stackmap_attribute, которая определяет производный тип стековой карты, как изложено ниже:

StackMap_attribute

{

u2 attribute_name_index; u4 attribute_length; u2 .iumber_of_entries;

u4 byte_code_offset;

{

u2 number_of_locals;

cy types_of_locals[number_of_locals];

u2 number_of_stack_iteras;

ty types_of_stack_items[nuraber_of_stack_iterns];

} entries [number_of_entriesj;

}

Для получения дополнительной информации об описании и функционировании каждого из этих полей, пожалуйста, смотрите спецификацию Connected, Limited Device Configuration Specification.

Проектирование и кодирование

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

Я сначала создаю директорию под названием HelloWorld, что является названием примера нашего первого приложения, под директорией apps/, предназначенной для установки инструментария для работы с беспроводными устройствами. Эта директория является корневой для вашего нового проекта. Проект - это организованное объединение ресурсов - исходного кода, файлов ресурсов, откомпилированных файлов, - специфических для одного или более связанных приложений.

Корневой каталог проекта содержит подкаталоги, показанные в следующем примере кода:

$ pwd

/cygdrive/c/ J2rnewtk/apps/HelloWorld

3 Is -F

bin/ classes/ res/ src/ tmpclasses/

Есть причина для использования такой точной структуры каталогов, которую я объясню далее, когда вы узнаете, как использовать эмулятор Wireless Toolkit Emulator. Однако даже если вы не планируете использовать J2ME Wireless Toolkit, такая организационная структура является самой разумной для начала работы. В таблице 2.1 объяснено содержание и цель этих каталогов.

Таблица 2.1. Поддиректории проектов, созданных с помощью J2ME Wireless Toolkit

Название поддиректории		Содержание директории
Bin		Файлы приложения: файл .jar, файл .jad, MANIFEST. MF
classes		Откомпилированные и предварительно проверенные файлы .class
Res		Файлы ресурсов приложения, такие, как файлы изображений .png в формате PNG
Src		Файлы исходного приложения
tmpclasses		Откомпилированные, непроверенные файлы .class

Я не буду объяснять здесь проектировку самого приложения, поскольку эта тема лежит за пределами темы этой главы. Цель на данный момент заключается не в том, чтобы описать, как проектировать приложения Java или даже приложения MIDP. В последующих главах, однако, будет говориться об организации MIDP-приложений.

Размещение исходного кoдa в пpoeктe

Теперь пришло время поместить исходный файл приложения внутри проекта, как указано в панели результатов диагностики KToolbar. Когда вы создадите новый проект, KToolbar создаст соответствующие директории под структурой директорий установки, как вы уже видели, когда использовали интерфейс командной строки. Вспомните, что на моей системе эта директория располагается в /cygdrive/c/J2mewtk/apps.

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

Создание файла дecкpиптopa приложения для набора МID-летов

Программное обеспечение управления приложениями на устройстве, таком, как мобильный телефон, использует файл JAD для получения информации, необходимой для управления ресурсами во время выполнения MID-лета. Файл дескриптора приложения является необязательным, однако полезным. Вы можете использовать любой текстовой редактор для его создания, но вы должны дать файлу расширение . jad. Чтобы избежать путаницы, я рекомендую давать ему имя, которое характеризует весь набор MID-летов.

Создание файла JAR для набора МID-летов

Теперь, когда вы создали файл манифеста, вы готовы к созданию файла JAR приложения. Используйте следующую команду jar:

$ jar craf bin/MANIFEST.MF bin/HelloWorld.jar -C classes/ . -C res .

Эта команда создаст файл JAR для вашего набора MID-летов HelloWorld. Листинг содержимого директории bin/ обнаруживает только что созданный файл HelloWorld. jar:

$ Is -i bin

total 2

-rw-r--r-- 1 vartan None 1393 HelloWorld.jar

-rw-r--r-- 1 vartan None 193 MANIFEST.MF

Листинг содержимого файла JAR, который вы только что создали, выдает следующую информацию:

$ jar tf bin/HelloWorld.jar

META-INF/

META-INF/MANIFEST.MF

classes/./

classes/./HelloWorid.class

HelloWorld.png

Как вы можете видеть, файл манифеста включается в файл JAR. Файл JAR содержит один файл .class для нашего приложения HelloWorld. Он также содержит файл формата .png (portable network graphics -переносимая сетевая графика), который является подходящим вариантом для использования в качестве значка приложения. Файл MANIFEST.MF, конечно, был создан вручную, как описано выше.

Создание файла манифеста JAR

ЕСЛИ вы хотите добавить файл Manifest к вашему заархивированному набору MID-летов, вам необходимо создать его прежде, чем вы создадите сам JAR-архив. Вы можете создать этот файл в любом текстовом редакторе. Потом создайте JAR-файл с помощью стандартной утилиты JAR J2SE. Утилита JAR включается в утилиты инструментария Wireless Toolkit.

Спецификация MIDP требует, чтобы в файле Manifest присутствовали определенные поля. Требуемые поля показаны в таблице 2.2.

Таблица 2.2. Обязательные атрибуты файла MANIFEST.MF

Имя атрибута		Описание
MIDlet-Name		Название набора MID-летов
MIDlet-Versiorv		Номер версии набора MID-летов в форме <major>.<minor>.<micro>, определяемой схемой спецификации управления версиями продукта JDK
MIDlet-Vendor		Разработчик приложения (компания или частное лицо)
MIDlet-<n>		По одному на MID-лет в данном наборе, содержит разделяемый запятой список из текстового имени MID-лета, значка и имени класса п-ного MID-лета в наборе
MicroEdit ion-Profile		Профиль J2ME, необходимый для исполнения MID-лета
MicroEdition-Configuration		Конфигурация J2ME, необходимая для исполнения MID-лета

Файл манифеста содержит строки атрибутов, один атрибут на строку. Каждый атрибут состоит из ключа и значения. После ключа ставится двоеточие, которое отделяет его от связанного с ним значения. Файл MANIFEST.MF программы HelloWorld находится в папке HelloWorld/bin/. Он выглядит следующим образом:

MIDlet-l: HelloWorld, HelloWorld.png, HelloWorld

MIDlet-Narae: HelloWorld

MIDlet-Vendor: Vartan Piroumian

MIDlet-Version: 1.0

MicroEdition-Configuration: CLDC-1.0

MicroEdition-Profile: MIDP-1.0

Обратите внимание на имя атрибута MIDlet-1: в файле MANIFEST.MF. Файл манифеста различает различные MID-леты, нумеруя их от MIDlet-l до MIDlet-/!. Число 1 должно идентифицировать первый MID-лет.

У атрибута MIDlet-1 существует три значения. Первое - название набора MID-летов, который содержит данный MID-лет. Это значение может быть именем, воспринимающимся человеком.
Второе значение является именем файла изображения PNG, который AMS использует как значок, представляющий этот MID-лет. Последнее значение является именем файла класса MID-лета, который определяет входную точку исполнения MID-лета.

Наверное, самыми важными атрибутами являются атрибуты MicroEdition-Configuration и MicroEdition-Profile. AMS использует эти значения для определения того, подходит ли MID-лет для данного устройства.

Спецификация MIDP позволяет также создавать необязательные поля в файле манифеста. В таблице 2.3 показаны необязательные поля файла манифеста.

Таблица 2.3. Необязательные атрибуты файла MANIFEST.MF

Имя атрибута	Описание
MI Diet-Description	Описание набора MID-летов
MIDlet-Icon	Имя файла PNG, содержащегося в JAR
MIDlet-Info-URL	URL, который содержит дополнительную информацию об этом наборе MID-летов
MIDlet-Data-Size	Минимальное количество байт данных постоянного хранения, требуемое набором

Создание пpoeктa

Свойства и функции Wireless Toolkit базируются на проектах. Проект представляет собой разработку набора из одного или более MID-летов. Завершение выполнения цикла разработки проекта выражается в создании файлов приложения JAR и JAD и файла манифеста, который описывает файл JAR.

KToolbar является основной утилитой Wireless Toolkit. На рисунке 2.1 показано главное окно KToolbar. Обратите внимание, что во время запуска он предлагает вам создать новый проект или открыть существующий и снова использовать исходный код, который вы уже видели в примерах с использованием командной строки.

Рисунок 2.1. KToolbar является главным окном, из которого вы можете получить доступ ко всем функциям Wireless Toolkit

Первый этап затем заключается в создании нового проекта. Я собираюсь создать проект HelloWorld и вновь использовать исходный код, который вы уже видели. На рисунке 2.2 показано окно, которое всплывает, когда вы выбираете пункт New Project... (Новый проект...) в строке меню KToolbar.

Рисунок 2.2. Чтобы создать новый проект, вы должны задать, по крайней мере, один MID-лет. Вы должны предоставить имя проекта и имя основного класса Java для первого MID-лета

После того как вы введете и подтвердите имя проекта и имя класса MID-лета, появится окно, показанное на рисунке 2.3. Это окно предложит вам ввести необходимую информацию о вашем проекте, которая будет использоваться для создания файла манифеста JAR и файла JAD. Заметьте, что закладка Required (Требуемые атрибуты) всегда показывается вначале при появлении окна. Атрибуты, которые вы видите, соответствуют атрибутам, перечисленным в таблице 2.4, обязательным атрибутам дескриптора приложения. Вы можете изменять информацию, установленную по умолчанию, например, атрибуты MIDlet-Vendor или MIDlet-Jar-URL.

Обязательные атрибуты файла дескриптора приложения

Имя атрибута		Описание
MIDlet-Jar-URL		URL файла JAR набора MID-летов
MIDlet-Jar-Size		Размер (в байтах) файла JAR
MI Diet-Name		Имя набора MID-летов
MIDlet-Vendor		Разработчик приложения (например, название компании или имя частного лица]
MIDlet-Version		Номер версии набора MID-летов в форме <major>. <minor>.<micro>, определяемой схемой спецификации управления версиями продукта JDK
MicroEdition-Configuration		Конфигурация J2ME, необходимая для исполнения MID-лета
Mi croEditi on- Profile		Профиль J2ME, необходимый для исполнения MID-лета

Необязательные атрибуты файла дескриптора приложения

Имя атрибута		Описание
MIDlet-Data-Size		Минимальное количество байт данных постоянного хранения, требуемое набором
MIDlet-Delete-Confirm		Указывает, должна ли AMS запрашивать подтверждение пользователя перед удалением MID-лета
MI Diet -De script ion		Описание набора MID-летов
MIDlet-Icon		Имя файла PNG, содержащегося в JAR
MIDlet-Info-URL		URL, который содержит дополнительную информацию об этом наборе MID-летов
MIDlet-Install-Notify		Указывает, должна ли AMS уведомлять пользователя перед установкой нового MID-лета

В дополнение к необязательным полям, перечисленным в таблице 2.5, файл JAD может содержать отдельные поля атрибутов для каждого MID-лета, описанные и названные разработчиком приложения. Вы можете называть эти атрибуты так, как вам нравится, однако вы не должны использовать «MIDlet-» в имени атрибута. Этот префикс зарезервирован для имен стандартных атрибутов, определенных спецификацией MIDP.

Файл JAD для программы HelloWorld также находится в директории HelloWorld/bin/ и его содержимое выглядит так:

MIDlet-1: HelloWorld, HelloWorld.png, HelloWorld

MIDlet-Jar-Size: 1393

MIDlet-Jar-URL: HelloWorld.jar

MIDlet-Name: HelloWorld

MIDlet-Vendor: Vartan Piroumian

MIDlet-Version: 1.0

В частности, обратите внимание на поле атрибута MIDlet-Jar-Size. Когда вы используете инструменты командной строки, вы должны вручную редактировать файл JAD, чтобы обновлять значение атрибута MIDlet-Jar-Size каждый раз, когда вы создаете файл JAR, для точного отражения размера файла JAR. Листинг директории bin/ показывает, что ваш файл JAR занимает 1393 байта. Поэтому файл JAD должен точно отражать этот размер, что он и делает.

Заметьте, что некоторые из полей появляются как в файле манифеста, так и в файле JAD. Причина этого заключается в том, что спецификация MIDP требует их наличия в обоих полях. В частности, три атрибута - MIDlet-Name, MIDlet-Version и MIDlet-Vendor -заслуживают особого внимания. Они должны иметь одно и то же значение, если присутствуют как в файле JAD, так и в файле Manifest. Спецификация MIDP оговаривает, что файл JAR не должен загружаться, если эти три значения не являются идентичными в этих двух файлах.

Упаковка

Следующим этапом после предварительной проверки является упаковка приложения. Упаковка набора MID-летов включает 2 объекта:

архивный файл Java файлов MID-лета;

необязательный файл дескриптора приложения.

Хотя вы можете выбирать, упаковывать ли приложения J2SE для распаковки в дальнейшем, спецификация MIDP требует, чтобы вы упаковывали набор MID-летов с помощью утилиты архивации Java (JAR). В действительности спецификация MIDP требует, чтобы все наборы MID-летов переносились на устройства в сжатом файловом формате JAR. Обычно серверы, которые поддерживают перенос наборов MID-летов на устройства, хранят файлы наборов MID-летов в сжатом формате JAR. Либо сервер, либо компонент, который загружает файл на сервер, создает сжатый JAR-файл.

Архив JAR набора MID-летов может содержать несколько типов файлов, как показано в следующем списке:

файл манифеста (manifest file) - файл, который описывает содержимое JAR-файла;

файлы классов Java, которые содержат MID-леты из набора MID-летов архива;

файлы ресурсов приложения, используемые MID-летами из набора MID-летов.

JAR Файл манифеста (manifest file) содержит атрибуты, которые описывают содержимое самого JAR-файла. Его наличие в JAR-файле необязательно.

Другой необязательный описательный файл, называемый файлом дескриптора приложения, содержит информацию о наборе MID-летов. Этот файл иногда называется дескриптором приложения Java (JAD). Каждый набор MID-летов может иметь связанный с ним файл описания.

Файл дескриптора приложения используется по двум причинам. Программное обеспечение управления приложениями устройства (AMS) использует информацию из этого файла для первоначальной проверки того, что все MID-леты в файле JAR соответствуют требованиям устройства, перед тем как оно загрузит полный файл JAR. AMS также использует эту информацию для управления MID-летом. AMS устройства отвечает за установку и удаление наборов MID-летов. Оно также обеспечивает MID-леты средой исполнения, требуемой спецификацией MIDP. Наконец, AMS управляет выполнением MID-летов, а именно запуском, приостановкой и закрытием всех MID-летов.

Наконец, сами MID-леты могут извлекать из конфигурации JAD-файла специфические атрибуты, которые представляют собой параметры MID-лета. Файл ресурсов приложения является основным механизмом для распаковки конфигураций MIDP-прило-жений.

Упаковка проекта

После того кай вы выполните компиляцию, вы должны упаковать приложение, что вы уже делали при работе с инструментами командной строки. На панели кнопок KToolbar нет кнопки Package (Упаковка). Вместо этого раскройте пункт меню Project (Проект) в меню KToolbar и выберите пункт меню Package (Упаковка), как показано на рисунке 2.8.

Рисунок 2.8. Выберите пункт меню Package (Упаковка) для упаковки вашего приложения. На этом этапе создаются файлы JAD и JAR приложения

Рисунок 2.9 показывает результат диагностики, созданный, когда вы закончили процесс упаковки. Заметьте, что он показывает, что Wireless Toolkit создал файлы Hello World jar и HelloWorld.jad.

Рисунок 2.9. Этап упаковки на самом деле компилирует приложение прежде, чем его упаковать. Результат диагностики отражает выполнение этапов компиляции и упаковки

Вы можете вновь проверить наличие этих файлов, вручную выведя описание содержимого директории bin/ проекта:

pwd /cygdrive/c/J2mewtk/apps/HelloWorld/bin

$ Is -1

total 3

-rw-r--r-- 1 vart'an None 282 HelloWorld.jad

-rw-r--r-- 1 vartan None 6960 HelloWorld.jar

-rw-r--r-- 1 vartan None 29V MANIFEST.MF

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

Выполнение приложения

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

Панель кнопок KToolbar содержит комбинированное окно, называемое Device (Устройство) под главной строкой меню. Вы можете выбрать одно из шести устройств в этом комбинированном окне. Выбранный пункт указывает эмулятору, какое устройство имитировать при запуске приложения. На рисунке 2.10 показан список устройств, который вы видите при выборе в комбинированном окне.

Рисунок 2.10. Wireless Toolkit может имитировать пять устройств. Два из них являются реальными устройствами

После того как вы выберете устройство по вкусу, вы будете готовы к запуску -вашего приложения. Чтобы запустить ваше приложение в эмуляторе, просто нажмите на кнопку Run (Запуск) на панели кнопок KToolbar. Я закрываю эмулятор Default Color Phone. На рисунке 2.11 показано окно, которое появляется, имитируя среду реального устройства.

На рисунке 2.11 представлено главное окно программы управления приложениями, которое вы можете увидеть на реальном устройстве. Оно дает вам возможность выбрать MID-лет, который вы хотите выполнить. Обычно вы запускаете систему AMS из меню на вашем мобильном устройстве. На рисунке 2.12 показан дисплей после того, как вы выберете пункт HelloWorld, указанный в списке на дисплее. Это и есть окно, показываемое MID-летом.

Рисунок 2.12 является тем же, что и рисунок 3.1. В главе 3 описывается исходный код приложения HelloWorld и его варианты в деталях. В этой главе я описываю только процесс разработки приложения.

На рисунке 2.13 показано главное окно эмулятора J2MEWTK после того, как вы завершите эмуляцию MID-лета HelloWorld. Заметьте, что оно выводит некоторую диагностическую информацию о процессе эмуляции.

Рисунок 2.11. Главное окно AMS дает вам возможность выбрать MID-лет, который вы хотите выполнить.
Если более одного MID-лета присутствуют в наборе MID-летов, вы увидите список их всех. Заметьте, что кнопка Launch (Запуск) предоставляется системой AMS

Рисунок 2.12. Это единственное окно, показываемое приложением HelloWorld. Заметьте, что здесь нет кнопки выхода из приложения. Вы можете нажать на красную кнопку Hang Up (Отбой), чтобы вернуться к главному окну AMS

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

Рисунок 2.13. Эмулятор выводит результат диагностики на консоль

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

Процесс разработки приложений на J2ME

Процесс разработки приложений на J2ME включает компиляцию, предварительную проверку, упаковку, раскрытие и выполнение.
Вы компилируете ваши MIDP-приложения с помощью стандартного компилятора J2SE. Новая утилита предварительной проверки создает проверенные файлы .class, которые могут быть интерпретированы как KVM, так и стандартной виртуальной машиной J2SE.
Эмуляторы являются важными инструментами при разработке приложений для мобильных устройств. Они дают вам возможность проделывать начальное тестирование без вынужденного использования настоящего устройства. Это, в частности, важно для тестирования логической правильности ваших приложений, поскольку среды тестирования и отладки недоступны на настоящих устройствах. Однако эмуляторы не являются заменителями тестирования на реальных устройствах. Вы должны протестировать каждый аспект приложения на реальном устройстве до его выпуска как готового продукта.
Инструментарий J2ME Wireless Toolkit содержит инструменты разработки приложений и эмулирования, которые дадут вам возможность выполнять все этапы процесса разработки, а именно: компилирование, предварительную проверку, упаковку, раскрытие и выполнение.

Это MIDP-версия знакомой вам программы HelloWorld

import javax.microedition.lcdui.Display;

import javax.microedition.lcdui.Displayable;

import javax.microedition.lcdui.Form;

import javax.microedition.midlet.MIDlet;

/**

Создание программы «Hello world» в J2ME MIDP.

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

управления приложениями устройства могла создать его экземпляр.

public class HelloWorld extends MIDlet

{

// Displayable. Этот компонент отображается на экране, private Form form;

// Display. Этот объект управляет всеми компонентами

// Displayable.

private Display display;

// Открытый конструктор no-arg необходим, даже хотя система

// вызывает startAppO! AMS вызывает конструктор

// no-arg класса для создания экземпляра класса.

// Либо создайте открытый конструктор no-arg, либо

// объявите об отсутствии конструкторов и позвольте

// компилятору создать открытый конструктор no-arg. public HelloWorldO

{

super () ; I

public void destroyApp(boolean destroy)

form = null;

notifyDestroyed();

}

public void pauseAppO

}

public void startAppf)

// Создайте элемент Displayable. form = new Form (."Hello, World");

// Добавьте строку в форму. String msg = "My first MIDlet!"; form.append(msg);

// Это приложение просто выводит на экран одну форму, созданную выше.

display = Display.getDisplay (this) ;:

display.setCurrent(form);

}

Во-первых, отметьте, что это приложение описывает класс, называемый HelloWorld, который дополняет javax.microedition.midlet.MIDlet. Все MID-леты должны дополнять этот класс.

Класс HelloWorld является основным классом вашего приложения. По этой причине он должен быть объявлен открытым (public). Более того, вы должны объявить открытый безаргументный (no-argument) конструктор или убедиться, что конструкторов нет, в этом случае компилятор определит безаргументный конструктор для вас. Те читатели, которые знакомы с апплетами Java, найдут сходство между моделями управления жизненным циклом апплета и MID-лета.

Когда вы выберете HelloWorld в главном окне AMS, AMS запустит ваше приложение и создаст экземпляр класса HelloWorld. Технически она запустит виртуальную машину (или убедится, что она запущена) и проинструктирует ее создать экземпляр вашего класса. В этом случае виртуальная машина называется безаргументным конструктором.

AMS затем вызовет метод startAppO. В листинге 3.1 методы startApp(), pauseApp() и destroyApp() подменяют абстрактные объявления класса MIDlet. Обратите внимание на то, что все кода инициализации входят в метод startApp (), а не в конструктор. Вы, естественно, можете добавить какой-либо код инициализации в ваш конструктор, он будет выполнен перед вызовом startApp(). Однако метод startApp() всегда вызывается в качестве входной точки вашего MID-лета.

А как насчет метода main ()? Определение языка Java требует, чтобы все приложения на Java имели метод main () со следующей сигнатурой:

public static void main(String [] args)

Если приложения на J2ME являются настоящими приложениями Java, а это требование я оговаривал ранее, тогда где-то должен быть главный метод, который является реальной точкой входа, используемой виртуальной машиной для запуска процесса выполнения приложения. В действительности существует такой метод. Это часть реализации MIDP (не приложения), и, обычно, программное обеспечение AMS вызывает его. Программа AMS обрабатывает запросы вызова приложения, например, порождая подпроцесс нити запроса запуска каждого MID-лета и контролируя MID-лет из этой нити. Реальные детали зависят от продукта. В J2ME Wireless Toolkit компании «Sun» класс com.sun.midp.Main определяет метод main().

Метод startApp() создает объект, называемый формой, и пересылает в конструктор строку, которая представляет из себя название формы. Форма - это экземпляр класса javax.microedition.lcdui.Form, который является разновидностью экрана, отображаемого на вашем дисплее. Она имеет такое название, поскольку ее функции в чем-то сходны с функциями формы HTML - она содержит один или более визуальных элементов, таких как строки.

Затем метод startApp() создает стандартный объект String и добавляет его в форму. Он затем получает ссылку на объект, называемый display, и устанавливает объект формы в качестве текущего отображаемого на дисплее объекта.

Когда этот код выполняется, вы видите экран, изображенный на рисунке 3.4. Когда вы нажимаете на кнопку с телефонной трубкой, которая сообщает устройству об отключении, AMS вызывает destroyApp(), который просто устраняет все ссылки на объект формы, созданные перед этим. Теперь наступает время сборки мусора. Затем AMS закрывает MID-лет.

Вы отвечаете за правильное расположение объектов, созданных вашими МЮ-летами. В случае с данным примером не должно иметь значения, задали ли вы то, что ссылки на формы изменяются до нуля, поскольку MID-лет был закрыт. Но, в общем, вам необходимо правильно управлять ссылками на объекты вашей программы, как и в любой программе Java.

MID-леты имеют прямой

import javax.microedition.Icdui.Display;

import javax.microedition.Icdui.Displayable;

import javax.microedition.Icdui.Form;

import javax.microedition.midlet.MIDlet;

/**

Создание программы «Hello world» в J2ME MIDP.

Заметьте, что класс должен быть открытым, для того чтобы программа

управления приложениями устройства могла создать его экземпляр.

public class HelloWorld extends MIDlet

public void startApp()

{

// Создайте элемент Displayable. form = new Fo.rmC'Hello World");

// Добавьте строку в форму. String msg = "My first MIDlet!"; form.append(msg);

// Это приложение просто выводит на экран одну форму, созданную выше.

display = Display.getDisplay(this);

display.setCurrent(form);

printSystemPropertiesf) ;

/**

Вывести значения стандартных системных свойств

С помощью вызова System.getProperty().

protected void printSystemProperties()

String conf;

String profiles; String platform; String encoding; String locale;

conf = System.getProperty("microedition.configuration") ;

System.out.println(conf);

profiles = System.getProperty("microedition.proflies");

System.out.println(profiles);

platform = System.getProperty("microedition.platform");

System.out.println(platform);

encoding = System.getProperty("microedition.encoding");

System.out.println(encoding);

locale = System.getProperty("microedition.locale");

System.out.println(locale);
System.out.println();

}

Обратите внимание на добавление вызова к методу printSystemProperties () в конце метода startApp(). Этот метод просто извлекает и отображает стандартные данные значений пяти стандартных системных свойств MIDP. Данные, которые программа записывает в стандартные результаты, показаны здесь:

CLDC-1 .0

MIDP-1.0

J2me

ISO-8859-1

enJJS

Четвертая строчка выходных данных просто воспроизводит набор знаков кодировки, который использует текущая реализация платформы CLDC/MIDP. Последняя строка выходных данных отражает текущую локализацию. Спецификации локализации включают две части: первая часть показывает языковые настройки, в то время как вторая часть показывает код страны. Международная организация по стандартизации (ISO) издает два стандарта, которые определяют набор приемлемых значений для языкового и странового кодов.

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

Измененный метод

public void startApp()

// Создайте элемент Displayable. form = new FormC'Hello, World")/'

// Добавьте строку в форму. String msg = "My-first MIDlet!"; form.append(msg);

// Это приложение просто выводит на экран одну форму,

// созданную выше.

display = Display.getDisplay (this) ;

display.setCurrentfform);

printSystemProperties () ; printAppProperties () ) ) ;

}

Метод, показанный в листинге 3.3, выдает значения стандартных свойств приложения MID-летa в стандартный результат. Листинг 3.4 показывает метод printAppProperties().

Атрибуты MID-лета

/ * *

Вывести свойства приложения с помощью вызова

MIDlet.getAppProperty ().

protected void printAppProperties ()

(

System.out.println(getAppProperty("MI Diet-Name"));

System.out.println(getAppProperty("MIDlet-Jar-Size"));

System, out. println (getAppProperty ("MI Diet-Jar-URL ")) ;

System.out.println(getAppProperty("MIDlet-Vendor"));

}

Эта последняя версия программы HelloWorld теперь выводит следующие строки в дополнение к стандартному результату, который вы можете видеть в окне основной консоли Wireless Toolkit. Метод printAppProperties () выводит последние четыре строки результата.

CLDC-1.0

MIDP-1.0

J2me

ISO-8859-1

en_US

HelloWorld 6781

HelloWorid.jar Vartan Piroumian

Четыре атрибута, выбранные в листинге 3.4, являются стандартными свойствами приложений, доступными для всех MID-летов. Однако вспомните главу 2 и то, что в таблице 2.4 описаны некоторые дополнительные обязательные атрибуты MID-лета. Также спецификация MIDP определяет некоторые необязательные дополнительные атрибуты, в таблице 2.5 перечислены эти необязательные атрибуты. Ваши приложения имеют доступ к ним ко всем через механизм, продемонстрированный в листингах 3.3 и 3.4.

Кроме того, MID-леты могут описывать необязательные зависимые от приложения атрибуты. Вы можете описать так много связанных с приложением свойств, сколько хотите. Ваше приложение будет затем получать к ним доступ с помощью метода MIDlet.getAppProperty(), показанного в листингах 3.3 и 3.4. Эта возможность является своего рода конфигурированием или механизмом настройки MID-летов. Вы увидите некоторые примеры выборочного описания атрибутов и их использования в главе 9.

Модель компонентов пользовательского интерфейса MIDP

Компоненты пользовательского интерфейса MIDP определены в пакете javax.microedition.Icdui. Название этого пакета, возможно, изменится в будущих выпусках, поскольку его имя слишком близко связано с определенным типом физических устройств отображения. Компоненты пользовательского интерфейса MIDP составляют большинство классов в этом пакете. Понимание организации этих компонентов пользовательского интерфейса является наиважнейшим при создании приложений MIDP.

Листинг 3.1 предлагает первую демонстрацию использования некоторых из этих компонентов. Последние две строчки метода startApp() обращают особое внимание на вопрос модели программирования пользовательского интерфейса MIDP и демонстрируют, как взаимодействуют классы основных компонентов пользовательского интерфейса:

display = Display.getDisplay (this);

display.setCurrentl form);

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

Форма является одним из видов отображаемых компонентов, которые могут иметь визуальное представление. Отображаемый компонент в MIDP является верхнеуровневым компонентом пользовательского интерфейса. Верхнеуровневые компоненты могут быть самостоятельно отображены MID-летом. То есть они не нуждаются в том, чтобы содержаться внутри любого другого компонента - в действительности они и не могут. Приложение MIDP может отображать только один компонент верхнего уровня за раз.

Для программистов на AWT и Swing компонент верхнего уровня MIDP эквивалентен java.awt.Frame или java.awt.Window в инструментариях Swing и AWT. Продукт MIDP управляет компонентами верхнего уровня так же, что и собственная система окон управляет Window в реализации платформы J2SE.

Когда AMS запускает MID-лет, она делает следующее:

Она задает класс Display.

Она связывает экземпляр Display с вашим экземпляром MIDlet.

Ваша программа никогда не создает объект Display, а реализация MIDP делает это. Ваш MID-лет создает только компоненты пользовательского интерфейса - экземпляры конкретного подкласса Displayable или Item, которые будут отображены на экране в течение жизненного цикла вашего MID-лета. Вы сообщаете объекту Display, когда показывать ваши отображаемые компоненты, вызывая метод Display.setCurrent().

Здесь взаимодействуют три основных объекта: ваш экземпляр MIDlet, экземпляр Display, созданный AMS, и компонент Displayable, который вы хотите отобразить на экране. На рисунке 3.6 показана диаграмма связей между объектами.

Рисунок 3.6. Реализации MIDP создают только один объект Display на один MID-лет. Ваш MID-лет является примером вашего основного класса, который дополняет класс MID-лета. Однако он может создавать много объектов Displayable

Важными понятиями являются следующие:

Объект Display управляет физическим дисплеем.

Display может отображать объекты Displayable.

Вы должны получить ссылку на объект Display, связанный с вашим MID-летом реализацией MIDP.

Только один объект Displayable может быть отображен единовременно.

Диаграмма наследования является прекрасным инструментом, способным помочь в систематизации понимания модели программирования и связей между классами. На рисунке 3.7 показана диаграмма наследования всех классов в пакете javax.microedition.lcdui.

В частности, отметьте равнородные связи между типами Display и Displayable, их цели различны, поэтому они не имеют связей наследования. Также отметьте, что Form, которую создала наша программа «Hello World», является видом Displayable, называемым Screen. По идее эта организация поддерживает понятие того, что Form может взять на себя роль screen верхнего уровня.

Screen также является абстрактным классом. Он инкапсулирует природу всех типов объектов верхнего уровня экрана в MIDP. Form является отдельным конкретным подклассом Screen, используемым MID-летом HelloWorld.

MID-лет HelloWorld добавляет String в Fora.

Эта способность объединять объекты делает класс Form разновидностью контейнера. Хотя контейнеры являются основой моделей программирования AWT и Swing, MIDP не имеет на самом деле такого понятия. Класс Form является единственным типом MIDP, который способен содержать что-либо еще.

Формы могут содержать только три типа объектов: Strings, Images и Items. Form не может содержать другой Displayable любого рода, даже Screen или другой Form. Иерархия наследования, показанная на рисунке 3.7, подтверждает это. Это означает, что формы не могут быть представлены в форме вложений. Эта модель значительно упрощает структуру приложений MIDP по сравнению с графическим интерфейсом пользователя AWT или Swing. Поддержка вложенной структуры означала бы, что реализации пришлось бы поддерживать абстракцию визуального представления исполняемой иерархии вложенности для пользователя. Эта возможность была намеренно исключена из MIDP, потому что ресурсы, требуемые для поддержки родственных абстракций, слишком дороги для мобильных устройств.

Обратите внимание, что на рисунке 3.7 классы Item и Image не находятся под иерархией Displayable и поэтому не являются отображаемыми объектами. Items, Images и Strings могут быть добавлены в формы с помощью методов из класса Form, показанных в таблице 3.3.

Таблица 3.3. Методы класса формы для добавления элементов в объект Form

Название метода класса формы	Описание
public int append (Item item)	К данной форме добавляется объект Item
public int append (String string)	К данной форме добавляется объект String
public int append (Image image)	К данной форме добавляется объект Image

Класс Form реализует абстракции, необходимые для отображения объектов String, Image и Item. Он также отвечает за реализацию политики организации объектов, которые были к нему добавлены. Другими словами, реализация Form определяет политику расположения.

Тем не менее, в MIDP нет понятия диспетчеров расположения, которыми мог манипулировать программист на AWT или Swing.Спецификация MIDP рекомендует, чтобы реализации Form сопровождались компоновкой, но она не устанавливает обязательных правил. Реализации могут варьироваться в способе, которым они осуществляют компоновку формы.

Иерархия Item определяет визуальные компоненты. Вы должны, однако, различать эти компоненты, которые имеют визуальное представление и отображаемые компоненты, которые являются компонентами высшего уровня. Отражены могут быть конкретные подклассы Itern. Однако они не могут быть отображены независимо как компоненты высшего уровня Screen. Более того, они могут быть отображены только с помощью объекта Fo rm, но не другого типа Screen.

Модель состояний MID-лета

MID-леты переходят к различным состояниям в течение их жизненного цикла. Спецификация MIDP определяет модель перехода из режима в режим. В таблице 3.1 перечислены возможные состояния MID-лета и их соответствующие описания.

Таблица 3.1. Состояния MID-лета

Название состояния MID-лета		Описание
Paused (Приостановлен)		MID-лет не выполняется. Он не может начать работу до тех пор, пока не перейдет в активное состояние.
Active (Активен)		MID-лет либо готов к запуску, либо запущен. Процесс, который управляет MID-летом, может не быть в запущенном состоянии, но MID-лет все равно активен.
Destroyed (Прерван)		MID-лет не запущен и уже не может переходить в другие состояния.

На рисунке 5 показана диаграмма перехода из состояния в состояние, которая представляет из себя эти режимы MID-лета и события, которые служат причиной перехода из одного состояния в другое. Методы startApp(), pauseApp() и destroyApp(), которые вы видели в листинге 3.1, позволяют MID-лету изменять свое состояние. Технически программа управления приложениями устройства изменяет состояние MID-лета, вызывая один из этих методов в MID-лет. MID-лет не может сам изменять свое состояние, хотя он может запрашивать об изменении состояния AMS.

Программа управления приложениями сначала создает экземпляр класса вашего MID-лета, вызывая его конструктор no-argument. Затем она устанавливает его в приостановленное состояние. Прежде чем MID-лет сможет выполняться, AMS должна поместить MID-лет в активное состояние в первый раз. Она помещает MID-лет в активное состояние и затем вызывает метод MID-лета startApp ().

Рисунок 3.5. MID-лет может находиться в одном из трех состояний. Когда AMS впервые создает МЮ-лет, MID-лет существует в приостановленном состоянии

Программа управления приложениями помещает MID-лет в приостановленное состояние, вызывая метод pauseApp(). MID-лет может также запрашивать AMS о входе в приостановленное состояние, вызывая свой метод notifyPausedf). MID-лет может после этого запрашивать, чтобы он был помещен в активное состояние, вызывая resumeRequest ().

AMS может сигнализировать MID-лету, что он должен привести себя в порядок и подготовиться к тому, что он будет прерван с помощью вызова метода MID-лета destroyApp(). MID-лет может сигнализировать о завершении своего выполнения AMS, вызывая notifyDestroyed(). В таблице 3.2 перечислены методы класса javax.microedition.midlet.MIDlet, которые управляют состоянием MID-лета.

Таблица 3.2. Методы классов MID-летов, управляющие состояниями MID-летов

Название метода класса MID-лета	Описание
protected abstract void destroyAppf)	AMS сигнализирует MID-лету о прекращении работы. MID-лет входит в прерванное состояние
void notifyDestroyed ()	MID-лет запрашивает о входе в прерванное состояние
void notifyPausedf)	MID-лет запрашивает о дезактивации и входе в приостановленное состояние
protected abstract void pauseApp()	AMS сигнализирует MID-лету остановиться, MID-лет входит в приостановленное состояние
void resumeRequest ()	МЮ-лет запрашивает о повторном входе в активное состояние
protected abstract void startApp()	AMS сигнализирует MID-лету, что он активен

Обратите внимание на то, что программа в листинге 3.1 не вызывает System.exit(). Приложения MIDP отличаются от приложений J2SE тем, каким образом они заканчивают работу. Для завершения работы вашего MID-лета вы просто должны вызвать метод MID-лета notifyDestroyed(). Это сигнализирует AMS, что ваш MID-лет завершил выполнение. AMS закрывает MID-лет и все его объекты. Однако виртуальная машина продолжает работу.

Вы хотите, чтобы виртуальная машина продолжала работу, чтобы можно было запустить другие MID-леты. Вызов System.exit() сигнализирует виртуальной машине завершить свою работу. Такое поведение нежелательно в приложениях MIDP. Ваши приложения не должны завершать работу виртуальной машины, в действительности они и не могут этого сделать. Если ваше приложение вызывает System.exit(), java.lang.SecurityException обязательно прекратит работу. Вы увидите что-либо сходное со следующим:

java.lang.SecurityException: MIDP lifecycle does not support system exit.

(Жизненный цикл MIDP не поддерживает системный выход).

at Java.lang.Runtime.exit(+9)

at Java.lang.System.exit(+7)

at HelloWorld3$MyCommandListener.commandAction(+15)

at javax.microedition.Icdui.Display$DisplayAccessor.

commandAction(+99)

at сот.sun.kvem.midp.Icdui.EmulEventHandler$EventLoop.run(+430)

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

Программная cтpyктypa MID-лета

Теперь, когда.вы изучили жизненный цикл приложения, наступило время взглянуть на исходный код простого MID-лета. Вы, возможно, уже догадались, что я собираюсь начать с показа наипростейшего MID-лета - MIDP-версии все той же злополучной программы «HelloWorld». В листинге 3.1 показан исходный код для первой версии MID-лета HelloWorld.

Системные свойства

CLDC/MIDP поддерживает системные свойства, которые являются парами «ключ-значение», представляющими информацию о платформе и среде, в которой выполняются приложения MIDP. Теоретически это тот же тип свойств, который вы найдете в J2SE. К сожалению, в CLDC/MIDP нет класса Java.util.Properties для облегчения вашей работы со свойствами.

Спецификация MIDP определяет только небольшой набор стандартных свойств, которые показаны в таблице 3.4. Реализации могут поддерживать дополнительные системные свойства определенных производителей, но необязательно. Вы должны знать о том, свойства какого производителя или платформы вы используете для того, чтобы предупреждать проблемы с мобильностью.

Как и приложения J2SE, приложения MIDP могут отыскивать системные свойства с помощью класса java.lang.System. Чтобы узнать значение свойства, используйте метод класса System

String getProperty(String key)

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

Таблица 3.4. Стандартные системные свойства CLDC

Ключ свойства	Описание	Значение по умолчанию
mi с г oedit ion. con figuration	Название и версия поддерживаемой конфигурации	CLDO1.0
microedit ion. encoding	Набор знаков кодировки по умолчанию, используемый платформой	IS08859-1
micr oedit ion. locale	Название текущей местной среды платформы	нуль
microedition. platform	Название платформы или устройства	нуль
micr oedition. profiles	Названия всех поддерживаемых профилей	нуль

Листинг 3.2 иллюстрирует отслеживание системных свойств в MID-лете. Код дополняет пример, указанный в листинге 3.1.

Свойства приложения

Вы узнали о наличии определенных атрибутов MID-лета, которые описываются в файле JAD каждого набора MID-летов. Вспомните, что всем MID-летам требуются атрибуты. Таблица 2.4 перечисляет требуемые атрибуты MID-лета, которые находятся в файле дескриптора приложения. MID-лет может получать доступ к значениям этих атрибутов во время выполнения через программу управления приложениями.

Когда AMS устанавливает набор MID-летов на устройстве, она размещает JAD-файл MID-лета в определенном месте под своим контролем. Когда MID-лет запускается, AMS считывает JAD-файл и строит структуру данных атрибутов приложения. MID-лет может считывать значение атрибута с помощью метода класса MIDlet

String getAppProperty(String key)

Параметр key является именем атрибута, например, MIDlet-Name. Возвращаемая строка является связанным значением, находящимся в файле JAD.

Листинг 3.3 демонстрирует, как MID-лет может извлекать атрибуты. Он модифицирует листинг 3.2, добавляя вызов к методу printAppProperties() в конце метода startApp(). Новый метод startApp() :

В этой главе вы узнали

В этой главе вы узнали о базовой организации и структуре приложений 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 устройства во время выполнения.

Жизненный цикл выполнения приложения

Здесь приведен пример этапов, включаемых в выполнение приложения:

Запуск эмулятора. Вы увидите появившееся окно, которое имитирует интерфейс устройства. Если вы используете J2MEWTK версии 1.0.2, вы заметите, что эмулятор просто выполняет приложение HelloWorld, потому что это единственное приложение, присутствующее в наборе. На рисунке 3.1 показано главное окно выполнения этого MID-лета. Однако, если у вас J2MEWTK версии 1.0.3, вы увидите список выбора из всех MID-летов, даже если он у вас один.

Добавьте вторую версию программы, названную HelloWorld2, к набору MID-летов. Вы можете начать этот процесс, нажав на кнопку Settings... (Параметры...) на основном окне инструментария, которое вы видели на рисунке 2.5. Во-первых, напишите исходный код и затем поместите его в директорию проекта srс /. Добавьте его к набору MID-летов, выбрав закладку MIDlets (MID-леты) в окне параметров проекта. На рисунке 3.2 показано окно конфигурации после добавления нового MID-лета.

Экранная навигация

Пример HelloWorld2 демонстрирует центральную абстракцию MIDP - Screen. Вы, несомненно, уже обратили внимание, что.можете отображать одновременно только один Displayable - один Screen. Когда приложению необходимо отобразить Alert, ему приходится заменять основной экран.

Причина этой одноэкранной абстракции кроется в ограниченности экранных ресурсов устройства. В отличие от инструментов графических пользовательских интерфейсов для настольных компьютеров, таких, как J2SE Swing toolkit, вы не можете иметь большое количество накладываемых друг на друга окон, всплывающих уведомлений, диалоговых окон и так далее. Хотя внедрение этих абстракций и не невозможно, требования памяти и ЦП на современных мобильных устройствах таковы, что фактически запрещают это. Более того, жидкокристаллические дисплеи с низким разрешением, низким потреблением энергии и маленькой площадью, характерные для большинства мобильных устройств, не приспособлены для этих абстракций. Даже дисплеи «карманных компьютеров» имеют минимально приемлемые характеристики для наложения окон, всплывающих окон и тому подобного. Однако очень вероятно, что примерно через год эти устройства будут иметь значительно большие мощности, порядка 50 МГц и 32 Мб RAM.

Существует простая идиома экранной навигации, связанная с этой абстракцией экранов дисплея. Если вы хотите отобразить новый экран, просто установите, что экран является отображаемым в настоящий момент (current displayable). Чтобы сделать это, вы запрашиваете.объект Display вашего MID-лета на отображение Screen. Вспомните, в главе 2 вы узнали, что каждому MID-лету при запуске присваивается уникальный объект Display реализацией MIDP. Вы никогда не создаете объект Display, но вы можете получить ссылку на него, сделав следующий вызов со ссылкой на ваш MID-лет как на аргумент: Display.getDisplay(midlet);

Затем вы просто делаете вызов метода, показанный далее, с аргументом, который ссылается на Displayable, который вы хотите отобразить:

display.setCurrent(nextDisplayable)

Вы можете найти эти две строчки кода в методе startAppf) обеих версий приложения HelloWorld.

Разработка навигации и перемещений в вашем МЮ-лете включает следующие этапы:

Создание экранов.

Создание команд, которые вам нужны для каждого экрана.

Присвоение команд экранам.

Для каждой команды каждого экрана определите следующий экран для отображения результата выполнения каждой команды.

Важным атрибутом успешных приложений MIDP является легкая, интуитивная навигация между окнами. Анализ задач пользователя является темой отдельной книги и лежит за пределами темы данной книги. Самым важным, однако, является умение думать с точки зрения пользователя. Делайте все простым. Не путайте ваших пользователей, прыгая с места на место, так что пользователь не сможет следовать навигации. Слишком легко пользователю потеряться при просмотре на маленьком экране без контекстной привязки ко всему приложению. И никогда не создавайте ваши экраны, приспосабливая их к внутренней организации вашего приложения, его структуре данных, классам и так далее. Наоборот, позвольте дизайну вашего приложения следовать расположению, дизайну, навигации, последовательности экранов и так далее.

Oбpaбoткa кoмaнд

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

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

Класс Command в пакете javax.microedition.lcdui описывает команды. Этот класс инкапсулирует информацию о:

метке (label);

приоритетности (priority);

типе команды (command type).

Метка - это String, подходящая для дисплея, с условием, что она может предоставлять пользователю семантику команды. Приоритетность является int, которая отражает важность команды по отношению к другим командам. Тип команды - это внутреннее представление намеченного использования команды. Текущая спецификация определяет типы команды, перечисленные в таблице 4.1.

Организация команд

Взглянув более внимательно на пример, приведенный в предыдущем разделе, вы можете догадаться, что на самом деле вы не можете контролировать то, где появляется каждая из меток Command на экранных клавишах. Как-никак, я не указывал левую или правую экранную клавишу для размещения обеих Command. Приложение HelloWorld2 добавило клавиши «Alert Me!» и «Say Hi», в таком порядке. Первая появилась на правой экранной клавише, вторая - на левой.

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

Следующая версия нашей программы HelloWorld, HelloWorldS, добавляет третью команду к главному экрану. Вместо того чтобы приводить вновь весь MID-лет целиком, я просто покажу части, которые отличаются от предыдущего примера.

В масштабах класса HelloWorld3 определяет три объекта Command:

/**

Третья версия приложения HelloWorld.

Эта версия встраивается поверх HelloWorld2 с помощью добавления

нескольких команд к компоненту Displayable. Здесь демонстрируется,

что ComraandListener должен определять, какая из команд была

активирована на экране.

Вы также можете видеть, как реализация расставляет команды

на экранных клавишах и как она создает меню и упорядочивает команды

в меню в соответствии с типом команды.

public class HelloWorld3 extends MIDlet,

{

Command showAlert= new Command("Alert Me!", Command.SCREEN, 1);;

Command sayHi = new Command("Say Hi", Command. SCREEN, I);-;

Command cancel = new Command("Cancel", Command.CANCEL, 1);

public HelloWorld3()

{

super ();

}

. . .

}

В методе startApp() эти объекты Command добавляются к главному экрану следующим образом:

form.addComraand(showAlert) ;

form.addCommand(sayHi) ;

form.addCommand(cancel);

Создание и запуск этой новой версии в эмуляторе J2ME Wireless Toolkit Emulator отражен в главном экране, показанном на рисунке 4.7.

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

Устройства имеют только две экранные клавиши, но мы вставили три команды в наш главный экран. Реализация обнаружила это и создала меню, которое содержит вторую, третью и другие команды. На рисунке 4.8 показан дисплей после того, как вы выбрали клавишу «Меню».

Запустите эту последнюю немодифицированную версию с помощью эмулятора Motorola iS5s, и вы увидите, что ключ «Меню» появится на левой экранной клавише, что отражено на рисунке 4.9. В действительности рисунки 4.8 и 4.9 демонстрируют, что конкретное поведение и политика размещения меню зависят от реализации.

Сценарий 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 может иметь только один командный блок прослушивания

В отличие от инструментария Swing MIDP не имеет общей модели блока прослушивания событий. Высокоуровневый API имеет только один тип командного блока прослушивания, называемого, что неудивительно, javax.microedition.lcdui.Command-Listener.

В листинге 4.1 показана вторая версия MID-лета HelloWorld. Она добавляет экранные клавиши к главному окну и устанавливает блок прослушивания команд для распознавания нажатия пользователем на экранную клавишу. MID-лет отвечает, показывая другой вид экрана, называемый уведомлением (alert), который является MIDP-эквивалентом всплывающего диалогового окна.

Листинг 4.1. В программу HelloWorld2 добавлена обработка команд

import javax.microedition.midlet.MIDleC;

import javax.microedition.lcdui.Alert;

import javax.microedition.lcdui.AlertType;

import javax.microedition.lcdui.Command;

import javax.microedition.lcdui.CommandListener;

import javax.microedition.lcdui.Display;

import javax.microedition.ledui.Displayable;

import javax.microedition.lcdui.Form;

* /**

Вторая версия приложения HellcWorld.

Эта версия добавляет команду в компонент Displayable и устанавливает

* /

• блок прослушивания команд для активации команд и принятия какого-либо

действия в ответ на нее. Этот пример демонстрирует, как Displayable

определяет семантику выполнения команд.

*/

public class HelloWorld2 extends M.I Diet

// Display. Этот Объект управляет всеми компонентами Displayable.

private Display display;

// Displayable. Этот компонент отображается на экране, private-Form form;

private final String ALERT_LABEL = "Alert Me!"; private Alert alert;

// Две команды добавлены к отображаемым на экране объектам

// этого MID-лета. private Command showAlert; private Command sayHi;

// Экземпляр внутреннего класса, который определяет

// CommandListener для этого MID-лета.

private MyCommandListener cl = new MyCommandListener();

public HelloWorld2()

(

super();

public void destroyApp(boolean destro()

form = null; notifyDestroyed();

}

public void pauseApp()

)

public void startApp()

form = new Form("Hello World();

String msg = "My second MIDletl"; form.appendjmsg);

form.setCommandListener(cl) ;

showAlert = new Command(ALERT_LABEL, Command.SCREEN, 1);

form.addCommand(showAlert) ;

sayHi = new Command("Say Hi", Command.SCREEN, 1);

form.addCommand(sayHi);

display = Display.getDisplay(this) ; display.setCurrent(form);

}

private class MyCommandListener implements CommandListener

public void commandAction(Command c, Displayable d)

{

'alert = new Alert("Button pressed",

"The '" + ALERT_LABEL + "' button was pressed", null, AlertType.INFO); alert.setTimeout(Alert.FOREVER); display.setCurrent(alert, form);

}

}

}

Я создал вышеописанный МID-лет HelloWorld2 с помощью моего любимого текстового редактора. Затем я разместил исходный файл под управление установленного у меня инструментария Wireless Toolkit:

? pwd

/cygdrive/c/J2mewtk/apps/HelloWorld/src

$Is

HelloWorld.lava HelioWorld2.Java

$

J2ME Wireless Toolkit компилирует все файлы .Java в директории. Компиляция проекта HelloWorld компилирует обе версии HelloWorld. На рисунке 4.3 показан стартовый экран эмулятора, который появляется, когда я открываю проект HelloWorld. Обратите внимание, что теперь вы видите два MID-лета в списке. Используя клавиши стрелок, выберите HelloWorld2 и запустите его, нажав экранную кнопку Launch (Запуск).

На рисунке 4.4 показан главный экран HelloWorld2. Обратите внимание, что теперь справа появилась экранная клавиша под названием «Alert Me». На этом устройстве недостаточно места, чтобы показать полное сообщение «Alert Me!», которое установлено в исходном коде - так что восклицательный знак пропущен.

Это первая проблема транспортабельности, с которой вы столкнулись, и она имеет практическое значение. К счастью, эмулятор поддерживает четыре различных устройства. Вы можете выполнить ваши MID-леты с помощью любого из четырех эмуляторов устройств, поддерживаемых эмулятором J2ME Wireless Toolkit Emulator, чтобы посмотреть, как они выглядят на каждом. Таким образом вы можете обнаружить множество потенциальных проблем, связанных с транспортабельностью.

Рисунок 4.3. Добавление нового MID-лета к набору приводит в резул: тате к тому, что AMS отображает меню, из которого вы выбираете приложение, которое хотите запустить

Рисунок 4.4. Основной экран MID-лета HelloWorld2

Ha рисунке 4.5 показан основной экран HelloWorld2, как он появляется при имитировании устройства Motorola i85s. Обратите внимание, что в отличие телефона со стандартными настройками, он способен отображать полный текст команды на экранной клавише. Есть также вторая Command с меткой «Say Hi», которая появляется на экранной клавише слева.

Нажатие на экранную клавишу «Alert Me!» отображает экран уведомления, показанный на рисунке 4.6. Действие отображения этого экрана является поведением, которое HelloWorld2 определило для команды, связанной с выбором экранной клавиши.

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

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

Семантика команд

Взгляните вновь на команду «Exit» («Выход»). Объект Command определяется с помощью метки «Exit» («Выход»). Но это не делает команду командой выхода! Я указал тип Command.EXIT в вызове конструктора. Это указание атрибута типа делает команду командой «Exit» («Выход»). Если бы я задал ее тип, как, скажем, Command. SCREEN, эта команда не появилась бы на экранной клавише. Вы можете попробовать проделать это самостоятельно.

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

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

Я определил различные приоритеты для каждой команды в примере HelloWorldS. Вы можете убедиться, что приоритетность не влияет на размещение команд. Если вы немного поэкспериментируете с меню, вы сможете выяснить политику размещения команд реализации каждого устройства, предоставляемого эмулятором. Вы также можете изменить приоритетность команд в исходном коде и увидеть, как это влияет на_их размещение.

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

Типы команд

Константа типа команды		Описание
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		Остановка некоторой выполняемой в настоящее время операции

Упорядочивание команд

Вы, должно быть, удивлены, почему команда «Cancel» (Отмена) была помещена на экранную клавишу, даже несмотря на то, что бна была добавлена на экран последней. Интуитивно вы можете предположить, что она должна добавляться последней в меню. Вы бы предположили, конечно, что клавиша «Alert Me!», которая была добавлена первой, должна быть на экранной клавише.

Объяснение этого очевидного отклонения заключается в том, что команды организуются в соответствии с их типом. Вспомните из предыдущего раздела этой главы, что одной из трех частей информации, которые определяют Command, является тип команды. Класс Command определяет константы, которые представляют собой действующие типы. Вы видели перечисление этих констант в таблице 4.1.

Теперь я добавляю следующие объекты Command в пример HelloWorld3. На уровне классов я определяю следующие новые команды:

...

public class HelloWorid3 extends MIDlet

private Command exit = new Command("Exit", Command.EXIT, 2);

private Command help = new Command ("Help", Command.HELP, 3);

private Command item. = new Command ("Item", Command . ITEM, 4 ) ;

private Command ok = new Command("OK", Command.OK, 5);

private Command screen = new Command("Screen", Command.SCREEN, 6);

private Command stop = new Command("Stop", Command.STOP, 7);

...

}

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

В методе 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 определяет политику размещения команд в соответствии с их типом

Размещение команд осуществляется в соответствии с их типом. Конкретная же политика, однако, зависит от реализации.

В этой главе вы узнали

В этой главе вы узнали о высокоуровневом программном интерфейсе приложения (API) MIDP. Абстракции высокоуровневого API описывают следующее:
визуализация элементов пользовательского интерфейса;
обработка событий.
MID-леты, которые используют высокоуровневый API, не могут изменять внешний вид и впечатление от элементов, И они не могут получать информацию о реальных клавишах устройства и нажимаемых кнопках, которые служат причиной активизации команды.
Команды получают только семантическую информацию о «событии». Команда не представляет собой поведение или действие, которое осуществляется в ответ на событие. Блоки прослушивания команд задают поведение команд, определяя обработку, которая осуществляется в результате запуска команды реализацией.
Определенная политика размещения меток команд на экране зависит от реализации. MIDP устанавливает, что размещение команд в меню должно быть сделано в соответствии с типом команды.
Приоритетность команд диктуется порядком, в котором команды запускаются и посылаются в блок прослушивания команд.