Платформа J2Me

Автор неизвестен

Поддержка постоянного хранения устройством

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

RMS API извлекает подробную информацию об области хранения устройства и доступе к этой информации, а также предоставляет

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

Модель хранения данных RMS

RMS поддерживает создание множества хранилищ записей, показанных на рисунке 7.1, и управление ими. Хранилище записей — это база данных, основным понятием которой является запись. Каждое хранилище записей содержит ноль или больше записей. Название хранилища записей чувствительно к регистру и может состоять максимум из 32 знаков уникода. Хранилище записей создается МШ-летом.

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

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

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

RMS определяет следующие абстрактные операции для отдельного хранилища записей:

Добавление записи. Удаление записи. Изменение записи. Просмотр (извлечение) записи. Составление списка всех записей.

Записи однозначно идентифицируются с помощью ID записи, который является единственным поддерживаемым важнейшим ключевым типом. Тип ID всех записей является встроенным типом Java int. RMS не поддерживает свойств — таких, как таблицы, строки, столбцы, типы данных и так далее, — которые присутствуют в реляционных базах данных.

Записи

Запись

является массивом байтов типа byte []. RMS не поддерживает описание или форматирование полей записи. Ваше приложение должно определять элементы данных записи и их формат.

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

Пример приложения

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

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

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

Следующие файлы включены в адресную книгу, описанную в данном примере:

— AddScreen.java;

— AddressBook.java;

— AddressBookMain.java;

— DeleteAllConfirmationScreen.java;

— PersistenceDemo.java;

— RecordList.java;

— SearchResultScreen.java;

— SearchScreen.java.

Подробные листинги этих файлов можно найти на Web-сайте «Prentice-Hall» по адресуФайл PersistenceDemo.java определяет MID-лет, который представляет меню, содержащее приложение адресной книги. Файл AddressBookMain.java определяет точку входа в приложение адресной книги.

В листинге 7.1 показан полный исходный код класса AddressBook.java. Этот класс извлекает подробную информацию о вызовах RMS API из остальной части МID-лета. При инициализации MID-лета он создает экземпляр класса AddressBook, который, в свою очередь, открывает хранилище записей с именем addressbook.

Листинг 7.1. Класс AddressBook позволяет приложению получать доступ к хранилищу записей

import javax.microedition.rms.RecordComparator;

import javax.microedition.rms.RecordEnumeration;

import javax.microedition.rms.RecordFilter;

import javax.microedition.rms.RecordStore;

import javax.microedition.rms.RecordStoreException;

import javax.microedition.rms.RecordStoreNotOpenException;

import Java.io.ByteArrayInputStream/

import java.io.ByteArrayOutputStream;

import Java.io.DatalnputStream;

import java.io.DataOutputStream;

import Java.io.lOException;

/**