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

голоса
9

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

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

Там находится множество различных типов данных, которые хранятся, но только один набор, в частности, будет превышать предел 64К.

Задан 20/08/2008 в 23:42
источник пользователем
На других языках...                            


8 ответов

голоса
9

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

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

Ответил 15/09/2008 в 14:25
источник пользователем

голоса
4

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

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

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

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

Ответил 25/08/2008 в 13:36
источник пользователем

голоса
3

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

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

Ответил 21/08/2008 в 10:01
источник пользователем

голоса
2

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

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

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

Ответил 02/11/2009 в 10:55
источник пользователем

голоса
2

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

Ответил 17/09/2008 в 19:48
источник пользователем

голоса
2

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

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

Ответил 17/09/2008 в 14:29
источник пользователем

голоса
1

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

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

Ответил 18/09/2008 в 21:27
источник пользователем

голоса
1

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

Ответил 17/09/2008 в 09:54
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more