Текст книги "Платформа J2Me"

Автор книги: Автор Неизвестен

сообщить о нарушении

Текущая страница: 2 (всего у книги 21 страниц)

Отсутствие поддержки плавающей точки является основным отличием на языковом уровне виртуальной машины 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 предназначена для персональных мобильных устройств с ограниченным соединением

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

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

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

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

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

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

Глава 2. Процесс разработки приложений MIDP

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

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

Различные производители мобильных устройств и разработчики комплектующего оборудования предлагают эмуляторы, которые запускаются на стандартных настольных операционных системах. Отдел «Java Software» компании «Sun Microsystems», например, предлагает инструментарий J2ME Wireless Toolkit (J2MEWTK), который запускается на платформах Windows и Unix. Он содержит эмулятор, компилятор, виртуальную машину, библиотеки классов и другие полезные инструменты разработки. Вы можете загрузить его бесплатно с сайта http://java.sun.com.

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

1. Проектирование и кодирование – написание программы.

2. Компилирование – компилирование программы с помощью стандартного компилятора J2SE Java.

3. Предварительная проверка – выполнение предварительной проверки обработки классов Java до упаковки: проверка использования операций с плавающей точкой и методов завершения в классах Java.

4. Упаковка – создание архивного файла JAR, содержащего ресурсы приложения, создание файла описания приложения, содержащего метаинформацию о приложении.

5. Раскрытие – распаковка и размещение ресурсов приложения под контролем эмулятора.

6. Выполнение – запуск приложения с использованием эмулятора.

7. Отладка – нахождение и выделение ошибок в программе и внесение исправлений в исходный код.

Стадии предварительной проверки и упаковки являются новыми и уникальными для процесса создания приложений J2ME и будут кратко пояснены.

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

Между прочим, примеры с использованием командной строки, показанные в этой книге, используют синтаксис оболочки Unix, поддерживаемый оболочкой bash проекта GNU. С учетом нескольких изменений синтаксиса примеры являются абсолютно подходящими к исполнению с помощью приглашения на ввод команды Microsoft Windows MS-DOS.

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

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

Ресурсы GNU находятся под покровительством «Free Software Foundation» (FSF). Вы можете найти информацию о проекте GNU и «Free Software Foundation» на Web-сайте Free Software Foundation, расположенном по адресу http://www.fsf.org.

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

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

Компиляция

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

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

S javac – d  – bootclasspath

Указание – 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

$

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

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

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

tmpclasses

S

Если вы используете 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-летов включает 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-прило-жений.

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

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

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

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

Имя атрибута – Описание

MIDlet-Name – Название набора MID-летов

MIDlet-Versiorv – Номер версии набора MID-летов в форме .., определяемой схемой спецификации управления версиями продукта JDK

MIDlet-Vendor – Разработчик приложения (компания или частное лицо)

MIDlet- – По одному на MID-лет в данном наборе, содержит разделяемый запятой список из текстового имени MID-лета, значка и имени класса п-ного MID-лета в наборе

MicroEdition-Profile – Профиль J2ME, необходимый для исполнения MID-лета

MicroEdition-Configuration – Конфигурация J2ME, необходимая для исполнения MID-лета

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