Artigo: Symbian C++ (Estrutura de um aplicativo) :: Parte 01

1. Introdução

Dando continuidade ao estudo da plataforma Symbian C++, irei descrever algumas peculiaridades da plataforma Symbian para celulares Série 60 (Mais informações, ver o primeiro post explicando os conceitos iniciais sobre a plataforma Symbian). Inicialmente, é importante frisar que a sintaxe para incluir bibliotecas, fazer comentários, definir classes e funções é a mesma da linguagem C++ para desktops, embora existam algumas diferenças e particularidades em comparação ao Symbian C++.

2. Symbian C++

A primeira diferença é que o Symbian C++ define seus próprios tipos primitivos (além de usar os tipos primitivos já existentes no C++) e recomenda aos seus desenvolvedores a utilizá-los. A razão para isso é que esses tipos customizados tem uma garantia de seu comportamento independente da implementação e são consistentes (por exemplo, um TInt tem sempre 32 bits). Esses tipos primitivos podem ser vistos na tabela abaixo:

Tipos Primitivos

Descrição

TInt8/TUint8

Inteiros de 8 bits com e sem sinal

TInt16/TUint16

Inteiros de 16 bits com e sem sinal

TInt32/TUint32

Inteiros de 32 bits com e sem sinal.

Tint/TUint

Inteiros com e sem sinal. Na prática, significa o mesmo que TInt32 e TUint32.

TReal32/TReal64/TReal

Números de ponto flutuante de precisão simples e dupla de acordo com a norma IEE 754. Equivalentes ao float e Double. TReal equivale a TReal64.

TAny

Equivalente ao void, e usado normalmente como TAny* (Um ponteiro para qualquer coisa)

Tbool

Boolean


Além disso, o Symbian OS define algumas formas diferentes de compilação de código-fonte. Os mais usados são listados abaixo:

* EXE (.exe) : Um programa com um único ponto de entrada E32Main(). A interface do usuário é limitada a uma janela de console (semelhante ao DOS). É importante frisar que esse tipo de aplicação não aparece no menu de celular, sendo necessária outra aplicação para iniciá-la.

*Dinamic Link Library (.dll) : Biblioteca de códigos com vários pontos de entrada. DLLS são carregadas por outros programas.

*Application (.app): Programas com uma interface gráfica com o usuário. Esa aplicação instala um ícone no menu do celular e pode ser iniciada diretamente.

Um projeto de desenvolvimento em Symbian é composto por vários arquivos, além dos arquivos com o código fonte. Os principais são bld.inf e .mmp. Eles são usados para guiar a compilação gerando arquivos específicos para o funcionamento do aplicativo. Existem outros arquivos envolvidos com interface gráfica, os quais serão explicados em um próximo tutorial.



3. Estrutura do Aplicativo

O arquivo bld.inf é um descritor de componentes. Ele indica para o ambiente de desenvolvimento como criar o script de compilação ( por exemplo , quais as especifações de projeto devem ser usadas parar criar os arquivos na construção da aplicação desejada). Este arquivo é um arquivo de texto comum que pode ser construído com qualquer editor de texto não formatado. Para ver um exemplo de um arquivo bld.inf, clique aqui.

O arquivo de especificações de projeto (.mmp) define as propriedades dos componentes do projeto de uma forma independente (Ex: helloworld.mmp) . Junto com o bld.inf, ele é usado pelo ambiente de desenvolvimento para criar o script de compilação da aplicação. Para ver o conteúdo de um arquivo .mmp, clique aqui .

O UID também é um item importante a ser explicado nesse tutorial e é amplamente utilizado nos aplicativos Symbian C++. O Unique Identifier Number (UID) é um identificador global de 32 bits e funciona da mesma forma que a extensão de um arquivo Windows, que é usada para definir o tipo do arquivo. Ou seja, todo arquivo criado por uma aplicação tem o UID da aplicação associada ao arquivo, permitindo que o sistema operacional relacione o arquivo à aplicação que o gerou. O UID possui três componentes: UID1, UID2 e UID3. O UID1 é definido pelo tipo de aplicação do campo TARGETTYPE do arquivo .mmp do projeto. O UID2 define um subgrupo para tipos de arquivos que compartilham o mesmo UID1. O UID3 serve para distinguir cada aplicação, e este é usado pelo sistema para associar arquivos a aplicativos. O Desenvolvedor deve pedir para a própria Symbian o seu UID3, de modo que 2 aplicativos diferentes não compartilhem o mesmo UID3. Na fase de testes, entretanto, podem ser usados algums dentre estes UID3 que a Symbian alocou para esse propósito: 0x1000000 - 0x0fffffff.


4. Construindo um aplicativo

É importante relembrar que os aplicativos Symbian são nativas para os dispositivos aos quais se destinam. Portanto, a construção final do executável deve ser compatível com o assembly do processador do aparelho, pois diferente de uma aplicação Java, o emulador não consegue rodar o arquivo construído para o aparelho celular uma vez que a arquitetura do computador (X86) é diferente da arquitetura dos aparelhos Symbian. Logo, se a plataforma alvo desejada for o emulador do PC, então a compilação deve ser feita para o tipo WINS (Windows Single Process). Se a plataforma alvo desejada for o dispositivo real, a compilação deve ser feita para o tipo ARMI. Durante o desenvolvimento usam-se os dois tipos - um para testar a aplicação no PC e outro para testar no dispositivo real.
Além da plataforma alvo, existem mais dois tipos de construção possíveis: a compilação do tipo "Debug" (undeb) e a compilação do tipo "Release" (urel). A compilação para debug habilita uma série de funcionalidades (escritas em forma de macros específicas) como assertivas e checagem de balanço de heap. Essas funcionalidades são desabilitadas no tipo "release" , visto que já no lançamento do aplicativo o mesmo deve estar totalmente testado e não precisa mais delas.

O ponto de partida de um aplicação é através da chamada da função E32Main(), responsável por iniciar a aplicação e aloca algumas variáveis e classes. Por padrão, a declaração do E32Main é formadaa por GLDEF_C TInt E32Main() { ... } . Onde GLDEF_C indica que ela é uma função global, o TInt é o tipo de retorno da funçã0 (nesse exemplo retornando um inteiro) e a assinatura da função formada pelo nome E32Main.

Uma importante convenção na codificação de aplicativos Symbian é o uso da letra L no fim do nome de algumas funções (Exemplo: MainL() ou ConsoleMainL()). Esse formato permite identificar as funções que podem falhar, e que elas não gerenciam essa falha internamente (leave). Portanto, essa convenção de colocar um L no final é muito importante.

Alguns outros arquivos importantes que fazem parte da aplicação é o arquivo .pkg, que é um arquivo de diretivas para criar o pacote de instalação .sis. Esse arquivo .sis é levado ao aparelho onde ele é instalado para execução nos dipositivos reais.


5. Gerenciamento de Erros

Uma ferramenta que auxilia os programadores a liberar os recursos alocados é a checagem de balanço na heap. Algumas macros específicas como _UHEAP_MARK e UHEAP_MARKEND podem utilizadas em qualquer parte do seu programa, inclusive criando aninhamentos.
Cada objeto criado com uma função new() ( ou uma de suas variantes) deve ser destruído com um comando delete. A macro U_HEAP_MARKEND verifica se a heap está balanceada. Se a heap não estiver o mesmo número de células alocadas que ela tinha quando _UHEAP_MARK foi chamado, a aplicação entra em pânico. Uma aplicação entra em pânico quando um erro ocorre durante o tempo de execução do aplicativo, fazendo com que interrompa a execução tão logo que este erro seja detectado e mostrando na tela uma informação que pode ser útil para encontrar esse erro(debug).
Além da forma usual de entrar em pânico, o desenvolvedor pode forçar o seu programa a entrar, utilizando a função User:: Panic(). Essa função recebe dois parâmetros- uma string com no máximo 16 caracteres que será mostrada como mensagem na tela e um código de pânico. Na compilação debug para o emulador, a função de pânico da kernel unclui uma macro DEBUGGER() que pode ser usada como auxílio para procurar o erro. Entretantom, na versão final para o hardware real a mensagem é simplesmente "Program Closed" (Programa Terminado), citando o nome do processo, a categoria e o número do erro identificado.
A prática muito utilizada para lidar com pânicos é o uso de macros de assert. Elas permitem verificar quando expressão é executada se a condição não é verdadeira (_ASSERT_DEBUG e _ASSERT_ALWAYS).



6. Conclusão


Nessa primeira parte do artigo, foram explicados algumas estruturas e convenções no desenvolvimento de aplicativos para plataforma Symbian usando a linguagem Symbian C++. Na próxima parte desse artigo, irei explicar outros componentes e ir mais a fundo na estrutura dos arquivos que definem uma aplicação Symbian.





7. Referências

C++ Developers Library 1.1 (http://www.forum.nokia.com/document/Cpp_Developers_Library)



0 comentários:

top