Interface Gráfica para aplicações J2ME
Uma introdução à MIDP UI API
Uma interface gráfica atraente, com uma arte bem trabalhada, é um bom pré-requisito para o sucesso de um jogo ou de um aplicativo. Quando se trata de dispositivos móveis, como celulares e PDAs, existe um outro fator muito importante para o sucesso dessas aplicações: a acessibilidade aos recursos do aplicativo. Devido às limitações do aparelho (tamanho da tela, quantidade de cores, memória, entre outras), a interação do usuário com o dispositivo é bem diferente, por exemplo, da interação que ele teria com um computador.
Devido a essas características específicas deste tipo de aplicação, o desenvolvedor de aplicações para dispositivos móveis deve estar atento a estes fatos de maneira tal que os menus da interface gráfica tenham uma boa navegabilidade e que os gráficos não consumam muitos recursos do aparelho, o que prejudica a performance da aplicação. É importante que as opções sejam acessadas por comandos intuitivos e de fácil acesso em interfaces similares àquelas das aplicações nativas. Tudo isso para ajudar o usuário em seu processo de aprendizagem, mesmo porque nem todos têm intimidade com os recursos disponíveis em um aparelho celular.
A quantidade de telas e a dificuldade de navegação entre elas são diretamente proporcionais à complexidade da aplicação. Deve-se sempre analisar cuidadosamente o impacto que a inclusão de uma nova funcionalidade irá gerar na interface gráfica. Ainda mais em um dispositivo tão “limitado” quanto um celular, onde o usuário tem a possibilidade de usar apenas uma mão para manusear o aparelho.
É pensando um pouco nestes aspectos que iremos discutir neste artigo algumas características da construção de interfaces gráficas para aparelhos celulares, e comentar as ferramentas básicas fornecidas pela API MIDP 2.0 que foram usadas no desenvolvimento da aplicação de Jogo da Velha publicado na quarta edição da Web Mobile.
Visão geral da API MIDP 2.0
A segunda versão do Mobile Information Device Profile está descrita na JSR-118, que é a especificação Java que define um conjunto de APIs associadas necessárias para a criação de um ambiente de desenvolvimento de aplicações destinadas a um determinado conjunto de dispositivos. É baseada na primeira versão e fornece 100% de compatibilidade de forma que uma aplicação escrita para o ambientes MIDP 1.0 possam executar em ambientes MIDP 2.0.
A API MIDP 2.0 divide as classes de interface com o usuário em dois pacotes: javax.microedition.lcdui, que contém as principais classes para desenvolvimento de interfaces para aplicativos, e javax.microedition.lcdui.game, que contém classes específicas para o desenvolvimento de jogos. Vamos começar pela principal classe da API, a classe Display.
A Figura 1 apresenta uma hierarquia das principais classes de interface com o usuário, começando com a classe Display.
Figura 1. Hierarquia de classes.
A classe Display
Um objeto da classe Display é o gerenciador da tela, pois controla tudo aquilo que é mostrado no dispositivo. Todo MIDlet pode obter uma referência para um objeto do tipo Display por meio de uma chamada ao método estático getDisplay() declarado dentro desta classe. Esse objeto oferece métodos para se obter informações sobre a tela atual (quantidade de cores, por exemplo) e para solicitar que um determinado objeto seja mostrado na tela.
A classe Displayable
Seguindo a hierarquia descrita na Figura 1, a classe seguinte é Displayable.
Para que um componente possa ser mostrado na tela ele deve estar contido dentro de um objeto do tipo Displayable. Em qualquer momento, a aplicação poderá mostrar apenas um objeto Displayable na tela do dispositivo usando o método setCurrent() da classe Display e é com este objeto que o usuário irá interagir.
O MIDP inclui duas subclasses de Displayable: Screen e Canvas (ver Figura 1).
Como a classe Displayable é abstrata, não é possível criar um objeto do tipo Displayable diretamente. A solução para isso é estender a classe Canvas ou a classe Screen e, dessa forma, ter acesso aos métodos de Displayable:
public abstract class Displayable
public abstract class Screen extends Displayable
public abstract class Canvas extends Displayable
Basicamente, isto pode ser feito de três formas diferentes:
· Estender a classe Canvas diretamente, lembrando que a aplicação deve prover uma implementação válida para o método paint(), pois este é declarado como abstrato em Canvas (Listagem 1).
Listagem 1. Estendendo a classe Canvas.
public class JogoDaVelha extends Canvas {
// código
public void paint(Graphics g) {
// mais código aqui
}
}
· Usar subclasses de Screen: a API MIDP 2.0 já tem componentes prontos que são subclasses de Screen. São eles: List, Alert, TextBox e Form;
· Estender uma das classes anteriores (List, Alert, TextBox ou Form).
Componentes de alto nível
As classes que compõem a API de alto nível são as mais adequadas quando o objetivo é desenvolver aplicativos que funcionem em um maior número possível de dispositivos. Isso porque quem define a aparência dos componentes não é o aplicativo, mas sim a implementação do MIDP no próprio dispositivo. Também é a implementação no dispositivo que se encarrega de gerenciar internamente os eventos capturados pelos componentes da tela.
A classe Screen
Screen é a classe básica da qual são derivadas todas as telas da API de alto nível. Os objetos das subclasses de Screen são os componentes de alto nível da interface com o usuário. A partir de agora, iremos descrever cada subclasse de Screen, conforme descrito na Figura 1.
Classe TextBox
Um exemplo de subclasse de Screen é a classe TextBox, uma tela para mostrar e editar texto. Por ocupar a tela inteira do dispositivo, este componente pode conter uma grande quantidade de texto espalhado em várias linhas. O código descrito na Listagem 2 é exemplo muito simples de como TextBox pode ser usado e a Figura 2 mostra o resultado no J2ME Wireless Toolkit, um ambiente de emulação fornecido pela Sun para o desenvolvimento de aplicações MIDP.
Listagem 2. Instanciação de um objeto TextBox.
TextBox tb = new TextBox("Título", "texto", 200, TextField.ANY);
Display.getDisplay(this).setCurrent(tb);
Figura 2. Exemplo de um TextBox.
Classe Form
A subclasse de Screen que é normalmente a mais utilizada é Form, pois permite construir interfaces com vários componentes – os Items. Convém ressaltar que Item não é subclasse de Form, mas foi ilustrado dessa maneira na Figura 1, pois ela é uma superclasse de componentes que podem ser adicionados a um Form. A seguir está uma lista descrevendo os componentes que podem ser adicionados a um Form:
· ChoiceGroup: provê um conjunto de opções que podem ser ou não mutuamente exclusivas. Pode apresentar escolhas explícitas por meio de botões de seleção ou múltiplas escolhas através de caixas de seleção.
· TextField: é um campo com uma única linha para entrada de texto, muito semelhante ao TextBox.
· DateField: é uma versão de TextField específica para manipular o objeto java.util.Date utilizando as teclas do dispositivo móvel. De acordo com a implementação, pode apresentar uma aparência e funcionalidade que simplifique o processo de escolha de datas.
· Gauge: é a famosa barra de progresso, tão popular nos computadores desktop. Pode ser interativa, permitindo a seleção de um valor dentro de um conjunto de valores, ou não-interativa, mostrando o progresso de uma determina operação.
· ImageItem: permite especificar a forma com que uma imagem será exibida em um objeto Form.
· StringItem: mostra um rótulo estático e uma mensagem de texto na interface gráfica. Como o usuário não pode editar nem o rótulo e nem o texto, um objeto StringItem não pode reconhecer eventos.
Na Figura 3 temos o exemplo de um Form com dois itens: um ChoiceGroup e um DateField. À direita está a maneira com que a implementação do MIDP “ajuda” o usuário a escolher uma data. O código referente à tela apresentada na Figura 3 está descrito na Listagem 3.
Figura 3. Exemplo de ChoiceGroup e DateField.
Listagem 3. Criação de um Form com os objetos ChoiceGroup e DateField.
Form mainForm = new Form("Título");
ChoiceGroup cg = new ChoiceGroup("Escolha uma opção:", Choice.EXCLUSIVE);
cg.append("Opção 1", null);
cg.append("Opção 2", null);
cg.append("Opção 3", null);
mainForm.append(cg);
DateField df = new DateField("Data:", DateField.DATE);
df.setDate(new Date());
mainForm.append(df);
Display.getDisplay(this).setCurrent(mainForm);
Classe Alert
Continuando a descrever as classes que compõem a Figura 1, a seguinte é a classe Alert. Esta é uma subclasse de Screen que se comporta de forma parecida com uma caixa de diálogo, embora tenha funcionalidades bem reduzidas. Este objeto pode ocupar uma parte ou toda a tela com uma mensagem de texto e uma imagem, e seu uso mais comum é para mostrar uma mensagem de aviso ou erro.
Um Alert pode permanecer na tela até que o usuário pressione uma tecla ou apenas por um determinado intervalo de tempo até ser fechado automaticamente. Este objeto tem um atributo do tipo AlertType que é usado pelo aparelho para mudar a aparência do componente e ajudar o usuário a fazer distinção entre mensagens de erro, informação, advertência, confirmação e alarme.
Classe List
Agora só nos resta falar de List, o último dos componentes gráficos de alto nível. Assim como o ChoiceGroup, um objeto List implementa a interface Choice e contém uma série de escolhas. Em outras palavras, List é a versão de ChoiceGroup que ocupa toda a tela do dispositivo.
Além de suportar seleção exclusiva e seleções múltiplas, List tem um terceiro modo de operação: a seleção implícita. Neste modo, um objeto List se comporta como uma lista padrão, restringindo a seleção a apenas um elemento por vez. Este modo de operação é muito utilizado na criação de menus, pois em uma lista implícita o elemento em destaque é implicitamente considerado como o elemento selecionado. A Figura 4 apresenta um exemplo de uma lista implícita construída com um código (Listagem 4) muito semelhante ao código mostrado no exemplo do ChoiceGroup.
Listagem 4. Criação de um objeto List.
List list = new List("Lista Implícita", List.IMPLICIT);
list.append("Opção 1", null);
list.append("Opção 2", null);
list.append("Opção 3", null);
...
