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


9

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

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

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

  0

Возможно, стоит отметить, что некоторые устройства также ограничивают количество хранилищ записей, которые вам разрешены. Это может быть всего лишь 2. 18 мар. 152015-03-18 16:29:44

9

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

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


3

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

Tanenbaum's classical book on operating systems охватывает, как реализовать простую файловую систему, но я уверен, что вы можете найти другие ресурсы в Интернете, если вам не нравится бумага.


4

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

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

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

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


1

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


2

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

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


2

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


1

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

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

  0

Если вы зарегистрировались в RIM и получили ключ подписи, вы могли бы использовать постоянный API хранилища, где хранение даже мегабайт данных работает нормально. Я думаю, что ключ подписи не стоит многого. 29 сен. 082008-09-29 10:33:26

  0

Как я уже сказал, я использую только J2ME API. Я не могу получить доступ к API RIM, иначе у меня не было бы этой проблемы. 02 окт. 082008-10-02 22:07:45


2

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

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

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