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.

"