 |
     |
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Процесс разработки приложений MIDP
Как вы уже знаете, приложения J2ME являются программами Java и исполняются под управлением виртуальной машины Java. По этой причине все устройства с J2ME должны поддерживать среду исполнения Java. Приложения MIDP, как и любые другие приложения, проходят цикл разработки. В этой главе рассказывается о цикле и процессе разработки МID-приложений. Не имеющие соединения устройства, такие, как мобильные телефоны, обычно не имеют встроенной в них среды разработки. Не имея среды разработки на самом устройстве, разработчики вынуждены делать межплатформенную разработку - разрабатывать приложение на другой системе, загружать его на устройство и затем тестировать его там. То, что приходится постоянно загружать приложение в процессе разработки на устройство для того, чтобы протестировать его, делает процессы разработки и тестирования трудоемкими и утомительными. Эмуляторы представляют альтернативный вариант. Они имитируют среду исполнения устройства и позволяют вам выполнять полный цикл разработки на другой системе. Эмуляторы предоставляют среду, которая поддерживает редактирование, компиляцию, выполнение и отладку. Такая среда является более благоприятной, поскольку она позволяет вам избегать периодически повторяющихся циклов загрузки и установки на устройство. Она также позволяет вам избегать проблемы наполненных ошибками программ, разрушающих ваше мобильное устройство. Различные производители мобильных устройств и разработчики комплектующего оборудования предлагают эмуляторы, которые запускаются на стандартных настольных операционных системах. Отдел «Java Software» компании «Sun Microsystems», например, предлагает инструментарий J2ME Wireless Toolkit (J2MEWTK), который запускается на платформах Windows и Unix. Он содержит эмулятор, компилятор, виртуальную машину, библиотеки классов и другие полезные инструменты разработки. Вы можете загрузить его бесплатно с сайта http://java.sun.com. Процесс разработки приложений на J2ME является в значительной степени идентичным процессу разработки обычных программ на Java с некоторыми небольшими отличиями. Процесс разработки приложения состоит из следующих этапов: Стадии предварительной проверки и упаковки являются новыми и уникальными для процесса создания приложений J2ME и будут кратко пояснены. Вы можете выполнить все вышеупомянутые этапы вручную, используя командный процессор или версии с командной строкой инструментов разработки. В этой главе я сначала покажу вам каждый этап, используя только инструменты с командной строкой, так что вы сможете понять, как работает этот процесс в общем. Поэтому я использую эмулятор инструментария J2ME Wireless Toolkit, разработанный «Java Software». Между прочим, примеры с использованием командной строки, показанные в этой книге, используют синтаксис оболочки Unix, поддерживаемый оболочкой bash проекта GNU. С учетом нескольких изменений синтаксиса примеры являются абсолютно подходящими к исполнению с помощью приглашения на ввод команды Microsoft Windows MS-DOS. Я не описываю здесь исходный код, поскольку эта глава сконцентрирована на том, чтобы показать, как заставить пройти абсолютно надежное CLDC/MIDP-приложение через весь цикл разработки. В главе 3 я начну анализировать код, чтобы показать вам модель программирования и абстракции инструментария и объяснить принципы работы важнейших неотъемлемых частей приложения. В рамках проекта GNU разрабатываются сотни утилит и приложений в стиле
Unix. Они были приспособлены для запуска на множестве операционных систем,
включая Windows. Эти инструменты включают все: от утилит, командных
процессоров, компиляторов, компоновщиков и инструментов управления исходными
кодами Unix до приложений, таких, как программы просмотра PostScript,
текстовой редактор Emacs и профессиональные приложения обработки изображений,
и это лишь несколько примеров. Прежде чем вы приступите к самому циклу разработки, вы должны сначала создать структуру директорий, которая будет поддерживать разработку вашего набора MID-летов. Набор MID-летов - это комплект MID-летов, которые используют общие ресурсы приложений. Вы получите более подробную информацию об этих общих ресурсах MID-летов в следующих главах книги. Я сначала создаю директорию под названием HelloWorld, что является названием примера нашего первого приложения, под директорией apps/, предназначенной для установки инструментария для работы с беспроводными устройствами. Эта директория является корневой для вашего нового проекта. Проект - это организованное объединение ресурсов - исходного кода, файлов ресурсов, откомпилированных файлов, - специфических для одного или более связанных приложений. Корневой каталог проекта содержит подкаталоги, показанные в следующем примере кода: $ pwd Есть причина для использования такой точной структуры каталогов, которую я объясню далее, когда вы узнаете, как использовать эмулятор Wireless Toolkit Emulator. Однако даже если вы не планируете использовать J2ME Wireless Toolkit, такая организационная структура является самой разумной для начала работы. В таблице 2.1 объяснено содержание и цель этих каталогов. Таблица 2.1. Поддиректории проектов, созданных с помощью J2ME Wireless Toolkit
Я не буду объяснять здесь проектировку самого приложения, поскольку эта тема лежит за пределами темы этой главы. Цель на данный момент заключается не в том, чтобы описать, как проектировать приложения Java или даже приложения MIDP. В последующих главах, однако, будет говориться об организации MIDP-приложений. Следующим этапом в цикле разработки после создания вашей программы является компиляция исходной программы. Прежде чем вы приступите к компиляции, убедитесь, что список командных путей среды вашей оболочки включает маршрут к директории, в которой содержатся утилиты 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 \ Указание -d сообщает компилятору записать непроверенные компилированные классы в директорию tmpclasses, которая является поддиректорией каталога HelloWorld/. Указание -bootclasspath определяет путевое имя относительно данного каталога. Наконец, последний параметр указывает относительное путевое имя исходного файла HelloWorld.Java. Вы узнали, что библиотеки MIDP и CLDC определяют полную платформу для создания приложений на MIDP. Следовательно, вам не придется включать путь для любой J2SE установки в CLASSPATH вашей среды при компилировании ваших приложений. В действительности вы не можете включить его. Если вы это сделаете, вы получите ошибку компиляции, поскольку компилятор найдет конфликтующие определения в библиотеках J2SE и J2ME. После завершения компиляции ваших файлов директория tmpclasses будет содержать непроверенные файлы .class: $ Is -I tmpclasses/ Следующим этапом после компиляции является предварительная проверка файлов .class, которые вы только что откомпилировали. Чтобы провести ее, запустите следующую команду: $ preverify -classpath "lib/midpapi.zip;tmpclasses"
-d classes \ Если вы используете J2ME Wireless Toolkit, вы должны отделить элементы пути классов точками с запятой, или заключить их в кавычки, если вы используете оболочку Unix, чтобы избежать того, что оболочка начнет интерпретировать точки с запятой. Элементы путей классов представляют собой директории, из которых должны загружаться классы. Разделитель элемента пути класса - точка с запятой в данном случае -зависит от платформы. Параметр -d указывает директорию, в которую должны быть записаны предварительно проверенные выходные классы, генерируемые с помощью этой команды. Наконец, имя замыкающей директории, tmpclasses, показывает местонахождение, из которого можно получить непроверенные файлы классов, которые были созданы на предыдущем этапе компиляции. Запуск вышеуказанной команды preverify создает предварительно проверенные файлы . class в директории классов в соответствии с вашими указаниями: S Is -I classes/ Команда preverify является инструментом предварительной проверки файлов классов, который используется в процессе проверки файлов классов. Проверка файлов классов в CLDC, как и в J2SE, является процессом проверки истинности файлов классов Java и отклоняет неправильные файлы. Однако в отличие от процесса проверки в J2SE проверка файлов классов в CLDC включает два этапа: Использование команды preverify, о которой мы только что говорили, представляет собой фазу предварительной проверки вне устройства - стадию 1 в двухэтапном процессе проверки. В реальной среде эта первая фаза обычно осуществляется на сервере, с которого MIDP-приложения загружаются на мобильные устройства. Обычно сервер выполняет это до того, как делает приложение доступным для загрузки. Причина появления этого нового процесса проверки заключается в том, что обычный верификатор файлов классов J2SE требует больше памяти и возможностей по обработке данных, чем стандартные мобильные устройства могут реально предоставлять. Он использует около 50 Кб места под двоичный код и от 30 до 100 Кб динамической памяти при работе. Новый верификатор CLDC требует намного меньше RAM и является при этом намного более эффективным. Для стандартных файлов классов верификатор CLDC использует только около 10 Кб кодового пространства и требует только 100 байт динамической памяти при работе. Новый верификатор может достигать такой высокой производительности благодаря новому алгоритму, который он использует. Этот новый алгоритм, однако, требует наличия специальных атрибутов в каждом файле классов Java. Верификатор предварительной проверки записывает эти новые атрибуты в каждый файл классов Java. Верификатор затем использует атрибуты, созданные верификатором предварительной проверки. Новые файлы классов приблизительно на 5 процентов больше, чем их немодифицированные версии. Верификатор предварительной проверки выполняет две задачи:
Эти новые файлы классов все еще являются действующими файлами классов 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 Для получения дополнительной информации об описании и функционировании каждого из этих полей, пожалуйста, смотрите спецификацию Connected, Limited Device Configuration Specification. Следующим этапом после предварительной проверки является упаковка приложения. Упаковка набора MID-летов включает 2 объекта:
Хотя вы можете выбирать, упаковывать ли приложения J2SE для распаковки в дальнейшем, спецификация MIDP требует, чтобы вы упаковывали набор MID-летов с помощью утилиты архивации Java (JAR). В действительности спецификация MIDP требует, чтобы все наборы MID-летов переносились на устройства в сжатом файловом формате JAR. Обычно серверы, которые поддерживают перенос наборов MID-летов на устройства, хранят файлы наборов MID-летов в сжатом формате JAR. Либо сервер, либо компонент, который загружает файл на сервер, создает сжатый JAR-файл. Архив JAR набора 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-прило-жений. ЕСЛИ вы хотите добавить файл Manifest к вашему заархивированному набору MID-летов, вам необходимо создать его прежде, чем вы создадите сам JAR-архив. Вы можете создать этот файл в любом текстовом редакторе. Потом создайте JAR-файл с помощью стандартной утилиты JAR J2SE. Утилита JAR включается в утилиты инструментария Wireless Toolkit. Спецификация MIDP требует, чтобы в файле Manifest присутствовали определенные поля. Требуемые поля показаны в таблице 2.2. Таблица 2.2. Обязательные атрибуты файла MANIFEST.MF
Файл манифеста содержит строки атрибутов, один атрибут на строку. Каждый атрибут состоит из ключа и значения. После ключа ставится двоеточие, которое отделяет его от связанного с ним значения. Файл MANIFEST.MF программы HelloWorld находится в папке HelloWorld/bin/. Он выглядит следующим образом: MIDlet-l: HelloWorld, HelloWorld.png, HelloWorld Обратите внимание на имя атрибута 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
Создание файла 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 Листинг содержимого файла JAR, который вы только что создали, выдает следующую информацию: $ jar tf bin/HelloWorld.jar Как вы можете видеть, файл манифеста включается в файл JAR. Файл JAR содержит один файл .class для нашего приложения HelloWorld. Он также содержит файл формата .png (portable network graphics -переносимая сетевая графика), который является подходящим вариантом для использования в качестве значка приложения. Файл MANIFEST.MF, конечно, был создан вручную, как описано выше. Создание файла дecкpиптopa приложения для набора МID-летов Программное обеспечение управления приложениями на устройстве, таком, как мобильный телефон, использует файл JAD для получения информации, необходимой для управления ресурсами во время выполнения MID-лета. Файл дескриптора приложения является необязательным, однако полезным. Вы можете использовать любой текстовой редактор для его создания, но вы должны дать файлу расширение . jad. Чтобы избежать путаницы, я рекомендую давать ему имя, которое характеризует весь набор MID-летов. Таблица 2.4. Обязательные атрибуты файла дескриптора приложения
Таблица 2.5. Необязательные атрибуты файла дескриптора приложения
В дополнение к необязательным полям, перечисленным в таблице 2.5, файл JAD может содержать отдельные поля атрибутов для каждого MID-лета, описанные и названные разработчиком приложения. Вы можете называть эти атрибуты так, как вам нравится, однако вы не должны использовать «MIDlet-» в имени атрибута. Этот префикс зарезервирован для имен стандартных атрибутов, определенных спецификацией MIDP. Файл JAD для программы HelloWorld также находится в директории HelloWorld/bin/ и его содержимое выглядит так: MIDlet-1: HelloWorld, HelloWorld.png, HelloWorld В частности, обратите внимание на поле атрибута 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-лета загрузил бы файл JAR на какую-либо систему инициализации приложений (системы инициализации приложений описываются в главе 10). Системы инициализации предлагают распаковку приложения вслед за его загрузкой. Пользователи загружают файл JAR набора MID-летов на свои устройства и запускают его с помощью программного обеспечения системы управления приложениями устройства. В этой главе распаковка означает размещение файлов под управлением эмулятора инструментария J2ME Wireless Toolkit. Вы можете затем запустить приложение в эмуляторе, имитируя его выполнение на реальном устройстве. Вместо того чтобы просто показать вам, как размещать упакованные файлы приложения под управлением Wireless Toolkit для выполнения, в следующем разделе вам будет показано, как выполнять полный цикл разработки, который вы только что завершили, с помощью Wireless Toolkit. Последняя часть этого описания покажет вам, как выполнять ваши приложения. Использование J2ME Wireless Toolkit Этот раздел покажет вам, как использовать J2SE Wireless Toolkit, разработанный в отделе «Java Software» компании «Sun», для выполнения всех этапов цикла разработки, который вы выполнили вручную. Вы можете загрузить J2ME Wireless Toolkit бесплатно с Web-страницы Java Software на сайте Sun Microsystems, http://java.sun.com. Загрузите версию, соответствующую вашей операционной системе, и следуйте инструкциям по установке, предоставляемым при загрузке. Свойства и функции 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. Рисунок 2.3. Wireless Toolkit создает файлы манифеста и JAD для вас, основываясь на информации, которую вы предоставили в этом окне, которое представляет из себя обязательные поля дескриптора приложения На рисунке 4 показана панель, которая появляется, когда вы выбираете закладку Optional (Необязательные атрибуты). Она позволяет вам вводить информацию о полях обязательных атрибутов MID-лета, которые вы видели ранее в таблице 2.5. Рисунок 2.4. Эта панель позволяет вам редактировать необязательные атрибуты мета-информации вашего файла дескриптора приложения для вашего MID-лета После завершения этого этапа главное окно KToolbar выведет три строки информационных сообщений в своей панели вывода результатов диагностики. Они сообщат вам, где размещены ваши исходные файлы Java, файлы ресурсов приложения и файлы библиотеки приложения. На рисунке 2.5 показано обновленное окно KToolbar. Рисунок 2.5. После того как вы завершите ввод необходимой информации о наборе МЮ-летов, KToolbar покажет, где разместить файлы конкретного приложения. Обратите внимание, что файлы ресурсов помещаются в директорию приложения res/, а не в директорию bin/ В версии 1.0.3 J2ME WTK добавлена закладка User Defined (Определяемые пользователем) к основной панели Settings (Параметры). Вы можете видеть эту закладку User Defined (Определяемые пользователем) на рисунках 2.3 и 2.4. На рисунке 6 показана панель User Defined (Определяемые пользователем), которая появляется, когда вы нажимаете на закладку User Defined (Определяемые пользователем). Панель, показанная на рисунке 2.6, позволяет вам задать атрибуты приложения. Обратите внимание, что панель имеет кнопку Add (Добавить), которая позволяет вам добавлять дополнительные атрибуты. В главе 9 есть несколько примеров, которые покажут вам, как добавлять выборочные атрибуты с помощью Wireless Toolkit и как использовать атрибуты в ваших приложениях.
Рисунок 2.6. Разработчики приложения могут устанавливать определенные атрибуты для одного или более MID-летов в наборе MID-летов Если вы взглянете еще раз на рисунки 2.3 и 2.4, вы увидите, что панели Required (Требуемые атрибуты) и Optional (Необязательные атрибуты) не позволяют вам добавлять какие-либо атрибуты в них. Вы можете только редактировать значения атрибутов, которые уже есть. Вы не можете добавлять обязательные поля, потому что они стандартизованы. Набор необязательных полей также стандартизован, хотя их присутствие не обязательно. После того как вы закончите этот цикл начального определения набора MID-лета, вы всегда можете отредактировать значения любого из атрибутов MID-лета. Выберите кнопку Settings (Параметры) в строке меню KToolbar. Когда вы это сделаете, вновь появится окно, показанное на рисунке 2.3. Внесите желаемые изменения и нажмите ОК. Размещение исходного кoдa в пpoeктe Теперь пришло время поместить исходный файл приложения внутри проекта, как указано в панели результатов диагностики KToolbar. Когда вы создадите новый проект, KToolbar создаст соответствующие директории под структурой директорий установки, как вы уже видели, когда использовали интерфейс командной строки. Вспомните, что на моей системе эта директория располагается в /cygdrive/c/J2mewtk/apps. Под этой директорией существует директория проекта HelloWorld. Ваш следующий шаг заключается в размещении исходного файла HelloWorld. Java вручную под директорией HelloWorld/src/. Конечно, если бы вы действительно создавали проект с нуля, вы бы сначала создали исходник с помощью своего любимого текстового редактора. Теперь вы готовы к компиляции. Нажмите на кнопку Build (Создать) на панели кнопок главного окна KToolbar. Wireless Toolkit откомпилирует исходный файл HelloWorld.java и выдаст результат диагностики в главном окне KToolbar, которое показано на рисунке 2.7. Конечно, если ваша компиляция не удастся, обычный благоприятный результат компиляции появится на этой панели.
Рисунок 2.7. Компиляция вашего проекта выведет дополнительные результаты диагностики в главном окне KToolbar Если результаты вашей компиляции кажутся вам неубедительными, вы можете использовать ваш командный процессор для подтверждения наличия файлов .class в директориях tmpclasses/ и classes/: $ pwd Как вы уже знаете, директория tmpclasses/ содержит файлы .class, созданные в самом процессе компиляции. Директория classes/ содержит предварительно проверенные файлы, созданные утилитой preverifу. J2ME WTK запускает утилиту preverify автоматически, когда вы нажимаете на кнопку Build (Создать) KToolbar. После того кай вы выполните компиляцию, вы должны упаковать приложение, что вы уже делали при работе с инструментами командной строки. На панели кнопок KToolbar нет кнопки Package (Упаковка). Вместо этого раскройте пункт меню Project (Проект) в меню KToolbar и выберите пункт меню Package (Упаковка), как показано на рисунке 2.8.
Рисунок 2.8. Выберите пункт меню Package (Упаковка) для упаковки вашего приложения. На этом этапе создаются файлы JAD и JAR приложения
Рисунок 2.9 показывает результат диагностики, созданный, когда вы закончили процесс упаковки. Заметьте, что он показывает, что Wireless Toolkit создал файлы Hello World jar и HelloWorld.jad.
Рисунок 2.9. Этап упаковки на самом деле компилирует приложение прежде, чем его упаковать. Результат диагностики отражает выполнение этапов компиляции и упаковки Вы можете вновь проверить наличие этих файлов, вручную выведя описание содержимого директории bin/ проекта: $ На самом деле упаковка вашего приложения с помощью J2MEWTK сначала компилирует и предварительно проверяет вашу программу, а затем упаковывает ее. Так что вы можете пропустить процесс явной компиляции, описанный в предыдущем разделе, и просто упаковать ваше приложение до его раскрытия и тестирования. Однако явный этап компиляции важен, если вы хотите откомпилировать вашу программу без ее упаковки. Фактически при использовании Wireless Toolkit нет разграничения этапов разработки. Инструментарий создает компоненты, которые вам нужно будет раскрыть в реальной системе, а именно файл дескриптора приложения и файл JAR приложения. В главе 10 описывается, что вы будете делать с этими файлами в реальной системе, которая предлагает приложения MIDP для загрузки на реальные устройства. Выполнение приложения означает имитирование среды исполнения реального мобильного устройства. Одним из прекрасных свойств эмулятора 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 включает компиляцию, предварительную проверку, упаковку, раскрытие и выполнение. Вы компилируете ваши MIDP-приложения с помощью стандартного компилятора J2SE. Новая утилита предварительной проверки создает проверенные файлы .class, которые могут быть интерпретированы как KVM, так и стандартной виртуальной машиной J2SE. Эмуляторы являются важными инструментами при разработке приложений для мобильных устройств. Они дают вам возможность проделывать начальное тестирование без вынужденного использования настоящего устройства. Это, в частности, важно для тестирования логической правильности ваших приложений, поскольку среды тестирования и отладки недоступны на настоящих устройствах. Однако эмуляторы не являются заменителями тестирования на реальных устройствах. Вы должны протестировать каждый аспект приложения на реальном устройстве до его выпуска как готового продукта. Инструментарий J2ME Wireless Toolkit содержит инструменты разработки приложений и эмулирования, которые дадут вам возможность выполнять все этапы процесса разработки, а именно: компилирование, предварительную проверку, упаковку, раскрытие и выполнение. |
|
Книги-online
