Artigo da WebMobile 13 - Interface gráfica com o usuário em BREW - Parte 1

Clique aqui para ler todos os artigos desta edição

Interface gráfica com o usuário em BREW – Parte 1

Antonio Luiz Cavalcanti e João Alberto Amaral

Aprendemos no primeiro artigo de nossa série (Web Mobile, edição 12) a estrutura básica de uma aplicação BREW, os arquivos que a compõem e como tratar os eventos enviados pela plataforma BREW. Neste artigo veremos como desenhar toda a interface com primitivas gráficas, implementando todo o controle de ação, como controle de foco da tela desenvolvida. Começaremos também neste artigo a desenvolver uma aplicação completa, realizando um estudo de caso que deve ser finalizado até o final desta série.

Essa aplicação será desenvolvida em quatro etapas. Neste artigo, será apresentada a primeira parte do desenvolvimento da interface gráfica e o fluxo de navegação. No segundo artigo, utilizaremos os componentes gráficos já fornecidos pela plataforma como labels, controles de edição de texto e menus para finalizar nossa interface. O próximo artigo terá como foco o desenvolvimento da camada de persistência de dados. E no último artigo da série, o desenvolvimento da camada de comunicação http.

Estudo de caso “Gerenciador de abastecimentos”

Para explanar as principais funcionalidades da plataforma BREW, criaremos uma aplicação que servirá como estudo de caso. Essa aplicação terá o objetivo de: permitir que o usuário anote os abastecimentos feitos em seu carro, facilitando o controle sobre o consumo de combustível de seu automóvel. Os requisitos da aplicação são:

1.     A aplicação deve permitir que o usuário entre com dados sobre o abastecimento e sobre a quilometragem do carro.

Os dados são:

a.    Data do abastecimento;

b.    Quantidade de litros abastecidos;

c.    O valor do abastecimento;

d.    Quilometragem total do carro.

2.     A aplicação deverá listar os abastecimentos na ordem decrescente de data (os abastecimentos mais recentes primeiro) exibindo ao usuário a data e a quilometragem total do carro. Além disso, deve permitir que o usuário selecione um item da lista para visualização de seus detalhes ou remoção do registro.

3.     A aplicação deverá ser capaz de enviar a lista de abastecimentos para um servidor Web que tratará e armazenará os dados.

O diagrama navegacional ilustrado na Figura 1 mostra o fluxo da aplicação. O diagrama não tem por objetivo apresentar a aparência final da aplicação, mas somente seu fluxo e telas.

Figura 1. Diagrama Navegacional do Fuel Manager.

No diagrama de classes, ilustrado na Figura 2, temos a representação das classes do nosso estudo de caso. A arquitetura que usamos foi simplificada e tem fins didáticos para facilitar o entendimento do sistema de eventos da Plataforma BREW, podendo sofrer diversas melhorias em uma aplicação para o mercado.

Alguns detalhes técnicos sobre a representação da aplicação em UML com relação à implementação que será desenvolvida devem ser esclarecidos antes de continuarmos. O motivo disso é que a plataforma BREW não é orientada a objetos apesar de dar suporte a C++, por isso precisamos adaptar o uso dos diagramas UML nos pontos onde a nossa aplicação (desenvolvida orientada a objetos em C++) se utiliza de APIs e funcionalidades da plataforma BREW (desenvolvida no paradigma estruturado modular em C). Os pontos a serem esclarecidos são:

·         A relação de extensão (herança) que existe entre a classe FuelManager e a struct C AEEApplet na verdade é uma relação de composição, ou seja, a classe FuelManager compõe a struct C AEEApplet. Isso ocorre por causa da diferença de representação em memória de classes C++ e struct C. Caso FuelManager herdasse de AEEApplet não poderíamos utilizar métodos virtuais e alguns atributos da struct original. Como isso é uma limitação técnica e essa composição deve ser entendida como uma extensão, no diagrama ela é representada dessa forma.

·         O método FuelManager_HandeEvent() representado na classe FuelManager não é exatamente um método da classe, é uma função C comum que é registrada no ato de criação do applet da aplicação como a função que vai receber e tratar os eventos enviados pela plataforma BREW (detalhes na edição 12 da Web Mobile). Como sua relação conceitual com a classe FuelManager é de método da classe, então o representamos dessa forma para facilitar o entendimento.

·         A classe abstrata “Screen” define um contrato de assinaturas que deve ser implementado por toda tela do sistema. O método “draw()” vai ser chamado pela classe “FuelManager” fazendo com que a tela se pinte no display do handset, e o método “handle_Event()” será chamado pelo “FuelManager_HandleEvent()” repassando a chamada, quando necessário, para a tela tratar o evento.

Figura 2. Diagrama de classes do FuelManager.

Os diagramas de seqüência da Figura 3 e Figura 4 mostram de forma mais clara como essas classes interagem. O comportamento de chamadas para transição das outras telas é o mesmo que o representado pela Figura 4. Vejamos o fluxo de cada diagrama.

Figura 3. Diagrama de seqüência do Startup da aplicação.

Passos do diagrama de seqüência do startup da aplicação (Figura 3):

1.    Repasse dos eventos da plataforma BREW ao método da aplicação registrado para receber esses eventos;

2.    A aplicação cria a classe SplashScreen;

3.    A aplicação registra o timer que irá manter a SplashScreen sendo exibida no display (3 segundos);

4.    A aplicação chama o método draw() da SplashScreen que desenha a tela no display;

5.    Após se passar os três segundos a plataforma informa a aplicação;

6.    A aplicação é informada que precisa realizar a transição entre a tela atual e o MainMenu;

7.    A aplicação cria a tela MainMenu;

8.    A aplicação chama o destrutor (libera a memória) da tela SplashScreen;

9.    A aplicação chama o método draw() da tela MainMenu, que se pinta no display.

Figura 4. Diagrama de seqüência de transição de tela.

Passos do diagrama de seqüência da transição de tela da aplicação (Figura 4):

1.    Chamada de vento indireta através do método ISHELL_PostEvent() da plataforma BREW;

2.    Recebimento do evento gerado;

3.    Repasse do evento à tela corrente para que ela a trate;

4.    A tela corrente faz a transição para a próxima tela chamando o método show() da aplicação;

5.    O método show() cria a nova tela a ser exibida;

6.    O método show() destrói a tela atual;

7.    O método show() chama o procedimento de pintura da nova tela.

Interface com usuário em BREW

É natural que quando desenvolvemos aplicações B2C (Business to Consumer, ver Nota 1) elaborarmos boas interfaces de iteração com o usuário. Em dispositivos móveis, as implicações das limitações dos dispositivos de entrada e saída (nesse contexto display e teclado) e a própria natureza de desenvolvimento exigem mais atenção e trabalho. Entretanto, foge do escopo do artigo entrar em detalhes sobre usabilidade de interfaces para dispositivos móveis.

Em dispositivos móveis, para praticamente toda plataforma de desenvolvimento, temos dois conjuntos de APIs utilizadas para criação dessas interfaces:

·         APIs de alto nível: possuem componentes de iteração prontos para serem utilizados, por exemplo: campos de entrada de texto;

·         APIs de baixo nível: também conhecidas como APIs de primitivas gráficas. Estas APIs dão muito mais poder ao desenvolvedor, porém, também deixa sob sua responsabilidade todo o controle sobre os componentes que forem criados.

Neste artigo focaremos na API de baixo nível. A API de alto nível será explorada na parte 2 desta matéria.

Nota 1. Classificação de aplicações segundo o consumidor alvo

Quando desenvolvemos produtos ou serviços costumamos classificá-los de acordo com o consumidor alvo a quem a aplicação se destina. São algumas dessas classificações:

B2B – Business to Business: Produtos/Serviços produzidos por empresas e destinados a empresas. Podemos usar como exemplo os softwares destinados a controle de folha de pagamento.

B2C – Business to Consumer: Produtos/Serviços produzidos por empresas destinados a consumidores finais. Um exemplo seriam softwares como uma agenda de telefones para celulares.

C2C – Consumer to Consumer: Produto/Serviço desenvolvidos por consumidores para consumidores. Um dos melhores exemplos atuais são os produtos oferecidos em sites de leilão como EBay, Mercado livre etc.

B2G – Business to Governement: Produtos/Serviços desenvolvidos por empresas para governos.

B2E – Business to Employee: Produtos e serviços desenvolvidos pela empresa para seus próprios funcionários. Temos como exemplo sites de intranet e compras subsidiadas.

Utilizando APIs de baixo nível

A plataforma BREW possui um bom suporte a primitivas gráficas e funções de desenho em tela. Podemos dizer que a plataforma encoraja a utilização dessas APIs por dois motivos: o primeiro é que mesmo quando utilizamos os componentes gráficos fornecidos pela plataforma, ainda é de responsabilidade do desenvolvedor implementar todo o controle de comportamento da tela, por exemplo: o controle de foco e o repasse dos eventos a cada componente de edição; segundo, podemos sempre misturar a pintura de componentes já disponibilizados pela plataforma (exibição de um componente na tela, normalmente feito com uma chamada ao método update() da plataforma) com a pintura de baixo nível (desenho de primitivas gráficas como retas e polígonos ou exibição de imagens), o que não é possível com outras plataformas, como é o caso do JME.

Temos três bibliotecas de funções para esse fim. O IGraphics que provê ao desenvolvedor uma API de pintura de gráficos 2D, as funções da biblioteca IDisplay, que possui suporte a pintura de elementos mais simples como texto e quadriláteros (preenchimento ou bordas) no display e IImage que permite a carga e desenho de uma imagem presente no arquivo de recursos da aplicação. Vejamos nas Tabelas 1 e 2 algumas das funções básicas das bibliotecas IDisplay e IImage respectivamente. As funções da biblioteca IGraphics são semelhantes em utilização com as da biblioteca IDisplay, e podem ser utilizadas facilmente após entendermos como utilizar as funções de IDisplay.