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

wm06_capa.JPG

a versão 4.1 do NetBeans Mobility Pack.

Das diversas novidades introduzidas nesta versão, o Visual Mobile Designer é uma das principais, e será o foco deste artigo. Com ele, o trabalho de criação, codificação e testes do layout, bem como da lógica de navegação dos diversos componentes de uma interface de usuário na plataforma J2ME, torna-se muito mais fácil e rápido.

Este artigo apresentará como construir uma aplicação J2ME, onde grande parte do trabalho de codificação é automatizado utilizando-se o Visual Mobile Designer.

Para os leitores iniciantes em J2ME, é recomendável a leitura do artigo “Introdução ao J2ME” publicado na edição 01 da Web Mobile. Também é recomendável que o leitor possua alguma experiência com o NetBeans, caso queira instalar e manipular a aplicação.

O estudo de caso a ser seguido

O estudo de caso que criaremos para demonstrar a utilização do NetBeans como editor Visual de uma aplicação J2ME é uma aplicação para cotações de moedas. O usuário informará as duas moedas e a aplicação fará a conversão de uma para outra, buscando as cotações disponibilizadas no site Yahoo Finance, e apresentando o resultado ao usuário.

Todos os arquivos que compõe o projeto criado pelo NetBeans para esta aplicação estão disponíveis no portal Web Mobile (www.portalwebmobile.com.br).

Mesmo sendo uma aplicação Java bastante simples, sua divisão em módulos principais com responsabilidades bem definidas é sempre uma boa prática que facilita tanto o desenvolvimento e testes, quanto as posteriores modificações e eventualmente até a reutilização de algum módulo.

A seguir está a solução adotada para este exemplo, baseada em três módulos:

-          módulo 1: interface para entrada de dados e apresentação dos resultados ao usuário;

-          módulo 2: busca das informações no site Yahoo Finance;

-          módulo 3: formatação dos resultados.

Definindo as classes da aplicação

Uma vez definidos os módulos principais, podemos agora começar a pensar nas classes que precisaremos para implementar nossa aplicação. Para este estudo de caso, a solução adotada foi a implementação de cada um dos módulos em uma classe. Sendo uma aplicação J2ME, precisaremos de uma MIDlet (ver Nota 1) que será responsável pelo gerenciamento do ciclo de vida da aplicação, bem como pela funcionalidade definida no módulo 1. Para o módulo 2 precisaremos de uma classe que faça a comunicação via HTTP com o servidor do Yahoo Finance e traga as cotações. E, finalmente, para o módulo 3, precisaremos de uma classe utilitária que faça a formatação dos dados recebidos do servidor de acordo com as necessidades da nossa aplicação, pois o que o Yahoo Finance nos fornece como resposta é uma string do tipo CSV (Comma Separeted Values). A maneira como os dados serão exibidos é definida mais adiante, quando elaborarmos o esboço das telas da aplicação.

 

Nota 1. MIDlets

A especificação J2ME define uma plataforma Java para dispositivos portáteis. Uma das famílias de dispositivos (a mais comum hoje em dia) que esta especificação endereça é denominada MID (Micro Information Device).

 

Os componentes definidos pela especificação J2ME para os dispositivos MID são os seguintes:

-  uma máquina virtual Java bastante reduzida e otimizada, denominada KVM (Kilobyte Virtual Machine);

- uma configuração, denominada CLDC (Connected, Limited Device Configuration), que define os padrões desta plataforma, tais como: características de hardware do dispositivo, o modelo de segurança implementado na plataforma Java, as diferenças nas implementações da linguagem Java e da máquina virtual Java (em comparação com a especificação J2SE), e as bibliotecas de programação Java inclusas;

- um perfil, denominado MIDP (Micro Information Device Profile), que define as características de hardware, porém agora de forma mais específica para os dispositivos MID, e as bibliotecas de programação Java, também específicas para os dispositivos MID, como: interface de usuário, comunicação em rede, armazenamento persistente, e gerenciamento de aplicação.

 

Veja na Figura 1 o diagrama mostrando a arquitetura da plataforma J2ME para os dispositivos MID:

 

Figura 1. Arquitetura da plataforma J2ME para dispositivos MID.

 

MIDlet, portanto,  é o nome que se utiliza para definir uma aplicação java feita para ser executada num dispositivo MID.

 

Uma MIDlet, como CCMidlet no nosso exemplo, estende a classe javax.microedition.midlet.MIDlet, que é responsável pelo gerenciamento do ciclo de vida da aplicação (inicialização, execução, encerramento, pausa), e se comunica com o software gerenciador de aplicativos nativo do dispositivo MID.

 

Existem várias boas práticas no desenvolvimento de aplicações J2ME que fazem uso de conexões HTTP e que implementaremos aqui ao desenvolvermos o módulo 2 do nosso estudo de caso. Por exemplo, mostrar algum indicador de progresso da comunicação ao usuário e fazer a conexão em uma thread separada da thread principal da aplicação, dando ao usuário a chance de cancelar a comunicação caso seja necessário. Estas e outras práticas, bem como maiores detalhes sobre comunicação HTTP com J2ME podem ser consultados no artigo “Conexão HTTP com J2ME” publicado na edição 02 da Web Mobile.

Veja na Figura 2 o diagrama de classes da aplicação. CCMidlet é a MIDlet da aplicação, e como veremos adiante, os métodos initialize e get_ são criados automaticamente pelo NetBeans. A notação extra oficial get_ foi utilizada para simplificar o diagrama e significa que existem vários métodos get_, um para cada elemento da interface de usuário. Quoter é a classe responsável pela conexão com o servidor e busca das informações. Um objeto Quoter, quando instanciado por CCMidlet, rodará numa thread separada. Ao final da execução de sua thread, o Quoter chamará um de dois métodos de CCMidlet: retornoConversao, caso a conexão obteve sucesso, ou retornoErroConexao em caso de erro. Uma vez com as informações recebidas, CCMidlet pode utilizar-se dos métodos da classe Parser para checar a consistência das informações recebidas e extrair e formatar as informações relevantes. Existe ainda uma quarta classe, ConnectTimer, responsável pela atualização do indicador de progresso da conexão. Observe que esta é uma classe interna de CCMidlet. Esta classe estende a classe TimerTask e implementa em seu método run a lógica necessária para a atualização do indicador de progresso.

 

Figura 2. Diagrama de classes da aplicação.

Antes ainda de iniciarmos qualquer codificação, convém criarmos um esboço da interface de usuário, com seus elementos e navegação entre as telas. Isso nos auxilia na identificação dos tipos de componentes que precisaremos para esta interface. Veja o esboço na Figura 3, representando as telas e a navegação entre as mesmas para a operação Converter. As setas com linhas cheias representam ações iniciadas pelo usuário, enquanto a seta com linha tracejada representa uma ação iniciada automaticamente pela aplicação. A Figura 4 mostra o diagrama de seqüência para esta mesma operação, explicado a seguir:

1)      O usuário informa os códigos das moedas a serem convertidas, como USD e BRL;

...

Quer ler esse conteúdo completo? Tenha acesso completo