Лучшая практика для хранения больших объемов данных с J2ME

Я занимаюсь разработкой приложения J2ME, которое имеет большой объем данных для хранения на устройстве (размером около 1 МБ, но с переменной). Я не могу полагаться на файловую систему, поэтому я застрял в Системе управления записями (RMS), которая позволяет хранить несколько записей, но каждый имеет ограниченный размер. Моя начальная целевая платформа, Blackberry, ограничивает каждую до 64 КБ.

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

Существует много разных типов хранимых данных, но только один конкретный набор превысит ограничение в 64 КБ.

20.08.2008 22:42:04
Стоит отметить, что некоторые устройства также ограничивают количество разрешенных хранилищ записей. Это может быть всего 2.
ban-geoengineering 18.03.2015 16:29:44
8 ОТВЕТОВ
РЕШЕНИЕ

Для всего, что превышает несколько килобайт, вам нужно использовать либо JSR 75, либо удаленный сервер. RMS-записи чрезвычайно ограничены по размеру и скорости даже в некоторых более дорогих телефонах. Если вам нужно манипулировать 1 МБ данных в J2ME, единственный надежный и портативный способ - сохранить их в сети. Класс HttpConnection и методы GET и POST поддерживаются всегда.

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

9
15.09.2008 13:25:10

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

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

3
21.08.2008 09:01:19

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

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

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

К сожалению, когда дело доходит до JavaME, вас часто тянет к написанию специфичных для устройства вариантов вашего кода.

4
25.08.2008 12:36:21

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

1
17.09.2008 08:54:34

Под Blackberry OS 4.6 ограничение размера хранилища RMS было увеличено до 512 КБ, но это не сильно помогает, так как многие устройства, скорее всего, не будут поддерживать 4.6. Другим вариантом в Blackberry является постоянное хранилище, которое имеет ограничение на размер записи 64 КБ, но без ограничения размера хранилища (кроме физических ограничений устройства).

Я думаю, что Карлос и Изб правы.

2
17.09.2008 13:29:24

Это довольно просто, используйте JSR75 (FileConnection) и не забудьте подписать свой мидлет действительным (доверенным) сертификатом.

2
17.09.2008 18:48:59

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

Разработка приложения J2ME для Blackberry без использования компилятора .cod ограничивает использование JSR 75, поскольку мы не можем подписать архив. Как отметил Карлос, это проблема на любой платформе, и у меня были похожие проблемы при использовании PIM-части. RMS кажется невероятно медленным на платформе Blackberry, поэтому я не уверен, насколько полезной будет файловая система inode / b-tree в верхней части, если только данные не были кэшированы в памяти и записаны в RMS в фоновом потоке с низким приоритетом.

1
18.09.2008 20:35:18
Если вы зарегистрировались в RIM и получили подписывающий ключ, вы можете использовать API постоянного хранилища, где отлично работает хранение даже мегабайт данных. Я думаю, что подписывающий ключ не стоит много вообще.
Alexander 29.09.2008 10:33:26
Как я уже сказал, я использую только API J2ME. Я не могу получить доступ к API RIM, иначе у меня не было бы этой проблемы.
roryf 2.10.2008 22:07:45

Только для чтения я прибываю в приемлемое время (в течение 10 секунд), индексируя файл ресурсов. У меня есть два ~ 800KB экспорта CSV прайс-листа. Классы программы и оба этих файла сжимаются до 300 КБ JAR.

При поиске я отображаю a Listи запускаю две Threads в фоновом режиме, чтобы заполнить его, поэтому первые результаты появляются довольно быстро и сразу же отображаются. Сначала я реализовал простой линейный поиск, но он был слишком медленным (~ 2 минуты).

Затем я проиндексировал файл (который отсортирован по алфавиту), чтобы найти начало каждой буквы. Теперь, прежде чем разбирать строку за строкой, я сначала InputStreamReader.skip()на нужную позицию, основываясь на первой букве. Я подозреваю, что задержка вызвана главным образом декомпрессией ресурса, поэтому разделение ресурсов ускорит его. Я не хочу этого делать, чтобы не потерять преимущество простого обновления. CSV экспортируются без предварительной обработки.

2
2.11.2009 09:55:39