A melhor prática para armazenar grandes quantidades de dados com J2ME

votos
9

Estou desenvolvendo um aplicativo J2ME que tem uma grande quantidade de dados para armazenar no dispositivo (na região de 1MB, mas variável). Eu não posso contar com o sistema de arquivos, então eu estou preso a Record Management System (RMS), que permite que várias lojas de discos, mas cada um tem um tamanho limitado. Minha plataforma de destino inicial, Blackberry, limita cada a 64KB.

Eu estou querendo saber se alguém já teve que enfrentar o problema de armazenar uma grande quantidade de dados na RMS e como eles conseguiram isso? Estou pensando em ter que calcular tamanhos gravar e dividir um conjunto de dados em frente várias lojas se o seu muito grande, mas que adiciona muita complexidade para mantê-lo intacto.

Há lotes de diferentes tipos de dados que estão sendo armazenados, mas apenas um conjunto em particular irá exceder o limite de 64 KB.

Publicado 20/08/2008 em 23:42
fonte usuário
Em outras línguas...                            


8 respostas

votos
9

Para qualquer coisa passado alguns kilobytes você precisa usar JSR 75 ou um servidor remoto. registros RMS são extremamente limitados em tamanho e velocidade, mesmo em alguns aparelhos mais sofisticados. Se você precisar fazer malabarismos 1MB de dados em J2ME a única maneira confiável, portátil é armazená-lo na rede. A classe HttpConnection e os métodos GET e POST são sempre apoiou.

Nos aparelhos que suportam a JSR 75 FileConnection pode ser alternativa válida, mas sem assinatura de código é um pesadelo experiência do usuário. Quase todas as chamadas API única irá invocar um aviso de segurança com nenhuma escolha permissão cobertor. As empresas que implantam aplicativos com JSR 75 geralmente precisam de meia dúzia de binários para todas as portas apenas para cobrir uma pequena parte dos possíveis certificados. E isso é apenas para os certificados fabricante; alguns aparelhos só tem certificados locked-transportadora.

Respondeu 15/09/2008 em 14:25
fonte usuário

votos
4

RMS desempenho e implementação varia muito entre os dispositivos, por isso, se portabilidade de plataforma é um problema, você pode achar que seu código funciona bem em alguns dispositivos e outros não. RMS é projetado para armazenar pequenas quantidades de dados (tabelas de recordes, ou qualquer outro) não grandes quantidades.

Você pode achar que algumas plataformas são mais rápidos com arquivos armazenados em vários lojas de discos. Alguns são mais rápidos com vários registros dentro de uma loja. Muitos são ok para o armazenamento, mas tornam-se bastante lento ao excluir grandes quantidades de dados a partir da loja.

Sua melhor aposta é usar JSR-75 em vez quando disponíveis, e criar sua própria interface de armazenamento de arquivo que cai de volta para RMS, se nada melhor é suportado.

Infelizmente, quando se trata de JavaME, que são muitas vezes atraídos para escrever variantes do seu código específicas do dispositivo.

Respondeu 25/08/2008 em 13:36
fonte usuário

votos
3

Eu acho que a abordagem mais flexível seria a de implementar seu próprio sistema de arquivos em cima dos RMS. Você pode lidar com os registros do RMS em uma maneira similar como blocos em um disco rígido e usar uma estrutura inode ou similar para difundir arquivos lógicos ao longo de vários blocos. Eu recomendaria a implementação de um byte ou interface orientada para o fluxo em cima dos blocos e, em seguida, possivelmente fazendo uma outra camada API em cima do que para escrever estruturas de dados especiais (ou simplesmente fazer seus objetos serializado para o fluxo de dados).

Clássico livro de Tanenbaum em sistemas operacionais aborda como implementar um sistema de arquivos simples, mas eu tenho certeza que você pode encontrar outros recursos on-line se você não gosta do papel.

Respondeu 21/08/2008 em 10:01
fonte usuário

votos
2

Para ler somente eu estou chegando às vezes aceitáveis ​​(dentro de 10s), indexando um arquivo de recurso. Eu tenho dois ~ 800KB CSV lista de preços das exportações. aulas do programa e ambos esses arquivos comprimir a um JAR 300KB.

Em busca I exibir um Liste executar um dois Threads no fundo para preenchê-lo, de modo que os primeiros resultados vêm muito rapidamente e são visíveis imediatamente. I implementado pela primeira vez uma pesquisa linear simples, mas que foi muito lento (~ 2min).

Então eu indexado o arquivo (que é ordenada alfabeticamente) para encontrar o início de cada letra. Agora, antes de analisar linha por linha, I primeiro InputStreamReader.skip()para a posição desejada, com base na primeira carta. Eu suspeito que o atraso vem principalmente de descomprimir o recurso, para que os recursos de divisão iria acelerá-lo ainda mais. Eu não quero fazer isso, para não perder a vantagem de fácil atualização. CSV são exportados sem qualquer pré-processamento.

Respondeu 02/11/2009 em 10:55
fonte usuário

votos
2

É muito simples, use JSR75 (FileConnection) e lembre-se de assinar o seu midlet com um certificado válido (confiável).

Respondeu 17/09/2008 em 19:48
fonte usuário

votos
2

Sob Blackberry OS 4.6 o limite de tamanho de loja RMS foi aumentado para 512Kb, mas isso não ajuda muito como muitos dispositivos provavelmente não terá suporte para 4.6. A outra opção no Blackberry é o Persistent Store, que tem um limite de tamanho de registro de 64kb, mas há limite para o tamanho da loja (que não sejam os limites físicos do dispositivo).

Eu acho que Carlos e izb está certo.

Respondeu 17/09/2008 em 14:29
fonte usuário

votos
1

Obrigado a todos por commments úteis. No final, a solução mais simples era para limitar a quantidade de dados armazenados, a implementação de código que ajusta os dados de acordo com o tamanho da loja é, e buscar dados do servidor sob demanda se não for armazenado localmente. Isso é interessante que o limite é aumentado em OS 4.6, com alguma sorte meu código vai simplesmente ajustar por conta própria e armazenar mais dados :)

Desenvolver um aplicativo J2ME para Blackberry sem usar o compilador .cod limita o uso de JSR 75 alguns que já que não podemos assinar o arquivo. Como apontado por Carlos este é um problema em qualquer plataforma e eu tive problemas semelhantes usando a parte PIM dele. O RMS parece ser incrivelmente lento na plataforma Blackberry, então eu não tenho certeza o quão útil um sistema de arquivos inode / b-tree no topo seria, a menos que os dados foram armazenados na memória e gravados RMS em um baixo discussão de fundo prioridade.

Respondeu 18/09/2008 em 21:27
fonte usuário

votos
1

Eu estou apenas começando a codificar para JavaME, mas tem experiência com versões antigas do PalmOS, onde todos os blocos de dados são limitados em tamanho, que exigem o desenho de estruturas de dados usando índices recordes e deslocamentos.

Respondeu 17/09/2008 em 09:54
fonte usuário

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