I18NDemo midlet; 37 38 // Уведомление

Проблема разработки интернационализации заключается в схеме поиска, используемой для нахождения локализованных строк в файле JAD. Программно определяемый метод getResource (String key), заданный в строках с 103 по 115, на самом деле определяет и реализует схему поиска. Чтобы обнаружить ресурс, метод getResource (String key) создает имя атрибута, а затем ищет сам атрибут.

Например, следующие два оператора, показанные в строках 84 и 85, выбирают строку заголовка Form, использующейся в приложении.

String formTitle = getResource("title");

form = new HelloForm(formTitle);

Метод создает полное имя атрибута, объединяя три строки: 118NDemo - префикс атрибута для данного приложения, идентификатор атрибута ресурса без какой-либо меняющейся в зависимости от региональной настройки информации и обозначение региональной настройки. Параметр строки title является идентификатором атрибута ресурса, а не заголовком формы.

В строке 36 MID-лет определяет префикс атрибута I18NDemo-. Метод startApp() извлекает информацию о контексте региональной настройки, в котором исполняется приложение, из системного свойства microedition.locale и сохраняет его как экземпляр атрибута.

Объект HelloForm использует значение, выданное вызовом getResource(), как его заголовок. Класс HelloForm в листинге 9.3 повторяет этот сценарий. Он просто вызывает getResource() для поиска локализованных значений всех текстов, которые пользователь видит во время исполнения приложения.

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

Альтернативный подход заключается в создании нескольких версий файла JAD приложения так, чтобы каждая версия содержала атрибуты для каждой региональной настройки. Добавьте соответствующую версию JAD для требуемого контекста региональной настройки.
Конечно, вам понадобится определить контекст локальной настройки, в которой будет использоваться телефон, или просто местные настройки пользователя.
В листинге 9.2 используется системное свойство microedition.locale для извлечения региональной настройки для того, чтобы акцентировать внимание на понятии динамически определяемого контекста региональной настройки и ресурсов, связанных с контекстами региональных настроек. Разграничение ресурсов для различных региональных настроек может помочь пониманию вашей разработки и сделать ваше программное обеспечение более восстанавливаемым. Не забывайте, что в будущем, когда устройства станут более мощными, реализации MIDP смогут очень хорошо поддерживать множество региональных настроек. Когда это произойдет, подход, показанный в листинге 9.2, станет более предпочтительным.
Взглянув на метод getResource(), показанный в строчках с 103 по 115, вы увидите, что он использует метод MIDlet.getAppProperty() для извлечения ресурсов из файла дескриптора приложения и файла манифеста. Если атрибут существует в обоих файлах с абсолютно одинаковыми именами ключа, тогда значение извлекается из файла дескриптора приложения и значение в файле манифеста игнорируется. Если не найдено ни одного атрибута или если для ключа не найдено ни одного значения, выдается значение ноль. Если вводимый ключ не найден, сбрасывается NullPointerException.
Значения атрибутов в файле JAD (или манифеста) должны быть кодированы с помощью символьной кодировки, которая поддерживает нужный язык. Существует два способа выполнения этого:
Кодировать значения атрибутов с помощью символьной кодировки, предназначенной для языка региональной настройки. Символьная кодировка может быть той, что соответствует более чем одному лишь нужному языку, как, например, LJTF-8.
Кодировать значения атрибутов с помощью последовательностей переключения кода Уникод, например \u4EA9. Файл все равно состоит только из символов ASCII, но последовательности переключения уникода могут представлять любой символ любого письменного языка.


Листинг 9.2 включает поддержку английской и французской региональных настроек. Символьная кодировка ISO8859-1 может представлять английский и французский алфавиты. Если вы желаете локализовать данное приложение на языки, не поддерживаемые семейством ISO8859 (китайский, например), вам придется кодировать значения атрибутов с помощью соответствующей многобайтовой символьной кодировки.
Если вы выбрали первый из только что описанных подходов (кодирование с помощью символьной кодировки, предназначенной для языка региональной настройки), вам понадобится найти текстовой редактор, который поддерживает методы ввода китайского языка и записывает символы в соответствующую кодировку. Либо вы можете использовать второй подход и вводить последовательности переключения уникода Java для каждого символа. Просто найдите точку кодирования уникода для каждого символа в вашей строке. Этот подход работает, поскольку класс Java.lang.String знает, как создавать строковые объекты из последовательностей переключения уникода. Ваше приложение может затем считывать значения атрибутов и создавать из них объекты String.
Вы можете определить имена атрибутов с помощью панели Settings J2MEWTK. Поскольку WTK не поддерживает ввод не-ASCII текста, однако, вы не можете определить не английский локализованный текст значений атрибутов. Чтобы ввести не английские символы, вам придется использовать текстовой редактор для ввода символов непосредственно в файл JAD. Вы можете использовать тот, что поддерживает редакторы методов ввода (IME) для назначенного языка, или вводить последовательности переключения уникода.

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


Чтобы поддерживать нестроковые локализованные ресурсы - например, чувствительный к региональной настройке числовой форматер, - вы можете установить значение атрибута на имя класса, который реализует ваш форматер. Например, вы можете определить атрибут следующим образом:
I18NDemo-number_forraat-fr_FR: NumberFormat_FR
Вы извлекаете значение атрибута, а затем создаете экземпляр данного класса. Следующий фрагмент кода показывает способ, с помощью которого ваш MID-лет может это сделать.
...

try

{

String name =

getAppProperty("I18NDemo-number_format-fr_FR");

// "name" теперь эквивалентно "NumberFormat_FR"

Class с = Class.forName(name);

NumberFormat_FR nf =

(NumberFormat_FR) с.new Instance();

}

catch (InstantiationException ie)

{

...

}

catch (IllegalAccessException iae)

{

...

catch (ClassNotFoundException cnfe)

{

...

}

...
Конечно, вы должны предоставить MIDP-совместим'ый классификационный файл Java с файлом JAR вашего приложения для того, чтобы эта схема работала.
Другой недостаток использования дескрипторов приложения заключается в том, что они неправильно обращаются с файлами JAD и манифеста для программно определяемых свойств. Вы, возможно, думаете, что это просто философское размышление, но это отражается на производительности. Чтобы прочитать файлы JAD или манифеста, вы должны привлечь помощь AMS. Единственный вызов вовлекает несколько компонентов реализации. Файл JAD на самом деле не предназначен для подобного частого доступа. Вы могли заметить, что происходит снижение производительности при попытке прочесть большой файл локализованных ресурсов - или любого другого типа программно определяемых ресурсов.
Кроме того, этот единственный файл JAD должен соответствовать всем МЮ-летам в наборе MID-летов, что делает его еще больше. При использовании файла JAD не в простой демонстрационной программе, а где-либо еще он станет слишком громоздким, так как число атрибутов вырастет.
Другой проблемой является место для указателя ошибок.Разработчик, вручную локализующий файл JAD, легко может сделать незаметные опечатки в указанных атрибутах. А файл JAD не поддерживает вставку комментариев, которые могут помочь людям понять использование атрибута в приложении.

Acпекты интернационализации

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

Работа с сообщениями - представление всего видимого текста (текст сообщения, текст ошибки, заголовки компонентов пользовательского интерфейса, приглашения и так далее) на языке, соответствующем контексту региональной настройки исполнения.

Политика задания формата - использование правильных, зависящих от региональной настройки форматов даты, времени и числовых значений.

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

Политика строкового сравнения - использование соответствующей политики строкового сравнения на основе языка региональной настройки.

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

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

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

определение среды региональной настройки устройства;

загрузка локализованных ресурсов приложения;

динамический поиск и извлечение локализованных ресурсов для отображения пользовательского интерфейса;

отображение локализованных ресурсов.

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

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

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

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

Форматирование даты, времени, числовых и денежных значений. В различных ре гионах используют различные форматы написания дат, времени и чисел. Например, в Европе люди пишут даты и числа не так, как жители Соединенных Штатов. Француз ский пользователь пишет дату, время и числовые величины с помощью следующих форм:

25 decembre 2002

2002/12/25



25/12/2002

08.30

14.45

20.000,45 (двадцать тысяч и сорок пять сотых)

В Соединенных Штатах, однако, те же самые значения обычно пишутся следующим образом:

December 25, 2002

12/25/2002

8:30 am

2:45 pm

20,000.45 (двадцать тысяч и сорок пять сотых)

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

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

Cтроковая сортировка

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

Cтруктуры интернационализации

В основном проблема всех разработок интернационализации заключается в поиске механизма, который дает возможность приложениям извлекать правильную версию локализованных ресурсов при работе. В отличие от J2SE, MIDP не имеет реального API или классов, которые поддерживают общее извлечение локализованных ресурсов. Здесь нет класса ResourceBundle или каких-либо его подклассов. Приложения MIDP должны создавать свои собственные механизмы для определения и извлечения локализованного ресурса. В реальности, наиболее жизнеспособными подходами являются:

извлечение локализованных ресурсов из файла JAD;

извлечение локализованных ресурсов из текстового файла, который является частью файла JAR приложения;

извлечение локализованных ресурсов из классификационного файла Java, такого, как определяемый приложением механизм упаковки пакетов ресурсов стиля J2SE.

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

Форматирование дат, времени и чисел

MIDP не предоставляет поддержки форматирования дат, времени, числовых или денежных значений. В MIDP нет классов платформы J2SE, которые поддерживают это форматирование: здесь нет классов DateFormat, NumberFormat и DecimalFormat. Однако производители могут предоставлять определяемые реализацией классы для поддержки этих возможностей форматирования.

MIDP определяет классы Date и TimeZone в своем пакете java.util, но эти классы на самом деле не интернационализированы. То есть их интерфейсы не определяют каких-либо возможностей, которые связаны с чувствительной к региональным настройкам обработкой.

Класс Date просто представляет определенный экземпляр формата времени в Универсальном синхронизированном времени (UTC). В MIDP нет поддержки изменения значения Date на представление временного значения в любой другой временной зоне или для форматирования временных значений при отображении пользователям. Платформа J2SE, однако, имеет связанные классы (такие, как DateFormat), которые могут форматировать значения даты в манере, принятой в данном регионе. В MIDP нет таких классов.

MIDP поддерживает временные зоны с помощью своего класса java.util.TimeZone. Этот класс абстрактен. Ваша реализация MIDP предоставит, по крайней мере, один конкретный подкласс, который представляет временную зону GMT. Спецификация MIDP требует поддержки только временной зоны GMT, однако ваша реализация может также поддерживать другие зоны.

Метод TimeZone.getDefault() выдает объект TimeZone, который представляет временную зону, устанавливаемую по умолчанию, для сервера, на котором ваше приложение запущено. Убедитесь, что он может определить временную зону GMT, даже если это не временная зона, в которой работает приложение вашего компьютера.

Метод TimeZone.getTimeZone(String id) выдает объект TimeZone для трехбуквенного обозначения аргумента временной зоны, указанного в вызове. Имейте в виду, что выдаваемый объект может не представлять временную зону, которую вы запрашивали, потому что реализация не поддерживает ее. Очевидно, для вас как для разработчика приложения важно знать, в каких временных зонах поддерживается ваша платформа.

Инициализация приложения с локализованными ресурсами

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

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

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

Использование атрибутов МID-лета для определения локализованных ресурсов

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

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

Для демонстрации данного подхода я вновь использовал демонстрационную программу HelloWorld из главы 3. Приложение переименовано на IISNDemo для отличия его от оригинальной версии.

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

Использование классификационных файлов Java для определения интернационализированных ресурсов

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

Эта разработка аналогична разработке иерархии пакетов ресурсов J2SE. Классы java.util.ResourceBundle и java.util.ListResourceBundle J2SE являются абстрактными классами, определяющими структуру создания агрегаций произвольных чувствительных к региональным настройкам объектов Java. Эти объекты могут быть любыми объектами Java.

Этот подход к разработке интернационализации определяет свою собственную версию классов ResourceBundle и ListResourceEundle J2SE. В листингах 9.7 и 9.8 показаны их реализации, которые определяют, соответственно, подмножества классов ResourceBundle и ListResourceBundle платформы J2SE. Хотя эти реализации являются собственными, сигнатуры методов являются теми же, что и у их аналогов в J2SE.

Использование текстовых файлов приложения для определения локализованных ресурсов

Второй подход к локализации использует программно определяемые текстовые файлы, которые содержат локализуемые атрибуты. Приложение с помощью данной схемы может, например, определить один файл локализованных атрибутов для каждой региональной настройки. Схема имен может соответствовать обозначению региональной настройки, например, en_US.txt для английской, fr_FR.txt для французской, ja_JP.txt для японской и так далее. В листинге 9.4 показан один пример такого файла, содержащего пары «ключ-значение» локализованных строк.

Файл JAD содержит

I18NDerao-alert-en_US: Alert

I18NDemo-alert-fr_FR: Alerce

H8NDemo-alert_text-en_US: The button was pressed

I18NDemo-alert_text-f£_FR: Le bouton a ete presse

I18NDemo-alert_title-en_US: Button Pressed

I18NDemo-alert_title-fr_FR: Eouton a ete Presse

I18NDemo-cancel-en_US: Cancel !18NDemo-cancel-fr_FR: Quitter

I18NDemo-exit-en_US: Exit IlSNDemo-exit-fr_FR: Sortie

I18NDemo-greeting-en_US: Another MIDlet!

I18NDerao-greeting-fr_FR: Un autre MIDlet!

I18NDemo-help-en_US: Help I18NDemo-help-fr_FR: Aider

I18NDemo-item-en_US: Item I18NDemo-item-fr_FR: Item,

I18NDemo-menu-en US: Menu

I18NDemo-menu-fr_Fr: Menu

I18NDemo-ok-en_US: OK

I18NDemo-ok-fr_FR: OK

I18NDe:r.o-sayhi-en_US: Say hi

I18NDemo-sayhi-fr_FR: Dis bonjour

I18NDemo-screen-en_US: Screen

I18NDemc-screen-fr_FR: Ecran I18NDemo-stop-en_US: Stop

I18NDemo-stop-fr_FR: Arreter I18NDemo-title-en_US: Hello, World

I18NDemo-title-fr_FR: A116, tout le Monde MIDlet-1: I18N Demo 1,

I18n.png, I18NDemo MIDlet-Info-URL:

MIDlet-Jar-Size: 19101 MIDlet-Jar-URL: ilSn.jar MIDlet-Name:

I18n MIDlet-Vendor: Vartan Piroumian MIDlet-Version: 1.0

Имена атрибутов в файле JAD, показанные в листинге 9.1, приобретают следующую форму:

<название МID-лета>
-<ключ>
-<обозначение региональной настройки>

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

I18NDemo-title-en_US: Hello, World .

I18NDemo-title-fr_FR: A116, tout le Monde

В листингах 9.2 и 9.3 показаны два файла, которые составляют исходный код приложения. Они определяют и реализуют схему поиска атрибутов, отражаемую именами атрибутов в файле JAD. Программа извлекает версию атрибута, связанного с контекстом региональной настройки, в котором приложение работает.

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

Измененный класс

1 import javax.microedition.midlet.MIDlet;

2

3 import javax.microedition.Icdui.Display;

4 import javax.microedition.Icdui.Displayable;

5 import javax.microedition.Icdui.Form;

6

7 /**

8 Первая версия приложения IlSNDemo.

9

10 <р>
Данная версия демонстрирует простейший подход к

11 загрузке локализованных ресурсов из файла JAD MID-лета.

12 этот подход быстро становится непригодным при большом

13 количестве ресурсов. И он полезен только для текстовых

14 сообщений, но не для других видов локализованных

15 ресурсов.

16 */

17 public class IlSNDemo extends MIDlet

18 {

19 // Региональная настройка, указанная для выполнения в

20 // данном MID-лете.

21 private String locale;

22

23 // Displayable. Этот компонент отображается

24 // на экране.

25 private HelloForm form;

26

27 // Экземпляр Display. Данный объект управляет всеми

28 // компонентами Displayable данного MID-лета.

29 private Display display;

30

31 // Экземпляр MID-лета.

32 private static IlSNDemo instance;

33

34 // Префикс имен атрибутов локализуемых

35 // ресурсов.

36 String attrPrefix = new String("I18NDemo-");

37

38 /**

39 Конструктор No-arg.

40 */

41 public I18NDemo()

42 {

43 super();

44 instance = this;

45 }

46

47 /*

48 Получает экземпляр данного класса, который существует в

49 работающем приложении.

50

51 Звоззращает экземпляр, созданный при запуске

52 приложения.

53 */

54 public static IlSNDemo getlnstance()

55 {

56 if (instance == null)

57 {

58 instance = new IlSNDemo ();

59 }

60 return instance;

61 }

62

63 /**

64 Запускает .MID-лет. Получает текущую региональную

65 настройку для реализации. Использует ее для

66 создания префикса ключей атрибутов всех

67 локализованных ресурсов. Названия локализованных

68 ресурсов в файле JAD соответствуют

69 совместимой схеме имен.

70 */

71 public void startApp()

72 {

73 // Извлекает региональную настройку из программного

74 // обеспечения AMS. Региональная настройка должна быть

75 // установлена прежде, чем данный MID-лет начнет выполняться.



76 locale =

77 System.get Property("microedition.locale");

78

79 // Создает элемент Displayable. Получает локализованную

80 // String, которая представляет заголовок

81 // Form, из определенных пользователем атрибутов файла

82 // JAD. Получает все локализованные строки таким

83 // образом.

84 String formTitle = getResource("title");


85 form = new HelloForm(formTitle);


86

87 // Это приложение просто отображает единственную форму,

88 // созданную ранее.

89 display = Display.getDisplay(this);


90 display.setCurrent(form);


91 }

92

93 /**

94 Выдает значение, связанное с указанным

95 ключом из списка определяемых пользователем

96 ресурсов MID-лета в файле JAD приложения.

97

98 @param key - ключ пары «ключ-значение».

99

100 @выдает значение, связанное с указанным

101 ключом.

102 */

103 public String getResource(String key)

104 {

105 StringBuffer index = new

106 StringBuffer(«ttrPrefix);


107 String value;

108

109 index.append(key);


110 index.append('-');


111 index.append(locale);

112

113 value = getAppProperty(index.toString ());


114 return value;

115 }

116

117 /**

118 Закрываем приложение. Уведомляем

119 реализацию о выходе.

120 */

121 public void quit() ,

122 {

123 notifyDestroyed ();


124 }

125

126 public void destroyApp(boolean destroy)

127 {

128

129 }

130

131 public void pauseApp()

132 (

133

134 }

135 }

Имя данного файла - fr_FR.txt. Он состоит из франкоязычных версий строк приложения

alert: Alerte

alert_title: Bouton Presse alert_text: Le bouton a ete presse

cancel: Quitter exit: Sortie

greeting: Mon troisieme MIDlet!

help: Aider

item: Item

menu: Menu

ok: OK

sayhi: Dis bonjour

screen: Ecran

stop: Arreter

Mtle: A116, tout le Monde

Этот подход по существу тот же самый, что и предыдущий, за исключением того, что теперь вы должны создавать и поддерживать файл ресурса. Любые файлы ресурсов, которые вы создаете, должны быть частью JAR приложения. Вспомните, что спецификация MIDP запрещает прямой доступ к файлам на родной платформе.

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

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

Класс I18NDemo2 использует

1 import javax.microedition.midlet.MIDlet;

2

3 import javax.microedition.Icdui.Display;

4 import javax.microedition.Icdui.Displayable;

5 import javax.microedition.Icdui.Form;

6

7 import java.io.DatalnputStream;

8 import Java.io.InputStream;

9 import Java.io.InputStreamReader;

10 import Java . io . EOFException;

11 import Java.io.lOException;

12 import Java.io.Reader;

13 import Java.io.UTFDataFormatException;

14 import Java.io.UnsupportedEncodingException;

15

16 import Java.util.Hashtable;

17

18 /**

19 Вторая версия приложения HSNDemo.

20

21 <р>
Эта версия'также дехонстрирует простой способ определения

22 локализованных ресурсов. Она считывает файл, который является

23 частью файла JAR приложения (не файла JAD)

24 для загрузки локализованных ресурсов. Файл

25 состоит из набора пар «ключ-значение», одной на строку,

26 которые представляют локализованные строки.

27 MID-лет должен затем проанализировать содержимое файла

28 и создать внутреннюю хэшированную таблицу для поиска.

29

30 <р>
Этот подход требует слишком много усилий по обработке

31 потока, который содержит файл

32 локализованных ресурсов. Более того, этот подход

33 не отвечает за локализацию ресурсов, которые

34 не являются строками.

35 */

36 public class I18NDemo2 extends MIDlet

37 {

38 // Файл, который содержит ресурсы для

39 // активной локальной настройки.

40 private String resourceFile;

41

42 // Региональная настройка, указанная для выполнения данного

43 // MID-лета.

44 private String locale;

45

46 // Символьная кодировка, установленная по умолчанию,

47 // используемая данной платформой.

48 private String encoding;

49

50 // HashTable, которая содержит локализованные

51 // ресурсы.

52 private Hashtable resources = new Hashtable () ;

53

54 // Displayable. Этот компонент отображается

55 // на экране.

56 private HelloForm2 form;

57

58 // Экземпляр Display. Данный объект управляет всеми

59 // компонентами Displayable данного MID-лета.



60 private Display display;

61

62 // Экземпляр данного MID-лета.

63 private static I18NDemo2 instance;

64

65 /**

66 Конструктор No-arg.

67 */

68 public I18NDemo2()

69 {

70 super();


71 instance = this;

72 }

73

74 /*"

75 Получает экземпляр данного класса, который существует

76 в действующем приложении.

77

78 @выдает экземпляр, созданный при запуске

79 приложения..

80 */

81 public static I18NDemo2 getlnstance ()

82 {

83 return instance;

84 {

85

86 /**

87 Запускает MID-лет. Получает текущее название

88 региональной настройки. Использует его для создания

89 имени файла, который содержит локализованные

90 ресурсы региональной настройки. Файл ресурса

91 находится в файле JAR приложения.

92 */

93 public void startApp()

94 {

95 // Извлекает региональную настройку из программного

96 // обеспечения AMS. Региональная настройка должна быть

97 // установлена до выполнения данного MID-лета.

98 locale =

99 System.getProperty("microedition.locale");

100

101 // Названия файлов локализованных ресурсов, соответствующих

102 // форме: <язык>
_<страна>
.txt.

103 // Создает строку имени файла и передает ее в

104 // метод, который открывает файл и извлекает

105 // содержимое.

106 resourceFile = locale + ".txt";

107 int status = loadResources(resourceFile);


108

109 if (status < 0)

110 {

111 quit();


112 return;

113 }

114

115 // Создаем элемент Displayable. Получаем

116 // локализованную String, которая представляет

117 // заголовок Form.

118 String formTitle = getResource ("title" );


119 form = new HelloForm2(formTitle);

120

121 // Это приложение просто отображает одну .

122 // форму, созданную выше.

123 display = Display.getDisplay (this);


124 display.setCurrent(form);


125 }

126

Данный класс определяет Form,

1 import javax.microedition.midlet.MIDlet;

2

3 import javax.microedition.Icdui.Alert;

4 import javax.microedition.Icdui.AlertType;

5 import javax.microedition.Icdui.Command;

6 import javax.microedition.Icdui.CommandListener;

7 import javax.mi'croedition. Icdui .Display ;

8 import javax.microedition.Icdui.Displayable;

9 import javax.microedition.Icdui.Form;

10

11 /**

12 Данный класс определяет Form, которая отображает некоторый

13 простой текст и меню команд. Цель данного класса

14 продемонстрировать интернационализацию и локализацию

15 видимых пользователю атрибутов. Он работает с классом

16 I18NDemo2.

17 */

18 public class HelloForm2 extends Form

19 {

20 // Заголовок даннвй Form, устанавливаемый по умолчанию.

21 private static final String DEFAULTJTITLE =

22 "Hello, World";

23

24 // Блок прослушивания команд, который обрабатывает

25 // командные события в данной Form.

26 private MyCommandListener cl = new

27 MyCommandListener (1;

28

29 // Экземпляр дисплея, связанный с данным

30 // MID-летом.

31 Display display;

32

33 // Ссылка на связанный с данным объектом

34 // объект MID-лета.

35 IlSNDemo midlet;

36

37 // Уведомление, отображаемое в ответ на активацию

38 // некоторой из команд данной Form.

39 Alert alert;

40

41 private Command showAlert;

42 private Command sayHi;

43 private Command cancel;

44 private Command exit;

45 private Command help;

46 private Command item;

47 private Command ok;

48 private Command screen;

49 private Command stop;

50

51 /**

52 Конструктор No-arg. Устанавливает заголовок

53 по умолчанию данной формы.

54 */

55 HelloForm2()

56 {

57 this(DEFAULT_TITLE);


58 }

59

60 /**

61 Конструктор.

62

.63 @param title - Заголовок данной Form.

64 */

65 KelloForm2(String title)

66 {

67 super (title);


68

69 midlet = IlSNDemo.getlnstance();

70

71 // Добавляет строковый элемент в форму.

72 String msg = midlet.getResource("greeting");


73 append (msg);


74

75 display = Display.getDisplay(midlet);




76

77 // Добавляет MyCommandListener в Form для прослушивания

78 // события нажатия клавиши «Back», которое должно

79 // создавать всплывающее уведомление Alert.

80 setCommandLiscener (cl) ;

81

82 showAiert = new

83 Command(midlet.getResource("alert"),

84 Command.SCREEN, 1);


85 addCommand(showAlert);


86

87 sayHi = new

88 Command(midlet.getResource("sayhi") ,

89 Command.SCREEN, 1) ;

90 addCommand(sayHi);


91

92 cancel = new

93 Command(midlet.getResource("cancel"),

94 Command.SCREEN, 1);


95 addCommand(cancel);


96

97 exit = new

98 Command(midlet.getResource("exit"),

99 Command.SCREEN, 1);


100 addCommand(exit);


101

102 help = new

103 Command(midlet.getResource("help"),

104 Command.SCREEN, 1);


105 addCommand(help);

106

107 item = new

108 Command(midlet.getResource ("item"),

109 Command.SCREEN, 1);


110 addCommand(item);


111

112 ok = new

113 Command(midlet.getResource("ok"),

114 Command.SCREEN, 1) ;

115 addCommand(ok);


116

117 screen = new

118 Command(midlet.getResource("screen") ,

119 Command.SCREEN, 1);


120 addCommand(screen);

121

122 stop = new

123 Command(midlet.getResource("stop"),

124 Command.SCREEN, 1);


125 addCommand(stop);


126 }

127

128 // Данный класс просто прослушивает активацию

129 // какой-либо команды. Экземпляр HelloForm

130 // устанавливает экземпляр данного класса как

131 // свой блок прослушивания команд. Экземпляр

132 // объекта не проверяет информацию команды,

133 // а просто отображает модальное Alert, показывающее,

134 // что экранная клавиша была активирована пользователем.

135 public class MyCommandListener

136 реализует CommandListener

137 {

138 public void commandAction(Command c,

139 Displayable d)

140 {

141 String title =

142 midlet.getResource("alert_title") ;

143 String msg = midlet.getResource("alert_text");


144

145 if (с == showAlert)

146 {

147 alert = new Alert(title,



148 msg,

149 null, AlertType.INFO);


150 alert.setTimeout(Alert.FOREVER);


151 display.setCurrent(alert, HelloForm2.this);

152 }

153 else if (c == sayHi)

154 {

155 alert = new Alert(title,

156 msg,

157 null, AlertType.INFO);


158 alert.setTimeout(Alert.FOREVER);


159 display.setCurrent(alert, HelloForm2.this);


160 }

161

162 if (c == exit)

163 {

164 I18NDemo.getInstance-() .destroyApp (true) ;

165 }

166 }

167 }

168 }

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

Метод Class.getResourceAsStream(String name) является единственным способом, с помощью которого MID-лет может считывать файл из JAR приложения. Параметр имени представляет собой имя файла без информации о пути. Этот метод выдает объект java.io.InputStream, который является байтовым потоком.

Вы должны преобразовать этот байтовый поток в символьный для того, чтобы считывать значения строковых атрибутов в вашей программе. Единственный практичный способ преобразовать байтовые потоки в символьные - это использовать класс java.io.InputStreamReader. Вы создаете экземпляр данного класса, пересылая ваш объект InputStream в конструктор InputStreamReader. В строках с 137 до 154 листинга 9.5 символьный поток срздает определяемый приложением метод loadResources ().

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


В листинге 9. 5 происходит преобразование из кодировки ISO8859-1 (используемой файлом en_US.txt) в уникод. При считывании символьных данных в программу конечной кодировкой всегда является уникод. Java всегда представляет символы и строки внутренне с помощью уникода.

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

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

ключи и значения атрибутов должны быть кодированы с помощью одной и той же символьной кодировки;

все файлы ресурсов для всех региональных настроек должны использовать одну символьную кодировку.

Лучше всего использовать одну символьную кодировку для всего файла. В противном случае вам понадобится создать два символьных потока: один для анализа ключей атрибутов и второй для анализа значений. Подобная схема добавляет вашей обработке потоков ненужный уровень сложности.

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



Двумя практичными вариантами символьных кодировок являются последовательности переключения кодов UTF-8 и Unicode Java. UTF-8 - это код изменяющейся ширины, который поддерживает определения символьной кодировки ASCII. Он вмещает все символы всех языков. К несчастью, потоковые классы MIDP не имеют удобных методов, таких, как DatalnputStream.readUTFO J2SE, для считывания строк UTF. Итак, вам все равно придется выполнять анализ потока собственноручно. Другая сложность заключается в том, что теперь вам придется записывать ваши файлы ресурса в формате UTF-8. Поэтому вам нужны текстовые редакторы и другие инструменты, которые поддерживают создание файлов, кодированных в UTF-8.

Простейшее решение - использовать последовательности переключения кода Unicode Java для кодирования значений строковых атрибутов. Каждая последовательность переключения кода представляет собой уникальный символ уникода. У этого подхода есть два преимущества. Во-первых, вы можете записывать эти последовательности в файл как символы ASCII. Во-вторых, уникод поддерживает все языки. В листинге 9.4 используется ISO8859-1. Он адекватен для франкоязычных ресурсов, но в то же время он может не поддерживать корейский язык, например, тогда как уникод поддерживает. Вы можете использовать некоторые другие многобайтные кодировки, но затем вам придется положиться на редакторы методов ввода и другие инструменты для считывания и записи файла ресурса в этой кодировке.

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

Когда вы создали ваш объект InputStreamReader, который является символьно ориентированным потоком, вы можете извлекать символы из него с помощью методов read().Они происходят из класса, стоящего над ними, java.io.Reader. Эти методы выдают char уникода. В таблице 9.1 перечислены методы класса Reader.

Класс ResourceBundle

import Java.util.Hashtable;

/**

Данный класс определяет базовый класс для определения локализованных ресурсов

приложения. Он реализует подмножество класса java.util.ResourceBundle J2SE,

но придерживается интерфейса, определенного данным классом.

public abstract class ResourceBundle

«Родительские» ресурсы. Если ресурс не найден в данном пакете, производятся

поиски родительского пакета.

*/

protected ResourceBundle parent;

/**

Конструктор No-arg. public ResourceBundle () super();

/**

Получает пакет ресурсов с указанным именем класса.

Имя класса уже содержит язык и код страны назначения в стандартном формате.

Например, имя класса пакета ресурсов может быть «I18NDeraoResources_fr_FR».

@param className Полное имя класса, такое, как «I18NDemoResources_fr_FR».

@возвращает объект пакета ресурсов.

*/

public static ResourceBundle getBundle(String classNarae) throws IllegalArgumentException,

KissingResourceException

{

return ResourceBundle.getBundle(className, "");

}

/**

Получает пакет ресурсов с указанным базовым именем.

@param baseName Полностью определенное имя класса извлекаемого пакета.

Например, базовое имя «I18NDemo_fr_FR» - «HSNDerao».

Sparam строка региональной настройки, представляющая региональную настройку,

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

Ожидаемая форма <язык>
.<страна>
в соответствии с ISO 639 и ISO 3166, соответственно.

@выдает пакет ресурсов для возвращения

*/

public static ResourceBundle getBundle(String baseName, String locale)

throws IllegalArgumentException, MissingResourceException

{

Class c; if (baseName == null)

{

throw new IllegalArgumentException("No basename.");

{

String className = baseName + "_" + locale;

ResourceBundle bundle = null;

try

{

с = Class.forName(className);

bundle = (ResourceBundle) с.newlnstance();

}

catch (ClassNotFoundException cnfe)

throw new

MissingResourceException("Class not found.");




}

catch (InstantiationException ie)

{

throw new

MissingResourceException("Can11 instantiate.") ;

}

catch (IllegalAccessException iae)

{

throw new

MissingResourceException("Can1t access.");


}

return bundle;

}

/**

Извлекает объект с указанным ключом. Если ключ не найден, ищется родительский пакет.

@param key Ключ объекта

@выдает объект с указанным ключом

*/

public final Object getObject(String key)

throws MissingResourceException

}

Object obj; if (key == null)

{

throw new NullPointerException();


}

obj = handleGetObject(key);
if (obj == null SS parent 1= null)

{

obj = parent.getObject(key);


}

if (obj == null)

{

throw new MissingResourceException ();


return obj;

}

/**

Ищет данный пакет ресурсов для объекта с указанным ключом.

@param key Ключ поиска желаемого объекта.

@выдает объект с указанным ключом.

*/

protected abstract Object handleGetObject(String key);


}

Класс. ListResourceBundle

/**

Этот класс определяет пакет ресурсов как подходящий массив ресурсов.

Он воспроизводит класс того же имени, определяемый платформой J2SE, java.util.ListResourceBundle.

<р>
Данный класс абстрактен. Приложения вынуждены создавать его

подклассы и определять конкретные классы, которые содержат локализованные ресурсы.

<р>
0пределенные подклассы конкретного приложения должны быть названы так,

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

стандартами ISO 639 и ISO 3166 для языковых и страновых кодов соответственно.

*/

открытый абстрактный класс ListResourceBundle дополняет ResourceBundle

/**

Конструктор No-arg.

*/

public ListResourceBundle()

super();

// Массив ресурсов в формате ключ-значение, private static final Object [][] contents = null;

/**

Получает массив ресурсов.

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

*/

public abstract Object [][] getContents();

/**

Получает объект, который представляет значение, связанное с указанным ключом.

@param key Ключ пары ключ-значение.

@выдает объект, который представляет значение пары ключ-значение.

*/

public final Object handleGetObject(String key)

{

Object value = null; if . (key == null)

{

return null;

}

Object [][] pairs = getContents ();

for (int i = 0; i < pairs. length; i + +) if (key.equals(pairs [i] [0]))

value = (pairs [i] [1]) ;

}

}

return value;

}

}

Смысл данной разработки заключается в том, что разработчики приложения создают подклассы ListResourceBundle. Каждый подкласс представляет собой агрегацию локализированных ресурсов для определенной региональной настройки. В листинге 9.9 показан конкретный подкласс ListResourceBundle, который предоставляет ресурсы приложения, локализованные под англоязычный регион. Отметьте, как имя класса отражает поддерживаемую региональную настройку. Эта схема присвоения имен не только облегчает управление классом во время разработки, она также помогает обнаруживать местонахождение и загружать класс во время работы приложения.

Конкретный подкласс

import Java. io.lOException;

/**

Данный класс определяет локализованные ресурсы приложения I18NDemo3.

Вы извлекаете ресурс, вызывая метод getObject() в классе ResourceBundle.

*/

public class I18NDemoResources_en_US extends ListResourceBundle

// Содержит один из локализованных ресурсов. Нам необходимо

// инициализировать данную переменную в статическом

// инициализаторе данного класса, private static Image applcon;

private Object [][] contents =

{

("title", "Hello, World"}, // Form title.

("greeting", "My third MIDlet"}, // Form text.

("alert_title", "Button Pressed"), // Alert title.

{"alert_text", "A button was pressed!"),// Alert text.

{"exit", "Exit"}, // "Exit" menu item.

{"menu", "Menu"}, // "Menu" soft button.

{"cancel", "Cancel"}, // "Cancel" menu item.

{"stop", "Stop"}, // "Stop" menu item.

{"ok", "OK"}, // "OK" menu item.

{"alert", "Alert"}, // "Alert" soft button.

{"sayhi","Say Hi"}, // "Say Hi" menu item.

{"screen", "Screen"}, // "Screen" menu item.

{"item", "Item"}, // "Item" menu item.

{"help", "Help"}, // "Help" menu item.

{"app_icon", applcon} // Application icon.

};

/**

Конструктор No-arg.

*/

public I18NDemoResources_en_US()

{

super();

}

public Object ij[] getContents()

{

return contents;

}

// Необходим статический инициализатор для инициализации

// переменных, которые не могут быть инициализированы в

// массиве содержимого. Например, мы не можем выделить что-либо

// в массиве содержимого'для создания изображения и,

// выполнить требуемую обработку исключений.

static

{

try

{

applcon = Image.createlmage("i!8n-en_US.png");




}

catch (lOException ioe)

{

System.оut.println(ioe.getMessage)));


ioe.printStackTrace();


}

}

}

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

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

Ресурс каждой региональной

import javax.microedition.lcdui.Image;

import Java.io.lOException;

/'**

Класс, представляющий локализованные ресурсы для французского языка региона Франции.

Обратите внимание на использование последовательностей

переключения уникода в строковых литералах. Использование последовательностей

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

этот файл с помощью одних только символов ASCII, делая его эксплуатацию

более легкой. Легко добавлять комментарии для создания удобочитаемых строк.

*/

public class I18NDemoResources_fr_FR

extends ListResourceBundle

{

// Содержит один из локализованных ресурсов. Нам необходимо

// инициализировать данную переменную в статическом

// инициализаторе данного класса.

private static Image applcon;

private Object [][] contents =

{ {"title", "All\uOOf4, tout le Monde"), // Form title.

// Создаем текст: "My third MIDlet". ("greeting", "Mon troisi\uOOe8me MIDlet"),

// «Кнопка была нажата» ("Button was Pressed").

{"alert_title", "Bouton a \uCOe9t\uOOe9 press\uOOe9"),

// «Кнопка была нажата» ("The button was pressed").

{"alert_text", "Le bouton a \uOOe9t\uOOe9 press\uOOe9!"},

("exit", "Sortie"), // Пункт меню «Выход» ("Exit").

("menu", "Menu"), // Экранная клавиша «Меню» ("Menu").

("cancel", "Quitter"), // Пункт меню «Отмена» ("Cancel").

("stop", "Arreter"), // Пункт меню «Стоп» ("Stop").

("ok", "OK"), // Пункт меню "OK".

("alert", "Alerte"), // Экранная клавиша «Уведомление» ("Alert").

i"sayhi","Dis bonjour"), // Пункт меню «Скажи- привет» ("Say Hi").

("screen", "Ecran"), // Пункт меню «Экран» ("Screen").



{"item", "Item"), //.Пункт меню «Предмет» ("Item").

("help", "Aider"), // Пункт меню «Помощь» ("Help").

("app_icon", applcon) // Значок приложения.

};

/**

Конструктор No-arg.

*/

public I18NDemoResources_fr_FR()

{

super();


/**

Получает содержимое пакета ресурсов.

@возвращает массив пар ключ-значение.

public Object [][] getContents()

{

return contends;

}

// Обратите внимание, что статический инициализатор создает

// экземпляры класса Image с другими изображениями, нежели он

// использует в региональной настройке en_US. static

{

try

{

applcon = Image.createlmage("i!8n-fr_FR.png");


}

catch (lOException ioe)

{

System.out.printIn(ioe.getMessage());


io.e.printStackTracel) ;

}

}

}

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

Данная версия IlSNDemo использует пакет

import javax.microedition.midlet.MIDlet;

import javax.microedition.Icdui.Display;

import javax.microedition.Icdui.Displayable;

import ]avax.microedition.Icdui.Form;

import Java.util.Hashtable;

Третья версия приложения IlSNDemo.

<р>
Данная версия IlSNDemo использует пакет ресурсов для определения

локализованных ресурсов. Приложение определяет текущую региональную

настройку и пытается загрузить связанный с ней пакет, содержащий

соответствующие локализованные ресурсы. Если оно не может найти эти ресурсы,

оно загружает ресурсы U.S. English, представленные языком en_US и страной назначения.

<р>
Этот подход наиболее предпочтителен. Легко поддерживаются локализованные

ресурсы, отличные от строк.

*/

public class I18NDemo3 extends MIDlet

{

// Региональная застройка, указанная для выполнения

// данного МID-лета.

private String locale;

// Пакет ресурсов, который содержит локализованные ресурсы

// для выполнения данного приложения, private static ResourceBundle bundle;

{

// Displayable. Этот компонент отображается

// на экране.

private HelloForm3 form;

// Экземпляр Display. Этот объект управляет всеми

// компонентами Displayable для данного MID-лета.

private Display display;

// Экземпляр MID-лета.

private static !18NDerao3 instance;

/**

Конструктор No-arg.

*/

public I18NDemo3()

{

super();


instance = this;

}

/**

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

@выдает экземпляр, созданный при запуске приложения.

*/

public static I18NDemo3 getlnstance()

{

if (instance == null)

{

instance - new I18NDemo3();


}

return instance;

}

/**

Получает пакет ресурсов, используемый данным MID-летом.

Этот метод полезен для других классов, которым необходим доступ

к локализованным ресурсам приложения.

@выдает локализованные ресурсы MID-лета.

*/

public static ListResourceBundle getResourceBundle ()

{

return (ListResourceBundle) bundle;

}

/**

Запускает MID-лет. Определяет текущую региональную настройку среды исполнения



и использует ее для создания имени пакета локализованных ресурсов. Использует

это имя для создания имени класса Java, который затем загружается с помощью

Class. Если нет соответствия пакету ресурсов, по умолчанию используется пакет

ресурсов U.S. English.

*/

public void startApp()

{

// Извлекает региональную настройку из программного обеспечения

// AMS.Региональная настройка должна быть установлена

// до выполнения данного MID-лета.

locale = System.getProperty("microedition.locale");


bundle = null;

cry

{

bundle =

ResourceBundle.getBundle("IlSNDemoResources", locale);


if (bundle == null)

{

bundle =

ResourceBundle.getBundle("IlBNDemoResources", "en_US");


}

}

catch (MissingResourceException mre)

mre.printStackTracef);


}

try

}

/ Создаем элемент Displayable. Получаем локализованную

// String, которая представляет заголовок Form.

String formTitle = (String)

bundle.getObject("title");


form = new HelloForm3(formTitle);


}

catch (MissingResourceException mre)

{

rare.printStackTrace();


}

// Это приложение просто отображает одну форму, созданную ранее, display = Display.getDisplay(this);
display.setCurrent(form);


}

/**

Выдает значение, связанное с указанным ключом из списка определяемых

пользователем ресурсов MID-лета в файле JAD приложения.

@param key Ключ пары ключ-значение.

@выдает значение, связанное с указанным ключом.

*/

public Object getResource(String key)

}

Object resource = null;

try

{

resource = bundle.getObject(key);


}

catch (MissingResourceException mre)

}

}

return resource;

/**

Выход из MID-лета. Уведомляет реализацию, что она

может прервать работу всех ресурсов приложения.

Реализация вызывает destroyApp().

*/

public void quit()

{

notifyDestroyed();


/*

public void destroyApp(boolean destroy)

{

{

public void pauseApp()

{

}

}

На рисунке 9.1 показано основное окно, созданное программой I18NDemo3 при ее запуске в региональной настройке en_US. Программа динамически извлекает локализованные ресурсы, описанные в листинге 9.9.На рисунке 9.2 показан экран меню того же приложения, запущенного в региональной настройке fr_FR, которая использует локализованные ресурсы, описанные в листинге 9.10. Код приложения I18NDemo3 абсолютно не изменяется. Он просто динамически определяет контекст региональной настройки при инициализации и загружает соответствующий пакет ресурсов.

Файл русского локализированного

import javax.microedition.Icdui.Image;

import Java.io.lOException;

/"*

Данный класс определяет локализованные ресурсы

для приложения I18NDemo3. Вы извлекаете ресурс, вызывая метод getObjectf)

в классе ResourceBundle.

*/

public class I18NDemoResources_ru_RU

extends ListResourceBundle

{

// Содержит один из локализованных ресурсов. Нам необходимо

// инициализировать эту переменную в статическом инициализаторе

// данного класса.

private static Image applcon;

private Object [][] contents =

// "Привет, мир".

("title", "\u0417\u0434\u0440\u0430\u0441\u0442\u0432\u0443\u0439,

\u041c\u0446\uO*440!"),

// "Мой третий MID-лет".

{"greeting", "\u041c\043e\u0439 \u0442\u0440\u0435\u0442\u0438\u0439 MIDlet!"},

// "Кнопка нажата".

{"alert_title",

"\u041a\u043d\u043e\u043f\u043a\u0430 \u041d\u0430\u0436\u0430\u0442\u0430"},

// "Кнопка была нажата!".

("alert_text", "\u041a\u043e\u043e\u043f\u043a\u0430

\u0411\u044b\u043b\u0430 \u043d\u0430\u0436\u0430\u0442\u0430!"},

// Экранная клавиша "Выход".

("exit", "\u0412\u044b\u0445\u043e\u0434"},

{

// Экранная клавиша "Меню".

("menu", "\u041c\u0435\u043d\u044e"},

// Пункт меню "Отмена".

{"cancel",

"\u041f\u0440\u0435\u043a\u0440\u0430\u0442\u0446\u0442\u044c"),

// Пункт меню "Стоп".

("stop", "\u0421\u0442\u043e\u043f"},

// Пункт меню "ОК". {"ok", "OK"},

// Экранная клавиша "Предупреждение".

("alert", "\u0412\u043d\u0446\u043c\u0430\u043d\u0446\u0435"),

// Пункт меню "Скажи привет".

("sayhi","\u0421\u043a\u0430\u0436\u0446

\u043f\u0440\u0446\u0432\u0435\u0442"),

it Пункт меню "Экран".

{"screen", "\u042d\u043a\u0440\u0430\u043d"),

// Пункт меню "Предмет".

Необходим статический инициализатор для инициализации

("item", "\u041f\u0440\u0435\u0434\u04c3\u0435\u0442"),

// Пункт меню "Помощь".

("help", "\u041f\u043e\u043c\u043e\u0449\u044c"},

// Значок приложения. ("app_icon", applcon} };

/**

Конструктор No-arg.

*/

public I18NDemoResources_ru_RU()

super();


}

public Object [][] getContents()

}

return contents;

}

// Необходим статический инициализатор для инициализации

// переменной, которая не может быть инициализирована

// в массиве содержимого. Например, мы не можем выделить

// что-либо в массиве содержимого для создания изображения и

// выполнить требуемую обработку исключений.

static

{

try

{

applcon = Image.createlmage("i!8n-ru_RU.png");


}

catch (lOExce'ption ioe)

{

System.out.print In(ioe.getMessage());


ioe.printStackTrace() ;

}

}

}

Если вы все еще не убеждены, взгляните на листинг 9.13, который показывает ресурсы того же самого приложения, локализованные на японский язык. Класс I18NdemoResources_ja JP был создан с помощью того же текстового редактора, основанного на ASCII. Японские символы не могут быть введены в традиционном текстовом редакторе без поддержки IME. И, если вы используете IME, вы должны убедиться, что используете уникод для записи строковых литералов в файл. В противном случае вашему приложению придется выполнять преобразование посимвольной кодировки.

Последовательности

import javax.microedition.Icdui.Image;

import Java.io.lOException;

/**

Данный класс определяет локализованные ресурсы для приложения I18NDemo3.

Вы извлекаете ресурс, вызывая метод getObject() в классе ResourceBundle.

*/

public class I18NDemoResources_ja_JP

extends ListResourceBundle

{

// Содержит один из локализованных ресурсов. Нам необходимо

// инициализировать эту переменную в статическом инициализаторе

// данного класса.

private static Image applcon;

private Object [][] contents =

{

// "Привет, мир"

{"title", "\u24f64\u3055\u3093, \u3053\u3093\u306b\u3061\u306f"),

// "Мой третий MID-лет".

("greeting", "\u79cl\u306e 3 \u3063\u3081\u306e MIDlet"},

// "Кнопка нажата".

{"alert_title")

"\u30dc\u30bf\u30f3\u304c\u62bc\u3055\u308c\u307e\u3057\u305f"},

// "Кнопка была нажата".

"alert_text",

"\u30dc\u30bf\u30f3\u304c\u62bc\u3055\u308c\u3C7e\u3057\u305f!"}

// Пункт меню "Выход", {"exit", "\u51fa\53e3"},

// Экранная клавиша "Меню".

("menu", "\u30el\u30cb\u30e6\u30fc"),

// Пункт меню "Отмена".

("cancel", "\u3Cad\u30e4\u30f3\u30bb\u30eb"),

// Пункт меню "Стоп". {"stop", "\u505c\u6b62"),

// Пункт меню "ОК". ("ok", "OK"},

// Экранная клавиша "Предупреждение", {"alert", "Alert"),

// Пункт меню "Скажи привет", ("sayhi","\u30cf\u30a4"},

// Пункт меню "Экран".

{"screen", "\u30b9\u30af\u30ea\u30f3"),

// Пункт меню "Предмет", {"item", "\u9805\u76ee"),

// Пункт меню "Помощь".

("help", "\u308d"},

// Значок приложения.

{"app_icon", applcon)

/**

Конструктор No-arg.

*/

public I18NDemoResources_ja JP()

{

super();

)

public Object [][] getContents ()



{

return contents;

{

// Необходим статический инициализатор для инициализации

// переменной, которая не может быть инициализирована в

// массиве содержимого. Например, мы не можем выделить что-либо

// в массиве содержимого для создания изображения и выполнить

// требуемую обработку исключений.

static

{

try

{

applcon = Image.createlmage("i!8n-ja_JP.png");


{

catch (lOException ioe)

{

System.out.println(ioe.getMessage());


ioe.printStackTracef);


}

}

}

В листинге 9.14 показан файл I18NDemoResources_zh_CH. Java, который определяет локализованные ресурсы для упрощенного китайского языка.

Листинг 9.14. Этот файл определяет локализованные ресурсы для региональной настройки zh_CN, Китай, приложения I18NDemo3

import javax.microedition.Icdui.Image; import Java.io.lOException;

/**

Данный класс определяет локализованные ресурсы для приложения I18NDemo3.

Вы извлекаете ресурс, вызывая метод getObjectO в классе ResourceBundle.

*/

public class I18NDemoResources_zh_CN

extends ListResourceBundle

{

// Содержит один из локализованных ресурсов. Нам необходимо

// инициализировать эту переменную в статическом инициализаторе

// данного класса.

private static Image applcon;

private Object [][] contents =

{

// Заголовок формы "Hello, World".

("title", "\u54c8\u7f57\u4el6\754c"),

// Текст формы "My third MIDlet".

("greeting", "\u62ll\u7684\7b2c\u4e09\u4187 MIDlet"},

// Заголовок уведомления "Button Pressed". ("alert_title", "\u6309\u4eOb\u6309\u9215"],

// Текст уведомления "A button was pressed!". ("alert_text", "\u6309\u4eOO\u4187\u6309\u9215!"},

// Пункт меню "Exit".

("exit", "\u767b\u51fa"},

// Экранная клавиша "Menu", ("menu", "\u76ee\u5f54"},

// Пункт меню "Cancel", {"cancel", "\u53d6\u6d88"j,

// Пункт меню "Stop", ("stop", "\u505c\u6b62"},



// Пункт меню "OK". {"ok", "OK"),

// Экранная клавиша "Alert", {"alert", "\u8b66\u793a"),

// Пункт меню "Say Hi", ("sayhi", "\u55e8"},

// Пункт меню "Screen". ("screen", "\u87a2\u5e55"),

// Пункт меню "Item", ("item", "\u9879\u76ee"},

// Пункт меню "Help", {"help", "\u8bf4\u660e"},

// Значок приложения. {"app_icon", applcon}

};

/**

Конструктор No-arg.

*/

public I18NDemoResources_zh CN()

{

super!);


{

public Object [][] getContents ()

{

return contents;

}

// Необходим статический инициализатор для инициализации

// переменной, которая не может быть инициализирована в

// массиве содержимого. Например, мы не можем выделить что-либо

// в массиве содержимого для создания изображения и выполнить

// требуемую обработку исключений.

static

{

try

{

applcon = Imagb.createlraage("i!8n-zh_CN.png");


}

catch (lOException ioe)

{

System.out.println(ioe.getMessage!));
ioe.printStackTrace();


}

}

}

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



Подход пакетов ресурсов также содействует легкому переносу приложений в среду J2SE. Реализации классов пакетов ресурсов, показанных в листингах 9.7 и 9.8, создают только подмножество необходимых свойств. Но их строгое следование интерфейсам версий J2SE означает, что подклассы ListResourceBundle вашего приложения совместимы снизу вверх.

Пакеты ресурсов также способствуют лучшей восстанавливаемости и большей понятности. Зависящие от приложения подклассы ListResourceBundle могут быть легко восстановлены только лишь с помощью текстового редактора, основанного на ASCII. Любой ASCII-текстовой редактор может считывать и записывать символы ASCII или последовательности переключения кода Unicode Java, присутствующие в пакетах ресурсов. Кроме того, поскольку это исходные файлы Java, разработчики могут вставлять комментарии, которые ясно описывают каждый ресурс и контекст, в котором приложение его использует.

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

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

Установка нескольких файлов классов Java для локализованных ресурсов может потребовать больше ресурсов хранения устройства, чем вы можете себе позволить. Наиболее очевидной проблемой при разработке MIDP является потребление памяти. Хотя два первых подхода неудобны по нескольким причинам, они затрачивают меньше ресурсов памяти, чем подход классификационного файла Java.Иногда, когда вы не можете позволить себе лишние траты памяти, вы можете позволить приложению затратить несколько дополнительных секунд при запуске на считывание и анализ локализованных ресурсов. Одним из возможных компромиссов является игнорирование иерархии наследования ResourceBundle и предоставление единственного класса, который содержит локализованные ресурсы для каждой региональной настройки. Предоставьте соответствующий локализованный классификационный файл указанной региональной настройке приложения. Здесь вы жертвуете гибкостью ради производительности. Вы также теряете совместимость снизу вверх с J2SE, но это может быть неважно.

З. Класс HelloForm определяет

1 import javax.raicroedition.midlet.MIDlet;

2

3 import javax.microedition.Icdui.Alert;

4 import javax.microedition.Icdui.AlertType;

5 import javax.microedition.Icdui.Command;

6 import javax.microedition.Icdui.CommandListener;

7 import javax.microedition.Icdui.Display;

8 import javax.microedition.Icdui.Displayable;

9 import javax.microedition.Icdui.Form;

10

11 /*

12 Данный класс определяет Form, которая отображает

13 простой текст и меню команд. Цель данного класса

14 заключается в демонстрации i18n и 110n

15 видимых пользователю атрибутов. Класс извлекает

16 локализованные ресурсы из программного обеспечения

17 управления приложениями.

18 */

19 открытый HelloForm дополняет Form

20 {

21 // Заголовок данной Form, устанавливаемый по умолчанию.

22 private static final String DEFAULT_TITLE =

23 "Hello, World";

24

25 // Блок прослушивания команд, который обрабатывает

26 // командные события в данной Form.

27 private MyCommandListener cl = new

28 MyCommandListener ();

29

30 //. Экземпляр дисплея, связанный с

31 // данным MID-летом.

32 Display display;

33

34 // Ссылка на связанный с данным объектом

35 // объект MID-лета.

Поддержка интернационализации в MIDP

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

Классы Calendar, Date и TimeZone: пакет Java.util;

Системные свойства: microedition.encoding, microedition.locale;

Изменение кодировки: пакет java.io;

Определяемые пользователем атрибуты набора MID-летов: файл дескриптора приложения (файл JAD);

Извлечение ресурсов (файлов) из файла JAR набора MID-летов: Class.getResourceAsStream(String resourceName).

Пакет java.util MIDP содержит три класса, которые связаны с интернационализацией, а именно: Calendar, Date и TimeZone. Эти классы, однако, сами по себе не являются межнациональными. То есть их конкретные реализации не поддерживают операций во многих региональных настройках. Например, Calendar не выполняет вычислений, связанных с календарем определенного региона. Класс Date не чувствителен к форматам даты и времени региона. Они также не представляют сами по себе локализованные ресурсы. В этих классах присутствуют, однако, базовые определения, из которых могут быть организованы подклассы.

Классы Calendar и TimeZone абстрактны. Реализации MIDP должны предоставлять, по крайней мере, один конкретный подкласс каждого из них. Хотя и не интернационализированные, их реализации будут совместимы с региональными настройками, поддерживаемыми реализацией MIDP. Например, в регионе Соединенных Штатов реализация будет, скорее всего, поддерживать грегорианский календарь.

Большинство реализаций MIDP поддерживает только одну региональную настройку. В действительности спецификация MIDP требует от реализации поддержки лишь одной региональной настройки и одной временной зоны - время по Гринвичу (GMT).

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

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

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

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

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

Читатели, знакомые с поддержкой интернационализации платформы J2SE, заметят, что в MIDP довольно заметно не хватает всесторонней поддержки интернационализации (смотри пакет Java.text J2SE).Причина опять же заключается в ограниченности среды мобильных устройств. MIDP не имеет пакета Java.text. В действительности MIDP не поддерживает API для таких свойств интернационализации, как пакеты ресурсов, форматирование сообщений, числовое форматирование, чувствительные к региональным настройкам форматы дат и времени и так далее. В MIDP также отсутствуют новые свойства интернационализации пакета Java.text JDK версии 1.4, такие, как сортировка, двунаправленная текстовая поддержка, аннотации, атрибуты и так далее.

Поддержка календаря и временных зон

Опять же в отличие от платформы J2SE в MIDP есть только ограниченная поддержка календаря. Класс java.util.Calendar абстрактен. Поэтому каждая платформа MIDP будет предоставлять, по крайней мере, одну конкретную реализацию. Скорее всего, она не будет интернационализирована.

Конкретный подкласс платформы Calendar, вероятнее всего, реализует один определенный календарь, такой, как грегорианский или лунный. Он может соответствовать контекстам региональных настроек, в которых вы размещаете ваши приложения, а может и не соответствовать. Метод Calendar.getlnstance(TimeZone zone) выдает объект Calendar, который использует указанную временную зону и региональную настройку платформы, установленную по умолчанию. Обратите внимание, что этот фабричный метод не делает класс Calendar полностью интернационализированным классом. Он все еще не выдает соответствующий календарь, основываясь на региональном контексте. Например, если вы укажете китайское стандартное время (Chinese Standard Time), вы не получите объект, который представляет лунный календарь, используемый в Китае, во всех реализациях MIDP. Это означает, что вам нужно знать, какой календарь поддерживается вашей платформой, и согласуется ли он с региональной настройкой, поддерживаемой реализацией.

Понятия

Интернационализация - это действия программного обеспечения по соблюдению географического, лингвистического и культурного контекста, определяемого средой исполнения. Термин интернационализация иногда сокращается как «i18n», потому что 18 букв в этом слове между буквами «i» и «n» опускаются.

Работа с сообщениями

К сожалению, в MIDP также отсутствует явная поддержка организации сообщений. В отличие от J2SE, MIDP не предлагает API для работы с сообщениями и здесь нет класса MessageFormat. При разработке решения организации работы с сообщениями в приложении MIDP, разработчики должны ра матривать следующие вопросы:

местонахождение локализованных данных;

механизм получения доступа к локализованным данным;

используемый формат локализованных данных и символьная кодировка;

следы локализованных ресурсов;

производительность выполнения;

проблемы процесса локализации, такие, как управление ресурсами разработки, восстановление и пр.;

беспроводные сетевые среды, среды инициализации приложений и проблемы установки.

Разработка решения интернационализации приложения MIDP

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

Региональные настройки и локализация

Региональная настройка представляет собой определенный географический, лингвистический и культурный контекст. Она описывает контекст, в котором работают интернационализированные приложения. Термин локализация относится к практике предоставления приложению возможности работать в контексте определенной региональной настройки. Слово локализация иногда сокращается как «11Оn», поскольку 10 букв опускаются между буквами «l» и «n» в этом слове. Разработчик локализует приложение для одной или нескольких региональных настроек после его интернационализации.

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

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

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

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

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

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

Символьные кoдиpoвки

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

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

Кроме должного внутреннего представления данных с помощью символьных кодировок, приложения должны представлять данные правильно пользователю. Это требует использования шрифта, который представляет элементы, используемые в языке. Компьютерная платформа отвечает за предоставление приложениям поддержки шрифтов. Платформа создает соответствия между символьными кодировками и шрифтами, чтобы приложениям не приходилось этого делать. Эти соответствия определяют связи между точками кода и глифами. Глиф - это объект, визуализирующий то, что представляет собой элемент языка, как, например, буква или идеограмма.

Конструкторы и методы java.io.Reader

Название Конструктора и метода java.io. Reader		Элемент		Описание
InputStreamReader (InputStream is)		Конструктор		Создает поток, который преобразует из кодировки, устанавливаемой платформой по умолчанию, в уникод
InputStreamReader (InputStream is, String enc)		Конструктор		Преобразует из указанной кодировки в уникод
void closed		Метод		Закрывает поток
void mark(int readAheadLimit)		Метод		Устанавливает лимит опережающего считывания для метки
boolean markSupported()		Метод		Показывает, поддерживает ли данный поток разметку
int read()		Метод		Считывает один символ
int read (char [] cbuf, int off, int len)		Метод		Считывает количество «len» символов в части символьного массива, начиная от указанной сдвига
boolean ready ()		Метод		Показывает, должно ли здесь считываться что-либо
void reset ()		Метод		Переустанавливает поток в последнюю позицию метки
long skip (long n)		Метод		Пропускает указанное число символов

Единственной пропущенной задачей является анализ символов, которые вы считываете. К сожалению, MIDP не имеет удобных классов, таких, как класс StringTokenizer J2SE, который облегчает расстановку меток. Вы должны поэтому самостоятельно проанализировать локализованные ресурсы, один символ за раз, с помощью любой из двух форм перегрузки Reader.read(). Если вы использовали такой формат файла, как в листинге 9.4, самое меньшее, что вы должны сделать затем, это отделить поле ключа от поля значения для каждого атрибута, убрать пробелы и так далее. В листинге 9.5 весь код в строках 127-318 посвящен обработке потока.

Одним из существенных недостатков данного проектирования интернационализации является дополнительное кодирование, необходимое для создания.анализаторов потоков. Кроме того, что это включает дополнительную работу по разработке данного кода, ваше приложение также ограничивается средой исполнения. Файл ввода/вывода может отнять много рабочих ресурсов и выдать при этом только минимально приемлемую производительность. Это важно рассматривать при разработке приложений MIDP.

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

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

это действия по предоставлению приложению

Интернационализация - это действия по предоставлению приложению возможности динамического извлечения и использования чувствительных к региональным настройкам ресурсов при раб*оте. Интернационализация является важным свойством приложений MIDP. Интернационализированное приложение предназначено для большей пользовательской аудитории.
Интернационализация приложения означает предоставление ему при выполнении возможности извлечения ресурсов, которые совместимй с контекстом региональной настройки, в которой приложение работает. Локализация - это процесс предоставления ресурсов одному или нескольким контекстам региональной настройки.
Локализация - это деятельность по созданию определяемых региональной настройкой ресурсов для интернационализированных программ, к которым приложение получает доступ при выполнении. Работы по интернационализации и локализации сходны. Организация и задание формата локализованных ресурсов должны отражать схему и проектирование интернационализации. Решения всесторонней интернационализации и локализации должны обращаться к чувствительным к региональным настройкам операциям в следующих областях приложения:
работа с сообщениями;
задание формата даты, времени, числовых и денежных значений;
поддержка календаря;
чувствительные к региональной специфике значки, изображения и цвета.
Возможности, доступные в платформе MIDP, влияют на выбор варианта разработки интернационализации и затрагивают осуществимость реализации определенных разработок приложений MIDP. Платформа MIDP предоставляет три следующих основных механизма, которые могут быть использованы для создания возможностей интернационализации:
определяемые пользователем атрибуты набора MID-летов: файл дескриптора приложения;
поддержка извлечения ресурсов (файлов) из файла JAR набора MID-летов: Class. getResourceAsStream(StringresourceName);
преобразование символьных кодировок: пакет java.io.
Разработчики приложений MIDP должны также учитывать факторы производительности, восстанавливаемости и установки при разработке решений интернационализации и локализации.

Аутентификация пользователей

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

Существуют некоторые беспроводные системы, которые не хранят много пользовательской информации на мобильных устройствах. В таких случаях сервер должен связывать пользовательскую информацию с информацией устройства - MSN устройства, например. Как описывалось ранее, системы инициализации могут взаимодействовать с другими системами транспортировщика, такими, как серверы аутентификации, серверами облегченного протокола службы каталогов (Lightweight Directory Access Protocol (LDAP)) или серверами шлюза беспроводного Интернета (WIG) для получения остальной необходимой пользовательской информации.

Генерирование события оплаты

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

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

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

оплата за загрузку приложения;

оплата за установку;

оплата за запуск приложения;

оплата за определенное время использования;

оплата за определенное количество раз использования.

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

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

Обновление приложения

Обновление приложения - это процесс обновления приложения, которое уже находится на устройстве, на более новую версию. В соответствии с приложением «Инициированная пользователем беспроводная инициализация» (Over the Air User Initiated

Provisioning) спецификации MIDP для поддерживания обновлений уже установленных на устройства приложений требуется система инициализации ОТА. Вы найдете ссылку на этот документ в разделе «Ссылки» в конце данной книги.

Программное обеспечение пользовательского агента устройства и программное обеспечение диспетчера инициализации использует обязательный атрибут MIDlet-Version файла JAD приложения для согласования обновления приложения. Кроме того, дескриптор приложения должен однозначно идентифицировать набор МГО-летов, который должен быть загружен, так чтобы устройство могло определять, должно ли оно выполнять обновление или новую установку. Разработчики должны убедиться, что они поставляют правильную информацию о версии MID-лета и идентификации набора MID-летов.

Подготовка приложений к системам инициализации

Подготовка приложений к использованию в системах инициализации заключается в предоставлении всех обязательных файлов приложения и обеспечении того, что они содержат информацию, требуемую в процессе инициализации. Основная задача этой подготовки - этв правильное создание файла дескриптора приложения (JAD) и файла приложения JAR.

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

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

Таблица 10.1. Атрибуты MID-лета, связанные с инициализацией приложения

Название атрибута MID-лета		Описание		Наличие
MI Diet- Dele te-Confirm		Определяет текстовое сообщение, которое должно быть представлено пользователю для подтверждения удаления набора MID-летов. Используется для уведомления пользователей во время работы AMS с приложением для того, чтобы освободить место для установки MID-лета		Необязателен
MIDlet-Description		Определяет текстовое описание набора MID-летов. Используется для представления описания пользователю во время обнаружения		Необязателен
MIDlet-Install-Notify		Определяет LJRL, на который пересылается отчет о состоянии установки MID-лета через HTTP-запрос POST		Необязателен
MIDlet-Jar-Size		Показывает размер (в байтах) файла JAR MID-лета. Используется AMS для определения того, содержит ли устройство достаточно общей памяти для установки набора MID-летов		Обязателен
MIDlet-Name		Определяет название набора MID-летов. Используется для предоставления названия набора MID-летов пользователям		Обязателен
MIDlet-Vendor		Определяет название поставщика набора MID-летов		Обязателен
MIDlet-Version		Используется для перемещения приложения		Обязателен

<
Как среда клиента, так и среда сервера используют файл JAD. Диспетчер инициализации использует его во время инициализации, а клиент использует во время установки и исполнения приложения. Во время инициализации сервер инициализации посылает файл JAD на устройство, где программное обеспечение агента пользователя использует его для подтверждения того, что набор MID-летов совместим с устройством, до загрузки файла JAR всего набора MID-летов. Во время исполнения, как вы узнали из главы 3, AMS использует информацию, представленную в файле JAD, для управления жизненным циклом приложения. Кроме того, AMS делает информацию файла JAD доступной MID-летам набора MID-летов для использования во время выполнения МЮ-лета.

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

Значение атрибута MIDlet-Install-Notify должно описывать URL, на который агент пользователя посылает HTTP-запрос POST, содержащий информацию о состоянии установки. Посылать полный запрос POST в соответствии с рекомендациями приложения «Инициированная пользователем беспроводная инициализация» (Over the Air User Initiated Provisioning) спецификации MIDP входит в обязанности агента пользователя. То есть агенту пользователя необходимо получить некоторую информацию о приложении от AMS и включить ее - возможно, как параметры HTTP, - в запрос POST.

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

Хорошей идеей является обеспечение того, что дескрипторы вашего приложения определяют значение атрибута MIDlet-Install-Notify, чтобы агент пользователя мог выдать состояние установки даже в случаях, когда набор MID-летов не был извлечен. Например, возможно, что URL, который определяет местоположение файла JAR и является значением атрибута MIDlet-Jar-URL, неправилен.

Подтверждение пoкyпки и соблюдение обязательных условий

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

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

Подтверждение совместимости

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

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

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

Поиск приложений

Поиск приложений - это процесс, с помощью которого пользователи обнаруживают интересующие их приложения. Это первый этап процесса инициализации, в который вовлечен конечный пользователь. Большинство систем инициализации обычно предоставляют пользователям какой-либо WML-интерфейс (или XHTML) для обнаружения приложений с помощью мобильных устройств. Мобильные устройства, которые предназначены для загрузки ОТА, имеют НТТР-микробраузер, который, наиболее вероятно, будет интегрирован до некоторой степени в программное ббеспечение пользовательского агента устройства.

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

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

пользовательский контекст;

контекст устройства;

контекст среды платформы J2ME;

требования приложения.

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

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

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

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

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


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

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

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

В более автоматизированных системах система инициализации извлекает информацию о предпочтениях пользователя из сети транспортировщика. Агент пользователя может пересылать идентификационный номер мобильной станции (MSISDN или MSN) на сервер инициализации. Если сервер инициализации поддерживает интеграцию с внешними системами, такими, как серверы каталогов, он может получать пользовательскую информацию с сервера каталогов транспортировщика. Для того чтобы этот подход работал, транспортировщик должен предоставлять пользователям возможность вносить в пользовательские записи свои предпочтения при поиске для инициализации.

Чем выше уровень автоматизации, тем более эффективным становится процесс поиска, и тем менее вероятно, что он сделает ошибку. Это важно учитывать как пользователям, так и транспортировщикам. Просмотр вручную занимает много времени и часто приводит к появлению ошибок. Вероятно, можно с уверенностью сказать, что навигация вручную и серфинг по WML-страницам (или XHTML в развивающихся в настоящее время системах) требует длительных соединений. Это следует из больших затрат на время передачи в сетях с коммутацией каналов (сети 2G) и высоких издержек при передаче пакетов в сетях с коммутацией пакетов (сети 2.5G и 3G), которые нежелательны для пользователей. ^Это также занимает полосу пропускания, что нежелательно для транспортировщиков.



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

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

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

Понятия

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

Для того чтобы инициализировать приложения на своих устройствах, пользователям нужна возможность обнаружения, выбора, покупки, загрузки и установки приложений с помощью своих мобильных устройств. Поскольку мобильные устройства не всегда имеют возможность соединения с какой-либо сетью или другим устройством посредством каких-либо способов, за исключением радиоинтерфейса, поддерживаемого беспроводной сетью, транспортировщики должны поддерживать установку приложений MIDP «по воздуху» (over-the-air (OTA)). Во время написания данной книги инициализация ОТА являлась краеугольным камнем инициализации приложений для мобильных устройств.

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

Беспроводные транспортировщики и другие поставщики услуг, поддерживающие инициализацию приложений для своих пользователей, предоставляют системы инициализации, с .которыми их пользователи могут взаимодействовать.
Эти системы инициализации поддерживают инициализацию ОТА для М9бильных устройств, связанную с беспроводной сетью транспортировщика и шлюзом беспроводного Интернета (wireless Internet gateway (WIG)). На рисунке 10.1 показана одна из возможных схематичных логических диаграмм, которая отражает роль системы инициализации в сетевой инфраструктуре транспортировщика.

Инициализация ОТА требует установления «телефонного звонка», или соединения для передачи данных в сетях передачи данных, таких, как 2.5G или 3G - для соединения мобильного устройства, которое является клиентом, с инициализирующим сервером. Со стороны сервера диспетчер инициализации теоретически представляет основной компонент системы инициализации, который управляет различными стадиями процесса инициализации. Эти стадии включают динамическое обнаружение, представление описаний содержимого, поставку, фиксацию транзакции и создание счета.

На устройстве программное обеспечение агента пользователя взаимодействует с диспетчером инициализации. Программное обеспечение агента пользователя должно быть совместимо с механизмом взаимодействия, определяемым диспетчером инициализации. Возможны две схемы: обнаружение протокола Wireless Application Protocol (WAP) с HTTP-пересылкой и обнаружение WAP с сегментацией и повторным ассемблированием (SAR) WAP. Беспроводные транспортировщики на определенных рынках, особенно в Японии, создают инфраструктуры, которые поддерживают TCP/IP к телефонной трубке. Эти инфраструктуры способны поддерживать передачу HTML (XHTML) телефонной трубке посредством HTTP-транспортировки, перемещая WAP. Когда эта модель станет более распространенной в реализациях сетей 2.5G и 3G, интерфейсы диспетчера инициализации изменятся соответственно.

Процесс инициализации

На практике процесс инициализации включает две основных фазы:

регистрация приложений;

инициализация зарегистрированных приложений на устройствах.

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

обнаружение - поиск приложения;

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

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

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

Регистрация приложений

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

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

Обычно системы инициализации поддерживают два основных механизма управления зарегистрированными приложениями. С помощью первого подхода разработчик загружает файлы JAR, JAD и манифеста приложения, как указано системой инициализации. Система инициализации физически содержит эти элементы в своем хранилище. С помощью второго подхода разработчик просто регистрирует URL и файл JAD (или метаданные, необходимые для создания файла JAD), которые показывают местонахождение, из которого диспетчер инициализации может извлекать приложение, необходимое во время инициализации. Разработчик или даже другой поставщик может фактически хранить файл JAR приложения.

Не все системы инициализации могут поддерживать как возможность внутреннего постоянного хранения файлов JAR, так и возможность ссылки на внешние файлы JAR. Как разработчик, вы должны предусмотреть, какие схемы приемлемы и какие, по вашему мнению, соответствуют сценариям использования ваших приложений. Возникают вопросы нетехнического плана - такие, как правовые вопросы обеспечения защиты от несанкционированного доступа к вашему приложению, которое может содержать ценную интеллектуальную собственность, или соглашения служебного уровня (service-level agreement (SLA)) с покупателем или транспортировщиком.

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

Согласование лицензии на программное обеспечение

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

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

Удаление приложения

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

Разработчикам не нужно предусматривать уведомление сервера об удалении приложения. В этот процесс вовлечены только агент пользователя и сервер. Разработчики ' должны, однако, предусмотреть вероятность необходимого удаления приложения на клиенте при подготовке файла JAD приложения. Атрибут MIDlet-Delete-Conf irm является необязательным атрибутом файла JAD. Цель - предоставить AMS текстовое сообщение, предоставляемое пользователю для подтверждения удаления связанного набора MID-летов.

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

Установка приложения и подтверждение установки

Установка приложения - это процесс установки программного обеспечения, которое уже находится на устройстве. После загрузки приложения браузер должен начать взаимодействие с AMS устройства, которая является компонентом, сохраняющим приложение на устройстве. AMS отвечает за установку программного обеспечения. Пользователь, однако, инициирует установку программного обеспечения посредством взаимодействия с AMS. AMS хранит приложения в определяемом устройством месте, но не в RMS MIDP, о которой вы узнали в главе 7.

Спецификация CLDC не требует того, чтобы AMS устройства хранила приложения MIDP, поскольку не все мобильные устройства поддерживают механизм постоянного хранения, такой, как файловая система. Альтернативным механизмом для AMS будет поддержка загрузки классификационных файлов с системы инициализации, необходимых для выполнения приложения. Виртуальная машина Java просто загружает классификационные файлы Java по мере их пересылки, выполняет приложение, а затем отбрасывает классификационные файлы, когда процесс установки завершен.

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

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

Подтверждение установки включает информирование диспетчера инициализации об успешной установке. Уведомление об установке важно, поскольку пользователи обычно получают счета после того, как они установили приложение.
Атрибут MIDlet-Install- Notify предоставляет способ для разработчиков приложений указывать URL, к которому должна быть послана HTTP-команда POST при успешной установке. Разработчики могут задавать значение этого атрибута. Иногда это значение будет задавать инициализирующее программное обеспечение, поскольку диспетчер инициализации лучше знает URL, который он установил для отслеживания установок.

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

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

это процесс поставки программного обеспечения

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

Загрузка приложения

Загрузка приложения - это процесс физической отправки приложения на мобильное устройство. Обычно этот процесс использует HTTP-механизм загрузки и браузер устройства для получения программного обеспечения.

Более совершенные системы будут поддерживать возможность контроля загрузки пользователем. Одним из примеров пользовательского контроля является возможность перезапуска прерванной загрузки пользователем. Прерывание загрузки может случиться, например, если вызов или данные соединения не прошли. Во время написания данной книги лучшим, на что мы могли надеяться, было то, что устройство выполняет частичные загрузки.

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

Более совершенные системы дадут пользователю возможность перезапускать загрузку из точки, на которой произошло прерывание. Это свойство предпочтительно, поскольку оно сокращает продолжительность передачи и уменьшает использование полосы пропускания. Более совершенные системы также поддерживают как небезопасную (HTTP), так и безопасную (HTTPS/SSL) загрузку приложений.

Apxитeктypa приложения

Построение архитектуры приложения - это искусство и наука. По существу, имеется много определений архитектуры приложения, каждое из них ожесточенно отстаивается своими сторонниками. Разумным определением кажется то, что предоставлено институтом разработки программного обеспечения Университета Carnegie-Mellon University (http://www.sei.cmu.edu):

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

Буч, Рамбаут и Якобсен приводят классическое определение архитектуры в своей книге «Руководство пользователя по языку моделирования UML» («UML Modeling Language User Guidz»), которое приведено ниже:

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

Архитектура создает артефакты, которые описывают систему. Важным аспектом архитектуры является то, что она включает использование процессов, которые выражаются в создании этих артефактов. Архитектурная методология (architectural methodology (AM)) - это набор действий, которые управляют использованием набора процессов. Сообщество разработчиков программного обеспечения определяет много методологий, каждая из которых отражает свою собственную философию, процессы и артефакты. Одна из таких архитектурных методологий - SunTone AM, которая была разработана в корпорации «§un Microsystems» и является дополнением к Rational Unified Process (RUP).

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

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

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

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

Архитектура - это комплексная тема и о ней написано множество отдельных книг. Цель данного раздела по архитектуре заключается лишь в знакомстве с понятием архитектуры, если вы с ним еще не знакомы.Для тех из вас, кто уже знаком с архитектурой, цель - побудить вас взглянуть на среду беспроводного Интернета с точки зрения архитектуры и мотивировать вас к размышлению об архитектурных проблемах для создания надежных коммерчески выгодных MIDP приложений для беспроводного Интернета. Я призываю вас оценить важность выполнения построения архитектуры и воспитать в себе привычку выполнять архитектурное построение в качестве первого этапа при разработке любого приложения.

Apxитeктypныe решения беспроводного Интернета

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

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

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

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

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

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

Повышение производительности может быть также достигнуто посредством использования дейтаграмм для определенных сетевых коммуникаций. Если приложения могут быть к нему приспособлены, использование UDP вместо HTTP или сокетов (то есть, даже если реализация MIDP поддерживает сокеты) может привести к резкому повышению сетевой производительности, поскольку реализации UDP не создают соединений на транспортном уровне.

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


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

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

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

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

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

Расширяемость близко связана с производительностью. Вы должны учитывать, поддерживает ли разработка, поддерживающая высокую производительность, также массовую расширяемость.


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

Поддержка определяющих местонахождение служб является другой областью, которая может повлиять на разработку приложений для телефонов. Как вы уже узнали ранее, среды беспроводного Интернета могут поддерживать один из трех типов технологий местоопределения, на основе которых строятся службы, определяющие местонахождение. Системы, базирующиеся на GPS, еще пока не очень доступны в реальных сетях. Во время написания данной книги службы, базирующиеся на сети, были превалирующими. Полуавтоматические системы GPS все еще находятся на стадии эксперимента, но подают надежды. На разработку вашего приложения влияет в большей степени доступная системная поддержка. Однако независимо от технологии вы можете выбирать альтернативные варианты разработки, повышающие производительность и расширяемость. Суть в том, что вы должны оценивать всю систему - а не только программное обеспечение, неотъемлемое от устройства - в соответствии с критериями, определяемыми системными качествами.

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

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

Это некоторые из причин, почему беспроводные сети имеют более ограниченную среду сетевой передачи данных, чем среды проводных сетевых комплексов. Разработчики MIDP должны учитывать ограничения сети при разработке приложений. С принятием IPv6 будет достаточно адресов для того, чтобы присвоить каждой телефонной трубке статический IP-адрес. Тем не менее, безопасность, производительность и расширяемость останутся важными вопросами.

Беспроводные приложения

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

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

Обмен сообщениями

Теоретически существует, грубо говоря, три типа обмена сообщениями в беспроводных средах:

мгновенный обмен сообщениями;

электронная почта;

интегрированная система обработки сообщений.

Точные определения этих типов обмена сообщениями являются чем-то неопределенным, потому что они зависят от характеристик конкретной реализации. Например, насколько «мгновенны» мгновенные сообщения? Тем не менее, существуют общепринятые трактовки этих терминов.

В беспроводных средах мгновенный обмен сообщениями обычно означает обмен SMS-сообщениями, поскольку системы каналов передачи SMS обычно используются для реализации службы IM. Адреса сообщений состоят из MSN. Каналы передачи SMS предоставляют мгновенный обмен сообщениями в пределах того, что сообщения посылаются «немедленно». Конечно, получается ли сообщение немедленно, зависит от нагрузки системы, управления потоком, ограничений полосы пропускания и так далее, что может привести к задержкам, которые будут выше, чем в технологиях мгновенной передачи сообщений проводных сетей.

Электронная почта (e-mail) - это передача сообщений произвольной длины с помощью модели с промежуточным хранением. Термин электронная почта подразумевает использование схемы адресации, сходной со схемой e-mail Интернета, пример которой показан ниже:

user@some-host.com

Конкретные возможности систем электронной почты в беспроводных сетях зависят от реализации. Например, не все реализации могут поддерживать доставку сообщений произвольной длины. Если электронная почта доставляет сообщения через стандартный канал передачи SMS, сообщения ограничиваются до 128 байтов. В Японии, например, два из основных беспроводных транспортировщиков поддерживают электронную почту на мобильных устройствах с длиной сообщений до нескольких килобайт. Эти системы используют собственную систему пересылки, полностью независимую от SMS.

Интегрированная система обработки сообщений - это понятие единого механизма, который интегрирует другие системы обработки сообщений и дает пользователям единую точку доступа ко всем службам обработки сообщений. Интегрированная система обработки сообщений может иметь пользовательский интерфейс как для Web-доступа, так и доступа с устройств с беспроводной связью. Коммерческие поставщики предлагают интегрированные системы обработки сообщений, которые обычно включают API для интерфейсов приложений. Например, приложение MIDP может взаимодействовать с системой через внешний API и представлять пользователю интегрированное отображение SMS и электронной почты. Этот сценарий работает только на телефонах, которые его поддерживают? Смысл в том, что интегрированные системы обработки сообщений извлекают подробную информацию о взаимодействии с отдельными системами обработки сообщений, такими, как серверы электронной почты или серверы SMS.

Персонализация

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

информация о предпочтениях предоставления - настройки того, как информация представляется пользователю;

информация о профиле пользователя - контактная информация пользователя, финансовая или коммерческая информация, информация о плане обслуживания, опыт пользователя;

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

Большинство систем использует механизмы персонализации сторонних разработчиков. Как и большинство предназначенного для Web программного обеспечения, большая часть служб персонализации поддерживает API HTML-через-НТТР.

Приложения личной информационной системы

Приложения личной информационной системы (Personal information management (PIM)) включают такие приложения, как календари с возможностью напоминания о событиях, адресную книгу, записную книжку и так далее. Все это - стандартные утилиты сайтов порталов Интернета. Проблема беспроводных сред заключается в поддержке : пользовательскогр интерфейса для этих приложений.

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

Протокол доступа к сообщениям в Интернете (The Internet mail application protocol (IMAP)) и почтовый протокол (post office protocol (POP)) являются двумя наиболее распространенными протоколами, поддерживаемыми почтовыми серверами. Беспроводные сети будут либо поддерживать эти протоколы на телефонах, либо реализовывать собственные.

Службы календаря обычно определяют свои собственные API и интерфейсы, которые настроены как для Web-доступа, так и для доступа приложений. Некоторые системы определяют один интерфейс HTML-через-НТТР. Клиентскому приложению календаря, которое использует сервер, на котором находится серверный компонент календаря, пришлось бы создавать запросы HTTP в соответствии с API, определенным сервером. Календарное уведомление может использовать SMS для посылки уведомлений клиентам. Приложениям MIDP, например, может понадобиться наличие некоторого способа взаимодействия с родным программным обеспечением обработки сообщений на телефоне. Во время написания данной книги спецификация MIDP не связывала интерфейсы с программным обеспечением родной системы. Ожидается, что спецификация MIDP-NG (следующее поколение) будет связывать интерфейсы родного устройства с приложениями MIDP.

Происхождение, терминология и понятия

Термины беспроводный Web и беспроводный Интернет относятся к среде, в которой беспроводные радиоустройства могут получать доступ к World Wide Web и Интернету. Эти термины являются чем-то абстрактным по той причине, что они не несут информации об архитектуре или физической природе среды. Беспроводной Интернет, как и Интернет, является сетевым комплексом, объединением сетей. Однако, в отличие от Интернета, это объединение беспроводных и проводных сетей.

Беспроводные сети связываются с проводными сетями - и с Интернетом - посредством шлюза беспроводного Интернета (wireless Internet gateway (WIG)), шлюзом, состоящим из аппаратного и программного обеспечения, который соединяет беспроводную сеть транспортировщика с его собственной проводной сетью intranet. Шлюзы беспроводного доступа в Интернет обычно состоят из принадлежащего провайдерам программного и аппаратного обеспечения, которое позволяет взаимодействовать с мобильными центрами коммутации (mobile switching center (MSC)). Вместе все эти компоненты реализуют определенные типы систем беспроводных коммуникаций. Например, многие из производителей мобильных телефонов предлагают свои собственные WIG. Они работают только с определенными системами беспроводных коммуникаций и с определенными базовыми станциями и телефонами.

На рисунке 11.1 показана схематичная логическая диаграмма, которая представляет связи между компонентами беспроводной сети, шлюзами WIG и сетями intranet транспортировщика. WIG дает беспроводной сети - и беспроводным устройствам - доступ в Интернет посредством проводной сети intranet поставщика беспроводной связи. Intranet беспроводного транспортировщика соединяется с проводными сетями или сетевыми комплексами, которые дают ему доступ к Интернету.

Системные качества

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

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

нефункциональные требования описывают системные характеристики или качества системы.

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

Одним из краеугольных камней SunTone AM, который отличает ее от других методологий, является ее сконцентрированность на системных качествах. Важным критерием при оценке отличия хорошей архитектуры от сомнительной является определение того, насколько хорошо она поддерживает системные качества, определяемые требованиями. Конечно, чтобы создать всеобъемлющую архитектуру, разработчик должен взглянуть на систему со всех ракурсов.

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

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

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

В контексте системной архитектуры системные качества включают следующие категории:

качества пользовательского уровня - практичность, доступность;

качества уровня служб - производительность, надежность, доступность;

качества стратегического уровня - расширяемость, гибкость;

качества системного уровня - безопасность, управляемость, восстанавливаемость.

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

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

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

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


Среда MIDP не предназначена для работы с доступностью для инвалидов, как это делают среды AWT или Swing.

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

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

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

Доступность - это измерение того, возможно ли получение доступа к службе (предоставляемой приложением). Доступность связана с надежностью. Различие между надежностью и доступностью заключается в том, что надежность относится к отдельным компонентам, в то время как доступность описывает степень, в которой доступна служба. Например, один из нескольких компонентов, который предоставляет резервирование, может сломаться, хотя служба может все равно остаться доступной.

Хотя доступность не является на самом деле проблемой при разработке отдельных приложений MIDP, она влияет на распределенные приложения MIDP, которые используют серверные компоненты.


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

Качества стратегического уровня. Качества стратегического уровня включают расширяемость и гибкость. Расширяемость - это измерение степени, для которой приложение может приспосабливаться к увеличению одновременных пользователей во время поддержки одного уровня производительности. Расширяемость серверных компонентов влияет на клиентов MIDP. Разработчики приложений MIDP, которые запрашивают данные с серверных компонентов, должны рассматривать, какая модель доступа наилучшим образом смягчает негативное воздействие большого объема пользователей. Например, возможно, что клиент MIDP запросит больше данных на запрос и сделает меньше запросов. Снижение производительности может не быть очевидным при небольших объемах пользователей, но когда приложение устанавливается на больших беспроводных средах, снижение производительности может быть радикальным.

Гибкость - это измерение того, насколько легко приложение может приспособиться или объединиться с новыми или измененными службами. Например, разработчик нашего почтового клиента MIDP может захотеть предугадать необходимость соединения с обоими почтовыми серверами РОРЗ или ШАР. Это решение может подтвердить реали- } зацию образца разработки, который спрячет подробности механизма соединения от большинства приложений, делая легким добавление поддержки для новых почтовых протоколов программного уровня.

Другим примером является гибкость, с которой клиент может анализировать новые протоколы программного уровня или форматы данных; полученных из служб. Поставщики служб беспроводного Интернета могут периодически переконструировать свои службы. Гибкость вашего приложения MIDP может сохранить вам много времени и усилий, так что вы можете избежать переконструирования вашего приложения для приспособления к изменениям в сетевых службах и серверных компонентах.


Взгляд на службу беспроводного Интернета с точки зрения архитектора позволит вам предвосхитить такого рода проблемы.

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

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

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

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

Управляемость - это измерение того, насколько легко управлять системой, контролировать ее и отслеживать операционные характеристики, которые могут указывать на проблемы в системе.


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

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

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

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

Наконец, клиенты MIDP должны знать системные качества любой службы, которую они используют. Даже если атрибуты этих служб лежат за границами контроля разработчика MIDP, важно понимать их ограничения и то, как они влияют на функциональные и системные качества приложения MID.P.

Службы местоопределения

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

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

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

В настоящее время существует несколько различных подходов, разработанных для предоставления информации о месте нахождения службам местоопределения:

Глобальная система местоопределения (Global positioning system (GPS)) - мобильные устройства содержат полностью основанные на технологии GPS приемные устройства.

Сетевое местоопределение - технология и обработка местоопределения расположены отдельно в беспроводной сети.

Полуавтоматическая GPS - телефон и сеть работают совместно для предоставления полной информации о местоположении.

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

Локальная информация, создаваемая сетевыми системами, менее точна, чем информация, создаваемая системами GPS. В основанных на сети системах беспроводная сеть сама определяет положение мобильного устройства. Мобильный центр коммутации (mobile switching center (MSC)) должен содержать программное обеспечение, которое может пересылать эту информацию службам приложения. Поскольку MSC обычно прозрачен для приложений, транспортировщик должен создавать объединение между MSC и службами приложения. То есть эти системы должны быть приспособлены друг к другу.

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

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

Среда беспроводного приложения

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

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

На рисунке 11.2 представлена схематичная логическая диаграмма, на которой показаны типичные компоненты системного уровня, находящиеся в системах беспроводного Интернета. На диаграмме представлены некоторые из наиболее часто используемых механизмов транспортировки, которые соединяют компоненты между собой. Цель данной диаграммы - дать разработчикам некоторый ракурс рассмотрения типов сред, которые поддерживают беспроводные приложения.

Среда, показанная на рисунке 11.2, является той, в которой беспроводные приложения устанавливаются и запускаются. Эти приложения включают не только приложения телефонов - такие, как приложения МID, - но также серверные компоненты, которые поддерживают службы, используемые приложениями на телефоне.

Серверные беспроводные приложения будут находиться внутри сети intranet транспортировщика. Они обычно состоят из нескольких систем аппаратных и программных компонентов, каждая из которых предоставляет собой одну или несколько служб приложений. Некоторые из этих служб приложений будут вести себя как стандартные основанные на Web приложения и предоставлять HTML-интерфейс, который требует браузера с клиентской стороны.

Платформа J2ME, и MIDP в частности, создают платформу, которая поддерживает так называемых интеллектуальных клиентов. Они могут быть приблизительно определены как приложения, которые выполняют значительно больший объем обработки на клиенте, чем Web-приложения.
Огромное количество приложений MIDP будет приложениями клиент-сервер или распределенными приложениями, взаимодействующими с компонентами клиент-сервер. Эти приложения M1DP будут взаимодействовать с системами, которые находятся в сети intranet беспроводного транспортировщика.

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

Большая часть Интернета стандартизирована на HTTP как на основном транспортном механизме сеансового уровня. Протоколы уровня приложений туннелируются при помощи HTTP, что связано с вопросами безопасности. Рисунок 11.2 отражает эту архитектуру между intranet, Интернет и пользовательскими объектами.

Беспроводная сеть, однако, ставит некоторые уникальные проблемы. Беспроводные сети используют сложные наборы собственных протоколов, которые представляют собой решения практических проблем реализации организации межсетевого обмена между беспроводными интерфейсами. Эти собственные наборы развиваются параллельно совершенствованию беспроводных систем и их продвижению к поддержке TCP/IP на телефонных трубках в системах третьего поколения (3G). Тем не менее, уровни, лежащие под сетевым уровнем, все еще очень отличаются от уровней, расположенных в проводных сетевых комплексах.

Структуры архитектуры

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

SunTone AM предлагает структуру, чьи основные характеристики включают:

сконцентрированная на случаях использования - подчеркивает, что начинать надо со сбора требований;

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

управляемая системными качествами - обращение к системным качествам на всех этапах разработки;

архитектурно-ориентированная - твердая приверженность архитектурным принципам;

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

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

Полное описание или объяснение даже одного из этих принципов лежит за пределами возможностей данной книги. Краткое описание, предоставляемое здесь, тем не менее, предназначено для ознакомления вас с понятиями, связанными с этими архитектурными принципами, и дает вам, разработчику приложений J2ME, понятие о том, как получить преимущества от искусства и науки построения архитектуры. Для более тесного знакомства с архитектурой и архитектурной методологией SunTone AM смотрите книгу "Dot-Corn & Beyond".

Первый элемент структуры SunTone AM, случай использования, - это описание системного требования. Случаи использования собирают и документируют системные требования в читабельной для человека форме. Невозможно преувеличить значение того, что разработка будет отвечать требованиям системы. Процесс сбора требований является деятельностью, дополняющей построение архитектуры. Существует несколько хороших книг, которые объясняют случаи использования в полном объеме, такие, как книга Элистера Кокбарна (Alistair Cockburn) «Writing Effective Use Cases», которая указана в разделе «Справочная литература» в конце данной книги.

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

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

Сбор требований - указание новых требований и детализирование существующих требований.

Построение архитектуры - описание разработки системы.

Разработка - например, объектно-ориентированный анализ и проектирование.

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

Тестирование - тестирование функциональной возможности, встроенной на данном этапе.

Отладка - выявление, локализация и исправление ошибок.

SunTone AM объединяет эти этапы в повторяемые циклы, каждый раз улучшая свою реализацию до тех пор, пока все требования не будут соблюдены.


Например, при разработке IMAP- почтового клиента для платформы MIDP разработчик может понять, что определенную архитектуру нелегко реализовать из-за ограничений доступных библиотек. Разработчик понимает это после прохождения через'первый цикл вышеуказанных этапов разработки. После завершения первоначального прототипа становится ясно, что некоторую часть логической схемы сложно реализовать.

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

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

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

Среда беспроводного Интернета состоит из

Среда беспроводного Интернета состоит из мобильных устройств, беспроводной се ти, шлюзов и сетевых комплексов, которые соединяют беспроводную сеть с Интерне том. Сила беспроводного Интернета заключается в том, что он позволяет мобильны\ устройствам получать доступ к Web и другим интернет-приложениям. Среда беспровод ной сети создает абстракции, которые скрывают от приложений различия между беспро водной сетью и Интернетом.
Беспроводные устройства получают доступ ко многий из тех же категорий приложе ний, что и постоянно подсоединенные устройства с проводной связью, такие, как персо нальные компьютеры. Кроме того, определенные приложения, такие, как службы дина мического местоопределения, особенно популярны в области мобильных устройств.
Основанная на Java технология платформы J2ME значительно увеличивает способ ность мобильных устройств использовать преимущества интернет-приложений. Он помогает скрывать от приложений различия в технологии и службах беспроводной CCTI и Интернета.
Однако в реальном мире ограничения и сдерживающие факторы технологической плана требуют, чтобы предназначенное для Интернета основанное на Web программно! обеспечение специально приспосабливалось к беспроводному Интернету, то есть обра щалось к технологиям, используемым для доступа радиоустройств. Но с развитием тех нологии беспроводной Интернет начнет поддерживать абстракции, которые устраня' необходимость наличия специального, основанного на Web программного обеспечения которое поддерживает мобильные устройства отлично от постоянно подсоединенны: устройств, таких, как персональные компьютеры.
Архитектура - это набор понятий и действий, которые поддерживают проектирова ние и описание системы. Методология построения архитектуры - это порядок примене ния архитектурных понятий и действий. Методология построения архитектуры SunTom - это дополнение к процессу Rational Unified Process.
Методологию построения архитектуры дополняет сбор требований. Разработчи! должен согласовать архитектуру с объявленными требованиями системы. Методологи: построения архитектуры SunTone подчеркивает важность определения нефункциональ ных или системных качеств системы и использования их для установления соответстви: системы объявленным требованиям.
Разработчик J2ME должен рассматривать выполнение архитектурного анализа в ка честве первого этапа при проектировании и разработке приложения. Построение архи тектуры может помочь разработчику описать программное обеспечение, которое он соз дает, а также выяснить, каким образом лучше взаимодействовать со службами беспро водного Интернета, если он понимает принципы построения архитектуры систеи беспроводного Интернета.

---

---