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

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

Я думаю, Carlos и izb правы.

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

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

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

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

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

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

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

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

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

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

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

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

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