"Платформа J2Me" - читать интересную книгу автора (неизвестен Автор)

Глава 3. Программная структура приложений MIDP

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

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

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

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

Рисунок 3.1. Этот MID-лет запускается с помощью используемого по умолчанию цветного телефона, предоставляемого инструментарием. Обратите внимание на название MID-лета

Рисунок 3.2. Добавьте новые MID-леты к набору с помощью закладки MIDIets (MID-леты) в окне Settings (Параметры)

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

На реальном устройстве AMS устройства показывает это меню. Например, телефоны Motorola и Siemens используют стандартные списки выбора, которые позволяют вам выбрать сначала AMS, затем набор MID-летов и, наконец, MID-лет. На чужих рынках (в Японии, например) телефоны могут иметь кнопку, помеченную «Web», которая запускает AMS и автоматически запускает Web-браузер, созданный на Java. Перечисленные MID-леты — это те, которые известны AMS.

Когда вы добавляете MID-лет к набору, вы сообщаете инструментарию, что вы хотите, чтобы новый MID-лет был доступен для выполнения. Когда вы создаете MID-лет, инструментарий размещает его файлы. class в файле JAR набора MID-летов и обновляет файлы манифеста и JAD. Этот порядок действий осуществляется в согласии со спецификацией J2ME, которая, как вы помните, требует, чтобы МID-леты содержались в файле JAR.

4. Выберите MID-лет HelloWorld и затем нажмите на экранную кнопку Launch (Запуск), чтобы выполнить его. На рисунке 3.4 показано одно окно, которое он создает и показывает.

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

Рисунок 3.4. Главное окно этого приложения содержит название и одну строчку текста

Нажмите на красную кнопку с трубкой («hang up» — «отбой») на эмуляторе и вы вернетесь в главное окно AMS. Закрыв окно эмулятора, вы завершите его работу. Теперь вы закончили полный жизненный цикл выполнения приложения. Далее в этой главе вы узнаете больше о деталях жизненного цикла MID-лета и модели состояний MID-лета.

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

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

Во-первых, отметьте, что это приложение описывает класс, называемый 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 () со следующей сигнатурой:

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

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

Название состояния 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 о входе в приостановленное состояние, вызывая свой метод notifyPaused(). MID-лет может после этого запрашивать, чтобы он был помещен в активное состояние, вызывая resumeRequest ().

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

В таблице 3.2 перечислены методы класса javax.microedition.midlet.MIDlet, которые управляют состоянием MID-лета.

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

Название метода класса MID-лета — Описание

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

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

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

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

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

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

Первая из двух показанных выше строчек получает ссылку на объект 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

Название метода класса формы — Описание

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

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

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

Рисунок 3.7. Диаграмма наследования компонентов пользовательского интерфейса MIDP показывает связи между MID-летом, связанным с ним объектом Display и его объектами Displayable. Если не определено иное, все классы принадлежат пакету javax.microedition.lcdui. абстрактный класс, конкретный класс

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

Ключ свойства — Описание — Значение по умолчанию

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

Листинг 3.2. MID-леты имеют прямой доступ ко всем четырем стандартным системным свойствам, определяемым спецификацией CLDC

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

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

Вывести значения стандартных системных свойств С помощью вызова System.getProperty().

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

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

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

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

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

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

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

Листинг 3.3. Измененный метод теперь также выдает свойства приложения. Программное обеспечение AMS устройства управляет свойствами приложения.

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

Листинг 3.4. Атрибуты MID-лета, или свойства, отличаются от системных свойств. Вы можете описать неограниченное количество необязательных атрибутов MID-лета в дополнение к предварительно определенным, требуемым

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

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

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

В этой главе вы узнали о базовой организации и структуре приложений MIDP. Центром модели программирования MIDP является MID-лет.

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

Объекты MID-лета связаны с объектом Display. MID-леты создают элементы Displayable, которые являются компонентами пользовательского интерфейса, и требует, чтобы они отображались на экране устройства. Display управляет экраном устройства и видимостью элементов пользовательского интерфейса.

Абстрактный класс Screen является первым из двух основных типов, которые катего-ризируют все объекты Displayable. Класс Screen является центральной абстракцией дисплея. Класс Form является конкретным подклассом Screen. Только Screen видим в каждый момент жизни MID-лета.

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