Miglior pratica per archiviare grandi quantità di dati con J2ME

Question

Sto sviluppando un'applicazione J2ME che dispone di una grande quantità di dati da archiviare sul dispositivo (nell'ordine di 1 MB ma variabile).Non posso fare affidamento sul file system, quindi sono bloccato sul Record Management System (RMS), che consente più archivi di dischi ma ognuno di essi ha una dimensione limitata.La mia piattaforma di destinazione iniziale, Blackberry, limita ciascuna a 64 KB.

Mi chiedo se qualcun altro ha dovuto affrontare il problema dell'archiviazione di una grande quantità di dati nell'RMS e come lo hanno gestito?Sto pensando di dover calcolare le dimensioni dei record e dividere un set di dati tra più negozi se è troppo grande, ma ciò aggiunge molta complessità per mantenerlo intatto.

Esistono molti tipi diversi di dati archiviati, ma solo un set in particolare supererà il limite di 64 KB.

Answer 1

Per qualsiasi cosa oltre pochi kilobyte è necessario utilizzare JSR 75 o un server remoto.I record RMS sono estremamente limitati in termini di dimensioni e velocità, anche in alcuni telefoni di fascia alta.Se devi destreggiarti tra 1 MB di dati in J2ME, l'unico modo affidabile e portatile è archiviarli sulla rete.La classe HttpConnection e i metodi GET e POST sono sempre supportati.

Sui telefoni che supportano JSR 75 FileConnection potrebbe essere un'alternativa valida ma senza la firma del codice è un incubo per l'esperienza dell'utente.Quasi ogni singola chiamata API richiamerà una richiesta di sicurezza senza alcuna scelta di autorizzazione generale.Le aziende che distribuiscono app con JSR 75 di solito necessitano di una mezza dozzina di binari per ogni porta solo per coprire una piccola parte dei possibili certificati.E questo solo per i certificati del produttore;alcuni telefoni dispongono solo di certificati bloccati dall'operatore.

Answer 2

Le prestazioni e l'implementazione di RMS variano notevolmente tra i dispositivi, quindi se la portabilità della piattaforma è un problema, potresti scoprire che il tuo codice funziona bene su alcuni dispositivi e non su altri.RMS è progettato per archiviare piccole quantità di dati (tabelle dei punteggi elevati o altro) e non grandi quantità.

Potresti scoprire che alcune piattaforme sono più veloci con file archiviati in più negozi di dischi.Alcuni sono più veloci con più record all'interno di un negozio.Molti vanno bene per l'archiviazione, ma diventano inutilmente lenti quando si eliminano grandi quantità di dati dallo store.

La soluzione migliore è utilizzare invece JSR-75, ove disponibile, e creare la propria interfaccia di archivio file che ricada su RMS se non è supportato nulla di meglio.

Sfortunatamente quando si tratta di JavaME, sei spesso portato a scrivere varianti del tuo codice specifiche per il dispositivo.

Answer 3

Penso che l'approccio più flessibile sarebbe implementare il proprio file system su RMS.È possibile gestire i record RMS in modo simile ai blocchi su un disco rigido e utilizzare un file struttura dell'inode o simili per distribuire file logici su più blocchi.Consiglierei di implementare un'interfaccia orientata ai byte o al flusso sopra i blocchi e quindi eventualmente creare un altro livello API sopra per scrivere strutture dati speciali (o semplicemente rendere i tuoi oggetti serializzabili nel flusso di dati).

Il classico libro di Tanenbaum sui sistemi operativi spiega come implementare un semplice file system, ma sono sicuro che puoi trovare altre risorse online se non ti piace la carta.

Answer 4

Con Blackberry OS 4.6 il limite della dimensione dell'archivio RMS è stato aumentato a 512Kb ma questo non è di grande aiuto poiché molti dispositivi probabilmente non avranno il supporto per 4.6.L'altra opzione su Blackberry è il Persistent Store che ha un limite di dimensione del record di 64kb ma nessun limite alla dimensione del negozio (a parte i limiti fisici del dispositivo).

Penso che Carlos e izb abbiano ragione.

Answer 5

È abbastanza semplice, usa JSR75 (FileConnection) e ricordati di firmare la tua midlet con un certificato valido (attendibile).

Answer 6

Per la sola lettura arrivo a tempi accettabili (entro 10 secondi), indicizzando un file di risorse.Ho due esportazioni di listini prezzi CSV da ~ 800 KB.Le classi del programma ed entrambi i file vengono compressi in un JAR da 300 KB.

Durante la ricerca visualizzo a List ed esegui un due Threadc'è in background per riempirlo, quindi i primi risultati arrivano abbastanza rapidamente e sono immediatamente visibili.Per prima cosa ho implementato una semplice ricerca lineare, ma era troppo lenta (~ 2 minuti).

Quindi ho indicizzato il file (che è in ordine alfabetico) per trovare l'inizio di ogni lettera.Ora, prima di analizzare riga per riga, per prima cosa InputStreamReader.skip() nella posizione desiderata, in base alla prima lettera.Sospetto che il ritardo derivi principalmente dalla decompressione della risorsa, quindi la suddivisione delle risorse accelererebbe ulteriormente il processo.Non voglio farlo, per non perdere il vantaggio di un facile aggiornamento.I CSV vengono esportati senza alcuna preelaborazione.

Answer 7

Sto appena iniziando a scrivere codice per JavaME, ma ho esperienza con le vecchie versioni di PalmOS, in cui tutti i blocchi di dati hanno dimensioni limitate e richiedono la progettazione di strutture dati utilizzando indici e offset dei record.

Answer 8

Grazie a tutti per gli utili commenti.Alla fine la soluzione più semplice era limitare la quantità di dati archiviati, implementando un codice che regola i dati in base alla grandezza del negozio e recuperando i dati dal server su richiesta se non sono archiviati localmente.È interessante che il limite sia aumentato nel sistema operativo 4.6, con un po' di fortuna il mio codice si adatterà semplicemente da solo e memorizzerà più dati :)

Lo sviluppo di un'applicazione J2ME per Blackberry senza utilizzare il compilatore .cod limita in qualche modo l'uso di JSR 75 poiché non possiamo firmare l'archivio.Come sottolineato da Carlos, questo è un problema su qualsiasi piattaforma e ho riscontrato problemi simili utilizzando la parte PIM.L'RMS sembra essere incredibilmente lento sulla piattaforma Blackberry, quindi non sono sicuro di quanto sarebbe utile un file system inode/b-tree in alto, a meno che i dati non fossero memorizzati nella cache in memoria e scritti su RMS in un thread in background a bassa priorità.