Persistncia em aplicativos para dispositivos mveis com J2ME

A capacidade de persistir dados ou armazenar informaes sem dvida um dos recursos mais importantes em qualquer linguagem de programao. Armazenar dados para uma posterior recuperao uma constante na maioria dos ambientes computacionais, seja para persistncia simples de parmetros de configuraes de algum sistema ou persistncia de informaes digitadas pelo usurio para alimentar algum banco de dados. No que diz respeito persistncia em ambientes computacionais, o complicador quando esse mesmo ambiente tem recursos de armazenamento restrito e, ainda, uma arquitetura de hardware e software bem diferente da encontrada em desktops ou grandes servidores, como o caso dos dispositivos mveis. Essas diferenas podem ser observadas tanto do ponto de vista do usurio (ergonomia de hardware e software), quanto do ponto de vista do desenvolvedor (ferramentas de software, APIs e recursos). Os telefones celulares conseguiram alcanar uma popularidade quase to grande quanto a observada na utilizao de computadores pessoais a partir da dcada de 80. Mas, assim como todos os dispositivos mveis, eles tambm trazem consigo algumas dificuldades, como, problemas relacionados ergonomia do teclado, uma interface visual simples porm limitada e a dependncia de baterias que requerem recarga constante. Nesse artigo, sero apresentadas as APIs que tratam da persistncia de dados disponveis no J2ME. Inicialmente, alguns fundamentos sero abordados e a seguir o pacote javax.microedition.rms, responsvel pelo gerenciamento de registros, ser detalhado atravs de definies e do uso de exemplos. A descrio do funcionamento de uma classe, quatro interfaces e cinco excees, tudo do que trata esse artigo. Comprovando, por incrvel que parea, toda a simplicidade e eficincia do pacote RMS.

J2ME e perfil MIDP

O Java 2 Micro Edition (J2ME) foi desenvolvido para contemplar toda a diversidade computacional existente nos dispositivos mveis. A tecnologia J2ME conseguiu abstrair conceitos e tcnicas para homogeneizar o desenvolvimento em dispositivos mveis de forma completamente transparente. O perfil de informao de dispositivos mveis, conhecido como MIDP (Mobile Information Device Profile) surgiu como soluo para diferenciar alguns dispositivos que apesar de possuirem caractersticas semelhantes, ainda assim so tecnologicamente diferentes. O perfil MIDP contempla os aparelhos celulares e o responsvel pela definio das APIs necessrias para a persistncia de dados.

RMS
O conjunto de classes responsveis por armazenar e recuperar dados conhecido como Record Management System (RMS) ou sistema de gerenciamento de registros. O RMS permite manter os dados persistentes entre vrias chamadas de um MIDlet (aplicao baseada no MIDP). Segundo a especificao MIDP, deve haver, disponvel no dispositivo, pelo menos 8 kbytes de memria no-voltil (ROM) para que os aplicativos persistam dados. Exemplos de memria no-voltil seriam ROM, flash e etc. Em teoria, todo o espao livre na memria ROM, ou flash de um dispositivo mvel, estaria disponvel aos aplicativos para persistirem seus dados. A unidade bsica de dados mantida pelo RMS conhecida como RecordStore ou repositrio de registro (RR). Um RR pode ser comparado a uma tabela ou entidade no modelo relacional e identificado por um nome de at 32 caracteres. Cada

registro composto por um identificador nico e um array de bytes, onde os dados do registro sero armazenados. Um RR mantm em sua estrutura um conjunto de registros que podem ter tamanhos variveis. Um MIDlet um aplicativo executado em um dispositivo mvel. Para isso, ele precisa ser empacotado em um arquivo Java (JAR). Um MIDlet pode, ainda, ser empacotado junto com outros MIDlets em um mesmo arquivo JAR, formando um conjunto. Tanto um MIDlet quanto um conjunto de MIDlets, formam uma aplicao J2ME nica e completa. Cada conjunto de MIDlets ou um MIDlet, pode criar e manter diversos RRs, podendo, inclusive, compartilh-los entre si, com o detalhe de que os nomes atribudos aos RRs precisam ser nicos. A verso 1.0 do MIDP no permitia o compartilhamento de RRs entre MIDlets empacotados em diferentes arquivos JAR. A verso 2.0 do MIDP corrigiu essa limitao, permitindo assim o compartilhamento de um RR por todas os MIDlets instalados no dispositivo. As APIs do RMS no fornecem recurso para travamento de registros. A implementao de um RR garante que a operao de persistncia ser realizada de forma indivisvel e sncrona evitando eventuais inconsistncias no caso de acessos mltiplos. Se for necessrio que um MIDlet utilize mltiplas threads para acessar um RR, necessrio toda uma ateno para manter a consistncia dos dados. Tambm, responsabilidade da implementao no dispositivo fazer todo o possvel para garantir a integridade e a consistncia dos RRs durante operaes normais ao seu uso como reinicializao, troca de baterias e etc. Durante a desinstalao de um MIDlet do dispositivo, os armazns de dados pertencentes a ele so removidos automaticamente.

Classe RecordStore
Qualquer operao de insero, atualizao e excluso de registros em um RR provocam a atualizao automtica do seu nmero de verso e da data em que ocorreu a mudana. O nmero da verso de um RR pode servir como referencial, por exemplo, para algoritmos de replicao. uma maneira interessante de detectar quantas vezes um RR foi modificado. Esses dois valores, o nmero da verso e a data da atualizao, podem ser recuperados atravs do uso dos mtodos getVersion() e getLastModified() respectivamente. A Tabela 1 lista mais algumas funcionalidades da classe RecordStore. A Listagem 1 contm um exemplo simples que cria um RR, preenche-o com dois registros e a seguir obtm e apresenta algumas informaes sobre o RR. A Figura 1 apresenta a mesma aplicao sendo executada no emulador.
Tabela 1. Alguns mtodos da classe RecordStore.

Funcionalidade Para fechar o RR. Para excluir o RR inteiro. Para obter uma lista com todos os RRs presentes no conjunto de MIDlets. Para obter o nome do RR. Para saber a data da ltima atualizao no RR. O detalhe aqui que essa data est no formato long e pode ser convertido para o tipo Data. Para obter a verso do RR. Para obter o nmero de registros existentes no RR. Para obter o total de bytes ocupado pelo RR. Para obter o espao total ainda disponvel para o RMS.

Mtodo Correspondente rr.closeRecordStore() RecordStore.deleteRecordStore(produto) String[] Arm = RecordStore.listRecordStores() String Nome = rr.getName() long UltimaMudanca = rr.getLastModified()

int vs = rr.getVersion() int nr = rr.getNumRecords() int tb = rr.getSize() int getSizeAvailable()

Figura 1. Informaes sobre um RecordStore. 1: 2: 3: 4: 5: 6: 7: 8: 9: /* ExemploRMS.java */ import javax.microedition.rms.*; import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class ExemploRMS extends MIDlet implements CommandListener { private List lsLista; // Lista de Informaes

10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: "

private Command cmSair; private RecordStore rr = null; public ExemploRMS() { cmSair = new Command("Sair", Command.EXIT, 1); lsLista = new List("Informaes RR", List.IMPLICIT); lsLista.addCommand(cmSair); // Janela com apenas um comando...Sair lsLista.setCommandListener(this); // Registrando um receptor para o evento Sair

A exibio deste artigo foi interrompida Este post est disponvel para assinantes MVP.

Leia mais em: Artigo WebMobile 3 - Persistncia em aplicativos para dispositivos mveis com J2ME http://www.devmedia.com.br/artigowebmobile-3-persistencia-em-aplicativos-para-dispositivos-moveis-comj2me/2725#ixzz2y0y9aymg