CMF: um framework multi-plataforma para desenvolvimento de aplicações para dispositivos móveis

Texto

(1)Universidade Federal de Pernambuco Centro de Inform atica. P os-Graduac~ao em Ciência da Computaca~o. CMF: um framework multi-plataforma para desenvolvimento de aplicaco~es para dispositivos m oveis Dissertaca~o de Mestrado por Tiago Guedes Ferreira Barros. Recife 24 de Agosto de 2007.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMATICA. TIAGO GUEDES FERREIRA BARROS. CMF: um framework multi-plataforma para desenvolvimento de aplicaco~es para dispositivos m oveis. Este trabalho foi apresentado a Pos-Graduaca~o em Ciência da Computaca~o do Centro de Informatica da Universidade Federal de Pernambuco como requisito parcial para a obtenc~ao do grau de Mestre em Ciência da Computaca~o. ORIENTADOR: Prof. Dr. Andre Lus de Medeiros Santos CO-ORIENTADOR: Prof. Dr. Geber Lisboa Ramalho. Recife, 24 de Agosto de 2007.

(3) Barros, Tiago Guedes Ferreira CMF: um framework multi-plataforma para desenvolvimento de aplicações para dispositivos móveis / Tiago Guedes Ferreira Barros. – Recife : O Autor, 2007. viii, 92 folhas : il., fig., tab. Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn. Ciência da computação, 2007. Inclui bibliografia. 1. Engenharia de software. 2. Aplicações para celulares. 3. Frameworks de aplicações. 4. Linux. 5. Brew. I. Título. 005.1. CDD (22.ed.). MEI2008-13.

(4) Dissertarca~o de Mestrado apresentada por Tiago Guedes Ferreira Barros a Pos-Graduac~ao em Ciência da Computac~ao do Centro de Informatica da Universidade Federal de Pernambuco, sob o ttulo \CMF: Um Framework Multi-plataforma para Desenvolvimento de Aplica co ~es para Dispositivos M oveis", orientada pelo Prof. Andr e Lu s de Medeiros Santos e aprovada pela Banca Examinadora formada pelos professores:. Visto e permitida a impress~ao. Recife, 24 de agosto de 2007..

(5) AGRADECIMENTOS Que a forca do medo que tenho, n~ao me impeca de ver o que anseio. Que a arte nos aponte uma resposta, mesmo que ela n~ao saiba, E que ninguem a tente complicar, porque e preciso simplicidade para fazê-la orescer... Porque metade de mim e a criac~ao, e na outra habita o criador. fadaptado de Metade, de Oswaldo Montenegro.g |-. Agradeco a Deus e aos meus pais, pela vida, e dedico este trabalho a eles. Gostaria de registrar meus agradecimentos como um reconhecimento sincero da dedicaca~o das muitas pessoas que, direta ou indiretamente, contriburam para a realizaca~o deste trabalho. Agradeco a minha famlia, pelo apoio, compreens~ao e incentivo, n~ao so durante o perodo da pos-graduaca~o, mas em todos os momentos importantes de minha vida. Agradeco a minha noiva, Carine, pessoa maravilhosa, por todo carinho, compreens~ao e ajuda durante o decorrer do meu curso. Agradeco tambem aos meus orientadores e amigos Andre Santos e Geber Ramalho e a todos os Mestres que contriburam para a minha formac~ao acadêmica, pessoal e pro

(6) ssional. Um agradecimento especial aos demais professores componentes da banca, Sergio Cavalcante e Sergio Soares, pela paciência e por todas as contribuic~oes dadas a este trabalho. N~ao poderia deixar de agradecer aos amigos que contriburam efetivamente no desenvolvimento desta dissertac~ao: Mauro Silva, Angelo Ribeiro, Gustavo Eliano, Tarciana Mello e Nara Lyra, apoiando-me e incentivando-me sempre. Agradeco tambem aos amigos Pedro Lages, Edilson Mendes, Eduardo Peixoto, Saulo Dourado, Karina Limongi, Eduardo Jose e Ricardo Couto, por sua efetiva participaca~o na construc~ao do Gluon, ferramenta desenvolvida e utilizada neste trabalho. Agradeco a Chico Buarque, Vincius de Moraes, Tom Jobim, Toquinho e Oswaldo Montenegro, compositores das musicas que escutei e que me inspiraram durante toda a escrita desta dissertac~ao. Por

(7) m agradeco a todos os meus amigos, que contriburam de todas as formas para a realizac~ao deste trabalho.. i.

(8) RESUMO Com o crescimento da tecnologia de telefonia celular, estes dispositivos passaram cada vez mais a focar seus objetivos em processamento e transmiss~ao de dados. Devido ao seu grande poder de conectividade e a sua mobilidade, os celulares tambem se tornaram uma potencial plataforma para o desenvolvimento de aplicac~oes. Desta forma, os fabricantes de aparelhos passaram a disponibilizar plataformas de desenvolvimento para que terceiros pudessem desenvolver aplicaco~es para os seus celulares. A primeira iniciativa neste sentido foi a inclus~ao de uma maquina virtual Java nos telefones TDMA e GSM; e um ambiente de execuc~ao de aplicac~oes chamado BREW, para CDMA. Com a evoluca~o do hardware dos dispositivos, comecou-se a adotar sistemas operacionais abertos como: Symbian; Windows Mobile; e Embedded linux. Estes sistemas operacionais tambem permitem o desenvolvimento de aplicac~oes por terceiros. Assim, percebe-se que n~ao existe uma plataforma padr~ao para desenvolvimento de aplicaco~es para dispositivos moveis. Para que uma aplicaca~o possa ser instalada no maior numero de dispositivos possvel, esta deve ser portada entre as diferentes plataformas de desenvolvimento. Alem disto, todas estas plataformas de desenvolvimento s~ao dirigidas a eventos. No entanto, elas n~ao oferecem uma arquitetura que facilite o desenvolvimento de aplicac~oes desta forma. O objetivo deste trabalho e especi

(9) car e implementar um framework de aplicac~oes para dispositivos moveis que minimize o esforco de porting de aplicaco~es entre as plataformas. Deve ser disponibilizada tambem uma arquitetura que auxilie o desenvolvimento de aplicac~oes dirigidas a eventos. Alem disto, visa-se propor uma soluca~o para um ambiente de desenvolvimento multi-plataforma que seja integrado ao Framework proposto e auxilie na interoperabilidade do desenvolvimento em varias plataformas diferentes. Este objetivo foi alcancado atraves da implementac~ao do CMF - C.E.S.A.R Mobile Framework - framework multi-plataforma de aplicaco~es para dispositivos moveis; e do Gluon, ambiente de desenvolvimento para estes dispositivos. O CMF auxilia o desenvolvimento de aplicac~oes dirigidas a eventos e permite que uma aplicaca~o que foi desenvolvida para uma determinada plataforma possa ser executada em outras plataformas, sem que seu codigo seja alterado. O Gluon possibilita um aumento de produtividade no desenvolvimento destas aplicac~oes, automatizando varias tarefas de con

(10) guraca~o de ambiente, compilaca~o e depuraca~o do codigo, permitindo que o desenvolvedor foque no desenvolvimento da aplicac~ao. Aplicaco~es para celulares, BREW, Embedded Linux, Frameworks de Aplicaco~es, Dispositivos Moveis, Ambientes de desenvolvimento, IDE, Eclipse, Padr~oes de Projeto, MVC. Palavras-chave:. ii.

(11) ABSTRACT With the growth of cell phone technology, these devices started focusing on data applications and data transmission, becoming platforms for software development. In parallel, device manufacturers started opening their platforms for third-party development. The

(12) rst initiative towards to this was to include a Java Virtual Machine into TDMA and GSM phones; and an execution environment called BREW for CDMA phones. With devices' hardware evolution, some operating systems were also developed for mobile devices, such as Symbian, Windows Mobile and Embedded Linux. These operating systems also allow third-party application development. Due to the number of platforms, there is no standard development platform for mobile devices. Application developers needs to port the applications among these platforms to reach a great number of supported devices. Another point to be considered is that all development platforms are event-driven but the platforms' architecture does not have good event handling support. According to these scenarios, the main goal of this work is to specify and implement an application framework for mobile devices that minimize the porting e ort among the platforms. This Framework shall also have an event-driven architecture to assist mobile applications development. It is also part of the goal, a proposal for an integrated development environment that uses the proposed framework and helps the platform interoperability. This goal was reached by implementation of CMF - C.E.S.A.R Mobile Framework, a multi-platform framework for developing mobile applications; and by the implementation of Gluon, an integrated development environment for mobile devices. CMF assists development of event-driven applications and enables the application execution on more than one platform without changing the application's code. Gluon leverages development productivity by automating environment con

(13) guration tasks and setup of compiling and debugging environments, making developer to focus on application development. Cellphone Applications, BREW, Embedded Linux, Application Frameworks, Mobile Devices, Integrated Decvelopment Environments (IDE), Eclipse, Design Patterns, MVC. Keywords:. iii.

(14) SUMARIO Captulo 1|Introduc~ao. 1. 1.1 Contexto . . . . . . . . . . . . . . . . . . . . . 1.2 Motivac~ao . . . . . . . . . . . . . . . . . . . . 1.3 Trabalhos Relacionados . . . . . . . . . . . . . 1.3.1 Interface com Usuario Abstrata (AUI) 1.3.2 Maquinas Virtuais . . . . . . . . . . . 1.4 Contribuico~es . . . . . . . . . . . . . . . . . . 1.5 Organizaca~o . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. Captulo 2|Plataformas de Desenvolvimento para Dispositivos Moveis 2.1 2.2 2.3 2.4 2.5 2.6. Introduca~o . . . . . . . . . J2ME . . . . . . . . . . . BREW . . . . . . . . . . . Symbian OS . . . . . . . . Windows Mobile . . . . . Embedded Linux . . . . . 2.6.1 Qt . . . . . . . . . 2.6.2 GTK . . . . . . . . 2.7 Comparando plataformas .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 7 . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. Captulo 3|CMF - Metodologia, Requisitos e Arquitetura 3.1 Introduca~o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 [RF001] - Ponto de entrada da aplicac~ao . . . . . . . . . . . . 3.3.2 [RF002] - Acesso a tela . . . . . . . . . . . . . . . . . . . . . . 3.3.3 [RF003] - Gerenciamento de telas . . . . . . . . . . . . . . . . 3.3.4 [RF004] - Gerenciamento de telas - Classe base . . . . . . . . 3.3.5 [RF005] - Gerenciamento de telas - Traduca~o de eventos . . . 3.3.6 [RF006] - Maquina de estados . . . . . . . . . . . . . . . . . . 3.3.7 [RF007] - Maquina de estados - Classe base para estados . . . 3.3.8 [RF008] - Maquina de estados - Despacho de eventos . . . . . 3.3.9 [RF009] - Maquina de estados - Comunicac~ao entre os servicos 3.3.10 [RF010] - Acesso as informaco~es do sistema . . . . . . . . . . 3.3.11 [RF011] - Servicos . . . . . . . . . . . . . . . . . . . . . . . . . iv. 1 2 3 3 4 5 6 7 7 10 15 17 18 19 22 23 26. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. 26 26 31 31 31 32 32 32 32 32 32 32 32 33.

(15) rio suma. v. 3.3.12 [RF012] - Recursos . . . . . . . . . . . . . . . . . . . . . . 3.4 Requisitos N~ao-Funcionais . . . . . . . . . . . . . . . . . . . . . . 3.4.1 [RNF001] - Portabilidade . . . . . . . . . . . . . . . . . . . 3.4.2 [RNF002] - Desempenho . . . . . . . . . . . . . . . . . . . 3.4.3 [RNF003] - Escopo do Framework . . . . . . . . . . . . . 3.4.4 [RNF004] - Extensibilidade . . . . . . . . . . . . . . . . . . 3.4.5 [RNF005] - Internacionalizac~ao . . . . . . . . . . . . . . . 3.5 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Dinâmica . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . 3.6.1 Ferramentas de Desenvolvimento em BREW . . . . . . . . 3.6.2 Ferramentas de Desenvolvimento em Linux . . . . . . . . . 3.6.3 Proposta de Integrac~ao dos Ambientes de Desenvolvimento. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. Captulo 4|CMF - Implementac~ao 4.1 Introduca~o . . . . . . . . . . . . . . . . 4.2 Implementaca~o do CMF . . . . . . . . 4.2.1 Tipos de dados . . . . . . . . . 4.2.2 Ponto de Entrada da Aplicac~ao 4.2.2.1 BREW . . . . . . . . 4.2.2.2 Embedded Linux . . . 4.2.3 Classe de Aplicac~ao . . . . . . . 4.2.4 Gerenciador de Objetos . . . . 4.2.5 Maquina de Estados . . . . . . 4.2.6 Estados da Aplicac~ao . . . . . . 4.2.7 Dispositivo Gra

(16) co . . . . . . . 4.2.7.1 BREW . . . . . . . . 4.2.7.2 Embedded Linux . . . 4.2.8 Gerenciador de Telas . . . . . . 4.2.9 Telas da Aplicaca~o . . . . . . . 4.2.10 Chamadas ao Sistema . . . . . 4.2.11 Servicos do sistema . . . . . . . 4.3 Testes de conformidade . . . . . . . . . 4.3.1 Estados do CCT . . . . . . . . 4.3.2 Telas . . . . . . . . . . . . . . .. 33 33 33 33 33 34 34 34 35 37 40 40 41 41 43. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .. Captulo 5|Gluon - Um Ambiente Integrado de Desenvolvimento 5.1 Introduca~o . . . . . . . . . . . . . . . . . . . . . . . . 5.2 A plataforma Eclipse . . . . . . . . . . . . . . . . . . 5.2.1 A arquitetura de plug-ins do Eclipse . . . . . 5.2.2 CDT - Eclipse C/C++ Development Tooling . 5.3 Gluon . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 43 43 44 44 44 46 47 48 50 51 54 56 57 57 58 60 61 62 64 66 68. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 68 68 70 71 72.

(17) rio suma. vi. 5.4 Componentes do ambiente Gluon . . . . . . . . . . . 5.5 Implementaca~o do Gluon . . . . . . . . . . . . . . . . 5.5.1 Integrac~ao do Gluon com ferramentas externas 5.5.1.1 Compilac~ao . . . . . . . . . . . . . . 5.5.1.2 Depurac~ao . . . . . . . . . . . . . . . 5.5.1.3 Simulac~ao . . . . . . . . . . . . . . . 5.5.1.4 Integraca~o com SDKs . . . . . . . . 5.5.2 Screenshots . . . . . . . . . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. Captulo 6|Estudo de Caso 6.1 6.2 6.3 6.4. Introduca~o . . . . . . . . . . . . . . . . . . . . . Metodologia do Estudo de Caso . . . . . . . . . Escopo do Estudo de Caso . . . . . . . . . . . . Apresentac~ao dos Resultados . . . . . . . . . . . 6.4.1 Quantidade de linhas de codigo(KLOC) . 6.4.2 Esforco . . . . . . . . . . . . . . . . . . . 6.4.3 Tamanho . . . . . . . . . . . . . . . . . 6.4.4 Desempenho . . . . . . . . . . . . . . . . 6.5 Consideraco~es Finais . . . . . . . . . . . . . . .. 73 74 75 75 75 76 76 76 78. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. Captulo 7|Conclus~ao e Trabalhos Futuros 7.1 Contribuico~es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Problemas Encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 78 78 79 80 80 82 83 84 86 87 87 88 89.

(18) LISTA DE FIGURAS 1.1 Arquitetura Java para dispositivos moveis . . . . . . . . . . . . . . . . . 1.2 .NET Compact Framework . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 2.2 2.3 2.4 2.5. Per

(19) s, con

(20) guraco~es e API's de J2ME . . . Modelo de negocios de BREW . . . . . . . Desenvolvimento de uma aplicac~ao BREW Symbian Application Framework . . . . . Diagrama de classes de Qt . . . . . . . . .. . . . . .. . . . . .. . . . . .. 8 10 12 16 21. 3.1 3.2 3.3 3.4 3.5. Padr~ao MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de classes UML do CMF . . . . . . . . . . . . . . . . . . . Construca~o de uma aplicac~ao no CMF . . . . . . . . . . . . . . . . . Inicializaca~o de uma aplicac~ao usando o CMF . . . . . . . . . . . . . Dinâmica do tratamento de eventos de uma aplicac~ao usando o CMF. . . . . .. . . . . .. 34 36 38 39 40. 4.1 Estrutura do repositorio do codigo do CMF . . . . . . . . . . . . . . . . 4.2 Diagrama de estados da aplicaca~o CCT . . . . . . . . . . . . . . . . . . .. 44 65. 5.1 5.2 5.3 5.4 5.5. Arquitetura da plataforma Eclipse . . . . . Arquitetura dos plug-ins do Eclipse . . . . Relacionamento entre o Gluon e o CDT . . Tela inicial do Gluon . . . . . . . . . . . . Gluon: depuraca~o de codigo no simulador .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 69 71 74 77 77. 6.1 6.2 6.3 6.4 6.5. Resultado das medidas de linhas de codigo (KLOC). . Resultado das medidas de esforco. . . . . . . . . . . . Resultado das medidas de tamanho da aplicac~ao. . . Resultado das medidas de tempo de execuc~ao. . . . . Resultado da analise das metricas para o CMF . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 81 83 84 85 86. vii. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 4 5.

(21) LISTA DE TABELAS 2.1 Comparaca~o entre as plataformas . . . . . . . . . . . . . . . . . . . . . .. 25. 3.1 Criterios para escolha das plataformas . . . . . . . . . . . . . . . . . . . 3.2 Pontuac~ao das plataformas de acordo com os criterios . . . . . . . . . . .. 29 30. 5.1 Estimativa de implementaca~o do Gluon . . . . . . . . . . . . . . . . . . . 5.2 Comparaca~o das funcionalidades do Gluon em relac~ao ao ambiente de desenvolvimento atual para BREW . . . . . . . . . . . . . . . . . . . . . .. 75 76. 6.1 6.2 6.3 6.4 6.5 6.6. 78 81 82 84 85 86. Ordem de implementac~ao das aplicac~oes do estudo de caso. Resultado das medidas de linhas de codigo (KLOC). . . . . Resultado das medidas de esforco. . . . . . . . . . . . . . . Resultado das medidas de tamanho da aplicac~ao. . . . . . Resultado das medidas de desempenho. . . . . . . . . . . . Resultado das metricas calculadas para o CMF. . . . . . .. viii. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . ..

(22) CAPITULO 1. ~ INTRODUC AO Neste captulo sera apresentada uma introduc~ao ao desenvolvimento de aplicaco~es para dispositivos moveis. Tambem ser~ao apresentadas as diversas plataformas de desenvolvimento existentes, bem como o funcionamento do processo de porting de aplicaco~es entre dispositivos e entre diferentes plataformas. Finalmente, e feita uma breve apresentac~ao da proposta de trabalho, abordando o escopo e sua contribuic~ao. |-. 1.1 CONTEXTO Com o crescimento da tecnologia de telefonia celular, estes dispositivos, que antes eram centrados na transmiss~ao de voz, passaram cada vez mais a focar seus objetivos em processamento e transmiss~ao de dados. Tirar fotos, receber e-mails ou navegar na web est~ao se tornando atividades comuns aos celulares atuais. Devido ao seu grande poder de conectividade e a sua mobilidade, os celulares tambem se tornaram uma potencial plataforma para o desenvolvimento de aplicac~oes. Desenvolver aplicac~oes para estes dispositivos e bastante diferente de desenvolver aplicaco~es para PC's. Devido a sua arquitetura fechada e baixo poder de processamento, principalmente nos primeiros celulares, cada fabricante de dispositivos terminou por desenvolver seu prorio hardware e, consequentemente, seu proprio sistema operacional. Estes sistemas operacionais, alem de todo o software e o hardware do dispositivo como um todo, s~ao as informaco~es mais importantes do telefone para os fabricantes. Devido a isso, os fabricantes n~ao permitem que terceiros conhecam seus sistemas proprietarios a

(23) m de que desenvolvam suas proprias aplicac~oes. Ent~ao, neste incio, os proprios fabricantes passaram a desenvolver aplicaco~es acessorias, principalmente jogos, para adicionar um diferencial aos seus dispositivos. No entanto, os fabricantes n~ao conseguiam desenvolver aplicac~oes na escala necessaria, o que terminou por fazê-los procurar formas de disponibilizar o desenvolvimento de aplicaco~es para outras empresas. A primeira iniciativa neste sentido foi a inclus~ao da maquina virtual java nos dispositivos TDMA[BKNR03]. Isto permitiu o desenvolvimento de aplicaco~es em J2ME[SUN], subconjunto da linguagem java, para dispositivos com limitaca~o de processamento e memoria. O aparecimento das tecnologias de comunicaca~o digital GSM e CDMA abriram novas possibilidades para o desenvolvimento de aplicac~oes. O CDMA, desenvolvido pela Qualcomm[QUA], ja previa o desenvolvimento de aplicaco~es no seu incio, incorporando o ambiente de desenvolvimento BREW aos chipsets dos telefones. Em GSM, os fabricantes passaram a experimentar e utilizar sistemas operacionais abertos, como Windows 1.

(24) ~o 1.2 motivaca. 2. Mobile[MICa], Symbian[SYM] e Embedded Linux[HOL02], o que, somado a J2ME, aumentou bastante a quantidade de alternativas para o desenvolvimento de aplicac~oes. Atualmente temos diversas plataformas para o desenvolvimento de aplicac~oes para celulares. Estas plataformas s~ao disponibilizadas pelos fabricantes de dispositivos para que outras empresas desenvolvam aplicac~oes para os seus aparelhos, aumentando assim, o valor percebido pelos clientes. Portanto, hoje existem diversas empresas especializadas no desenvolvimento de aplicaco~es para celulares e o maior problema enfrentado por elas e fazer com que suas aplicaco~es funcionem no maior numero de aparelhos possvel, ou seja, elas precisam portar estas aplicac~oes para os dispositivos desejados. Veremos com mais detalhes os problemas inerentes ao porting de aplicac~oes na proxima seca~o.. ~ 1.2 MOTIVAC AO Do ponto de vista da interface com o usuario, os celulares possuem geralmente con

(25) guraco~es de hardware muito parecidas. Todos possuem tela, um teclado numerico, softkeys, alto-falantes e microfone, conex~ao de rede, e alguns possuem câmera e conex~ao bluetooth. No entanto, como visto na Sec~ao 1.1, estes dispositivos possuem diferentes plataformas de desenvolvimento. Abaixo segue uma descric~ao das tecnologias mais utilizadas:. . J2ME - Java 2 Micro Edition [SUN]: possui uma boa aceitaca~o por parte dos desenvolvedores, pois Java e uma linguagem de facil programac~ao e possui uma portabilidade satisfatoria. Como pontos negativos, temos o baixo desempenho e algumas limitac~oes na API.. . BREW - Binary Runtime Environment for Wireless [QUA]: desenvolvido pela Qualcomm, e um ambiente de execuca~o para telefones CDMA que permite rodar aplicaco~es em linguagem C. Possui a vantagem de rodar mais rapido do que Java e permite acesso a quase todos os elementos do hardware disponvel nos telefones CDMA.. . Symbian OS [SYM]: Symbian e um consorcio de empresas de telefonia para o desenvolvimento de um sistema operacional para celulares. O Symbian OS possui o conceito de \open standard operating system" (sistema operacional de padr~ao aberto) o que permitiu, pela primeira vez, que fossem desenvolvidas aplicac~oes para celulares assim como s~ao desenvolvidas para PC's.. . Embedded Linux [HOL02]: Vers~ao do SO Linux para sistemas embarcados. Tem o seu uso crescente principalmente em telefones celulares. O desenvolvimento de aplicaco~es e feito em C ou C++, utilizando-se vers~oes reduzidas de frameworks gra

(26) cos como QT e GTK.. . Windows Mobile [MICa]: Sistema operacional para celulares baseado no Windows. Constitui um sub-conjunto das funcionalidades do Windows, de forma que a programaca~o e o acesso aos recursos do hardware s~ao feitos da mesma maneira que.

(27) 1.3 trabalhos relacionados. 3. a programaca~o para desktops. Pode-se desenvolver em C++ ou para a plataforma .NET (C# ou VB .NET). Cada uma das tecnologias citadas possui uma forma de desenvolvimento diferente. A maioria delas e baseada em eventos, no entanto, n~ao disp~oem de uma estruturaca~o arquitetural adequada ao desenvolvimento de aplicac~oes baseadas em eventos e estados. Alem disto, apesar de J2ME estar presente em quase todos os aparelhos GSM (que representam 62% do mercado[INT06]), as aplicac~oes que necessitam de um maior controle ou acesso ao dispositivo n~ao s~ao escritas em J2ME, o que nos leva a concluir que ainda n~ao existe uma tecnologia completamente dominante no desenvolvimento de aplicaco~es para dispositivos moveis e portar aplicac~oes entre estas plataformas se faz necessario. O problema de porting de aplicaco~es e bastante potencializado no âmbito dos dispositivos moveis. Diversas empresas est~ao focando os seus esforcos no porting de aplicac~oes, tanto para aumentar a distribuica~o das suas aplicaco~es quanto para fazer desta atividade o seu principal negocio. Existem dois principais problemas a serem atacados quando estamos portando uma aplicaca~o: a customizac~ao da interface; e a diferenca entre as plataformas de desenvolvimento. A customizaca~o da interface consiste em adaptar a interface da aplicaca~o para diversos dispositivos. Esta adaptaca~o consiste basicamente em alteraco~es no tamanho da tela e layout das teclas, menus e opc~oes. Apesar de parecer simples, 30% do tempo de desenvolvimento e gasto na resoluca~o deste problema de porting. Existem diversos estudos e iniciativas como [CPS04] [PHA00] [PQ02] [EVP00] [EVP01] [MHP00] que tratam o problema de customizaca~o de interface. Portar uma aplicac~ao entre diferentes plataformas de desenvolvimento e uma atividade que requer mais esforco do que apenas customizar a sua interface. As diferencas de API, formas de acesso aos recursos do hardware, linguagens de programaca~o e interac~ao com o dispositvo s~ao apenas alguns dos problemas inerentes a esta tarefa.. 1.3 TRABALHOS RELACIONADOS Nesta sec~ao ser~ao abordados os princpios dos sistemas concebidos para funcionarem em diversas plataformas. A maioria das pesquisas aponta para abstraca~o da interface gra

(28) ca, atraves de uma linguagem descritiva, e para a migrac~ao das aplicaco~es sobre uma maquina virtual como as alternativas para desenvolvimento destes sistemas.. 1.3.1 Interface com Usuario Abstrata (AUI) Diversas pesquisas est~ao sendo feitas no sentido de desenvolver sistemas multiplataforma. A maioria destas pesquisas [MHP00] [EVP00] [EVP01] considera a abstraca~o da interface com o usuario como alternativa para o desenvolvimento de aplicaco~es. Alguns trabalhos [PHA00] [PQ02] visam a utilizac~ao de linguagens descritoras de interface baseadas em XML como UIML - User Interface Markup Language. Estas linguagens permitem abstrair e descrever os objetos comuns de uma interface com o usuario, de

(29) nindo objetos de interface canônicos sendo implementados nas diferentes plataformas..

(30) 1.3 trabalhos relacionados. 4. Desta forma, uma interface descrita em UIML pode ter sua implementaca~o em J2SE para desktops, e em J2ME para celulares, mapeando a descrica~o da interface nos controles de interface inerentes a cada plataforma. Seguindo esta mesma linha, algumas pesquisas [CPS04] visam transformar as interfaces para que se adaptem aos diferentes tamanhos de tela e formas de entrada de dados (teclado ou touch screen, por exemplo). Neste caso, n~ao existe uma linguagem de descrica~o de interface, mas sim uma API com um conjunto de controles abstratos sobre a qual a aplicaca~o e construda. Estes controles abstratos possuem correspondentes concretos em cada plataforma, que s~ao instanciados dinamicamente dependendo da plataforma que a aplicaca~o esta rodando. No entanto, abstrair e adaptar a interface e apenas uma parte do problema de portar uma aplicac~ao de uma plataforma para outra. Todas as pesquisas que apontam neste sentido consideram que as diferentes plataformas possuem uma mesma API ou forma de programaca~o, e a diferenca entre elas e apenas na dimens~ao da tela e forma de entrada de dados. Desta forma, estas abordagens n~ao resolvem o problema de porting quando o mesmo ocorre entre plataformas com API's e ate linguagens de programac~ao diferentes.. 1.3.2 Maquinas Virtuais Uma outra abordagem para o desenvolvimento de sistemas portaveis seria a utilizaca~o de maquinas virtuais. Uma maquina virtual e uma camada de software que abstrai o sistema operacional, provendo a aplicac~ao toda API necessaria. A maquina virtual tambem e responsavel por garantir a seguranca na execuca~o da aplicaca~o e por interpretar o codigo da aplicaca~o e executa-lo no sistema correspondente. As principais maquinas virtuais para dispositivos moveis s~ao:. . Maquina Virtual Java[SUN]: interpreta J2ME; .NET Compact Framework [MICa]: maquina virtual do Windows Mobile .NET.. A arquitetura Java para dispositivos moveis e dividida em 3 camadas sobre o sistema operacional: a maquina virtual propriamente dita (KVM); os per

(31) s; e as con

(32) guraco~es.. Figura 1.1.. Arquitetura Java para dispositivos moveis. A KVM - Kilobyte Virtual Machine - e a base da arquitetura, responsavel por interpretar e executar o codigo Java e abstrair o sistema operacional. Sobre a maquina virtual s~ao de

(33) nidas as con

(34) guraco~es, que s~ao um conjunto mnimo de classes que provêem as.

(35) ~ es 1.4 contribuico. 5. funcionalidades basicas para as categorias de dispositivos. Sobre a con

(36) guraca~o, s~ao de

(37) nidos os per

(38) s, API's de alto-nvel que disponibilizam um ambiente de execuc~ao completo e direcionado para os dispositivos alvo. O .NET Compact Framework possui duas partes principais: a Common Language Runtime (CLR) e a .NET Compact Framework Class Library. A CLR e responsavel por gerenciar, interpretar e executar o codigo das aplicac~oes, que e gerado em forma de bytecode (linguagem intermediaria). A .NET Compact Framework Class Library e um conjunto de API's para a construc~ao de aplicaco~es. Estas API's v~ao desde a criac~ao de janelas e controles gra

(39) cos ate gerenciamento de dados e Web Services. Uma das vantagens do .NET e a possibilidade de escrever codigo em varias linguagens de programaca~o.. Figura 1.2.. .NET Compact. Framework. Apesar de possuir boa portabilidade das aplicac~oes, devido a uma API comum aos dispositivos, as maquinas virtuais n~ao conseguem resolver o problema do desenvolvimento de aplicaco~es multi-plataforma completamente, pois a interface com o usuario ainda e dependente da interface do dispositivo. Alem disto, as maquinas virtuais possuem problema de desempenho, visto que o codigo das aplicaco~es e interpretado. A falta de acesso aos recursos mais espec

(40) cos do hardware tambem e outro problema, pois as API's implementadas s~ao apenas as API's comuns a todos os dispositivos.. ~ 1.4 CONTRIBUIC OES O objetivo deste trabalho e facilitar o desenvolvimento de aplicaco~es para dispositivos moveis, particularmente, telefones celulares, atraves da construc~ao do CMF - CESAR Mobile Framework - um framework multi-plataforma para o desenvolvimento de aplicac~oes para dispositivos moveis. Portanto, propusemos uma nova arquitetura para desenvolvimento de aplicaco~es que facilite este desenvolvimento provendo um suporte a maquina de estados e que seja dirigida a eventos, para padronizar a forma de comunicac~ao entre a aplicaca~o e o dispositivo. Assim, poderemos implementar este Framework em varias plataformas, possibilitando que as aplicaco~es sejam escritas da mesma forma e usando uma mesma API, independente da plataforma escolhida. Escolhemos a linguagem de programaca~o C++ para a implementaca~o do Framework, visto que e a linguagem comum entre a maioria das plataformas de desenvolvimento de.

(41) ~o 1.5 organizaca. 6. aplicaco~es para dispositivos moveis, com excec~ao de J2ME. Alem do desenvolvimento de um framework multi-plataforma, construimos tambem um ambiente integrado de desenvolvimento, baseado na plataforma Eclipse, para que possamos realmente ter um ganho de produtividade ao alternarmos o desenvolvimento entre as plataformas. Portanto, dois problemas foram alvo desta proposta:. . Facilitar o desenvolvimento de aplicac~oes atraves de um suporte a maquinas de estados e eventos, bem como atraves da utilizaca~o de um ambiente integrado de desenvolvimento para as plataformas alvo, visto que as outras IDE's n~ao oferecem um ambiente integrado para mais de uma plataforma;. . E tambem resolver o problema de porting de aplicaco~es entre diferentes plataformas, provendo uma API comum para o desenvolvimento e abstraindo as interfaces individuais de cada plataforma para a disponibilizaca~o de uma interface comum.. ~ 1.5 ORGANIZAC AO Este trabalho esta organizado como segue: O Captulo 2 apresenta as plataformas mais utilizadas para o desenvolvimento de aplicac~oes para dispositivos moveis, os conceitos existentes no desenvolvimento de aplicaco~es para estes dispositivos bem como uma comparaca~o entre as diversas plataformas. Os requisitos e a proposta de arquitetura do Framework implementado ser~ao apresentados no Captulo 3. O Captulo 4 apresenta os detalhes da implementaca~o do Framework, bem como as restric~oes de implementaca~o assumidas devido as diversas plataformas. A implementaca~o de uma ferramenta para desenvolvimento integrado de aplicaco~es sera apresentado no Capitulo 5. No Captulo 6 ser~ao apresentados estudos de caso nos quais foi utilizado o Framework desenvolvido. Finalmente, o Captulo 7 conclui o trabalho e sugere possveis caminhos a serem abordados para trabalhos futuros..

(42) CAPITULO 2. PLATAFORMAS DE DESENVOLVIMENTO PARA DISPOSITIVOS MOVEIS Neste captulo ser~ao apresentadas as principais plataformas de desenvolvimento de aplicaco~es para dispositivos moveis. Para cada plataforma, sera apresentado um breve historico, quais as linguagens de programac~ao disponveis e como e feito o desenvolvimento de aplicaco~es. Finalmente, sera feita uma analise comparativa entre as plataformas abordadas. |-. ~ 2.1 INTRODUC AO Como pudemos perceber no Captulo 1, foram citadas maquinas virtuais, ambientes de execuca~o e sistemas operacionais como alternativas para o desenvolvimento de aplicac~oes para celulares. Estas alternativas ser~ao chamadas de \plataformas de desenvolvimento" daqui por diante. Uma plataforma de desenvolvimento e um conjunto de: linguagem de programaca~o; API; ambiente de desenvolvimento; e ambiente de execuc~ao. Levando em conta estas caractersticas, e possvel fazer uma comparaca~o entre estas plataformas, mesmo que elas sejam sistemas operacionais, maquinas virtuais ou ambientes de execuca~o, que possuem naturezas completamente diferentes. Ent~ao, neste captulo, ser~ao descritas cada uma das principais plataformas de desenvolvimento para dispositivos moveis, abordando as caractersticas citadas acima e realizando uma comparaca~o entre estas plataformas.. 2.2 J2ME A primeira iniciativa no sentido de desenvolvimento de aplicaco~es para celulares foi Java 2 Micro Edition - J2ME, uma vers~ao do ambiente JAVA para dispositivos com limitaco~es de memoria e processamento, como celulares, PDAs e sistemas embarcados em geral. J2ME esta presente em quase todos os telefones GSM, que, de acordo com a Wireless Intelligence [INT06], possua cerca de 62% do mercado de telefones moveis em Junho de 2006. Para rodar nestes dispositivos, a linguagem precisaria ser bastante simpli

(43) cada e otimizada, removendo os componentes que n~ao est~ao presentes ou n~ao s~ao utilizados. Sua arquitetura foi dividia em três camadas: a maquina virtual propriamente dita; os per

(44) s; e as con

(45) gurac~oes, como visto na Seca~o 1.3.2. 7.

(46) 8. 2.2 j2me. A maquina virtual de J2ME e a KVM - Kilobyte Virtual Machine. Ela e a base da arquitetura, devendo ser implementada para cada dispositivo. Na KVM e criada uma camada de software que abstrai o sistema operacional e garante a portabilidade. Sobre a maquina virtual s~ao de

(47) nidas as con

(48) guraco~es, que s~ao um conjunto mnimo de classes que provêem as funcionalidades basicas para as categorias de dispositivos. Atualmente existem 2 con

(49) guraco~es:. . CLDC - Connected Limited Device Con

(50) guration, projetada para dispositivos com conex~oes de rede intermitentes, processadores mais lentos e memoria limitada, como os telefones celulares e alguns PDA's;. . CDC - Connected Device Con

(51) guration, con

(52) gurac~ao para dispositivos com mais memoria e poder de processamento, e uma conex~ao com uma maior largura de banda. Um exemplo s~ao os set-top boxes, sistemas de telemetria de veculos e PDA's mais poderosos.. Sobre a con

(53) gurac~ao s~ao de

(54) nidos os per

(55) s, API's de alto-nvel que disponibilizam um ambiente de execuca~o completo e direcionado para os dispositivos alvo1 . O per

(56) l utilizado para telefones celulares e o MIDP - Mobile Information Device Pro

(57) le. Este per

(58) l provê as principais funcionalidades requeridas pelas aplicac~oes para celulares, como interface com o usuario, conectividade, manipulac~ao de arquivos e gerenciamento da aplicaca~o em geral.. Figura 2.1.. Per

(59) s, con

(60) guraco~es e API's de J2ME. Atualmente, os telefones celulares implementam a con

(61) gurac~ao CLDC 1.1 e o per

(62) l MIDP 2.0. Este per

(63) l possui as seguintes funcionalidades implementadas:. . Interface com o usuario: a partir do pacote microedition.lcdui e possvel ter acesso a interface com o usuario, no caso a tela e o teclado do dispositivo. Este acesso pode ser feito tanto em alto nvel quanto em baixo nvel. O acesso a tela em. 1 Entende-se. por dispositivos alvo os dispositivos que implementam o determinado per

(64) l..

(65) 2.2 j2me. 9. alto nvel constitui no uso de controles de telas prontos, como bot~oes, combo-boxes e caixas de texto. Ja o acesso em baixo nvel signi

(66) ca o desenho direto de primitivas gra

(67) cas;. . Armazenamento persistente: atraves do microedition.rms e possvel armazenar registros da aplicaca~o de forma persistente;. . Rede: e possvel criar conex~oes via sockets ou com protocolos de mais alto nvel como HTTP atraves do pacote microedition.io;. . Media: J2ME possui uma API espec

(68) ca para tocar e controlar media de diversos formatos. Esta API esta disponvel no pacote microedition.media;. . Jogos: foi incorporado na vers~ao 2.0 do MIDP um pacote espec

(69) co para o desenvolvimento de jogos chamado o microedition.lcdui.game. Este pacote possui classes responsaveis por tratar diversos problemas encontrados no desenvolvimento de aplicac~oes deste tipo. Alem das funcionalidades padr~ao includas no MIDP 2.0, varios fabricantes incluem API's espec

(70) cas de acordo com a disponibilidade do hardware no dispositivo. Estas funcionalidades s~ao baseadas nas JSR's (Java Speci

(71) cation Request ) aprovadas pela SUN. Desta forma, o conjunto

(72) nal de API's suportadas por um dispositivo varia bastante, dependendo da quantidade de JSR's implementadas. Esta caracterstica prejudica um pouco a portabilidade das aplicaco~es em J2ME, pois a utilizac~ao de uma JSR pode implicar na di

(73) culdade de portar a aplicaca~o para um dispositivo que n~ao possua esta JSR implementada. O desenvolvimento de aplicaco~es em J2ME inicia-se com um WTK - Wireless Toolkit - que e um conjunto de ferramentas para o desenvolvimento nesta plataforma. Um WTK e composto pela implementaca~o da con

(74) guraca~o e do per

(75) l escolhido, bem como documentaca~o e ferramentas para simulaca~o de aplicaco~es. Este toolkit integra-se com o JDK - Java Development Kit - kit de desenvolvimento Java, que possui compiladores, maquina virtual para PC e todas as ferramentas necessarias para o desenvolvimento Java. O WTK padr~ao para desenvolvimento e o da SUN [WTK]. No entanto, cada fabricante de dispositivos termina por disponibilizar seu proprio WTK. Cada WTK proprietario e customizado para os telefones do fabricante espec

(76) co, com as API's extras que os mesmos provêem e documentaca~o adicional, alem de ferramentas para comunicaca~o e depuraca~o no dispositivo. Alem do WTK, o desenvolvedor tambem pode utilizar IDE's para facilitar o desenvolvimento. A IDE mais utilizada para desenvolvimento em J2ME e o Eclipse [Ecla] com o plug-in EclipseME [Eclb]. Esta IDE integra os diversos WTK's com o ambiente desenvolvimento Eclipse, uni

(77) cando todas as ferramentas e facilitando o desenvolvimento. As aplicac~oes em J2ME consistem em dois arquivos: JAD - Java Application Descriptor Arquivo que descreve a aplicaca~o java, contendo informac~oes como: quais as classes que v~ao ser executadas; nome e cone da aplicac~ao; permiss~oes que a aplicaca~o possui; tamanho em bytes; vers~oes de con

(78) guraca~o; e per

(79) l utilizados na aplicac~ao..

(80) 10. 2.3 brew. . JAR - Java Archive Arquivo compactado que possui todas as classes da aplicaca~o ja compiladas para bytecode, os arquivos de recursos (imagens, por exemplo) e um arquivo Manifest que descreve o conteudo do JAR. Estes arquivos devem ser instalados no telefone para que a aplicaca~o esteja disponvel para a execuc~ao.. 2.3 BREW Seguindo o caminho de Java, a Qualcomm desenvolveu o BREW[QUA] - Binary Runtime Environment for Wireless (Ambiente de Execuc~ao Binario para Dispositivos Moveis). Neste ambiente, as aplicaco~es s~ao desenvolvidas em linguagem C ou C++, compiladas, e rodam em um chip separado do processador principal do dispositivo, o que possibilita uma performance melhor em relac~ao a J2ME. Alem de um ambiente de execuca~o para rodar aplicac~oes, BREW possui um modelo de negocios muito bem estruturado, o qual esta representado na Figura 2.2[NAS03].. Figura 2.2.. Modelo de negocios de BREW. Este modelo de negocios esta baseado em um sistema de distribuica~o de aplicaco~es, o BDS - BREW Distribution System, e consiste nos seguintes passos: i) O desenvolvedor cria suas aplicaco~es e passa por um processo de certi

(81) caca~o, o True BREW Test, que garante que a aplicaca~o esta dentro dos padr~oes de BREW e n~ao vai dani

(82) car o telefone nem prejudicar o usuario; ii) Uma vez certi

(83) cada, a aplicaca~o passa a fazer parte do Virtual Maketplace, especie de \vitrine" na qual as operadoras buscam por aplicaco~es;.

(84) 2.3 brew. 11. iii) Ao ser escolhida pela operadora, a aplicaca~o passa a fazer parte do seu catalogo de aplicaco~es, o qual

(85) ca disponvel para o usuario, atraves de um menu no aparelho; iv) Quando o usuario compra a aplicaca~o atraves deste catalogo, a cobranca pela aplicaca~o e feita e distribuda entre a Qualcomm (8%), a operadora (12%) e o desenvolvedor (80%), dentro de um sistema de billing completamente integrado com o resto do BDS. Para o desenvolvedor, BREW oferece uma API para acesso as varias funcionalidades dos dispositivos. O uso desta API se da no acesso a interfaces (em vez de objetos), que possuem um conjunto de func~oes associadas para acessar suas funcionalidades. Estas interfaces possuem um identi

(86) cador unico e implementam o padr~ao de projeto reference counting [MUL02] para gerenciar a alocaca~o e desalocaca~o de memoria. O desenvolvimento em BREW e feito em cima de um SDK - Software Development Kit - disponibilizado pela Qualcomm. Este SDK e composto por: um conjunto de headers que de

(87) nem a API; as bibliotecas que implementam esta API para o simulador; o simulador propriamente dito; ferramentas para edic~ao dos arquivos de recursos, download e logging da aplicac~ao no telefone; e outras ferramentas para debug e automaca~o de testes. O SDK tambem conta com um plug-in que o integra no Microsoft Visual Studio, facilitando o desenvolvimento no simulador. No entanto, para executar a aplicaca~o no telefone e necessario um compilador para ARM. Alem disto, e preciso escrever os make

(88) les e rodar este compilador em linha de comando. A vers~ao mais atual do SDK, quando foi escrito este trabalho, e a 3.1.5, de abril de 2006. Esta vers~ao suporta acesso a varios elementos do hardware do dispositivo:. . Acesso ao sistema: a interface IShell permite acesso as funcionalidades do sistema operacional, como gerenciamento do tempo de vida da aplicaca~o, manipulaca~o de eventos, uso de timers, criaca~o de dialogos, informac~oes do dispositivo, acesso ao arquivo de recursos, etc.. . Interface com o usuario: BREW disponibiliza as interfaces IDisplay e IDialog para acesso a tela do dispositivo. IDisplay fornece uma API de baixo nvel para desenho e manipulac~ao de primitivas gra

(89) cas, enquanto IDialog possibilita a criac~ao de controles gra

(90) cos pre-formatados, como bot~oes, caixas de texto e menus, atraves da interface IControl.. . Sistema de arquivos: BREW fornece pleno acesso ao sistema de arquivos do dispositivo atraves das interfaces IFileMgr e IFile.. . Rede: existe a possibilidade de criaca~o de conex~oes atraves de sockets TCP e UDP, bem como a utilizaca~o de protocolos de mais alto nvel como HTTP e HTTPS, usando INetMgr, ISocket e IWeb.. . Media: BREW disponibiliza a interface IMedia para gravar e reproduzir media (audio e vdeo) nos mais diferentes formatos de codi

(91) cac~ao..

(92) 12. 2.3 brew. . Agenda: e possvel manipular contatos na agenda do dispositivo, atraves de IAddrBook e IAddrRec.. . Ligaco~es: a interface ICall oferece a possibilidade de efetuar chamadas telefônicas atraves de BREW.. . Perifericos: todos os perifericos do telefone, como câmera, bateria e rede wi

(93) , possuem interface associadas para a sua manipulac~ao.. Uma aplicac~ao em BREW e formada por um conjunto de elementos: um arquivo MIF (Module Information File) que descreve as principais informaco~es da aplicac~ao, como nome da aplicaca~o, cone, nvel de acesso aos recursos do sistema operacional e outras classes e extens~oes utilizadas; o codigo-fonte da aplicaca~o, escrito em C/C++; e, opcionalmente, arquivos de recursos BAR (BREW Applet Resource), onde s~ao armazenados imagens, textos e de

(94) nico~es de dialogos usados na aplicaca~o.. Figura 2.3.. Desenvolvimento de uma aplicaca~o BREW. BREW da suporte ao desenvolvimento de aplicac~oes de duas formas: procedural ou orientado a objeto. Utilizando uma abordagem procedural, e obrigatorio declarar uma funca~o para tratar os eventos gerados pelo ambiente e uma estrutura para conter as variaveis da aplicaca~o, ja que n~ao se pode trabalhar com variaveis globais. Ao inicializar a aplicac~ao, o ambiente de execuca~o de BREW cria uma instância desta estrutura, registra a funca~o de tratamento de eventos e, opcionalmente, pode registrar uma func~ao para ser chamada quando a aplicac~ao for encerrada. Ja com a abordagem orientada a objeto, deve-se criar uma classe que herda atributos e metodos da estrutura AEEApplet. Por heranca, esta classe ira possuir, como atributos, ponteiros para as interfaces IShell, IDisplay e IModule que representam, respectivamente, a interface de acesso aos recursos do sistema, a interface de acesso a tela e a interface de acesso a outras aplicaco~es ou extens~oes utilizadas. Esta classe tambem deve.

(95) 2.3 brew. 13. ter metodos estaticos para inicializaca~o e

(96) nalizac~ao da aplicaca~o (alocac~ao e desalocaca~o dos objetos utilizados) e para tratar os eventos enviados a aplicac~ao, da mesma forma como temos estas funco~es na abordagem procedural. Vale salientar que o processo de execuca~o e o mesmo para as duas abordagens. Desta forma, ao implementar os metodos de inicializac~ao e

(97) nalizac~ao da aplicac~ao, bem como o metodo de tratamento de eventos, tem-se toda implementaca~o necessaria para uma aplicaca~o BREW. Ent~ao, basta tratar os eventos desejados e escrever a logica da aplicac~ao para reagir a estes eventos. Abaixo segue exemplo do codigo inicial de uma aplicaca~o em BREW, onde temos:. . Func~ao de criac~ao da aplicac~ao:. int AEEClsCreateInstance(AEECLSID ClsId,IShell * pIShell, IModule * pMod,void ** ppObj) { *ppObj = NULL; if(AEEApplet_New( sizeof(HelloWorld), // HelloWorld struct ClsId, pIShell, pMod, (IApplet**)ppObj, // HelloWorld handle event function (AEEHANDLER)HelloWorld_HandleEvent, NULL)) { return(AEE_SUCCESS); } }. return (EFAILED);. . Func~ao de tratamento de eventos:. static boolean HelloWorld_HandleEvent(AEEApplet * pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam) { AECHAR str[] = {'H','e','l','l','o',' ','B','R', 'E', 'W', '\0'}; switch (eCode) { case EVT_APP_START: //clear screen (default color is white).

(98) 14. 2.3 brew IDISPLAY_ClearScreen(pMe->m_pIDisplay); // draw string IDISPLAY_DrawText(pMe->m_pIDisplay, AEE_FONT_BOLD, str, -1, 0, 0, 0, IDF_ALIGN_CENTER | IDF_ALIGN_MIDDLE); //update screen IDISPLAY_Update(pMe->m_pIDisplay); //we have successfully handled this message return(TRUE); case EVT_APP_STOP: return(TRUE); case EVT_KEY: // if any key is pressed, finishes app ISHELL_CloseApplet(pMe->m_pIShell, FALSE); return(TRUE); default: break;. }. } return(FALSE);. A func~ao de criac~ao da aplicaca~o basicamente aloca memoria para a aplicaca~o ao chamar a funca~o utilitaria AEEApplet_New. Ela preenche a estrutura inicial da aplicac~ao AEEApplet com os ponteiros para as interfaces IShell, IModule e IDisplay. Uma vez inicializada com sucesso, a aplicaca~o esta apta a receber eventos que s~ao enviados para a func~ao tratadora de eventos da aplicac~ao, neste caso HelloWorld_HandleEvent. Os eventos EVT_APP_START e EVT_APP_STOP s~ao os eventos obrigatorios para toda aplicac~ao BREW e s~ao enviados quando a aplicaca~o e iniciada e

(99) nalizada, respectivamente. Neste exemplo, ao receber o evento EVT_APP_START, o texto \Hello BREW" sera impresso na tela do dispositivo. Ao ser pressionada qualquer tecla, o evento EVT_KEY e enviado para a func~ao HelloWorld_HandleEvent. O tratamento deste evento

(100) naliza a aplicaca~o ao chamar a funca~o ISHELL_CloseApplet()..

(101) 2.4 symbian os. 15. 2.4 SYMBIAN OS Estabelecida como uma empresa independente em 1998, Symbian surgiu como um consorcio formado pelas maiores empresas da industria de comunicaca~o sem

(102) o: Nokia, Panasonic, Motorola, Psion, Samsung Electronics, Siemens e Sony Ericsson. A intenca~o destas empresas foi desenvolver um sistema operacional para dispositivos moveis que fosse aberto e padr~ao, a partir do sistema operacional EPOC. Devido a estas caractersticas, tornou-se possvel o desenvolvimento de aplicaco~es, por parte de terceiros, para os dispositivos que possussem este sistema operacional. Estas aplicac~oes s~ao desenvolvidas em codigo nativo, sendo executado pelo processador do dispositivo, diferentemente de J2ME e BREW. Atualmente, a Nokia comprou as aco~es da Motorola e da Psion, tornando-se detentora de cerca de 70% das aco~es, e, desta forma, estabelecendo as regras de evoluca~o deste sistema operacional. Tambem e importante notar que, por ser um sistema operacional, o desenvolvimento de aplicac~oes para Symbian difere bastante de J2ME e BREW. Inclusive ja existe uma KVM que roda em cima de Symbian, possibilitando o desenvolvimento de aplicac~oes em J2ME para este sistema operacional. A API do Symbian OS fornece um framework de desenvolvimento de aplicaco~es. Desta forma, e necessario apenas herdar algumas classes reimplementado alguns metodos. Entretanto, para satisfazer as restric~oes do desenvolvimento para sistemas embarcados, deve-se implementar uma serie de praticas de

(103) nidas como Symbian Coding Idioms [NOK02]. O sistema operacional Symbian permite o desenvolvimento de aplicaco~es em C++, as quais s~ao instaladas no dispositivo em forma de uma biblioteca de ligaca~o dinâmica, ou DLL. Isto e necessario para que n~ao seja preciso reiniciar o dispositivo toda vez que uma aplicaca~o for instalada. Desta forma, as \aplicaco~es DLL" devem prover uma func~ao de acesso externo que serve justamente para instanciar a aplicaca~o, permitindo que a mesma seja executada. O Symbian OS pode ter varios tipos de interface gra

(104) ca com o usuario, as mais comuns s~ao a UIQ e a Series 60, discutidas a seguir:. . UIQ: interface para dispositivos que possuem uma tela com dimens~oes entre 4x6 cm a 6x8 cm e tela sensvel ao toque (touch screen). O Sony Ericsson P800 e um exemplo de dispositivo com esta interface. Maiores informac~oes podem ser encontradas em [UIQ].. . Series 60 : de acordo com [NOKb], a plataforma Series 60 e um padr~ao de interface com o usuario criada pela Nokia, mas aberta a todos os dispositivos que utilizem o voltada para smartphones, que possuem uma tela de 176x220 Pixels. Symbian OS. E O Nokia 3650 e o Nokia N-Gage s~ao exemplos de telefones com esta interface.. Estes dois modelos de interface com o usuario estendem de um mesmo framework de controle e interface com o usuario, o UIKON (User Interface and Control Framework ), que e a base do framework para desenvolvimento de aplicaco~es [NOK02] para o Symbian.

(105) 16. 2.4 symbian os. OS. Para cada tipo de interface com o usuario e criada uma extens~ao do UIKON: a plataforma Series 60 utiliza o AVKON, enquanto o UIQ utiliza o QIKON. Podemos encontrar maiores detalhes sobre as diferencas entre estas extens~oes e como fazer o porting de uma plataforma para a outra em [JOD02]. Para utilizar o framework de aplicaco~es Symbian, o desenvolvedor deve implementar as seguintes classes [NOK02]:. Figura 2.4.. i). ii). iii). iv). Symbian Application Framework. o ponto de entrada do programa. Esta classe provê a inicializaca~o da aplicaca~o, sendo a primeira classe a ser instanciada pelo framework. Tambem e responsavel por instanciar a classe de documento. Classe da Aplica c~ ao:. responsavel por gerenciar a parte persistente (arquivos) da aplicac~ao. Atraves desta classe, e possvel de

(106) nir ou associar quais os tipos de arquivos (extens~oes) s~ao suportados e gerenciados por uma determinada aplicaca~o. importante notar que nem todas as aplicac~oes possuem documentos associados. E No entanto esta classe deve existir, pois instancia a classe de interface com o usuario. Classe de Documento:. UI ): esta classe provê o gerenciamento. Classe de Interface com o Usu ario (. da interface com o usuario, realizando o tratamento de eventos, tais como: pressionamento de teclas; posicionamento do ponteiro (no caso de touch screens); abertura/fechamento de arquivos; entre outros. Tambem e responsavel pela criaca~o da(s) classe(s) de visualizaca~o.. View ): esta classe representa tudo o que esta sendo mostrado na tela, recebendo da classe de UI os comandos para desenhar e atualiza importante salientar que uma aplicaca~o pode ter varias views, sendo a classe la. E de UI responsavel por gerencia-las e de

(107) nir qual view estara ativa. Classe de Visualiza c~ ao (.

(108) 2.5 windows mobile. v). Motor ou n ucleo da aplica c~ ao (. 17. ApplicationEngine ): esta classe, implemen-. tada pelo desenvolvedor, e o que contem toda a logica da aplicac~ao, implementa seus algoritmos e provê os pontos de acesso para a classe de UI.. As classes de aplicac~ao, documento, UI e view que devem ser desenvolvidas, herdam de classes correspondentes do UIKON (ou de uma de suas extens~oes: AVKON para Series 60 e QIKON para UIQ) e possuem as suas funcionalidades basicas implementadas. Entretanto a classe nucleo da aplicaca~o (ApplicationEngine ) n~ao possui correspondente no UIKON, devendo ser criada pelo desenvolvedor. Tambem e importante salientar que o Symbian OS n~ao implementa a linguagem C++ padr~ao, n~ao fornecendo suporte a alguns recursos da linguagem tais como: a STL Standard Template Library (Biblioteca de classes template padr~ao); e RTTI - Run-Time Type Information (Informaca~o de tipos em tempo de execuca~o). Para desenvolver aplicaco~es para o Symbian OS e necessario o SDK da vers~ao do sistema operacional correspondente. Para Symbian, alem da divis~ao de interfaces gra

(109) cas entre UIQ e Series 60, cada uma destas interfaces possui diferentes vers~oes. A vers~ao mais atual da Series 60 e a 3rd Edition Feature Pack 3. A terceira edica~o do Symbian OS e baseada na Interface Binaria para Aplicaco~es (ABI - Application Binary Interface ) para a arquitetura ARM. A ABI e uma padr~ao desenvolvido pela propria ARM que determina como os arquivos executaveis e as bibliotecas ir~ao funcionar juntos. Isto signi

(110) ca que e necessario utilizar outros compiladores para gerar codigo binario para o Symbian OS terceira edica~o, e este binario n~ao e mais compatvel com os binarios das vers~oes anteriores. O desenvolvimento de aplicaco~es para o Symbian OS tambem utiliza um SDK, que contem: os arquivos de cabecalho com a de

(111) nica~o da API e o simulador; um compilador para ARM, para gerar codigo binario que possa ser executado no dispositivo; e um IDE para edic~ao e facilidade de desenvolvimento do codigo fonte. A Nokia lancou, no

(112) nal de 2005, um conjunto de IDE's baseados no Eclipse chamado carbide.c++. O carbide.c++ passou ent~ ao a ser o ambiente de desenvolvimento o

(113) cial do Symbian OS para a Nokia e integra todas as ferramentas e SDK's em uma unica aplicaca~o. Este ambiente possui as vers~oes Express, disponvel sem custo e que oferece as operac~oes basicas de desenvolvimento; Developer, que adiciona as funcionalidades de debug no dispositivo e design de interface; Professional, que possui ferramentas para analise de performance das aplicac~oes; e OEM, com ferramentas para criac~ao de telefones incluindo suporte a ROM e JTAG2 .. 2.5 WINDOWS MOBILE Criado em 1996 pela Microsoft, o sistema operacional Windows CE serve de base para todas as vers~oes do windows para dispositivos moveis. Este sistema operacional e uma vers~ao reduzida do Windows para desktops, contendo as principais funcionalidades da 2 Joint. Test Action Group - JTAG. Padr~ao IEEE 1149.1-1990 que de

(114) ne uma arquitetura para testes em placas de circuito impresso que usa boundary scan. Este metodo permite o teste das interconex~oes e sinais de um circuito atraves da programac~ao de celulas de teste..

(115) 2.6 embedded linux. 18. API WIN32. A base do Windows CE e o que de

(116) ne a vers~ao encontrada nos dispositivos atuais: o Windows Mobile. Assim como o Symbian OS, o Windows Mobile possui vers~oes diferentes de interface com o usuario:. . Windows Mobile Professional. . Windows Mobile Standard. : com tela sensvel ao toque, sem teclado e resoluca~o a partir de 240x320 pixels ;. : vers~ao do Windows para hardwares com teclado de telefone, telas de menor resoluca~o (a partir de 176x220) e sem ser sensveis a toque.. Antes das vers~oes atuais, existiram o Windows Mobile 2003 Second Edition, Windows Mobile 2003, Pocket PC 2002, Smartphone 2002, e Pocket PC 2000. Todas estas vers~oes eram baseadas em vers~oes anteriores do Windows CE. O desenvolvimento de aplicaco~es para o Windows Mobile pode ser feito de duas formas: utlizando a API nativa do sistema operacional ou escrevendo codigo para rodar no Microsoft .NET Compact Framework, vers~ao mobile do .NET para desktops. O ambiente de desenvolvimento do Windows Mobile e composto pelo SDK da vers~ao correspondente, que contem todos os arquivos de cabecalho da API e os simuladores; e do Microsoft Visual Studio, IDE que possui completa integrac~ao com o SDK e com os compiladores da Microsoft utilizados para gerar codigo binario para o simulador e para o dispositivo. Para todas as outras plataformas apresentadas neste captulo, foi descrito o desenvolvimento e o codigo de uma aplicac~ao basica nesta plataforma. O Windows Mobile n~ao fez parte do escopo de implementac~ao deste trabalho, como pode ser visto na Sec~ao 3.2. Desta forma, n~ao sera apresentada a forma de desenvolvimento de aplicaco~es. O desenvolvimento de aplicac~oes baseadas em janelas e igual ao do Windows para desktops e maiores detalhes podem ser encotrados em [MICa] [MICb] [MICc].. 2.6 EMBEDDED LINUX O Embedded Linux e um sistema operacional para sistemas embarcados baseado no Linux. Nesta vers~ao do Linux, o seu nucleo foi modi

(117) cado para suportar algumas funcionalidades presentes nos dispositivos embarcados. Assim como o Linux para desktops, o Embedded Linux possui varias distribuic~oes ativas. Basicamente, a diferenca entre estas distribuico~es s~ao o conjunto de funcionalidades disponveis na vers~ao basica e o conjunto de hardware suportado. Na pratica, cada fabricante de hardware adota uma das distribuic~oes comerciais e customiza essa distribuic~ao para o seu dispositivo. Atualmente existem diversos grupos com intenc~ao de padronizar o conjunto de funcionalidades que deve estar presente nas distribuic~oes Linux para sistemas embarcados. Entre estes grupos, est~ao includos: CE Linux Forum, o Linux Foundation, Linux Phone Standards Forum, LiMo Foundation, Embedded Linux Consortium e o OpenMoko. O desenvolvimento de aplicaco~es para embedded linux segue exatamente o mesmo modelo do desenvolvimento de aplicac~oes para o linux do PC. No entanto, como a maioria das distibuico~es Embedded Linux n~ao possui console e nem os telefones celulares.

(118) 2.6 embedded linux. 19. possuem interface adequada para rodar aplicac~oes em linha de comando, as distribuico~es Embedded Linux possuem implementaco~es dos principais frameworks gra

(119) cos existentes para Linux, Qt e GTK. Assim, implementar uma aplicaca~o Embedded Linux e basicamente, seguir um dos padr~oes de frameworks gra

(120) cos existentes: Qt ou GTK. N~ao existe um ambiente de desenvolvimento unico ou padr~ao para Embedded Linux. Basicamente e necessario um editor de textos, como o pico, nano ou xemacs, e a compilaca~o e feita em linha de comando, usando o GCC ou outro compilador para ARM. possvel tambem con

(121) gurar o Eclipse com o plug-in CDT para desenvolver para esta E plataforma. Existem alguns simuladores para ARM que podem ser usados para rodar a aplicaca~o antes de instalar no hardware

(122) nal. No entanto, estes simuladores devem possuir o mesmo ambiente gra

(123) co que a distribuica~o escolhida, e esta con

(124) guraca~o geralmente

(125) ca a cargo do desenvolvedor. Na pratica, apenas as plataformas com SDK bem de

(126) nido, como o Maemo da Nokia ou o Qtopia da Trolltech possuem simuladores que n~ao demandam instalaca~o e con

(127) guraco~es avancadas do desenvolvedor. O Embedded Linux disponibiliza API's para acesso a todos os recursos do hardware existentes no dispositivo:. . Acesso ao sistema operacional: todas as chamadas do sistema operacional, como timers, threads e as outras funco~es padr~ao da libc e posix est~ao presentes.. . Interface Gra

(128) ca: acesso ao sistema de janelas e a criac~ao dos elementos gra

(129) cos basicos e fornecida atraves do Qt.. . Acesso a rede: a API de sockets padr~ao do Linux pode ser utilizada para criar conex~oes de rede.. . Sistema de arquivos: o sistema de arquivos e acessado atraves das API's padr~ao do Linux.. . Dispositivos de entrada e sada: todos os recursos de entrada e sada de dados no Linux s~ao mapeados no sistema de arquivos como \arquivos de stream " e podem ser acessados atraves da API padr~ao. Nestes dispositivos est~ao includos a parte de audio; conex~ao serial; conex~ao USB; e Bluetooth.. importante salientar que, de acordo com o hardware do dispositivo e com a distriE buica~o do Linux utilizada, outras API's e recursos podem estar presentes e disponveis na API. A seguir, ser~ao apresentados os dois principais frameworks gra

(130) cos disponveis para Embedded Linux.. 2.6.1 Qt O framework gra

(131) co Qt3 foi desenvolvido pela Trolltech [TRO] em 1995. Sua proposta era ser um sistema gra

(132) co, orientado a objetos e multi-plataforma, funcionando 3 Pronuncia-se. \cute" em inglês, e signi

(133) ca bonito ou gracioso..

(134) 2.6 embedded linux. 20. inicialmente em Windows e Linux. Em 1997, este framework foi adotado para ser a base do KDE [GNUf] tornando-se, de fato, um padr~ao para desenvolvimento gra

(135) co em linux. Em 2000, a Trolltech lancou o Qtopia Core, base do Qt para dispositivos moveis. O Qtopia Core passou ent~ao a ser o padr~ao gra

(136) co para Linux em telefones celulares e PDA's. Recentemente a Trolltech lancou o Greenphone [TRO04], implementaca~o de referência do Qtopia para telefones celulares. Atualmente, a Motorola, Nokia, Panasonic, NEC e outros est~ao adotando o Embedded Linux como uma alternativa de plataforma de software para seus telefones celulares, o que nos leva a vislumbrar um crescimento desta plataforma nos proximos anos. O desenvolvimento de aplicac~oes em Qt segue um modelo de conex~oes, com elementos chamados \slots" e \signals". Podemos considerar os \signals" como eventos e os \slots" como os tratadores destes eventos. Ao conectarmos os eventos a estas func~oes tratadoras de eventos, as func~oes s~ao automaticamente chamadas quando os eventos s~ao disparados. Estas func~oes s~ao chamadas funco~es de callback. Uma aplicaca~o Qt e composta por um objeto da classe Qapplication e um ou varios \Widgets", que s~ao elementos gra

(137) cos basicos, que podem ser compostos para formar novos elementos. Estes elementos emitem os sinais (eventos) para a nossa aplicaca~o, que deve implementar \slots" para tratar estes sinais. Esta arquitetura simples fornece a base para a implementaca~o de aplicaco~es em Qt. A portabilidade do Qt e atingida ao portar os \Widgets" para as plataformas desejadas. No entanto, o Qt tambem n~ao fornece nenhuma estrutura para implementar aplicaco~es como maquina de estados. Na Figura 2.5 temos o diagrama de classes dos principais widgets de Qt. QObject e a base da estrutura de classes. Desta classe, herdam as 3 classes principais do framework : i) QApplication: representa a aplicac~ao propriamente dita, possuindo metodos para criar e executar uma aplicac~ao Qt. ii) QWidget: classe base para um componente de tela. Este componente pode ser uma janela, um bot~ao ou qualquer controle de interface com o usuario, que s~ao representados por classes que derivam de QWidget. iii) QLayout: funciona como um agrupador de widgets. De

(138) ne como os widgets ser~ao visualizados e dispostos na tela. Abaixo temos a implementaca~o de uma aplicac~ao simples em Qt. #include #include #include #include. <QApplication> <QLabel> <QPushButton> <QVBoxLayout>. int main(int argc, char *argv[]) { // Creating application QApplication app(argc, argv);.

(139) 21. 2.6 embedded linux. Figura 2.5.. Diagrama de classes de Qt. // creating basic widgets (label and pushbutton) QLabel *label = new QLabel("Hello Qt!"); QPushButton *button = new QPushButton("Quit"); // connecting clicked() signal to app->quit() slot QObject::connect(button, SIGNAL(clicked()), &app, SLOT(quit())); // creating window QWidget *window = new QWidget; window->setWindowTitle("Hello Qt!"); // creating a vertical layout to hold // the label and the button QVBoxLayout *layout = new QVBoxLayout; layout->addWidget(label); layout->addWidget(button);.

(140) 2.6 embedded linux. 22. // set layout to window window->setLayout(layout); // display it window->show();. }. // execute application return app.exec();. Esta aplicaca~o cria dois widgets, uma string \Hello Qt!" e um bot~ao \Quit". Estes widgets s~ao alinhados verticalmente e dispostos num terceiro widget, chamado window, que representa a janela da aplicaca~o. Esta janela ent~ao e requisitada para ser exibida na tela. Desta forma, quando nossa aplicaca~o e executada ao chamar app.exec();, a janela e seus widgets s~ao exibidos.. 2.6.2 GTK GTK+ (The Gimp Toolkit )[GNUe] e uma biblioteca para a criaca~o de interfaces chamada de Gimp Tool Kit pois foi escrita para desenvolver gra

(141) cas, assim como Qt. E o GIMP (GNU Image Manipulation Program ), programa de manipulac~ao de imagens da GNU. Esta biblioteca foi construda baseada no GDK (Gimp Drawing Kit ) que e basicamente um wrapper para as func~oes gra

(142) cas de baixo nvel do sistema de janelas X [XFR] e para o gdk-pixbuf que e uma biblioteca para manipulaca~o de imagens em baixo nvel. Atualmente, o GTK+ esta em sua vers~ao 2 e e a base para o Gnome (GNU Network Object Model Environment )[GNUa] ambiente gra

(143) co desktop para sistemas UNIX. GTK+ e escrita em C e possui licensa LGPL. No entanto existem diversos bindings de GTK para outras linguagens, como C++, C#, Objective C, Python, Perl, Free Pascal, Java e Ei el. Em dispositvos moveis, o GTK+ e usado como base de ambientes como o GPE Palmtop[GPE] e o Maemo[NOKa]. Aplicaco~es em GTK+ tambem possuem o conceito de tratamento de eventos (sinais) atraves de funco~es de callback. A aplicaca~o e construda ao criarmos widgets e conectarmos os eventos recebidos por estes widgets com as devidas func~oes de tratamento de eventos, de maneira analoga ao Qt. Abaixo temos a implementaca~o de uma aplicac~ao simples em GTK+. #include <gtk/gtk.h> int main( int argc, char *argv[] ) { /* GtkWidget is the storage type for widgets */ GtkWidget *window; /* This is called in all GTK applications..

(144) 2.7 comparando plataformas. 23. * Arguments are parsed from the command line * and are returned to the application. */ gtk_init (&argc, &argv); /* create a new window */ window = gtk_window_new (); /* Connect signal to X in the upper corner */ g_signal_connect(G_OBJECT(window), "delete_event", G_CALLBACK(gtk_main_quit), NULL); /* Add example label to window */ gtk_container_add(GTK_CONTAINER(window), GTK_WIDGET(gtk_label_new("Hello World!"))); /* and the window */ gtk_widget_show (window); /* All GTK applications must have a gtk_main(). * Control ends here and waits for an event * to occur (like a key press or mouse event). */ gtk_main (); }. return 0;. Esta aplicac~ao cria dois widgets, uma janela e um label (string de texto). No incio, e chamada a func~ao gtk_init() para inicializar o sistema gra

(145) co. Depois, a janela e criada e o sinal delete_event e conectado a func~ao de callback gtk_main_quit. Este sinal e enviado ao pressionar o bot~ao "X" que fecha a janela. A func~ao gtk_main_quit encerra o loop de execuca~o da func~ao gtk_main e encerra o programa. Ent~ao, o widget contendo o texto "Hello World!" e adicionado a janela e ela e exibida atraves da chamada a funca~o gtk_widget_show. Por