Artigos Java Artigo Java Magazine 63 - Aplicando Padrões de Projetos em Java ME

Esse artigo faz parte da revista Java Magazine edição 63. Clique aqui para ler todos os artigos desta edição

AN style="FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; FONT-FAMILY: Verdana; moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial">

PAN>

/o:p>

 

Em que situação o tema é útil:

Caso deseje utilizar padrões de projetos em Java ME que minimizem a complexidade enfrentada durante o desenvolvimento de conteúdo gráfico interativo.

 

Aplicando padrões de projetos em Java ME:

A plataforma Java ME se tornou uma das tecnologias mais utilizadas para o desenvolvimento de aplicações móveis. Com a evolução das tecnologias dos dispositivos (aumento do poder de processamento, de armazenamento, etc.), o desenvolvimento de MIDlets deixou de ser ad-hoc e passou a seguir um caráter mais profissional e comercial, no qual “BluePrints” disponíveis para as outras especificações da linguagem Java como Java SE ou Java EE puderam ser aplicados também para a versão móvel do Java.

Diante deste cenário, vários desenvolvedores móveis começaram a aplicar tais padrões de projetos em seus projetos e obtiveram casos de sucesso. E outros, dentre eles Ben Hui, desenvolveram padrões de projetos específicos para solucionarem problemas comuns enfrentados durante o desenvolvimento de interfaces gráficas em MIDP, que são: Cascading Menu, Wizard Dialog, Pagination e Slide Show.

 

Os padrões de projetos há muito tempo foram criados para solucionar problemas que nós, programadores, encontramos no desenvolvimento de cada dia, aumentando o nível de modularidade, a reusabilidade e diminuindo o grau de acoplamento entre os módulos ou componentes das nossas aplicações.

Estes padrões (Design Patterns ou simplesmente Patterns) são muito utilizados e conhecidos nas plataformas Java SE e Java EE. Entretanto, o desenvolvimento de aplicações móveis na plataforma Java ME tem amadurecido a cada dia, e “BluePrints” específicos para a confecção de aplicações têm surgido. Tudo isso com o objetivo de diminuir o esforço no desenvolvimento de aplicações que precisam ser executadas em dispositivos com características limitadas, como é o caso dos telefones celulares e Smartphones.

Este artigo irá demonstrar a viabilidade da utilização de padrões de projetos e como estes podem melhorar significativamente o desenvolvimento de MIDlets (aplicações para o perfil MIDP). Para isso, serão apresentados quatro padrões de projeto específicos para a plataforma Java ME: Cascading Menu, Wizard Dialog, Pagination e Slide Show.

Restrições em dispositivos móveis

Programar para dispositivos móveis requer um pouco de cautela, haja vista as limitadas configurações da maioria dos dispositivos. Restrições como baixo poder de processamento, capacidade de memória limitada e escassez de recursos gráficos ainda preocupam o desenvolvedor no momento de implementação da sua aplicação móvel Java ME. Em dispositivos celulares mais antigos, por exemplo, não há suporte para cores. Porém, há anos que os fabricantes de dispositivos produzem telefones celulares com suporte a cores. Com a evolução da tecnologia, hoje é comum encontrar um celular com suporte de 262 mil cores ou mais.

Outro fator restritivo é o limite da tela na maioria dos dispositivos. Por exemplo, em um celular que possui uma resolução de 12.288 pixels (96 x 128), se torna difícil exibir um simples nome completo ou endereço de uma pessoa.

Entretanto, o avanço da tecnologia dos dispositivos móveis, principalmente a capacidade de armazenamento (hoje podemos armazenar gigas de dados) e a de processamento, aliada ao fenômeno da convergência digital, têm proporcionado uma alternativa de melhoria no desenvolvimento de aplicações móveis, sendo possível elaborar arquiteturas mais robustas (várias camadas) a serem utilizadas por MIDlets. Hoje em dia é raro encontrar uma aplicação móvel que seja restrita a uma única MIDlet (e talvez mais algumas classes utilitárias), onde é possível perceber claramente a mistura das regras de negócios com componentes de Interface Gráfica com o Usuário, o que dificulta consideravelmente a reusabilidade e manutenibilidade. Portanto, para solucionar o problema, entram em cena os Padrões de Projeto.

Padrões de projetos em Java ME

Java ME, desde sua concepção, tem sido a plataforma preferida entre os desenvolvedores de aplicações para dispositivos móveis, graças às suas mais variadas características que seguem o lema do WORA (Write Once, Run Anywhere – escreva uma vez, execute em qualquer lugar), um dos fatores essenciais para a garantia da portabilidade da linguagem Java. Contudo, desenvolver aplicações para dispositivos que suportam essa plataforma ainda é desafiante. A evolução das tecnologias dos dispositivos móveis – quer seja de hardware ou de software – vem possibilitando a construção de sistemas móveis cada vez mais complexos, que podem variar desde uma aplicação M-Commerce que realiza transações bancárias até um jogo de estratégia.

Com o passar dos anos, os “desenvolvedores móveis” foram adquirindo experiências nessa plataforma e perceberam que para implementar determinada funcionalidade era necessário que tarefas semelhantes fossem replicadas por várias linhas de código, o que prejudicava a produtividade e tornava o desenvolvimento monótono. Assim, perceberam que determinados padrões de projetos poderiam ser adaptados para a plataforma Java ME e utilizados em suas aplicações sem comprometer o propósito deles. Os próprios arquitetos da versão móvel de Java utilizaram alguns patterns para a construção da plataforma (veja o quadro “O Padrão Factory em MIDP”).

Outros desenvolvedores criaram seus próprios padrões e aplicaram em suas aplicações, relatando casos de sucesso na utilização de tais padrões. Um deles, chamado Ben Hui, elaborou quatro padrões de projeto: Cascading Menu, Wizard Dialog, Pagination e SlideShow, os quais simplificam o desenvolvimento de conteúdo interativo usando o perfil MIDP (Mobile Information Device Profile). A seguir será descrito cada padrão. Para o desenvolvimento dos exemplos deste artigo, foi utilizada a IDE Eclipse 3.4 - Ganymede (www.eclipse.org/ganymede/) juntamente com o plugin EclipseME 1.7.9 (http://eclipseme.org/) e para a emulação, a ferramenta Sun Java Wireless Toolkit 2.5.2 for CLDC, para as especificações CLDC 1.1 e MIDP 2.0. Os exemplos de código dos padrões de projetos mostrados neste artigo foram baseados nas implementações do autor dos padrões. O link para baixá-los está disponível na seção Links. Para cada padrão de projeto apresentado, será utilizado um quadro que mostra a arquitetura e descreve sucintamente o objetivo, o problema e sua solução, os elementos que fazem parte do padrão, a conseqüência da aplicação deste pattern e sua implementação.

 

O padrão Factory em MIDP

  Desde a concepção de Java ME que os projetistas utilizam o conceito de padrão de projeto. Um exemplo disso é o GCF (Generic Connection Framework ou Framework de Conexão Genérica), que – como o nome sugere – é a estrutura que o MIDP utiliza para a realização de vários tipos de conexões. Este pattern deve ser aplicado quando não for possível determinar o tipo de objeto que deve ser instanciado (como pode ser visto na Listagem 1). Sendo assim, o padrão Factory (Fábrica) – que é caracterizado como um padrão de projeto criacional – pode ser utilizado para abstrair todo o trabalho de criação do objeto.

  No caso do GCF, percebemos claramente a presença deste padrão por meio da Classe javax.microedition.io.Connector, na qual chamamos o método Connector.open() e passamos como parâmetro apenas uma string representando a URL ao qual queremos ter acesso. Depois, de acordo com o tipo de protocolo que for passado (HTTP, Socket, HTTPS, Bluetooth, etc.), o framework instancia uma classe específica que implementa todas as funcionalidades referente àquele protocolo. Para isso, o parâmetro passado a Connector.open() deve estar no seguinte formato: {scheme}:[{target}][{params}], onde {scheme} representa o tipo de protocolo sendo acessado, {target} normalmente é algum endereço de rede (www.algumsite.com.br, por exemplo) e {params}, os parâmetros passados na URL no formato “;param=valor”. A arquitetura com os principais componentes do GCF é mostrada na Figura 1.

  Dessa forma, podemos tratar qualquer tipo de conexão como um Connection. Porém, caso queiramos, por exemplo, realizar uma conexão do tipo HTTP, deveremos realizar um cast para a interface HttpConnection. Então, o framework se encarregará de instanciar a classe que implemente a interface HttpConnection, tudo isso de forma transparente para o desenvolvedor, graças ao padrão Factory. A Listagem 1 mostra este pattern em ação no GCF, na qual é passado como parâmetro para o método open() de Connector apenas uma String que indica a URL a qual será realizada a conexão. De antemão, não se sabe qual será o tipo de objeto retornado pelo método, haja vista que este retorna uma interface (HttpConnection) em vez de uma classe concreta. Então, o framework trata de analisar o protocolo de acordo com o esquema da url passada (que no nosso caso é http://) e depois instanciar uma classe (esta classe irá variar de acordo com a implementação da CLDC do fabricante) que implemente todas as funcionalidades deste protocolo.

 

Figura 1. Arquitetura do GCF em MIDP.

Listagem 1. Exemplo do padrão Factory no GCF: FactoryPattern.java.

public class FactoryPattern extends MIDlet implements CommandListener {

 

  private HttpConnection con;

 

  //página inicial do portal DevMedia

  public final String URL = "//www.devmedia.com.br/portal/default.asp";

 

  // outras declarações de variáveis

 

  private void conectar() {

    try {

      // Utilização do padrão Factory

      con = (HttpConnection) Connector.open(URL);

      con.setRequestMethod(HttpConnection.GET);

 

      // abre a conexão

      is = con.openInputStream();

 

      // código para tratamento dos dados retornados

    }

    catch (IOException e) {

      // tratamento adequado da exceção

    }

  }

}

 

Padrão Cascading Menu

Várias são as maneiras de se implementar navegação em uma aplicação. Uma delas é por meio de menus. Para a representação de cada menu, uma possível implementação seria por meio de subclasses da classe javax.microedition.lcdui.List contendo várias opções de escolha. Um exemplo interessante da utilização do padrão Cascading Menu seria em uma aplicação do tipo guia de cidades, no qual o usuário vai navegando por vários menus até ser retornada alguma informação.

No modelo de tratamento de eventos em Java ME, as classes que necessitem capturar o pressionamento de teclas devem implementar a interface javax.microedition.CommandListener juntamente com seu método commandAction(), e configurar o método setCommandListener() do objeto que gerou o evento. No desenvolvimento de MIDlets comuns, cada objeto List implementa implicitamente (por meio da constante List.IMPLICIT passada no construtor da classe List) a interface javax.microedition.CommandListener. Sendo assim, o papel do controlador é realizada por esta para gerenciar o fluxo da aplicação e redirecionar para o menu de acordo com a escolha do usuário. Essa abordagem só é viável quando a aplicação estiver usando poucas subclasses de List para representar as listas com itens de menus. Supondo que uma MIDlet simples em Java ME tivesse mais de 15 menus, além de ser necessário criar subclasses de List para cada menu, a gerência do controle do fluxo entre os menus torna-se mais complexo e custoso.

Uma implementação de estrutura semelhante a essa pode ser alcançada por meio do padrão de projeto MVC (Model-View-Controller/Modelo-Visão-Controlador). Neste padrão, ocorre o total desacoplamento das responsabilidades de cada parte da aplicação, sendo que o Modelo de dados é responsável pela representação das regras de negócio, a Visão renderiza o modelo de dados por meio de componentes de Interface Gráfica com o Usuário (GUI – Graphical User Interface, na verdade, em Java ME este termo pode ser substituído por LCDUI – Liquid Crystal Display User Interface – que são componentes gráficos de MIDP que foram projetados especificamente para serem visualizados por dispositivos com telas reduzidas) e o Controlador é responsável por capturar eventos gerados pelo usuário (que pode ser o clique de uma tecla de um dispositivo), gerenciar o fluxo da aplicação e controlar a “conversa” com o modelo e a visão. O modelo informa à visão que os dados foram alterados e esta renderiza os dados com os valores atualizados. A arquitetura MVC é mostrada na Figura 2.

O padrão Cascading Menu (ver Figura 3) pode ser considerado uma versão “móvel” do MVC. Sendo assim, o modelo de dados pode ser mantido e atualizado independente do tipo de visão que será utilizada. Qualquer rearranjo no sistema de menus implicará apenas na reorganização da estrutura do modelo representada por uma árvore de menus.

 

Figura 2. A Arquitetura MVC.

Pattern: Cascading Menu

Figura 3. Arquitetura do padrão Cascading Menu.

Objetivo

Permitir criar uma hierarquia complexa de menus, de forma a abstrair o encadeamento entre telas.

Problema

Para implementação de uma hierarquia de menus com lista de itens, normalmente em MIDP, seria necessário criar subclasses de List para cada menu a ser utilizado pela aplicação.

Solução

A Arquitetura MVC para desacoplar a parte do Modelo da Visão por meio de um Controlador.

Participantes

MenuList: Responsável pela visualização da hierarquia de itens de menu. Realiza o papel da visão.

List: Componente gráfico de MIDP para representação de lista.

MenuElement: Representa um elemento do menu, que pode ser um texto ou um outro menu aninhado. Representa o modelo.

MDisplayable: Interface responsável pela visualização dos Displayables que desejam ser exibidos ao término da navegação dos menus.

Displayable: Classe mãe de todos os componentes gráficos de MIDP.

CommandListener: Interface de MIDP que permite capturar eventos de comandos (clique em uma tecla do dispositivo, por exemplo). Realiza o papel do Controlador.

Conseqüências

Uma hierarquia de menus mais complexa, porém, novas adições de menus à estrutura acontecem de modo mais simples.

...
Quer ler esse conteúdo completo? Tenha acesso completo