Desenvolvendo em BREW - Parte 3 – Etapa 01
Persistência de informações
Antonio Luiz Cavalcanti
Nivia Cruz Quental
Durante o levantamento dos requisitos de uma aplicação é possível constatar a necessidade do armazenamento de informações necessárias para o seu funcionamento. Para tal, soluções que envolvem mecanismos de persistência em arquivos ou bancos de dados são utilizadas em um contexto de aplicações voltadas para desktop.
Essa mesma necessidade se faz presente em aplicações para dispositivos móveis. Contudo, são conhecidas as limitações impostas aos dispositivos móveis, devido às suas dimensões reduzidas, quantidade de memória limitada e seu sistema de arquivos diferenciado. Para contornar este problema, a plataforma BREW fornece interfaces e APIs que possibilitam o gerenciamento da persistência de informações para aplicativos móveis, reduzindo assim a complexidade que encontraríamos se optássemos por implementar essa solução através dos recursos de baixo nível.
Neste artigo apresentaremos as APIs de gerenciamento de arquivos e registros, e exploraremos o seu uso dando continuidade ao desenvolvimento da aplicação “Fuel Manager”, introduzida nos artigos anteriores. O objetivo de seu uso é permitir que os dados referentes ao histórico de abastecimento sejam armazenados e atualizados.
Revisitando a aplicação Fuel Manager
A aplicação “Fuel Manager”, introduzida no segundo artigo dessa série (Edição 12 da WebMobile), tem como principal objetivo permitir que seu usuário faça anotações sobre abastecimentos realizados em seu automóvel com o intuito de disponibilizar ao usuário as informações necessárias para o controle de gastos e autonomia do mesmo. O fluxo da aplicação pode ser visto no diagrama navegacional descrito na Figura 1.
Os dados que a aplicação persistirá são:
· Data do abastecimento;
· Quantidade de litros de gasolina e o valor do litro da gasolina;
· Quantidade de litros de álcool e o valor do litro do álcool;
· Quilometragem total do carro e opcionalmente a quilometragem parcial do carro (quilômetros rodados desde o último abastecimento).
Figura 1. Diagrama Navegacional do Fuel Manager
Sistemas gerenciadores de dados
Hoje os SGBDs tradicionais exigem um grande poder de processamento e uso de memória. Como sabemos, esses recursos são limitados em dispositivos móveis, o que faz com que os SGBDs comuns ainda sejam inviáveis para esses dispositivos. Dessa forma, a alternativa para os sistemas móveis é voltar um pouco no tempo e utilizar conceitos usados em computadores de duas décadas atrás, com processadores de clock em torno de 66Mhz e pouco mais de 2 Mb de memória RAM, que são semelhantes à maioria dos celulares atuais.
Nesses computadores, era utilizado o que chamamos de Sistemas Gerenciadores de Registros (SGRs), cujo objetivo principal é disponibilizar ao desenvolvedor uma forma de armazenar registros e recuperá-los garantindo sua integridade física e sua unicidade. Esses sistemas não se preocupam com as relações entre os registros, o que é comum em SGBDs (ler Nota 1). Normalmente os SGRs são baseados em APIs dependentes da linguagem de programação utilizada e toda integridade lógica e relacional desses registros ficam a cargo do desenvolvedor da aplicação.
Nota 1. SGBDRs em dispositivos móveis
Existem algumas soluções SGBDRs para dispositivos móveis de grandes fabricantes de bancos como Oracle, Microsoft, Intersystems e outras de fabricantes não tão grandes, como a Hyper Sonic. Porém, ainda são muito custosos em termos de desempenho para a maioria dos celulares atuais. Seu foco são PDAs, que hoje estão com processadores em torno de 400Mhz e 256 Mb de RAM.
As APIs que iremos discutir são disponibilizadas pela plataforma BREW desde sua primeira versão e por isso podem ser consideradas maduras e bem fundamentadas. Existem duas formas básicas de persistência de dados em BREW: a manipulação direta de arquivos, que dá ao desenvolvedor a possibilidade de trabalho com suas bases em baixo nível; e a API de gerenciamento de registros que poupa tempo e trabalho do desenvolvedor. Ambas serão abordadas nas seções seguintes deste artigo.
A API para gerenciamento de registros em BREW possui dois conceitos básicos de banco de dados:
· O de registro, identificado por um Id único e composto por um ou mais campos cujos tipos de dados também são únicos;
· O de tabela, um conjunto de registros. BREW não provê suporte a relacionamentos entre tabelas nem agrupamento de tabelas formando um banco de dados. Para a aplicação, cada tabela é um banco de dados independente, ficando a cargo do desenvolvedor a escrita do código que controla a integridade referencial entre os registros, com o auxílio das interfaces IDBMgr, IDatabase e IDBRecord.
Para os desenvolvedores Java ME, a solução BREW é semelhante à solução padrão do MIDP chamada RMS (Record Management System) tanto em relação a funcionalidades quanto em relação à utilização da API.
