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

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

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

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

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

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

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

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

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

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

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

— работа с сообщениями;

— задание формата даты, времени, числовых и денежных значений;

— поддержка календаря;

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

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

— определяемые пользователем атрибуты набора MID-летов:

— файл дескриптора приложения; поддержка извлечения ресурсов (файлов) из файла JAR набора MID-летов: Class. getResourceAsStream(StringresourceName);

— преобразование символьных кодировок: пакет java.io.

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

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

В контексте данной главы или книги термин инициализация относится к поставке программных приложений на мобильные устройства. Для беспроводных транспортировщиков и фирм-производителей (называемых OpCos), инициализация имеет совершенно другое значение, а именно, настройка атрибутов устройства и модуля идентификации станции (station identification module (SIM)) для голоса, данных и других традиционных служб.

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

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