Текст книги "Платформа J2Me"

Автор книги: Автор Неизвестен

сообщить о нарушении

Текущая страница: 14 (всего у книги 21 страниц)

import javax.microedition. io._StreamConnectior.;

/**

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

Он действует как «агент» от имени сервера для того, чтобы сервер был свободен для прослушивания только новых запросов соединения.

Экземпляры данного класса являются частью сервера.

*/

public class ServerAgent implements Runnable

private StreamConnection conn;

/**

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

@param с Объект соединения, который представляет

соединение с клиентом. Класс ServerSocket создает и пересылает

его в данный конструктор.

*/

public ServerAgent(StreamConnection c)

super (); conn = с;

}

/**

Выполняется агент данного сервера. Начинается диалог с клиентом. Этот метод должен быть вызван явно после того, как создан данный объект.

public void run()

}

// Взаимодействует с клиентом. Реализует поведение,

// которое определяет данную службу.

}

}

Листинг 8.8. Клиент имеет отдельно соединение с агентом сервера. Модель состояния взаимодействий, а также синтаксис и семантика взаимодействий определяются сервером, но клиенты должны им подчиняться

import javax.microedition.midlet.MI Diet;

import javax.microedition.io.StreamConnection;

import javax.microedition.io.Connector;

import Java.io.lOException;

/**

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

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

*/

public class ClientSocket implements Runnable

{

public static final String P.ROTOCOL = «socket»;

// Порт известного сокета сервера, private String serverPort;

// Имя сервера, с которым соединяемся, private String serverHostName;

// URI известного серверного сокета. private String serverURI;

// Соединение с. сервером.

private StreamConnection streamConn;

protected ClientSocket()

}

super();

}

/**

Открытый конструктор. Вы должны указать имя сервера DNS и номер порта службы. @param server – имя DNS машины, с которой вы хотите соединиться.

@param port – Номер порта сервера, с которым вы хотите соединиться.

*/

public ClientSocket(String server, String port)

throws TOException

(

this();serverHostName = server; serverPort = port;

serverURI = buildServerURI (); open ();

}

/**

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

@param uri – полностью сформированный URI службы, запрос на соединение с которой вы хотите создать.

@сбрасывает InvalidArgumentException при несформированном URI.

*/

public ClientSocket(String uri) throws lOException

{

this (); serverURI = uri;

}

Открывает соединение. После того как создан данный объект, соединение с сервером еще не открыто. Вы должны открыть его явно.

Это делает модель использования более гибкой для клиентов.

@ сбрасывает lOException, если соединение не может быть открыто по некоторым причинам.

*/

public void open() throws lOException

streamConn = (StreamConnection) Connector.open(serverURI);

/**

Закрывает соединение с сервером.

*/

public void closed try streamConn. closed; }

catch (lOException ioe)

}

ioe.printStackTraced;

{

{

/**

Выполняет клиентское взаимодействие.

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

Этот метод должен быть вызван после того, как метод opend установит соединение.

*/

public void run ()

{

// Начинаем взаимодействие с сервером.

// Посылаем запросы, читаем ответы

….

private String buildServerURI ()

}

StringBuffex uri = new StringBuffer(PROTOCOL);

uri.append ("://"); uri.append(serverHostName);

uri.append(":"); uri.append(serverPort); return uri.toString ();

}

}

Использование соединений сокета в приложениях MIDP. Естественно, тот факт, что интерфейс StreamConnectionNotif ier определен как часть пакета IOMIDP, предполагает, что он должен использоваться приложениями, запускаемыми на устройствах MIDP. Это означает, что MID-лет может поддерживать открытое соединение с известным соке-том для использования клиентами. Клиенты, однако, могут находиться в другом месте.

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

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

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

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

Независимо от того, являются ли адреса мобильного устройства статическими или динамическими, сеть транспортировщика может задействовать какую-либо схему трансляции сетевого адреса (network address translation (NAT)) для изменения или преобразования адреса мобильного устройства. Мотив использования схемы NAT может быть связан с ограничениями места или безопасности. Определенные сетевые протоколы могут не иметь достаточного адресного места для обработки всех цифр сетевых устройств. Если это так, и если транспортировщик желает узнать адреса своих устройств, ему придется предоставить какой-либо реестр для отображения динамических адресов и механизм поиска. В противном случае ваше серверное приложение не будет доступно.

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

Беспроводные сети 3G двигаются в сторону принятия IPv6 как своих протоколов сетевого уровня. В IPv6 существует множество адресов, что делает возможным назначение уникального IP-адреса каждому мобильному устройству в мире. Если каждое устройство имеет уникальный статический IP-адрес, любое приложение, которое знает адрес вашего устройства, может соединиться с известным портом вашего устройства.

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

Различия между организацией сетей В J2ME и J2SE

В предыдущих разделах данной главы описывался полный набор сетевых свойств I MIDP. Пакет java.io MIDP определяет все эти свойства. В MIDP нет пакета java.net, как в J2SE.

Вы также должны знать, что пакет java.io MIDP поддерживает подмножество при– 1 вычных байтовых и символьных классов входных и выходных потоков, представленных в J2SE. В частности, классы BufferedReader, LineNumberReader и StringReader пакета java.io J2SE отсутствуют в пакете java.io MIDP.

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

– RMI требует слишком большой мощности для поддержки в мобильных устройствах на настоящий момент;

– Jini требует RMI, поэтому не присутствует;

– JavaSpaces не существует в J2ME;

– Связующее программное обеспечение CORBA не существует в J2ME.

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

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

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

Выводы по главе

MIDP поддерживает организацию сетей через свой пакет javax.microedition.io. Он предоставляет поддержку базовых коммуникационных протоколов без установления соединения и ориентированных на соединения.

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

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

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

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

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

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

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

Глава 9. Интернационализация

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

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

Понятия

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (двадцать тысяч и сорок пять сотых)

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

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

Поддержка интернационализации в 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, такие, как сортировка, двунаправленная текстовая поддержка, аннотации, атрибуты и так далее.

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

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

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

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

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

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

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

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