Автор неизвестен - Платформа J2Me
Листинг 7.4. Этот компаратор записей определяет семантику упорядочивания записей, базируясь на лексикографической сортировке значений их полей имени
/* *
Этот внутренний класс реализует RecordComparator, чья политика заключается в выполнении сортировки по алфавиту.
*/
class AlphabeticalOrdering implements RecordComparator
/**
Конструктор No-arg.
*/
public AlphabeticalOrdering()
}
super();)
public int comparelbyte [] reel, byte [] rec2)
ByteArraylnputStream baisl =
new ByteArraylnputStream(reel);
DatalnputStream disl = new DatalnputStream (baisl);
ByteArraylnputStream bais2 —
new ByteArraylnputStream(rec2);
DatalnputStream dis2 = new DatalnputStream(bais2);
String namel = null;
String name2 = null; try
(
namel = disl.readUTF ();
name2 = dis2.readUTF ();
catch (lOExceotion ioe)
ioe.pnntStackTrace ();
}
if (namel == null I | name2 == null) return 0;
int result = namel.compareTo(narae2);
if (result < 0)
return RecordComparater.PRECEDES;
else if (result == 0)
return RecordComparator.EQUIVALENT;
else
return RecordComparator.FOLLOWS;
}
}
Ваша адресная книга может использовать этот новый компаратор для лексикографической сортировки списка имен, извлеченных из хранилища записей. Например, чтобы отсортировать имена, выведенные поиском, вы просто создаете экземпляр вашего нового компаратора и пересылаете его как второй аргумент в вызов enumerateRecords (). Следующий фрагмент кода, показанный в листинге 7.5, является новой версией вызова метода getMatchesByName(String matchKey) в классе AddressBook.
Листинг 7.5. Чтобы осуществить сортировку, просто перешлите экземпляр компаратора в вызов списка записей из хранилища записей. Различные списки могут определять различную политику сортировки
RecordEnumeration getMatchesByName(String matchKey)
throws RecordStoreNotOpenException
{
MatchAllNaraesFilter filter =
new MatchAHNamesFilter (matchKey);
AlphabeticalOrdering comparator =
new AlphabeticalOrdering();
return recordStore.enumerateRecords(filter,
comparator, false);
}
Вы можете запустить это приложение и определить для себя, какие из записей, выведенных в результате поиска, теперь будут отсортированы лексикографически. Вы также можете использовать этот компаратор для сортировки имен, выводимых в List функцией ввода адресной книги. Вместо пересылки null как для фильтра, так и для компаратора перешлите экземпляр компаратора AlphabeticalOrdering при извлечении списка всех записей.
Блоки прослушивания записей
Приложения имеют способность получать уведомления при добавлении записи, ее удалении или изменении в хранилище записей. Класс RecordStore позволяет вам добавлять и удалять блоки прослушивания записей из определенного хранилища данных с помощью методов, перечисленных в таблице 7.2. Блок прослушивания записей является любым классом, реализующим интерфейс RecordListener, определенный в пакете javax.microedition.rms. Он объявляет три метода, показанных в таблице 7.3.
Таблица 7.2. Методы поддержки блока прослушивания событий RecordStore
Название метода RecordStore — Описание
Void addRecordListener (RecordListener listener) — Делает указанный объект блоком прослушивания для данного хранилища записей
Void removeRecordListener (RecordListener listener) — Удаляет указанный блок прослушивания как блок прослушивания данного хранилища записей
Таблица 7.3. Методы интерфейса RecordListener
Название метода RecordListener — Описание
void recordAdded (RecordStore recordStore, int recordld) — Уведомляет блок прослушивания записей о том, что запись была добавлена в указанное хранилище записей с указанным ID
void recordChanged (RecordStore recordStore, int recordld) — Уведомляет блок прослушивания записей о том, что запись с указанным ID была изменена в хранилище записей
void recordDeleted (RecordStore recordStore, int recordld) — Уведомляет блок прослушивания записей о том, что запись с указанным ID была удалена из хранилища записей
Возможность связывать блоки прослушивания с хранилищами записей означает, что ваши блоки прослушивания могут быть уведомлены об изменении любой записи в хранилище записей, к которому данные блоки прослушивания относятся. Необходимо переслать обратно информацию о задействованном хранилище записей, потому что ваш блок прослушивания может без труда регистрироваться более чем с одним хранилищем записей. Идея регистрации блока прослушивания записей сходна с идиомой, используемой любым другим блоком прослушивания событий, так что я не буду описывать здесь примеры кодов.
Различные свойства хранилищ записей
Класс RecordStore определяет несколько других свойств, которые полезны для приложений. В таблице 7.4 перечислены некоторые из других методов класса RecordStore и кратко описано их использование.
Таблица 7.4. Методы класса RecordStore
Название метода — Описание
void closeRecordStore () — Закрывает хранилище записей
static void deleteRecordStore () — Удаляет хранилище записей
long getLastModified () — Выдает время последней модификации
String getName () — Выдает название хранилища записей
int getNumRecords () — Выдает число записей в хранилище
byte [] getRecordfint recordl () — Извлекает запись по Ю
byte [] getRecord(int recordld, byte [] buffer, int offset) — Получает запись и помещает ее в предоставленный буфер
byte [] getRecordSize (int recordld) — Получает размер указанной записи
int getSize () — Выдает размер места (в байтах), которое занимает хранилище записей
int getSizeAvailable () — Выдает число оставшихся байтов, на которое хранилище записей может вырасти
int getVersion() — Выдает номер версии хранилища записей
static String [] listRecordStores () — Выдает список всех хранилищ записей, доступных набору MID-летов
static RecordStore openRecordStore (String name, boolean createlfNecessary) — Открывает указанное хранилище записей, создавая его, если оно не существует
Выводы по главе
Система управления записями (RMS) MIDP поддерживает постоянное хранение записей данных в зависимости от устройства. Класс RecordStore предоставляет API для постоянного хранения данных и извлекает подробную информацию о доступе к определяемым устройством областям хранения.
Хранилища записей определяются по именам, которые состоят максимум из 32 знаков уникода. Хранилища записей могут совместно использоваться MID-летами, находящимися в одном наборе MID-летов.
RMS определяет простую абстракцию базы данных, связанную с записями. Записи хранятся как массив байтов. Хранилище записей не имеет понятий встроенных типов Java.
Вы можете извлекать записи, предоставляя уникальный ID записи. Либо вы можете извлекать записи, получая список записей из RecordStore.
Списки необходимы для поиска записей в хранилище записей. Теоретически фильтры записей предоставляют своего рода механизм запросов. В связи с возможностью составления списков в RecordStore, фильтры записей поддерживают поиск только тех записей, которые соответствуют одному или нескольким критериям. Фильтр записей, класс, который реализует интерфейс RecordFilter, определяет критерии поиска.
Компараторы записей предоставляют возможность сортировки записей, извлекаемых из списка. Компараторы определяют политику сортировки и используются с механизмом составления списка. Реализация RecordComparator определяет семантику сортировки.
Блоки прослушивания записей являются блоками прослушивания, регистрирующимися с определенным хранилищем записей. Они дают возможность уведомления вашей программы об изменениях, вносимых в любую запись, находящуюся в хранилище записей.
Производительность является важной проблемой при доступе к хранилищу записей. Производительность современных реализаций RMS довольно низка. Разработчики приложений должны с осторожностью подходить к использованию RMS, применяя ее только тогда, когда это необходимо. Они должны рассматривать другие альтернативы постоянного хранения данных и сравнивать различные варианты.
Разработчики должны также измерять производительность их реализации RMS при запуске приложений, чтобы убедиться, что производительность приемлема для конечных пользователей. Бывало, что действующие приложения начинали работать слишком медленно из-за использования обновлений хранилища записей. Подтверждено, что перезапись приложений таким образом, чтобы все содержимое хранилища записей было загружено и перемещено, быстрее, чем выполнение обновлений в измененных элементах!
Глава 8. Организация сетей и коммуникации в MIDP
На данный момент вы знаете, как писать автономные приложения MIDP, которые могут, среди всего прочего, взаимодействовать с пользователем и хранить данные. Следующим шагом будет изучение того, как писать сетевые приложения. Как-никак, платформа J2ME поддерживает компьютерные технологии для портативных устройств, a CLDC/MIDP, в частности, поддерживает персональные мобильные устройства связи. Возможность связи очень важна для мобильных устройств с MIDP и является темой обсуждения в этой главе.
