Práctica recomendada para almacenar grandes cantidades de datos con J2ME

Question

Estoy desarrollando una aplicación J2ME que tiene una gran cantidad de datos para almacenar en el dispositivo (en la región de 1MB pero variable). No puedo confiar en el sistema de archivos, así que me quedo atascado en el Sistema de administración de registros (RMS), que permite múltiples tiendas de discos, pero cada una tiene un tamaño limitado. Mi plataforma de destino inicial, Blackberry, limita cada uno a 64 KB.

Me pregunto si alguien más ha tenido que abordar el problema de almacenar una gran cantidad de datos en el RMS y cómo lo lograron. Estoy pensando en tener que calcular los tamaños de discos y dividir un conjunto de datos al otro lado de varias tiendas si es demasiado grande, pero que añade mucha complejidad para mantenerlo intacto.

Hay muchos tipos diferentes de datos que se almacenan pero solo un conjunto en particular excederá el límite de 64 KB.

Answer 1

Para cualquier cosa que supere algunos kilobytes, necesita utilizar JSR 75 o un servidor remoto. Los registros RMS son extremadamente limitados en tamaño y velocidad, incluso en algunos terminales de gama más alta. Si necesita manipular 1MB de datos en J2ME, la única manera confiable y portátil es almacenarlo en la red. La clase HttpConnection y los métodos GET y POST siempre son compatibles.

En los teléfonos compatibles con JSR 75 FileConnection puede ser una alternativa válida, pero sin la firma de código es una experiencia de pesadilla para el usuario. Casi todas las llamadas a API invocarán un mensaje de seguridad sin opción de permiso general. Las empresas que implementan aplicaciones con JSR 75 generalmente necesitan media docena de binarios para cada puerto solo para cubrir una pequeña parte de los posibles certificados. Y esto es solo para los certificados del fabricante; algunos teléfonos solo tienen certificados de operador bloqueado.

Answer 2

Creo que el enfoque más flexible sería implementar su propio sistema de archivos sobre el RMS. Puede manejar los registros RMS de una manera similar como bloques en un disco duro y utilizar un inode structure o similar a difundir archivos lógicos largo de varias secuencias. Yo recomendaría la aplicación de un byte o una interfaz orientada a flujo en la parte superior de los bloques y, a continuación, posiblemente haciendo otra capa API por encima de eso para escribir estructuras de datos especiales (o simplemente hacer sus objetos serializable al flujo de datos).

Tanenbaum's classical book on operating systems explica cómo implementar un sistema de archivos simple, pero estoy seguro de que puede encontrar otros recursos en línea si no le gusta el papel.

Answer 3

El rendimiento y la implementación de RMS varían enormemente entre dispositivos, por lo que si la portabilidad de la plataforma es un problema, es posible que su código funcione bien en algunos dispositivos y no en otros. RMS está diseñado para almacenar pequeñas cantidades de datos (tablas de puntaje alto, o lo que sea) cantidades no grandes.

Es posible que algunas plataformas sean más rápidas con archivos almacenados en varias tiendas de discos. Algunos son más rápidos con múltiples registros dentro de una tienda. Muchos están bien para el almacenamiento, pero se vuelven inusualmente lentos al eliminar grandes cantidades de datos de la tienda.

Su mejor opción es utilizar JSR-75 en su lugar, cuando esté disponible, y cree su propia interfaz de la tienda de archivos que vuelva a RMS si no se admite nada mejor.

Desafortunadamente, cuando se trata de JavaME, a menudo se ve obligado a escribir variantes de su código específicas de un dispositivo.

Answer 4

Estoy empezando a codificar JavaME, pero tengo experiencia con las versiones anteriores de PalmOS, donde todos los fragmentos de datos tienen un tamaño limitado, lo que requiere el diseño de estructuras de datos mediante el uso de índices y compensaciones de registros.

Answer 5

En Blackberry OS 4.6, el límite de tamaño de la tienda RMS se ha aumentado a 512 Kb, pero esto no es de mucha ayuda ya que es probable que muchos dispositivos no sean compatibles con 4.6.La otra opción en Blackberry es la tienda persistente que tiene un límite de tamaño de registro de 64 kb pero no tiene límite en el tamaño de la tienda (aparte de los límites físicos del dispositivo).

Creo que Carlos y izb tienen razón.

Answer 6

Es bastante simple, use JSR75 (FileConnection) y recuerde firmar su midlet con un certificado válido (de confianza).

Answer 7

Gracias a todos por sus útiles comentarios. Al final, la solución más simple fue limitar la cantidad de datos almacenados, implementar código que ajusta los datos de acuerdo con el tamaño de la tienda y obtener datos del servidor a pedido si no se almacena localmente. Es interesante que el límite aumenta en OS 4.6, con algo de suerte mi código simplemente se ajustará solo y almacenará más datos :)

Desarrollar una aplicación J2ME para Blackberry sin utilizar el compilador .cod limita el uso de JSR 75 algo que ya que no podemos firmar el archivo. Como señaló Carlos, este es un problema en cualquier plataforma y he tenido problemas similares con la parte de PIM. El RMS parece ser increíblemente lento en la plataforma Blackberry, así que no estoy seguro de cuán útil sería un sistema de archivos inode/b-tree en la parte superior, a menos que los datos estuvieran guardados en la memoria y escritos en RMS en una cadena de baja prioridad.

Answer 8

Solo de lectura Llego en horarios aceptables (dentro de los 10 s), indexando un archivo de recursos. Tengo dos exportaciones de lista de precios de ~ 800KB CSV. Las clases de programa y ambos archivos se comprimen en un JAR de 300 KB.

Al buscar, visualizo un List y ejecuto dos Thread s en segundo plano para llenarlo, por lo que los primeros resultados se obtienen rápidamente y se pueden ver inmediatamente. Primero implementé una búsqueda lineal simple, pero eso fue demasiado lento (~ 2min).

Luego indexé el archivo (que está ordenado alfabéticamente) para encontrar el comienzo de cada letra. Ahora antes de analizar línea por línea, primero InputStreamReader.skip() en la posición deseada, según la primera letra. Sospecho que la demora proviene principalmente de descomprimir el recurso, por lo que dividir los recursos lo aceleraría aún más. No quiero hacer eso, no perder la ventaja de una actualización fácil. CSV se exportan sin ningún preprocesamiento.