Знакомство с платформой Java 2 Micro Edition (J2ME)

• Определение платформы Java для портативных устройств
• Конфигурации и профили
• Конфигурация Connected Device Configuration (CDC)
• Конфигурация Connected, Limited Device Configuration (CLDC)
• Системы управления приложениями устройств
• Выводы по главе

Компания «Sun Microsystems» определяет три платформы Java, каждая из которых отвечает нуждам различных компьютерных сред:

• Java 2 Standard Edition (J2SE);
• Java 2 Enterprise Edition (J2EE);
• Java 2 Micro Edition (J2ME).

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

Создатели платформы J2ME разделяют портативные устройства на две отдельные категории:

• Персональные мобильные информационные устройства, которые способны к нестационарным сетевым коммуникациям - мобильные телефоны, двусторонние пейджеры, персональные информационные устройства («карманные компьютеры») и органайзеры.
• Информационные устройства с общим соединением, подсоединенные к фиксированному беспрерывному сетевому соединению - компьютерные приставки к телевизору, телевизоры с выходом в Интернет, телефоны с дисплеем и возможностью выхода в Интернет, коммуникаторы высокого класса, развлекательные и навигационные автомобильные системы.

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1.1. Платформа J2ME состоит из ряда уровней, которые поддерживают базовую среду исполнения с корневыми библиотеками Java и Виртуальной машиной (VM), набора программных интерфейсов приложения системного уровня (API) в конфигурации и набора API программного уровня в профиле

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

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

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

• набор свойств языка программирования 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.

Таблица 1.1. Пакеты CDC

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

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

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

Вышеуказанный список пакетов выглядит точно так, как список, который включает в себя 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

Профиль 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.

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

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

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

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

Рисунок 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.