DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!


Artigo Java Magazine 48 - Programação Java ME

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."



ATENÇÃO! A exibição deste artigo foi interrompida.


  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Java Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!






    0 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.


Nenhum comentário foi postado - seja o primeiro a comentar!



Publicidade
Autor
Osvaldo Pinali Doederlein

é Mestre em Engenharia de Software Orientado a Objetos e Arquiteto de Tecnologia da Visionnaire Informática, trabalhando em projetos de software e prospecção tecnológica.


Space do autor
Estatísticas
Favorito:
Comentários:
Feedback:
Utilidade:
0   0
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2012 - Todos os Direitos Reservados a web-03