Artigo Java Magazine 48 - Programação Java ME

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo publicado pela Java Magazine 48.

Esse artigo faz parte da revista Java Magazine edição 48. Clique aqui para ler todos os artigos desta edição

Mini-curso

Programação Java ME

Parte 5: Persistência com File Connection e RMS

Explore as API da MIDP para persistência de dados, e conheça dicas, boas práticas e soluções para problemas e limitações comuns

Na primeira parte deste mini-curso (Edição 44) analisamos a plataforma Java ME como um todo. Depois nos especializamos no perfil MIDP, que é a fatia do leão do Java ME por ser o perfil dos onipresentes aparelhos de telefonia celular. Vimos na segunda parte as ferramentas do WTK e do IDE Eclipse e na terceira, os recursos do NetBeans e as APIs do MIDP para interface de usuário (LCDUI). Na quarta parte, demos uma pausa da prática para falar de desempenho e outros aspectos de implementação.

O que ficou faltando? Bastante coisa, pois como vimos na parte inicial, o número de APIs disponíveis para Java ME é grande, muito embora o universo do Java ME seja bem mais “minimalista” que o do Java SE: temos menos APIs, sendo que cada API é menor e freqüentemente mais genérica que as suas correspondentes do Java SE.

Ainda falta investigarmos pelo menos duas áreas de funcionalidade essencial. A primeira é a persistência de dados, sem a qual nenhuma plataforma computacional seria levada a sério (até o meu primeiro micro, em 1987, tinha memória de massa – em fita cassete, mas tinha!). A segunda, também crítica numa plataforma wireless, é a comunicação.

Veremos neste artigo duas APIs do MIDP para persistência: a GCF (com ênfase na sua extensão para I/O de arquivos, a API File Connection) e a RMS. As APIs discutidas são simples em si, mas aproveitaremos para apresentar mais técnicas, boas práticas e dicas gerais de programação Java ME. Na próxima parte, encerraremos o mini-curso examinando APIs de comunicação específicas para o mundo wireless, com as APIs para SMS/MMS e Bluetooth.

Retomando o projeto

Continuaremos trabalhando com o projeto MicroMandel, um gerador de fractais desenvolvido na terceira parte desta série (Edição 46). Apresentaremos somente os trechos de código alterado, mas a compreensão deste artigo não depende dos anteriores. O projeto completo e atualizado está disponível no download deste artigo.

Para quem perdeu a terceira parte, o programa MicroMandel tem uma estrutura muito simples. Temos um formulário de dados (que também é a tela inicial da MIDlet), implementado pela classe MicroMandel. Esse formulário permite editar diversos parâmetros para o cálculo do gráfico fractal. E uma segunda classe Fractal (um Canvas) é responsável pelo cálculo e exibição deste gráfico.

Este projeto foi feito originalmente com o NetBeans Mobility Pack, e continuei utilizando o mesmo ambiente ao atualizá-lo para este artigo. Usuários do EclipseME ou MTJ (ambos apresentados na segunda parte) ou de outros IDEs e plug-ins de suporte a Java ME, poderão utilizar o mesmo código sem problemas. Só a configuração de projetos (que é simples) ficará por conta do leitor.

Ao criar o projeto no NetBeans, recomendei que todas as APIs de extensão desnecessárias fossem desativadas no projeto. Agora será necessário alterar isso. Na página de propriedades do projeto, em Platform, ative a opção File Connection and PIM Optional Packages 1.0. (O download deste artigo inclui o projeto configurado para o NetBeans com o Mobility Pack.) Em outros IDEs poderá ser necessário fazer uma configuração semelhante, para poder usar a API File Connection (JSR-75). A RMS faz parte da MIDP, portanto não exige configurações adicionais.

Persistência

Muitas aplicações Java ME precisam armazenar dados persistentes – cujo tempo de vida excede o de processos individuais. Mas a primeira versão da MIDP foi criada sem nenhuma API para trabalhar com arquivos. Isso porque os dispositivos-alvo deste perfil, historicamente, não suportavam sistemas de arquivos (filesystems). A especificação exigia algum suporte a memória de massa, mas não eram exigidos diretórios, direitos de acesso, capacidade de acesso aleatório, extensão de arquivos preexistentes (append), locks, e outras facilidades comuns até nos sistemas de arquivos mais simples usados em PCs.

Devido a estas restrições, a MIDP 1.0 introduziu a RMS, uma API de persistência simples que podia ser implementada mesmo em dispositivos com organização de memória de massa rudimentar. Por um lado a RMS habilita a portabilidade entre aparelhos, cujas APIs nativas de persistência podem ser muito diferentes. Por outro, implementa por conta própria alguns recursos que a tornam uma API bastante conveniente (para os padrões dos aparelhos mais simples).

Nos aparelhos mais recentes, no entanto, o uso de sistemas de arquivos se universalizou. Praticamente todos utilizam algum sistema de arquivos convencional, tipicamente a FAT, para organizar dados, tanto nas memórias integradas quanto em cartões de expansão. Refletindo esta evolução, a JSR-75 inclui a File Connection[1], uma API que a maioria dos dispositivos Java ME recentes já suporta e permite manipular arquivos de maneira familiar.

A File Connection é uma extensão da GCF (Generic Connection Framework), uma API fundamental de I/O disponível desde o MIDP 1.0. Sim, precisamos mais uma vez de APIs totalmente novas, porque as APIs de I/O da Java SE (java.io, java.net e java.nio) não foram projetadas para uma plataforma limitada – são muito grandes. No lugar delas, a MIDP possui a GCF, que com um tamanho mínimo, oferece uma funcionalidade de I/O surpreendente e é muito simples de usar.

A especificação “guarda-chuva” JSR-248 (MSA: Mobile Systems Architecture) inclui a JSR-75, que assim passa a ser obrigatória em todos os novos dispositivos MSA (veja a Edição 45 para mais sobre a MSA).

Dito tudo isso, por que nos preocuparmos com a RMS? Por dois motivos. O primeiro é que a RMS ainda é relevante como menor denominador comum: todos os dispositivos MIDP a suportam, inclusive os mais velhos ou de baixo custo. O segundo é que a RMS também tem as suas vantagens. Assim, exercitaremos as duas APIs neste artigo, procurando um caso de uso ideal para cada uma.

Usando a File Connection (e a GCF)

Vamos começar usando a API de persistência mais moderna, a File Connection, apenas por ser a opção mais simples e familiar. O programa de exemplo MicroMandel produz um gráfico (Figura 1) que gostaríamos de armazenar num arquivo.

 

Figura 1. Exemplo de imagem produzida pelo MicroMandel

Nota1: Dissemos “inclui” porque a mesma JSR especifica também o PIM Optional Package (javax.microedition.pim), para acesso a dados como contatos e eventos, gerenciados por aplicações de Personal Information Management, tipicamente incluídas nos dispositivos-alvo da Java ME.

A Listagem 1 mostra o código que o MicroMandel precisa para implementar esta funcionalidade. O novo método save() é invocado dentro do tratador de eventos de teclado na classe Fractal, de forma que o acionamento da tecla ‘*’ irá acionar esta operação.

 

Listagem 1. Criando e gravando uma imagem com a File Connection.

protected void keyPressed (int key) {

  ...

  switch (getGameAction(key)) {

    "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?