fy>

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

 

Desenvolvendo em BREW

Parte I - Uma introdução

O desenvolvimento em BREW tem sido mistificado como sendo difícil e pouco produtivo. Gostamos de colocar que BREW é para programadores C/C++ o que J2ME é para programadores Java, ou seja, um programador C/C++ se sentirá tão confortável trabalhando com BREW, já que essa é a linguagem base para se desenvolver na plataforma, quanto um programador Java em J2ME.

Nesse artigo cobriremos todos os passos necessários para iniciar o desenvolvimento de aplicações nessa tecnologia. Mostraremos como instalar e configurar o ambiente, a estrutura básica de uma aplicação em BREW e explicaremos o código de um exemplo estilo “Hello World” escrito em C e outro equivalente em C++.

Esse é o primeiro de uma série de artigos sobre desenvolvimento em BREW. No segundo apresentaremos um estudo de caso que será completamente desenvolvido nessa série e implementaremos toda sua interface gráfica com o usuário. No terceiro explicaremos como trabalhar com os dois principais tipos de persistência em BREW, os arquivos e as bases de dados. No quarto abordaremos a utilização de uma conexão sobre HTTP para transferirmos os dados do handset para um servidor web. E, finalmente, no quinto como configurar o Make File para compilação para plataforma ARM e fazer o deploy em um handset real.

Ambiente de desenvolvimento

Os desenvolvedores BREW trabalham com três ferramentas básicas, o BREW SDK, o BREW Tools e um ambiente de desenvolvimento C/C++. O Visual C++, pertencente ao MS Visual Studio, é escolhido como ambiente de desenvolvimento deste artigo, pois é o que melhor se integra ao BREW SDK através do BREW Add-ins Plug-in, além de ser o ambiente recomendado pela Qualcomm e ao qual ela dá suporte.

Existe ainda a possibilidade de trabalharmos em outras IDEs como o Eclipse. Veja uma descrição mais detalhada dessas e outras ferramentas no artigo “Introdução a BREW, do modelo de negócio a ferramentas de desenvolvimento” publicado na WebMobile 9.

A instalação do BREW SDK e do MS-Visual Studio não tem uma ordem específica já que são ferramentas independentes. Porém, o BREW Add-ins Plug-in só deve ser instalado após a configuração e instalação das duas ferramentas para que as mesmas sejam integradas.

A versão do MS Visual Studio escolhida para nossa instalação foi o MS Visual Studio .Net 2003 (as únicas versões oficialmente suportadas pelo BREW Add-ins Plug-in são o Visual Studio 6.0 e o .Net 2003). A instalação do MS Visual Studio foge do âmbito desse artigo, porém é uma instalação de simples wizard. A única ferramenta necessária a ser instalada no MS Visual Studio é o Visual C++, as outras ficam a cargo do desenvolvedor.

Para instalar o BREW SDK é necessário que o desenvolvedor já tenha se cadastrado no site da Qualcomm (https://brewx.qualcomm.com/brew/sdk/register.jsp). O cadastro é gratuito, mas necessário para fazer o download da ferramenta. Após o cadastro, é fornecido um link chamado “Click here to get BREW SDK now”. Ele leva a uma lista de versões do BREW SDK. Nossa escolha foi a versão 3.1 que é a mais atual e com mais recursos. Porém, todos os exemplos do artigo devem funcionar perfeitamente em qualquer versão do SDK.

Para instalarmos o BREW Add-ins Plug-in, basta selecionar o link abaixo da lista de versões chamado “Miscellaneous Development Tools ”. Após acessar esse link, vá para a sessão “BREW Add-Ins 3.0 for Microsoft Visual Studio” e selecione o link “install”. Após isso, é só seguir o guia.

A instalação do BREW SDK é um wizard simples, não há configurações que precisem de maiores explicações. O único detalhe ao qual o desenvolvedor deve ficar atento é que no fim da instalação é questionado se o instalador deve configurar automaticamente a variável de ambiente BREWDIR (Figura 1). O desenvolvedor deve deixar o instalador configurar essa variável automaticamente.

Se por algum motivo não for possível realizar essa configuração devido, por exemplo, a restrições de escrita no registro do MS Windows, podemos registrá-la mais tarde nas variáveis de ambiente do MS Windows. A instalação do BREW Add-ins Plug-in também não precisa de maiores explicações, o desenvolvedor só deve estar certo que possui o Visual Studio e o BREW SDK antes de começar a instalar o plug-in.

 

      

Figura 1. Configuração da variável de ambiente BREWDIR.

Estrutura de uma aplicação em BREW

A maior dificuldade de desenvolvedores iniciantes em BREW é entender como uma aplicação se divide, a finalidade de cada um dos arquivos que a compõem e a relação que existe entre esses arquivos. A Figura 2 ilustra essa organização e relação.

Cada aplicação é composta por apenas um Módulo, porém pode se utilizar de outros recursos como bibliotecas de funções. O módulo é o código executável da aplicação e pode conter vários Applets criando uma suíte de pequenos aplicativos. O Applet é a classe principal da aplicação e seu ponto de entrada tanto para inicialização como para recebimento de eventos.

 

Figura 2. Aplicação BREW.

 

Uma aplicação precisa de quatro arquivos para ser executada:

·         .MIF: é o descritor da aplicação. Nele estão parâmetros de configuração como o nome do Applet, permissões de acesso a recursos do dispositivo, como sistema de arquivos, seus ícones e as informações sobre o desenvolvedor da aplicação. É gerado pelo BREW MIF Editor ilustrado na Figura 3. Na sessão “Criando nossa aplicação” aprenderemos a usar o MIF Editor.

·         .BID: arquivo que contém o identificador único da aplicação. Seu objetivo é gerar uma assinatura digital única, controlada pela Qualcomm, para cada aplicação diminuindo as chances de pirataria e instalação de softwares maliciosos na plataforma BREW. Poder ser gerado pelo MIF editor caso o desenvolvedor ainda não tenha acesso a extranet da Qualcomm (veja em links seu endereço). Esse identificador, quando gerado pelo MIF editor, é usado somente em tempo de desenvolvimento quando o desenvolvedor deseja testar a aplicação em um emulador Brew (incluso na instalação do SDK). Para injetar a aplicação no handset deve-se gerar o identificador único no site da Qualcomm.

 

Figura 3. MIF Editor.

 

·         .MOD: contém o código executável da aplicação. É gerado por um compilador ARM (vide Nota 1) para ser injetado no handset. Quando estamos executando nossa aplicação no emulador não precisamos de um compilador ARM. O emulador executa o código compilado em uma DLL (passa a representar o MOD para o emulador) padrão MS Windows, bastando então termos um compilador C/C++ comum.

 

Nota 1. O que é ARM?

 A ARM Corp. (http://www.arm.com) é uma empresa que desenvolve micro-processadores e micro-controladores baseados atualmente em uma arquitetura de 32bits. A ARM foi uma das pioneiras na fabricação desenvolvimento de processadores para dispositivos móveis em parceria com a Palm One. Atualmente seus processadores estão presentes na maioria dos celulares que conhecemos e em carros, impressoras fiscais, handhelds, câmeras fotográficas, equipamentos industriais, etc. A arquitetura da ARM é tão popular que foi criado um compilador GNU para ela, o ARM GCC ou também chamado GNU ARM. Esse compilador substitui o compilador vendido pela ARM para seus processadores, o ARM Compiler que atualmente custa em torno de 3 mil dólares para ser importado para o Brasil (valor real mais impostos). Apesar da configuração do Make File de um projeto para a arquitetura ARM ser auxiliado por ferramentas no caso da utilização do GNU ARM, a elaboração desse Make File não é trivial o que desanima os desenvolvedores iniciantes.

 

·         .BAR: contém recursos como imagens, Strings pré-definidas, etc. Deve ser gerado a partir do BREW Resource Editor criando-se um novo projeto de recursos (o .BRI) e posteriormente compilando-o para o BAR (Figura 4). Na sessão “Adicionando Imagens e Recursos à aplicação” entraremos em mais detalhes sobre como criar e configurar o arquivo BAR.

 

Figura 4. Resource Editor.

Sistema de eventos da plataforma BREW

Assim como na maioria das tecnologias de desenvolvimento para softwares embarcados, a plataforma BREW trabalha sobre um sistema de eventos simples e concentrado em um ponto de entrada único. Quando pressionamos uma tecla, recebemos um SMS ou desligamos o handset, a plataforma BREW notifica a aplicação através de um método especificado durante a criação do Applet. O registro se dá na execução da função “AEEApplet_New” (Listagem 2, linha 34) que cria uma nova instância do  Applet.

O método tem a assinatura, respeitando o tipo “AEEHANDLER”, apresentada na Listagem 1 e é comumente nomeado como HandleEvent (não sendo necessário ter esse nome).

 

Listagem 1. Assinatura do HandleEvent.

001: static boolean HelloBREW_HandleEvent(

002:                               HelloBREW* pMe,

003:                               AEEEvent eCode,

004:                               uint16 wParam,

005:                               uint32 dwParam);

                                  

Essa função deve ser definida como estática para que não seja visível pelo resto da aplicação já que é chamada internamente pela plataforma BREW e não desejamos que algum outro módulo da nossa aplicação possa acioná-la. Caso o desenvolvedor esteja trabalhando com C++ e deseje transformar o “HandleEvent” em um método de classe (a prática comum), ela precisa necessariamente ser estática pois o endereço da função é passado (através de um ponteiro) para a plataforma BREW.

Avaliando os parâmetros, vemos que o primeiro é do Tipo “HelloBREW” (Listagem 1, linha 002). Na verdade, para esse método, o primeiro parâmetro sempre é do tipo do Applet da sua aplicação. “HelloBREW” é uma struct que representa o Applet da nossa aplicação exemplo.  

No primeiro momento pode parecer estranho recebermos um ponteiro da nossa própria aplicação por parâmetro, afinal estamos rodando ela não é mesmo? Porém, devemos estar atentos ao detalhe que essa função é estática, ou seja, não tem acesso aos recursos alocados dinamicamente pela aplicação e esse parâmetro permite acessarmos o contexto da aplicação que está rodando no momento.

O segundo parâmetro do tipo “AEEEvent” (Listagem 1, linha 003) é o código do evento gerado. As constantes que definem esse código são encontradas no arquivo “AEE.h” que é o arquivo de header básico do BREW. Uma dica interessante é que o usuário também pode definir seus próprios eventos em BREW e acionar ele a qualquer momento da aplicação. Para isso, existe uma constante especial chamada “EVT_USER”. Todo evento definido pelo usuário deve ser um deslocamento a partir de “EVT_USER”, exemplo, “EVT_USER+0x001”, “EVT_USER+0x002”, etc.

O terceiro e o quarto parâmetros (Listagem 1, linha 004 e 005) são dependentes do segundo e assumem valores relativos a ele. Quando acionamos um evento de pressionamento de tecla o valor recebido em “eCode” é “EVT_KEY_PRESS” e o valor de “wParam” é o código da tecla pressionada e o “dwParam” traz um mapa de bits com flags sobre o evento.

Para uma lista completa dos eventos possíveis da plataforma e os valores e significados de seus parâmetros “wParam” e “dwParam” consulte o help do BREW SDK.

O funcionamento da notificação de eventos, ilustrado na Figura 5, ocorre como no Pattern GoF Observer/Subject onde nossa aplicação será o observador de notificações e a plataforma BREW o postador de notificações. É importante deixar claro que em alguns momentos a aplicação pode, indiretamente, virar um Subject dela mesma. Isso ocorre quando ela se utiliza das rotinas “ISHELL_PostEvent()” ou “ISHELL_SendEvent()”. Mas como sua utilização é bastante específica deixaremos para explicá-las mais tarde.

 

Figura 5. Sistema de eventos BREW.

Criando a nossa aplicação

O primeiro passo que devemos dar é a criação de um novo projeto no Visual Studio como visto na Figura 6.

 

Figura 6. Criando um novo projeto.

 

...

Quer ler esse conteúdo completo? Tenha acesso completo