Avaliando a Persistência em Dispositivos Móveis

Neste artigo identifica-se algumas vantagens propiciadas pela persistência local temporária em aplicações desenvolvidas para dispositivos móveis e que acessam dados externos a estes dispositivos.

 

 

Esse artigo faz parte da revista WebMobile edição 25. Clique aqui para ler todos os artigos desta edição

 

 

Java Mobile

Avaliando a Persistência em Dispositivos Móveis

 

 

De que se trata o artigo:

Neste artigo identifica-se algumas vantagens propiciadas pela persistência local temporária em aplicações desenvolvidas para dispositivos móveis e que acessam dados externos a estes dispositivos. Para isso, desenvolveu-se uma aplicação moldada sob os princípios da arquitetura cliente-servidor, sendo uma única versão para a aplicação servidora e duas versões para a aplicação cliente. Diante disso, realizou-se um comparativo quanto ao desempenho das duas versões cliente, uma com persistência local temporária e outra sem esta característica.

 

Para que serve:

A persistência local temporária junto às aplicações clientes instaladas em dispositivos móveis oferece maior agilidade e flexibilidade. Isto porque os modelos em que as aplicações clientes acessam diretamente uma aplicação servidora resultam em um maior número de acessos e necessitam do estabelecimento de conexões permanentes. Já com a persistência local temporária se evita o estabelecimento deste tipo de conexões quando os dados já estão armazenados no dispositivo.

 

Em que situação o tema útil:

Além do contexto apresentado neste artigo, abordagens que utilizam persistência local em dispositivos móveis são úteis em quaisquer situações em que os usuários precisem de agilidade e flexibilidade. Além disso, deve-se considerar também a economia de recursos (tempo e dinheiro, por exemplo) propiciada, pois não haverá gastos com tráfego de dados ou, pelo menos, estes gastos serão reduzidos.

 

 

Os dispositivos móveis são cada vez mais utilizados, tanto por pessoas quanto por empresas, e propiciam mobilidade e praticidade na execução de tarefas do dia-a-dia. Com isso, o número de aplicações para tais dispositivos tem crescido, fazendo com que haja transmissão de dados mesmo sem um meio físico de comunicação (sem fio – Wireless) [2][4]. Neste processo, a aplicação cliente (dispositivo móvel) executa requisições à aplicação servidora, onde se encontra o banco de dados, mas pode ter um baixo desempenho, perda de velocidade e serem custosas ao se considerar o tráfego de informações [2][4][5][6].

Diante destas circunstâncias, torna-se (no mínimo) interessante trabalhar com um nível de persistência local temporária nestes dispositivos móveis como solução para as desvantagens citadas. Assim, somente haveria requisições entre as aplicações cliente e servidora quando a primeira não possuísse os dados necessários em seu repositório local ou quando fosse necessário persistir novos dados gerados. Diante desta nova perspectiva, reduz-se o tráfego de informações e melhoram-se os resultados com relação a tempo, desempenho e custos, dentre outras vantagens quanto a realizar constantes buscas junto ao banco de dados (aplicação servidora). Para avaliar a influência da persistência local em dispositivos móveis utilizou-se a plataforma Java Micro Edition (Java ME).

Apresentação da Aplicação e seu Funcionamento

Para o desenvolvimento do presente artigo foram criadas três aplicações: uma servidora (utilizando Java EE); e duas cliente (utilizando Java ME), com as ferramentas NetBeans e NetBeans Mobility Pack (ambas na versão 5.5.1), Sun Java Wireless Toolkit (Java ME Wireless Toolkit) e Mobile Service Architecture (MSA, JSR 248), além do Java Development Kit (JDK, na versão 5.0).

Uma das aplicações cliente sempre realiza requisições de dados à aplicação servidora, enquanto outra aplicação, quando precisa acessar os dados, primeiro verifica se estes estão salvos temporariamente no próprio dispositivo e, caso não estejam localmente, requisita-os à aplicação servidora e os armazena no dispositivo. Independente de qual aplicação cliente for utilizada, a arquitetura caracteriza-se como cliente/servidor padrão (Figura 1), com clientes que interagem com os usuários e com um servidor que recebe e responde às requisições. Esta comunicação entre as aplicações cliente e servidora ocorre por meio do protocolo HTTP (HyperText Transfer Protocol) com o propósito de realizar pedidos de Produtos para Clientes (consumidores ou compradores), recuperando e salvando dados junto à aplicação servidora.

 

Figura 1. Arquitetura da Aplicação.

 

Na Figura 1, quando a aplicação cliente-1 precisa se comunicar com a aplicação servidora, esta envia um pedido pela Internet. Este pedido é interpretado pela aplicação servidora e uma resposta é gerada e enviada de volta. A comunicação entre as aplicações cliente-2 e servidora ocorre da mesma forma, mas, antes de cliente-2 enviar um pedido, esta verifica se já não possui localmente os dados necessários. Caso esses dados sejam encontrados, são recuperados do próprio dispositivo, sem qualquer comunicação entre as aplicações.

Descrição e Considerações quanto à Aplicação Servidora

Esta é uma aplicação web com um servlet que recebe e responde a requisições das aplicações cliente. Estas requisições podem ser pedidos de dados que precisam ser recuperados do BD localizado junto à aplicação servidora ou podem ser novos dados gerados nas aplicações cliente para serem persistidos.

Para desenvolver essa aplicação criou-se um projeto Java Web com a estrutura apresentada na Figura 2 e cujas relações são identificadas na Figura 3. No pacote tcc.beans estão as classes Cliente, ItemPedido, Pedido e Produto, que representam os dados a serem persistidos no banco. Para isso, estas classes possuem a anotação @Entity e algumas outras que permitem que o Hibernate as reconheça como classes de objetos que devem ser persistidos e/ou recuperados.

 

Figura 2. Estrutura de Pacotes e Classes da Aplicação Servidora.

 

Figura 3. Relacionamento entre as Classes e Pacotes da Aplicação Servidora.

 

"

[...] continue lendo...

Artigos relacionados