Платформа J2ME предназначена для двух
Платформа J2ME предназначена для двух классов портативных компьютерных устройств. Первый класс состоит из стационарных устройств с фиксированными сетевыми соединениями, таких, как компьютерные приставки к телевизору. Второй класс состоит из персональных мобильных устройств с нестационарной сетевой связью, таких, как «карманные» компьютеры, мобильные телефоны и так далее.
Различные комбинации конфигураций и профилей J2ME поддерживают эти классы устройств. Конфигурация CDC и профиль Foundation поддерживают первый класс устройств, а конфигурация CLDC и профиль MIDP поддерживают второй класс. Конфигурация стремится предоставлять интерфейсы для служб системного уровня. Профиль стремится предоставлять стандартные интерфейсы для служб уровня приложений. Конфигурация дает возможность работы профиля, предоставляя необходимые средства и механизмы. Устройства должны иметь некую систему управления приложениями (AMS), чтобы «самозапустить» процесс инициализации приложений J2ME на устройствах. Производитель устройства обычно предоставляет AMS.
В этой главе вы узнали о базовой организации и структуре приложений 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 устройства во время выполнения.
Эта глава знакомит вас с полным набором классов компонентов пользовательского интерфейса MIDP. Существует две общие категории компонентов интерфейса пользователя: те, что расположены под Displayable в иерархии, и те, что находятся под иерархией Item.
Класс Screen происходит непосредственно из Displayable и определяет основные абстракции в MIDP. Приложения MIDP в своей основе базируются на экранах.
Form, вид Screen, является только разновидностью экрана, которая может включать другие компоненты. Form может содержать объекты String, изображения, определяемые классом Image, и объекты, чьи типы являются подклассами класса Item.
Стандартное приложение MIDP должно быть способно переходить с экрана на экран. Поэтому экраны должны уметь передавать ссылки в экземпляр объекта экрана, который дисплей должен отображать следующим. Стандартная идиома заключается в предоставлении статического метода, возвращающего такую ссылку в каждом классе, который определяет экран.
В главе 3 представлена полная программная структура и метафоры программирования. В главе 4 описан высокоуровневый API MIDP. Эта глава дополняет все это знакомством с компонентами MIDP, которые реализуют высокоуровневый API.
В следующей главе вы познакомитесь с низкоуровневым API MIDP.
Два класса в пакете javax.microedition. lcdui формируют определение низкоуровневого программного интерфейса приложения в MIDP: класс Graphics и класс Canvas. Низкоуровневый API MIDP дает вашему приложению возможность получать информацию о событиях низкого уровня, которые недоступны для компонентов высокоуровневого программного интерфейса приложения. Объекты Canvas могут получать информацию о событиях нажатия кнопки или движения указателя. Объекты Canvas являются объектами Displayable. По этой причине они все еще могут выполнять обработку команд, как и другие компоненты Displayable.
Чтобы использовать низкоуровневый API, вы должны создать подкласс Canvas. Затем вы должны описать метод paint (Graphics g) в вашем подклассе, для того чтобы создать видимый внешний вид его экземпляров. Метод подкласса paint (Graphics g) определяет этот видимый внешний вид.
Метод paint (Graphics g) рисует внешний вид компонента Canvas с помощью графического контекста, определенного классом Graphics. Класс Graphics поддерживает рисование и заполнение базовых геометрических фигур, таких, как линии, дуги, прямоугольники, текст и так далее. Он также поддерживает рисование в цвете. Другими поддерживаемыми свойствами являются выбор шрифта для рисования текста, отсечение и перенос начала координат Graphics.
Объекты Canvas могут также отображать изображения с помощью функциональных возможностей класса Graphics. Приложения загружают изображения из файлов, которые должны храниться в формате PNG.
Двойная буферизация - это технология, которая повышает эффективность рисования на ресурсно ограниченных устройствах. Приложения используют два графических контекста. Приложение сначала рисует во внеэкранном буфере, а затем копирует содержимое этого буфера в графическую среду, связанную с дисплеем устройства, формируя изображение внешнего вида компонента Canvas. При рисовании изображений двойная буферизация осуществляется автоматически.
Система управления записями (RMS) MIDP поддерживает постоянное хранение записей данных в зависимости от устройства. Класс RecordStore предоставляет API для постоянного хранения данных и извлекает подробную информацию о доступе к определяемым устройством областям хранения.
Хранилища записей определяются по именам, которые состоят максимум из 32 знаков уникода. Хранилища записей могут совместно использоваться MID-летами, находящимися в одном наборе MID-летов.
RMS определяет простую абстракцию базы данных, связанную с записями. Записи хранятся как массив байтов. Хранилище записей не имеет понятий встроенных типов Java.
Вы можете извлекать записи, предоставляя уникальный ID записи. Либо вы можете извлекать записи, получая список записей из RecordStore.
Списки необходимы для поиска записей в хранилище записей. Теоретически фильтры записей предоставляют своего рода механизм запросов. В связи с возможностью составления списков в RecordStore, фильтры записей поддерживают поиск только тех записей, которые соответствуют одному или нескольким критериям. Фильтр записей, класс, который реализует интерфейс RecordFilter, определяет критерии поиска.
Компараторы записей предоставляют возможность сортировки записей, извлекаемых из списка. Компараторы определяют политику сортировки и используются с механизмом составления списка. Реализация RecordComparator определяет семантику сортировки.
Блоки прослушивания записей являются блоками прослушивания, регистрирующимися с определенным хранилищем записей. Они дают возможность уведомления вашей программы об изменениях, вносимых в любую запись, находящуюся в хранилище записей.
Производительность является важной проблемой при доступе к хранилищу записей. Производительность современных реализаций RMS довольно низка. Разработчики приложений должны с осторожностью подходить к использованию RMS, применяя ее только тогда, когда это необходимо. Они должны рассматривать другие альтернативы постоянного хранения данных и сравнивать различные варианты.
Разработчики должны также измерять производительность их реализации RMS при запуске приложений, чтобы убедиться, что производительность приемлема для конечных пользователей. Бывало, что действующие приложения начинали работать слишком медленно из-за использования обновлений хранилища записей. Подтверждено, что перезапись приложений таким образом, чтобы все содержимое хранилища записей было загружено и перемещено, быстрее, чем выполнение обновлений в измененных элементах!
MIDP поддерживает организацию сетей через свой пакет javax.microedition.io. Он предоставляет поддержку базовых коммуникационных протоколов без установления соединения и ориентированных на соединения.
Главный вопрос при проектировании сетевого пакета MIDP заключается в понятии структуры общих соединений. Она определяет общий механизм создания сетевых соединений для приложений. Кроме того, она определяет различия в установке и использовании различных видов соединений, которые затрагивают различные протоколы.
Эта структура дает возможность писать код приложения независимо от определенного вида соединения, которое будет использоваться. Эта независимость важна в мобильных средах, где природа базовых сетей может затронуть доступные службы приложения.
Класс Connector, создающий соединение, извлекает подробную информацию о запрашивании и получении различных видов соединений, которые используют различные базовые коммуникационные протоколы. С помощью создателя соединения приложения запрашивают о доступе к сетевым ресурсам. Ресурсы пересылаются приложениям через соединения, которые используют коммуникационный протокол, указанный в запросе соединения.
Иерархия типов соединений представляет различные типы соединений, которые может создать приложение. Определения различных интерфейсов этих типов соединений отражают протоколы, используемые различными типами соединений. Они также отражают желаемую семантику типа соединения.
Существует четыре базовых категории соединений. Потоковые соединения, поддерживающие соединения с коммуникационными портами, соединения уровня приложений со службами HTTP и базовые соединения сокета стиля Unix. Дейтаграммные соединения поддерживают соединения со службами передачи дейтаграмм.
В MIDP отсутствует поддержка других протоколов уровня приложений, таких, как RMI, CORBA или Jini. Причина этого кроется в том, что персональные мобильные устройства лишены требуемой мощности для поддержки этих механизмов распределенной обработки данных.
Новые профили, которые были встроены поверх CDC, предоставляют возможности, такие, как RMI. Создатели MIDP должны с осторожностью рассматривать то, какие коммуникационные возможности им необходимы для каждого приложения, и создавать свои приложения с расчетом на доступные.
Интернационализация - это действия по предоставлению приложению возможности динамического извлечения и использования чувствительных к региональным настройкам ресурсов при раб*оте. Интернационализация является важным свойством приложений MIDP. Интернационализированное приложение предназначено для большей пользовательской аудитории.
Интернационализация приложения означает предоставление ему при выполнении возможности извлечения ресурсов, которые совместимй с контекстом региональной настройки, в которой приложение работает. Локализация - это процесс предоставления ресурсов одному или нескольким контекстам региональной настройки.
Локализация - это деятельность по созданию определяемых региональной настройкой ресурсов для интернационализированных программ, к которым приложение получает доступ при выполнении. Работы по интернационализации и локализации сходны. Организация и задание формата локализованных ресурсов должны отражать схему и проектирование интернационализации. Решения всесторонней интернационализации и локализации должны обращаться к чувствительным к региональным настройкам операциям в следующих областях приложения:
Возможности, доступные в платформе MIDP, влияют на выбор варианта разработки интернационализации и затрагивают осуществимость реализации определенных разработок приложений MIDP. Платформа MIDP предоставляет три следующих основных механизма, которые могут быть использованы для создания возможностей интернационализации:
Разработчики приложений MIDP должны также учитывать факторы производительности, восстанавливаемости и установки при разработке решений интернационализации и локализации.
Инициализация приложений - это процесс поставки программного обеспечения на устройства. Инициализация не ограничивается беспроводными сетями, J2ME или даже приложениями Java. Тем не менее, системы инициализации стали важным компонентом, поддерживающим установку приложений J2ME, особенно в сфере инициализации ОТА приложений MIDP.
Процесс инициализации включает много этапов, среди которых регистрация приложений в системе инициализации и обнаружение, выбор, покупка, загрузка, установка и подтверждение установки программного обеспечения. Цель систем инициализации заключается в облегчении прохождения этих этапов и автоматизации процесса настолько, насколько это возможно для предоставления более совершенных возможностей и безошибочной работы.
Поскольку системы инициализации автоматизируют большую часть процесса инициализации, они хорошо подходят для беспроводных сетей. Они смягчают многие трудности и автоматизируют многие этапы, включенные в инициализацию приложений на устройствах с ограниченными пользовательскими интерфейсами через беспроводные соединения.
Системы инициализации являются комплексными корпоративными приложениями, которые обычно интегрируются в сеть беспроводного транспортировщика. Они предоставляют услуги инициализации для беспроводных подписчиков. Ключевым моментом для разработчиков приложений является подготовка своих приложений MIDP для использования в системах инициализации, поддерживаемых транспортировщиками, у которых их приложения будут зарегистрированы. Понимание сущности интерфейсов, свойств и возможностей системы инициализации, с которой вы будете взаимодействовать, важно. Как разработчик приложения, вы должны быть способны предоставить всю информацию, необходимую системе инициализации, для того чтобы вы могли извлечь из нее максимально возможные преимущества.
Системы инициализации поддерживают многие другие свойства, которые не были обсуждены в данной главе. Многие из этих свойств прозрачны для разработчика приложений, в том смысле, что разработчику не приходится ничего делать для регулировки этих аспектов работы системы инициализации. Многие из них не влияют на приложение. Или они просто обращаются к функциям, которые не зависят от вопросов разработки, конфигурирования или установки приложения.
Среда беспроводного Интернета состоит из мобильных устройств, беспроводной се ти, шлюзов и сетевых комплексов, которые соединяют беспроводную сеть с Интерне том. Сила беспроводного Интернета заключается в том, что он позволяет мобильны\ устройствам получать доступ к Web и другим интернет-приложениям. Среда беспровод ной сети создает абстракции, которые скрывают от приложений различия между беспро водной сетью и Интернетом.
Беспроводные устройства получают доступ ко многий из тех же категорий приложе ний, что и постоянно подсоединенные устройства с проводной связью, такие, как персо нальные компьютеры. Кроме того, определенные приложения, такие, как службы дина мического местоопределения, особенно популярны в области мобильных устройств.
Основанная на Java технология платформы J2ME значительно увеличивает способ ность мобильных устройств использовать преимущества интернет-приложений. Он помогает скрывать от приложений различия в технологии и службах беспроводной CCTI и Интернета.
Однако в реальном мире ограничения и сдерживающие факторы технологической плана требуют, чтобы предназначенное для Интернета основанное на Web программно! обеспечение специально приспосабливалось к беспроводному Интернету, то есть обра щалось к технологиям, используемым для доступа радиоустройств. Но с развитием тех нологии беспроводной Интернет начнет поддерживать абстракции, которые устраня' необходимость наличия специального, основанного на Web программного обеспечения которое поддерживает мобильные устройства отлично от постоянно подсоединенны: устройств, таких, как персональные компьютеры.
Архитектура - это набор понятий и действий, которые поддерживают проектирова ние и описание системы. Методология построения архитектуры - это порядок примене ния архитектурных понятий и действий. Методология построения архитектуры SunTom - это дополнение к процессу Rational Unified Process.
Методологию построения архитектуры дополняет сбор требований. Разработчи! должен согласовать архитектуру с объявленными требованиями системы. Методологи: построения архитектуры SunTone подчеркивает важность определения нефункциональ ных или системных качеств системы и использования их для установления соответстви: системы объявленным требованиям.
Разработчик J2ME должен рассматривать выполнение архитектурного анализа в ка честве первого этапа при проектировании и разработке приложения. Построение архи тектуры может помочь разработчику описать программное обеспечение, которое он соз дает, а также выяснить, каким образом лучше взаимодействовать со службами беспро водного Интернета, если он понимает принципы построения архитектуры систеи беспроводного Интернета.
