Vitor Medina Cruz Ginga-NCL para Dispositivos Portáteis

Todos os direitos reservados. É proibida a reprodução totalou parcial do trabalho sem autorização da universidade, doautor e do orientador.Vitor Medina CruzRecebeu seu título de Bacharel em Informática pelaPontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) em 2005. Atualmente integra o grupo depesquisadores do Laboratório TeleMídia da PUC-Rio,desenvolvendo pesquisa na área de Sistemas Hipermídia.Cruz, Vitor MedinaFicha CatalográficaGinga-NCL para Dispositivos Portáteis / Vitor MedinaCruz ; orientador: Luiz Fernando Gomes Soares. - 2008.84 f. ; 29,7 cmDissertação (mestrado) – Pontifícia UniversidadeCatólica do Rio de Janeiro, Rio de Janeiro, 2008.Inclui referências bibliográficas.1. Informática – Teses. 2. Middleware Declarativo. 3.TV Digital. 4. Ginga-NCL. 5. SBTVD. 6. NCL I. Soares, LuizFernando Gomes. II. Pontifícia Universidade Católica doRio de Janeiro. Departamento de Informática. III. Título.CDD: 004

Este trabalho é dedicado aos meuspais, Alice e João.

AgradecimentosPrimeiramente ao meu orientador, o professor Luiz Fernando Gomes Soares,pela sua dedicação em me orientar, pela sua paciência e pelo seu esforço emfazer com que eu me superasse.Em especial, ao Marcio Moreno pela sua disposição em me ajudar, pelosensinamentos, pelas dicas, enfim, por todo o auxílio oferecido que foifundamental na concepção deste trabalho.Ao Carlão, ao Felipe Nogueira, ao Rafael Savignon e ao Francisco pela ajudaoferecida. Ao Felipe Bittencourt pelo auxílio na criação das aplicações NCL.A todos do TeleMidia pela amizade e pelo companheirismo oferecidos ao longodesse período em que trabalhamos juntos. Esses também foram fatores muitoimportantes na realização deste trabalho.Agradeço também a minha namorada, Vilani, pelos momentos de descontraçãoe pela compreensão nas horas mais difíceis.À minha família, meus pais (Alice e João) e minha irmã (Helena), pelo apoio eauxílio oferecidos, que tornaram possível a minha chegada até aqui. Agradeçotambém aos meus amigos do n-eto, pela amizade sincera e pelo incentivo.Aos membros da banca, pelos comentários e sugestões.A todos os funcionários do Departamento de Informática da PUC-Rio.Por fim, agradeço à CAPES e ao Laboratório TeleMidia pelo auxílio financeiro,fundamental para a realização deste trabalho.

ResumoCruz, Vitor Medina; Soares, Luiz Fernando Gomes. Ginga-NCL paraDispositivos Portáteis. Rio de Janeiro, 2008. 84p. Dissertação deMestrado - Departamento de Informática, Pontifícia Universidade Católicado Rio de Janeiro.O advento da TV Digital traz muitas vantagens, como a melhora daimagem, do som e o suporte à interatividade. Um sistema de TV Digitalespecifica técnicas de codificação e transmissão de conteúdos televisivos aserem transmitidos das emissoras para os dispositivos receptores dostelespectadores. Um elemento importante definido por tais sistemas é omiddleware. No contexto da TV Digital, o middleware oferece uma linguagem deprogramação a ser usada na criação das aplicações interativas. O middlewareespecificado pelo Sistema Brasileiro de TV Digital (SBTVD), denominado Ginga,é composto por dois ambientes: um declarativo, o Ginga-NCL, e outroimperativo, o Ginga-J. Apenas o uso do Ginga-NCL é obrigatório nos dispositivosportáteis. Dentre as vantagens do Ginga-NCL, ressalta-se o fato da sualinguagem, a NCL, apresentar um conjunto de características que sãoadequadas para a criação de conteúdo televisivo interativo. É importante,entretanto, realizar uma implementação de referência do Ginga-NCL que sirvacomo prova de conceito da especificação, ou seja, que mostre a sua viabilidadede uso na prática. Este trabalho apresenta a primeira implementação dereferência do Ginga-NCL para dispositivos portáteis, baseada na suaimplementação de referência para os terminais fixos. Entre as plataformasestudadas, a do sistema operacional Symbian foi escolhida para a realização daimplementação proposta, por apresentar as maiores vantagens. Os problemasencontrados durante o desenvolvimento da implementação proposta sãoapresentados juntamente com as soluções dadas. Ao final, testes sistêmicosforam usados na identificação e correção de erros da implementação resultantedeste trabalho.Palavras-chavemiddleware, Ginga-NCL, SBTVD, portátil, NCL, TVD.

AbstractCruz, Vitor Medina; Soares, Luiz Fernando Gomes (Advisor). Ginga-NCLfor Portable Devices. Rio de Janeiro, 2008. 84p. Master Thesis -Departamento de Informática, Pontifícia Universidade Católica do Rio deJaneiro.The advent of the Digital TV brings many advantages, such as image andsound improvement and interactivity support. A Digital TV system definescodification and transmission techniques for content to be transmitted frombroadcasters to receiver devices belonging to viewers. An important elementdefined for such systems is the middleware. In the Digital TV context, themiddleware provides a programming language to be used on the creation ofinteractive applications. The middleware specified by the Sistema Brasileiro deTV Digital (SBTVD), known as Ginga, is composed by two environments: onedeclarative, the Ginga-NCL, and another imperative, the Ginga-J. Only Ginga-NCL is mandatory in portable devices. Among the advantages of Ginga-NCL,stands out the fact of its language, the NCL, has a set of characteristics that aresuitable for creation of interactive television content. However, it is important tomake a Ginga-NCL reference implementation that can be used as proof ofconcept of the specification, which shows its use viability in practice. This workpresents the first Ginga-NCL reference implementation for portable devices,based upon its reference implementation for fixed terminals. Among the studiedplatforms, the one provided by Symbian operating system was chosen to carryout the proposed implementation, since it has the greatest benefits. Theproblems found during the development of the proposed implementation arepresented together with the solutions given. At the end, systemic tests were usedon the identification and correction of errors of the implementation resulted fromthis work.Key wordsmiddleware, Ginga-NCL, SBTVD, portable, NCL, DTV.

Lista de figurasFigura 1: Camada de Serviço Específico do Ginga. Retiradoadaptado de (Soares, Rodrigues e Moreno, 2007). 24Figura 2: Núcleo Comum do Ginga. Retirado e adaptado de(Soares, Rodrigues e Moreno, 2007). 24Figura 3: Exemplo simples de uma aplicação NCL. 33Figura 4: Documento NCL como uma árvore. 34Figura 5: Diagrama de Classes da estrutura usada pararesolver o problema das dependências entre tags. 37Figura 6: Exemplo de um documento NCL com âncorastemporais. 48Figura 7: Exemplo de fila de tempos definidos em âncorastemporais. 49Figura 8: Acesso das camadas de abstração dos exibidorese do Display do dispositivo por parte da máquina deapresentação. 53Figura 9: Aplicação Fórmula1. 61Figura 10: Os três casos de interação da aplicação Fórmula1. 62Figura 11: Aplicação Matrix_Mobile. 64Figura 12: Primeiro caso de sincronismo da aplicaçãoMatrix_Mobile. 64Figura 13: Segundo caso de sincronismo da aplicaçãoMatrix_Mobile (Sem interação). 65Figura 14: Segundo caso de sincronismo da aplicaçãoMatrix_Mobile (Com interação). 65Figura 15: Aplicação Carnaval. 66Figura 16: Aplicação Carnaval com legenda e com as duasopções de interação. 67Figura 17: Os dois casos de interação da aplicação Carnaval. 68Figura 18: Aplicação 4. 69Figura 19: Seleção e uso da página HTML. 70Figura 20: Botão pressionado. 71

2Estado da ArteEste capítulo tem como objetivo apresentar, de forma sucinta, o estadoatual da TV Digital para dispositivos portáteis. A Seção 2.1 trata da TV Digital edos dispositivos portáteis. A Seção 2.2 aborda os middlewares declarativosexistentes, dando enfoque àqueles mais adequados ao contexto da TV Digitalpara dispositivos portáteis. Finalmente, a Seção 2.3 tece algumas consideraçõesacerca dos sistemas operacionais e das plataformas de desenvolvimentoexistentes no escopo dos dispositivos portáteis. Um estudo mais detalhado sobreesses pontos pode ser encontrado em (Cruz, Moreno e Soares, 2008).2.1.A TV Digital e os Dispositivos PortáteisA TV Digital possibilita uma grande melhora na qualidade da imagem e dosom dos programas ou conteúdos exibidos. Isso ocorre, dentre outros fatores,por conta da natureza da transmissão digital, que possui métodos muito maisprecisos de recuperação da informação recebida se comparados aos datransmissão analógica. Dessa forma, as perdas na qualidade da imagemgeradas por imprecisões ocorridas na transmissão são muito mais fáceis deserem compensadas em um sistema de TV Digital. Uma outra vantagem é que,sendo de natureza digital, o conteúdo oferecido pode ser comprimido, reduzindoa taxa de bits gerada. Isso possibilita a sua transmissão em uma banda defreqüência menor do que a utilizada pela TV analógica. O fato do conteúdo serde natureza digital também viabiliza seu armazenamento e o uso de funções dePVR (Personal Video Recoder), como pause e rewind, mesmo em programassendo exibidos ao vivo. Com relação à redução de banda necessária, o mesmocanal de freqüência hoje utilizado por uma transmissão analógica será capaz detransmitir mais de um fluxo de áudio e de vídeo, além dos fluxos de dados. Ovídeo transmitido poderá possuir a definição SDTV (Standard Definition TV),conforme utilizado na transmissão analógica, ou ainda HDTV (High DefinitionTV), que oferece uma qualidade de imagem superior.

Estado da Arte 13A transmissão de outros dados, além do áudio principal e do vídeoprincipal, permite o envio de aplicativos que possibilitam ao telespectadorinteragir com o programa que está sendo exibido. Também é possível oferecerconteúdos personalizados e mais adequados às necessidades do telespectador,o que pode contribuir, ainda, para uma mudança no modelo de negócios hojeusado.“A TV Digital pode ser provida trazendo-se tecnologias computacionaispara o âmbito da TV ou levando as tecnologias de TV para o ambientecomputacional.” (Cruz, Moreno e Soares, 2008: 2).No primeiro caso, enquadram-se, de maneira geral, as transmissões de TVDigital por radiodifusão terrestre, cabo ou satélite. Este modelo permite adisponibilização da TV Digital com interatividade e personalização do conteúdo.Se for adicionada alguma tecnologia de canal de retorno, também será possíveloferecer serviços de conteúdo sobre demanda. Esse tipo de serviço permite aotelespectador escolher um programa de um acervo fornecido pela emissora paraser assistido na hora que lhe for mais conveniente, e também torna viável àemissora obter um melhor conhecimento dos seus usuários.No caso em que a tecnologia de TV é levada ao ambiente computacional,temos a IPTV (TV over IP), onde o conteúdo televisivo é distribuído através doprotocolo da Internet IP (Internet Protocol). O uso da IPTV é feito, normalmente,em redes fechadas, como em TVs por assinatura, e encontra-se mais próximodo modelo da Internet. Com o uso dessa tecnologia é possível disponibilizar aTV Digital com interatividade, personalização e serviços de conteúdo sobredemanda. Por outro lado, serviços de broadcast, normais em transmissões deTV, não são providos naturalmente com o uso do protocolo IP, onde serviçosbidirecionais de unicast são mais comuns. Isso força a utilização da técnica demulticasting, pela qual a transmissão é feita de um para n endereços IP’sregistrados em um grupo, chamado de grupo multicast. Um problema associadoa isso seria a complexidade da rede envolvida, que pode acabar aumentandomuito. Uma maior discussão sobre as possibilidades da TV Digital é apresentadaem (Cruz, Moreno e Soares, 2008: 1).No caso da aplicação da TV Digital nos dispositivos portáteis, é precisoficar atento às características diferenciais encontradas nesses aparelhos, dasquais é possível citar:“• Uso de bateria, que exige um consumo moderado de energia.Aplicações nesse escopo podem ser sumariamente terminadas, e precisam seadequar ao fato. Um outro ponto é que o consumo de energia gerado pelaaplicação precisa ser baixo;

Estado da Arte 14• Limite de processamento e de memória;• Mobilidade, com processo de handoff;• Tamanho de tela pequeno;• A conversa, no caso do celular, como funcionalidade principal. Qualqueroutra atividade fica em segundo plano;• Teclado limitado;• Limite maior de banda. ” (Cruz, Moreno e Soares, 2008: 4)Os sistemas de TV Digital e seus middlewares precisam se adaptar aessas características a fim de possibilitarem a recepção dos conteúdos digitaisnos dispositivos portáteis. Entretanto, os esforços nesse sentido iniciaram-se hápouco tempo e ainda não são muitos. Um exemplo é o caso do Japão, paísavançado em termos de TV Digital, que começou a migração desse serviço paraos dispositivos portáteis apenas em meados de 2006.2.2.Middlewares“Middleware é uma camada intermediária entre o hardware/SO e asaplicações” (Cruz, Moreno e Soares, 2008: 18) que tem por finalidade facilitar odesenvolvimento das suas aplicações e torná-las independentes da plataformade hardware e do sistema operacional do aparelho receptor. (Cruz, Moreno eSoares, 2008), no Capítulo 6, estuda vários sistemas de TV Digital encontradosna literatura e os seus respectivos middlewares. Foi feita, ainda, uma análisecomparativa entre os vários middlewares, com o objetivo de determinar quaisseriam as melhores opções para o escopo dos dispositivos portáteis. Esta seçãoapresenta, de forma resumida, esse estudo e as suas conclusões.Em IPTV, não existe qualquer padrão de middleware definido. Hoje, o quemais se vê são soluções proprietárias, altamente especializadas e,freqüentemente, completamente fechadas. No que diz respeito ao uso dessatecnologia em dispositivos portáteis, existe menos definição ainda. As soluçõesproprietárias (Cruz, Moreno e Soares, 2008: 52-63) fazem nenhuma ou poucamenção ao uso nesses dispositivos. Mesmo a pequena movimentação depadronização existente na área de IPTV não chega a tocar nesse assunto comprofundidade. Sendo assim, não parece existir, em IPTV, qualquer soluçãointeressante para a disponibilização da TV Digital em dispositivos portáteis.Por outro lado, a TV Digital por radiodifusão terrestre, cabo ou satélitepossui padrões de sistemas de TV Digital abertos e implementados, que sãoapresentados, com os seus respectivos middlewares, em (Cruz, Moreno e

Estado da Arte 15Soares, 2008: 18-51). Os mais relevantes são apresentados aqui de formaresumida, ao mesmo tempo em que é feita a avaliação de seus usos nosdispositivos portáteis.O MHP (Multimedia Home Plataform), desenvolvido pelo fórum DVB(Digital Video Broadcast), não foi desenvolvido para o ambiente dos dispositivosportáteis. Sua especificação baseia-se no J2SE (Java 2 Standard Edition), que éuma plataforma de desenvolvimento Java feita para terminais fixos. Comodescrito em (Cruz, Moreno e Soares, 2008: 12-16), J2SE não é adequado paraser usado em dispositivos portáteis com limitações de recursos. Além disso, opróprio DVB define um padrão de transmissão de TV Digital para esse tipo deaparelho, o DVB-H (Digital Video Broadcast - Handheld), que não determina ouso do MHP. Esse middleware parece ser, portanto, inadequado para o escopodos dispositivos portáteis. Mais detalhes acerca deste middleware podem serencontrados em (Cruz, Moreno e Soares, 2008: 18-24).O sistema de TV Digital ACAP (Advanced Common Application Platform),criado pelo comitê internacional ATSC (Advanced Television SystemsCommittee), não é apropriado para a transmissão de TV Digital em dispositivosportáteis por conta do seu padrão de modulação, o 8-VSB. Como é detalhadoem (Digital TV Facts, 2006), o 8-VSB não atende os requisitos mínimosnecessários para a transmissão adequada aos dispositivos portáteis, que é feitasem o uso de cabos. O middleware do sistema ACAP não é implementado emnenhum aparelho desse tipo. Mais informações desse sistema de TV Digitalpodem ser encontradas em (Cruz, Moreno e Soares, 2008: 30).O middleware DIMS (Dynamic and Interactive Multimedia Scenes),desenvolvido por uma organização internacional de padronização na área detelecomunicações, denominada 3GPP (3rd Generation Partnership Project), foiespecificado para ser usado no padrão de transmissão do sistema de TV DigitalMBMS (Mobile Broadcast/Multicast Service). Esse middleware foi desenvolvidoespecificamente para os dispositivos portáteis. Apesar disso, a sua especificaçãoainda se encontra em fase de “drafting” e com pouco conteúdo definido, sendoque boa parte dele ainda é muito superficial. Dessa forma, o DIMS também podeser descartado, hoje, como uma opção de middleware para dispositivosportáteis. Um estudo mais aprofundado desse middleware e do seu respectivosistema de TV Digital é encontrado em (Cruz, Moreno e Soares, 2008: 44-46).O LASeR (Lightweight Application Scene Representation) é um padrão demiddleware da ISO (International Organization for Standardization) desenvolvidocom o objetivo de substituir o MPEG4 BIFS (Binary Format for Scene) que não

Estado da Arte 16se mostra adequado para o ambiente dos dispositivos portáteis. LASeR foidesenvolvido especificamente para esse tipo de aparelho e é um superset doSVG Tiny (Scalable Vector Graphics - Tiny), que, por sua vez, é uma linguagemdeclarativa do W3C, desenvolvida para dispositivos com limitações de recursos.A especificação LASeR define, além da linguagem declarativa, dois tipos delinguagens de script: o application/ecmascript e o application/laserscript. Oprimeiro deriva do SGV, que define uma linguagem de script baseada noECMAScript, e o segundo é usado em aplicações LASeR a fim de executarações de edição ao vivo. Mais detalhes sobre esse middleware podem serconferidos em (Cruz, Moreno e Soares, 2008: 40-44). Apesar de se apresentar,aparentemente, como um bom middleware de TV Digital para dispositivosportáteis, o LASeR não possui qualquer implementação sua sendo usada oumesmo de referência, além da sua especificação ainda não estar totalmentefinalizada.HisTV é um padrão de middleware desenvolvido especificamente paradispositivos portáteis que usam o DVB-H na recepção de conteúdo. Foi criadopela GMIT, uma empresa de consultoria relacionada ao padrão DVB-H, mas é,atualmente, suportado por outras instituições. A sua especificação já está bemadiantada e já existem alguns produtos da Siemens e da Benq com suaimplementação, como pode ser visto em (Cruz, Moreno e Soares, 2008: 40).O desenvolvimento de uma aplicação HisTV deve ser feito através de umprocesso de três etapas: “a construção do layout da tela, o projeto da máquinade estados e a produção dos objetos.” (Cruz, Moreno e Soares, 2008: 37). Aconstrução do layout deve ser feita com o uso de objetos espaciais predispostosna tela, os ifields. São dois os tipos de layout: o landscape (320x204) e o portrait(240x320). A aplicação deve ser desenvolvida considerando-se ambos. Pode-seperceber, portanto, que a arrumação dos objetos na tela é limitada aos ifieldsdisponíveis e aos modos de layout.O próximo passo no desenvolvimento de uma aplicação é a construção deuma máquina de estados que será usada na apresentação da aplicação HisTV.Essa máquina deve ser concebida com cuidado, pois o procedimento é bemcomplexo.A produção do conteúdo consiste na edição dos nomes dos arquivos querepresentam os objetos de mídia, levando-se em conta os ifields e os estados damáquina de estados relacionados a esses objetos. Esse procedimento é,aparentemente, muito complexo, confuso e trabalhoso. A especificação cita,entretanto, a existência de um script perl que gera automaticamente os arquivos

Estado da Arte 17corretamente nomeados. Isso é feito recebendo como entrada um arquivo noformato .csv, contendo informações sobre a máquina de estados, as mídias e osifields. O uso desse script, entretanto, não é muito claro, assim como tambémnão é claro como o arquivo no formato .csv deve ser criado. Detalhes emminúcias sobre o HisTV podem ser vistos em (Cruz, Moreno e Soares, 2008: 36-40).O HisTV tem como vantagem o fato de ter sido especificado para oambiente dos dispositivos portáteis e de já possuir implementações da suaespecificação executando nesse tipo de aparelho. Entretanto, o seu domínio deaplicações é pequeno por conta da sua interface fixa. Comparado aos outrosmiddlewares que serão apresentados, o seu maior problema é, contudo, o fatoda autoria das suas aplicações ser muito complicada, o que certamenteinviabiliza a criação de aplicações por pessoas leigas.A BML (Broadcast Markup Language) é parte integrante do middleware dopadrão de TV Digital Japonês, o ISDB-T. A linguagem baseia-se, com algumasadaptações e adições, na XHTML 1.0 e possui uma curva de aprendizagempequena. A BML possui também elementos imperativos especificados com umalinguagem de script baseada no ECMAScript. O foco do middleware BML é naapresentação do documento e na interação com o usuário. Nas aplicações deTV Digital, entretanto, o sincronismo e a adaptabilidade são fatores tão ou maisimportantes, conforme (Moreno, 2006). A BML é adequada à transmissão paradispositivos fixos ou portáteis, definindo perfis da linguagem que são maisadequados a cada um dos dois casos. No Japão, já existem implementaçõescomerciais desse middleware para terminais fixos e dispositivos portáteis.A BML é o único middleware apresentado até agora que possuiespecificação finalizada com implementações nos dispositivos portáteis, e que ésimples o suficiente de ser usada. Em (Cruz, Moreno e Soares, 2008: 30-36),podem ser encontradas mais informações sobre a BML.O Ginga-NCL faz parte do Sistema Brasileiro de TV Digital (SBTVD). Essesistema define dois ambientes para seu middleware: um ambiente declarativo(Ginga-NCL) e um ambiente imperativo (Ginga-J). Esta dissertação se concentrano Ginga-NCL, por ser o único ambiente obrigatório no perfil portátil. Alinguagem usada por esse middleware é a NCL (Nested Context Language), quedefine dois perfis: um avançado, o Enhanced Language Profile, e um outro maisbásico, o Basic Language Profile. A linguagem de script especificada para a NCLé a linguagem Lua. O Ginga-NCL possui uma curva de aprendizagem mais altaque a BML, mas, quando aprendida, é mais simples de ser usada. Ela se

Estado da Arte 18distingue da BML especialmente por ter o seu foco no sincronismo, em suaforma geral, e na adaptabilidade. Em (Cruz, Moreno e Soares, 2008: 25-28),podem ser encontradas mais informações sobre o Ginga-NCL.Dentre os middlewares apresentados, a BML e o Ginga-NCL parecem ser,atualmente, os mais relevantes para o escopo dos dispositivos portáteis. (Cruz,Moreno e Soares, 2008: 62-64) oferece mais detalhes sobre essa conclusão,bem como apresenta uma análise comparativa entre os middlewares aquiresumidos.Ainda que se apresente como uma boa opção de middleware para osdispositivos portáteis, faltava ao Ginga-NCL uma implementação de referênciapara esse tipo de dispositivo que demonstrasse o seu uso na prática, o que foirealizado e está sendo apresentado nesta dissertação.2.3.Sistemas Operacionais e suas PlataformasNo escopo dos dispositivos portáteis, encontramos Sistemas Operacionaisfeitos justamente para atender as características diferenciais desses aparelhos.Um desses sistemas teve que ser escolhido para a realização da implementaçãode referência do Ginga-NCL proposta nesta dissertação. Um estudo dessesSistemas Operacionais e das suas plataformas de desenvolvimento foi feito eapresentado em (Cruz, Moreno e Soares, 2008: 5-18) com o objetivo de levantartodas as opções existentes e permitir a escolha de uma delas. Nesse estudo,deu-se preferência a sistemas com plataforma aberta, estáveis, de baixo custo,com boa quantidade de dispositivos disponíveis para teste no mercado, quesejam usados hoje e que possam representar uma opção viável de uso nomercado futuro. Esta seção apresenta um resumo desse estudo realizado, ondeforam analisados cinco sistemas operacionais: Symbian, Linux, Windows,PalmOS e BlackBerry.O BlackBerry possui pouca participação no mercado, não apresentandotendências de crescimento. É fechado e não é distribuído em dispositivos quenão tenham sido desenvolvidos pela sua fabricante, a RIM (Research In Motion).Sendo assim, o BlackBerry foi desconsiderado para uma implementação dereferência do Ginga-NCL. O mesmo pode-se dizer do PalmOS, que não possuinenhuma das suas versões sendo substancialmente utilizada. Ao invés disso, aPalm, criadora do PalmOS, tem investido na criação de um novo sistema, o

Estado da Arte 21middleware de TV Digital. Maiores detalhes sobre a plataforma nativa do sistemaoperacional Symbian são discutidos em (Cruz, Moreno e Soares, 2008: 10-12).A plataforma JavaME (Micro ou Mobile Edition), por sua vez, é umsubconjunto da J2SE (Java Technology, 2007) e foi desenvolvida para atenderaos requisitos dos dispositivos portáteis e móveis de pequeno a grande porte. Aplataforma JavaME oferece uma linguagem simples de desenvolvimento que ébem conhecida, a Java, e oferece uma portabilidade que, na prática, não existe.A linguagem de programação Java é simples de ser usada, mas, por contadisso, ela remove parte do controle que o programador tem sobre o código dasua aplicação, impossibilitando-o de realizar otimizações mais refinadas.Entretanto, o maior fator negativo contra a JavaME é a impossibilidade deacesso aos recursos de hardware por meio da sua linguagem. Todafuncionalidade existente no dispositivo deve ser acessada através de uma APIJavaME, que, quando não existe, inviabiliza o uso da funcionalidade em questão.No que diz respeito à TV Digital, a comunidade Java ainda está preparando aJSR 272, uma API Java que oferecerá suporte às funcionalidades de TV Digital.Quando a especificação em questão estiver terminada, novos aparelhos com asua API precisarão ser lançados antes que novas aplicações que façam usodessa API possam ser desenvolvidas. Maiores detalhes sobre a plataformaJavaME são discutidos em (Cruz, Moreno e Soares, 2008: 12-16).O que se pôde concluir é que a plataforma nativa do Symbian OS reúnetodas as características necessárias para o desenvolvimento do middlewareGinga-NCL para dispositivos portáteis, enquanto que as limitações do JavaMEinviabilizam esse projeto. Portanto, para o objetivo proposto, optou-se pelaplataforma de desenvolvimento do Symbian OS. Essa resolução e uma análisemais detalhada dessas duas plataformas são apresentadas em (Cruz, Moreno eSoares, 2008: 17-18).Nessa plataforma, é preciso, ainda, escolher uma UI (User Interface) dedesenvolvimento. As UIs determinam as características específicas do sistemaSymbian, e são associadas às famílias de dispositivos. Como exemplo, tem-se oS60 Symbian SDK (Software Development Kit), usado para implementaraplicações compatíveis com a família de dispositivos S60 da Nokia. Naimplementação do Ginga-NCL para dispositivos portáteis, foi dada prioridade aouso de API’s Symbian genéricas. Entretanto, parte da implementação énecessariamente específica a uma UI.A UI escolhida foi a S60, com o SDK que oferece suporte a versão 9.2 dosistema operacional Symbian, a mais recente disponibilizada para

Estado da Arte 22desenvolvimento. Essa escolha foi feita devido à disponibilidade dedocumentação, a uma ampla comunidade que oferece suporte aodesenvolvimento e à grande quantidade de dispositivos Nokia S60 disponíveisno mercado, o que possibilitaria testes em dispositivos com mais facilidade erapidez. Neste trabalho, quando qualquer API for descrita, ela será sempregenérica, a não ser que o contrário seja dito.

3ImplementaçãoEste capítulo apresenta a implementação do Ginga-NCL para dispositivosportáteis, baseada no perfil Basic DTV da linguagem NCL. Sua implementaçãofoi baseada na implementação de referência do Ginga-NCL para dispositivosfixos, que é descrita resumidamente na Seção 3.1 desta dissertação. Da Seção3.2 em diante, são analisados os problemas surgidos na nova implementação,as soluções oferecidas e as principais diferenças entre a implementação dereferência para dispositivos fixos e a que está sendo apresentada nestadissertação. A Seção 3.2 apresenta as API’s básicas da plataforma SymbianC++, sua similaridade com a linguagem C++ e sua incompatibilidade com abiblioteca STL (Standard Template Library). A Seção 3.3 descreve os desafiossuperados na modificação do procedimento de parser do documento NCL para aversão portátil. A Seção 3.4 trata do uso e da necessidade da substituição daimplementação da thread POSIX (Portable Operating System Interface forUNIX) por um outro recurso mais apropriado à plataforma Symbian C++, o ActiveObject, descrito na Seção 3.5. A Seção 3.6 explica como e por que o tratamentode âncoras temporais teve que ser alterado. A Seção 3.7 apresenta osexibidores de mídia com suporte no Symbian e o desafio de implementá-los, afim de substituírem aqueles usados na implementação de referência paradispositivos fixos do Ginga-NCL. Por fim, a seção 3.8 tece algumasconsiderações finais acerca da implementação apresentada.3.1.A implementação de referência para terminais fixosA implementação de referência do Ginga-NCL para terminais fixos foidesenvolvida em C++ para plataformas que utilizam o sistema operacional Linux.A Figura 1 e a Figura 2 ilustram a arquitetura do middleware Ginga.Na Figura 1, a camada de serviço específico é apresentada. É possívelobservar a divisão do Ginga no ambiente declarativo Ginga-NCL, quecorresponde à máquina de apresentação, e no ambiente procedural Ginga-J,

Implementação 24que corresponde à máquina de execução. Nesta dissertação, como já foi dito,apenas o Ginga-NCL é abordado, pois é o único ambiente obrigatório emreceptores portáteis. Os módulos mais importantes da máquina de apresentaçãosão o Conversor e o Gerenciador de Exibidores, que estão representados naFigura 1.Figura 1: Camada de Serviço Específico do Ginga. Retirado adaptado de (Soares,Rodrigues e Moreno, 2007).A Figura 2, por sua vez, apresenta a camada de núcleo comum daarquitetura Ginga. Essa camada possui módulos que servem tanto para o Ginga-NCL quanto para o Ginga-J, ou seja, ambas as máquinas fazem uso dessacamada. Os módulos mais importantes, representados na figura, são: Exibidoresde Mídia, ou simplesmente Exibidores, Gerenciador do Módulo de Apresentação,Sintonizador, Filtro de Seções e Processador de Fluxos de Dados.Figura 2: Núcleo Comum do Ginga. Retirado e adaptado de (Soares, Rodrigues eMoreno, 2007).A máquina de apresentação é responsável por controlar a execução dasaplicações NCL. A implementação dessa máquina, assim como aimplementação do middleware como um todo, foi feita em C++ utilizando a STL astd lib e API’s POSIX. Um documento NCL, descrevendo uma aplicação, deveser processado pela máquina de apresentação antes que o controle da aplicaçãopropriamente dita possa ser realizado.

Implementação 25Por ser uma aplicação XML, o processamento de um documento NCL seinicia pelo emprego de um parser XML. O módulo Conversor, que faz parte damáquina de apresentação, é responsável justamente por fazer esseprocessamento, traduzindo o documento NCL recebido da emissora, ou dequalquer outra fonte, em uma estrutura baseada no modelo NCM (NestedContext Model) (SOARES et all, 2003), o modelo conceitual da linguagem NCL.A partir dessa estrutura, a máquina de apresentação cria um modelo deexecução que é, então, usado no controle da aplicação NCL. O móduloconversor foi implementado com base no framework para parsers DOM(Document Object Model) especificado em (Silva, Rodrigues e Soares, 2005) efazendo uso da biblioteca libxerces-c, que implementa um parser DOM paradocumentos XML.Uma vez tendo o modelo de execução montado, a máquina deapresentação inicia a apresentação da aplicação NCL. Para realizar a exibiçãodas mídias da aplicação NCL em execução, a máquina de apresentação faz usodos exibidores, ou objetos de execução. Os objetos de execução, pertencentesao módulo Exibidores da Figura 2, são responsáveis por tratar as diferentesmídias que podem ser usadas em uma aplicação NCL. Os exibidores abstraem ouso das API’s de mídia, que são específicas de plataforma, contribuindo paraque o funcionamento da máquina de apresentação seja independente deplataforma. Existe um exibidor para cada tipo de mídia diferente e fica a cargo doGerenciador de Exibidores, um outro módulo da máquina de apresentação,realizar a instanciação desses elementos. Uma vez instanciados, os conteúdos aserem exibidos devem ser apresentados em uma determinada região da tela dodispositivo em que a aplicação NCL está sendo executada, de acordo com aespecificação da aplicação.Cabe à máquina de apresentação determinar em qual região um exibidorassociado a uma mídia qualquer deve ser instanciado. Em outras palavras, é deresponsabilidade da máquina de apresentação o controle das regiões definidasem uma aplicação NCL e a associação dos exibidores a essas regiões.Para fazer o acesso à tela do dispositivo, a máquina de apresentação fazuso do Gerenciador do Módulo de Apresentação. Tal gerenciador abstrai oacesso das possíveis camadas gráficas definidas pelo sistema de TV Digital eainda o uso das API’s de acesso à tela do dispositivo, que são específicas deplataforma. Essa abstração feita pelo Gerenciador do Módulo de Apresentaçãotambém contribui, assim, para que o funcionamento da máquina deapresentação seja independente de plataforma. O acesso às regiões da tela,

Implementação 26bem como sua manipulação, é feita pelo Gerenciador do Módulo deApresentação através da biblioteca DirectFB (directfb.org | Main, 2008).Diversas bibliotecas são utilizadas pelo módulo Exibidores. Adecodificação por software de vídeos e de qualquer outro tipo de mídia contínuaé feita com o uso da libxine. Imagens png, jpg, gif, tiff e bmp, são tratadas pelasbibliotecas libpng, libjpeg e libtiff. Por fim, documentos HTML são tratados pelatelemidia-links. Mais informações sobre os exibidores e o acesso às camadasgráficas são encontradas em (Moreno, 2006: 74-81) e em (Moreno, 2006: 82-84).Os módulos da camada Núcleo Comum usados na recepção de dadospelo fluxo de transporte (TS — transport stream), são o Sintonizador, o Filtro deSeções e o Processador de Fluxo de Dados.O módulo Sintonizador permite que a máquina de apresentação sintonizeem um canal específico com o objetivo de receber um fluxo de transporteenviado pela emissora. Informações mais detalhadas desse módulo podem serencontradas em (Moreno, 2006: 66-69). O fluxo de transporte enviado pelaemissora pode, por sua vez, transportar, ao mesmo tempo que o vídeo e o aúdioprincipal de um programa, dados diversos. Dados no formato de estrutura desistema de arquivos são transportados pelo carrossel de objetos DSM-CC emseções privadas DSM-CC, conceito discutido com detalhes em (Moreno,2006:22-32). O módulo Filtro de Seções é usado com o objetivo de filtrar asseções do fluxo de transporte, conforme detalhado em (Moreno, 2006: 69-70).O módulo Processador de Fluxo de Dados, por sua vez, é usado notratamento do protocolo DSM-CC que, entre outras funcionalidades, define ofuncionamento do carrossel de objetos, usado na transmissão cíclica de dados(Moreno, 2006). O mesmo módulo é responsável por lidar também com eventosde fluxo, que também fazem parte do protocolo DSM-CC. Mais detalhes acercadesse protocolo e do Processador de Fluxo de Dados podem ser encontrados,respectivamente, em (Moreno, 2006: 32-39) e (Moreno, 2006: 70-74).Dos elementos apresentados resumidamente nesta seção, a máquina deapresentação, o Gerenciador de Exibidores, o Conversor, o modulo Exibidores eo Gerenciador do Módulo de Apresentação foram implementados na versão doGinga-NCL para dispositivos portáteis. As especificidades dessa implementaçãosão apresentadas nas seções seguintes.Como os receptores disponíveis no mercado não dispunham de recepçãona modulação SBTVD-T (modulação ISDB), os módulos Sintonizador, Filtro deSeções e Processador de Fluxo de Dados — usados no tratamento do fluxo detransporte — não foram implementados, ficando como trabalhos futuros a serem

Implementação 27realizados. Para a simulação de funcionamento, programas de TV préarmazenadosno dispositivos foram utilizados.3.2.Symbian C++, a API Base e a STLO desenvolvimento de aplicações na plataforma do Symbian OS é feitocom o uso da linguagem Symbian C++, que, por sua vez, é baseada nalinguagem C++. Symbian C++ possui uma série de API’s, mas a mais básicadelas é a API Base (Symbian Ltd, Nokia, 2006), como indica o próprio nome. Alinguagem Symbian C++ e a API Base possuem algumas diferenças dalinguagem C++ e das API’s básicas usadas na implementação de referência doGinga-NCL para dispositivos fixos. Essas diferenças tiveram que ser tratadascom cuidado na implementação do Ginga-NCL para dispositivos portáteis. Estaseção apresenta, primeiramente, as principais diferenças da linguagem SymbianC++ e sua API Base para a linguagem C++ e suas API’s básicas. Em seguida,apresenta como essas diferenças foram tratadas na atual implementação.Um recurso comum muito utilizado na linguagem C++ são as exceções. Ouso de exceções em Symbian C++ não era suportado inicialmente (Morley,2007). Ao invés delas, o uso de recursos nativos da plataforma Symbian, osLeaves e as TRAPS (Symbian Ltd, Nokia, 2006), era a solução oferecida pelalinguagem. Posteriormente, as exceções passaram a ser suportadas e atémesmo recomendadas por consumirem menos ciclos de CPU que os Leaves eTRAPS, e por serem compatíveis com o padrão da linguagem C++. Entretanto,existem algumas diferenças na implementação desse recurso no Symbian porconta do seu consumo de memória.Cada exceção exige a alocação de um espaço de memória e, nalinguagem C++, mais de uma exceção pode ser lançada ao mesmo tempo. Essaação, chamada de lançamento aninhado de exceções, pode ocorrer quando umaexceção é lançada no destrutor de um objeto qualquer, como é explicado em(Morley, 2007). Como o lançamento de exceções em destrutores é algoplausível, torna-se impossível saber o quanto de memória uma aplicaçãoprecisará alocar para permitir o uso de exceções. Se, no entanto, o lançamentoaninhado de exceções nunca ocorrer, ou seja, se exceções nunca foremlançadas em destrutores de objetos, é garantido que o espaço de memórianecessário seja exatamente o de uma única exceção.

Implementação 28Como a alocação do espaço de memória poderia ser proibitivo se mais deuma exceção fosse lançada ao mesmo tempo, Symbian C++ proíbe olançamento aninhado de exceções. Quando isso acontece, a aplicação que o fezé simplesmente abortada. Isso garante a necessidade de uma única alocação dememória para o uso de exceções ao longo de toda a vida do programa. Sendoassim, existe a necessidade de se remover quaisquer lançamentos aninhados deexceções de códigos portados para a plataforma Symbian. Essa resolução emais detalhes sobre o uso de exceções em Symbian são encontrados em(Morley, 2007).Felizmente, a implementação de referência do Ginga-NCL paradispositivos fixos faz pouco uso de exceções, e que nunca são lançadas deforma aninhada. Assim, o uso desse recurso não precisou ser modificado naimplementação para dispositivos portáteis. Chama-se a atenção, no entanto,para o problema, quando do porte de outras implementações Ginga-NCL quepossam vir a fazer uso de exceções aninhadas.O tratamento de exceções foi a única diferença encontrada entre alinguagem Symbian C++ e a C++. Problemas maiores são vistos no uso da APIBase do Symbian OS com o objetivo de se substituir as API’s básicas usadas naimplementação de referência do Ginga-NCL.A API Base do Symbian possui as estruturas mais simples que podem serusadas na implementação de uma aplicação qualquer. Nessa API, todos os tiposbásicos encontrados na linguagem C++ são redefinidos. Muitos desses tipossão, na verdade, meras re-declarações. Como exemplo, tem-se o TInt, um tipodefinido pela API Base, que é, na verdade, um typedef para o tipo básicosigned int. A afirmação é verdadeira para todos os tipos básicos integrais e,portanto, nesses casos, é seguro fazer uso desses tipos diretamente. Nosdemais casos, como o do TChar, substituto do char, são definidas novas classesna API Base, sendo o uso delas recomendado, mas não obrigatório, nem crítico.A recomendação de uso desses tipos específicos do Symbian serve mais paraforçar os programadores a manterem uma padronização no código do que paraaumentar a sua eficiência. Ou seja, essa recomendação não precisa ser seguidapara fins de porte.Com base nas afirmações do parágrafo anterior, todos os tipos básicosusados na implementação de referência do Ginga-NCL para dispositivos fixos,tanto na máquina de apresentação como em outros módulos, não forammapeados em tipos Symbian C++, ou seja, o porte foi feito de forma direta. Por

Implementação 29outro lado, todo o código novo inserido na implementação fez uso exclusivo daAPI Base.A implementação para dispositivos fixos do Ginga-NCL faz uso destrings, threads e mutexes, além de outras API’s std lib e POSIX. Isso simcausou, de fato, um problema de porte, uma vez que a API Base tem a suaprópria definição para esses elementos, que são incompatíveis com aqueles dastd lib e do POSIX.Para o problema mencionado no parágrafo anterior, foram criados oP.I.P.S. (P.I.P.S. Is Posix on Symbian) e o Open C. A Symbian Ltd, a pedido dacomunidade de desenvolvimento Symbian, iniciou o desenvolvimento do P.I.P.S.com o objetivo de facilitar o porte de aplicações desenvolvidas em C/C++. Essabiblioteca, entretanto, não cobre todas as API’s POSIX nem toda a std lib. Emdecorrência, a Nokia desenvolveu o Open C, um superset do P.I.P.S. para oS60, cuja implementação cobre um pouco mais o oferecido pelas API’s POSIX ea std lib, mas não ainda a sua totalidade. Maiores informações sobre opercentual das bibliotecas implementadas pelo P.I.P.S. e Open C podem serencontradas em (Forum Nokia, 2007: 6).Felizmente, na implementação do Ginga-NCL para dispositivos portáteis, oP.I.P.S. e o Open C cobriram o uso de todas as funcionalidades requeridas, oque inclui strings, threads e mutexes. A Seção 3.4 desta dissertaçãodemonstra, entretanto, que o uso de threads não pôde ser mantido naimplementação do Ginga-NCL para dispositivos portáteis.A implementação de referência do Ginga-NCL para dispositivos fixostambém faz muito uso de outros elementos complexos, como vetores, conjuntose listas, lançando mão da API STL. O problema aqui é que a API Base definenovas classes para esses elementos, que são completamente diferentesdaquelas definidas na STL.Uma solução para esse problema foi criar um mapeamento próprio dasclasses STL utilizadas na implementação de referência do Ginga-NCL paraclasses correspondentes da API Base. Como as classes da STL e da Base sãomuito diferentes entre si, tendo, normalmente, assinaturas de métodos muitodistintas, o mapeamento proposto tornou-se muito difícil. No caso da classe STLmap, não existe nem mesmo uma classe correspondente no Symbian quepudesse ser usada de forma adequada. A classe mais próxima da map definidapela API Base é a TBTreeFix (Symbian Ltd, Nokia, 2006), queusa uma árvore B para armazenar Valores relacionados às suas respectivasChaves. Contudo, essa API possui uma forte restrição, pois Valor e Chave

Implementação 30devem sempre possuir um tamanho fixo em bytes. Isso significa que todas asChaves inseridas em um objeto TBTreeFix devem possuir um tamanho fixo iguala X, e que todos os Valores inseridos devem ter tamanho fixo igual a Y, onde X eY são quaisquer números em bytes. Isso tornou a substituição da map pelaTBTreeFix inoportuna, uma vez que os objetos usados pela implementaçãopossuem tamanhos indefinidos. Seria necessário definir tamanhos máximos paratodos os objetos e garantir que todos tivessem exatamente esses valores,mesmo que precisassem, na prática, ocupar espaços menores.Uma opção muito mais simples foi implementar uma map própria, criandoduas listas, uma para armazenar as Chaves e a outra para armazenar osValores. As duas listas ficam relacionadas entre si e são ordenadascrescentemente por ordem de Chave. A solução proposta não causa gastodesnecessário de memória, fator importante no escopo dos dispositivosportáteis, e o tempo de busca por um elemento na lista não é substancial, umaver que o uso das maps no Ginga-NCL é bem simples e com poucas entradas. Acriação dessa map específica resolveu, portanto, o problema daincompatibilidade da classe map STL com a plataforma Symbian de formaeficiente.Uma outra incompatibilidade encontrada foi no uso de iterators. Esse éum recurso provido pela STL usado para realizar interações em estruturas delista. Esse recurso, entretanto, simplesmente não existe na API Base doSymbian. Diferentemente do caso das maps, a solução para esse problema foisubstituir todas as ocorrências encontradas de uso de iterators por um outroprocedimento de interação sobre listas equivalente.Essa solução de mapeamento foi usada em uma parcela daimplementação do Ginga-NCL para dispositivos portáteis com sucesso, masdemonstrou-se muito problemática. Se toda a implementação do Ginga-NCLfosse feita com o uso dessa solução de mapeamento, boa parcela do códigooriginal teria que ser desnecessariamente modificada. Isso poderia introduzirerros que, depois, seriam de difícil remoção.Outros programadores da comunidade Symbian também experimentaramo mesmo problema e, tendo consciência disso, a Symbian Ltd começou aimplementar um porte da STL para o sistema operacional Symbian. Todavia,essa implementação ainda não havia terminado quando o desenvolvimento doGinga-NCL para dispositivos portáteis foi iniciado. Dessa forma, ou mantinha-sea solução do mapeamento das API’s já descrita, o que consumiria muito tempo epoderia gerar erros, ou tentava-se realizar, por conta própria, o porte de alguma

Implementação 31implementação STL existente para o Symbian. Essa última opção poderiatambém consumir muito tempo. Além disso, a implementação STL escolhidapara o porte teria que ter sido desenvolvida com a preocupação no uso derecursos, caso contrário, a implementação do Ginga-NCL poderia ficar muitopesada para ser executada nos dispositivos portáteis.Um dos membros da comunidade Symbian, entretanto, fez um porteeficiente de uma implementação STL para o Symbian. Essa implementação é aSTLPort (STLPort, 2001), que foi desenvolvida em ANSI C++ de maneiraotimizada, visando ao máximo a eficiência. Com essas características, a APISTL em questão pode ser portada para plataformas embarcadas ou comrestrições de recursos sem muitos problemas. O porte dessa API para oSymbian pode ser obtido em (Jez, 2007). A sua instalação e uso são simples,bastando apenas fazer a referência correta aos headers e ligar estaticamente aúnica biblioteca necessária, a stlport_s.lib. Feito isso, o código com referências aSTL compila e executa normalmente. Não foi observada nenhuma degradaçãodo sistema devido ao uso dessa biblioteca. Sendo assim, a solução para oproblema da STL foi considerado resolvido com o uso desse porte, tendo sidoabandonada por completo a solução de mapeamento descrita.3.3.Parser do Documento NCLÉ possível enumerar dois tipos de parser XML: o SAX (Simple API forXML) e o DOM (Document Object Model) parser.O primeiro oferece uma API simples e eficiente para o tratamento dedocumentos XML. O SAX percorre todo o documento apenas uma vez e, duranteesse processo, lança eventos. Esses eventos indicam o início de uma tag, o fimdela, o início ou o fim de um documento como um todo, dentre outras ações.Para utilizar o SAX, uma aplicação precisa implementar funções que recebam etratem esses eventos. Essas funções, quando chamadas, são supridas de todasas informações necessárias, como os atributos de uma tag. Por conta dessemodelo, o SAX possui uma API leve, principalmente em termos de consumo dememória, pois, uma vez que o evento foi tratado, nada mais referente a ele ficaalocado. O problema no uso dessa API é o fato do desenvolvimento tornar-semais complicado. Não é possível, por exemplo, obter dados sobre uma tag quejá foi tratada. Assim, se uma aplicação precisa de informações do XML em

Implementação 32diferentes momentos, ou se precisa adicionar alguma informação ao documento,o SAX pode não ser uma boa opção.O DOM parser, por sua vez, monta um modelo de árvore em memória apartir de um documento XML qualquer. Esse modelo é como qualquer outroobjeto, podendo ser alterado e usado sem grandes dificuldades. Por outro lado,como o DOM armazena e mantém o modelo em memória, usá-lo em dispositivosque possuem restrições de recursos não é muito indicado.Estudos comparativos entre DOM e SAX são feitos em (Violleau, 2002),(Oren, 2002), (Devsphere, 2007) e (Franklin, 2007). Foram feitos testesempíricos de desempenho em relação ao consumo de memória e deprocessador nesses estudos, e os resultados demonstram a superioridade doSAX nesses aspectos. Entretanto, mesmo com as vantagens do SAX, a versãooriginal do Conversor desenvolvida para a implementação de referência doGinga-NCL em dispositivos fixos, descrito no Item 3.1, foi feita com o uso doDOM parser.A natureza do Ginga-NCL aparentemente não exige que sejam feitosmuitos acessos ao documento NCL, e qualquer alteração que precise ser feitana aplicação pode ser aplicada diretamente no seu modelo NCM associado.Essas características do Ginga-NCL fazem com que o uso do DOM parser nãoseja necessário. Em especial, levando-se em consideração que o estudo destadissertação lida com dispositivos que possuem limitações de recursos, o uso doDOM parser torna-se oneroso. A Symbian e a própria comunidade dedesenvolvimento recomendam sempre o uso do SAX para a realização do parserde documentos XML em dispositivos portáteis. Assim, dada a evidência da faltade necessidade do uso do DOM parser, do seu gasto elevado de recursos e dasrecomendações da Symbian, o seu uso no módulo Conversor foi substituído peloparser SAX na implementação do Ginga-NCL para dispositivos portáteis.Sabe-se que o módulo Conversor da implementação de referênciarealizava o parser do documento NCL fazendo uso de um framework paraparsers DOM especificado em (Silva, Rodrigues e Soares). Esse framework teveque ser estudado para que o funcionamento do módulo em questão pudesse serreformulado a fim de se remover as particularidades existentes do parser DOM.Por outro lado, a parte específica do Ginga-NCL, que cria a estrutura NCM, foimantida e adaptada para funcionar com o parser SAX. Essa adaptação gerou,para cada tag presente na linguagem NCL, uma função específica que cria oelemento NCM correspondente.

Implementação 33No Symbian, a API que realiza o parser de documentos XML não égenérica. No caso da plataforma S60, essa API se resume à classe CParser, umparser SAX de documentos XML. Para ser iniciado, o parser SAX em questãorecebe o documento XML, no caso um documento NCL, e o analisa do início atéo fim em busca de tags. Quando o parser descobre a existência de uma novatag, uma notificação é feita através de uma chamada a funçãoOnStartElementL, que, por sua vez, chama a função específica da tagencontrada, que irá criar o elemento da estrutura NCM correspondente. Oprimeiro problema encontrado foi o fato das chamadas feitas à funçãoOnStartElementL serem independentes, o que impossibilita saber qual tag foitratada antes ou qual será tratada depois. Para exemplificar o problema, a Figura3 mostra um documento NCL simples.Figura 3: Exemplo simples de uma aplicação NCL.Neste documento, um elemento encontra-se dentro de umelemento , que, por sua vez, está contido em um documento NCL. Naestrutura NCM, isso é representado por um objeto chamado NclDocument, quecontém um Context, representando o nó body, e que, por sua vez, deve contero nó de media com id igual a video. O parser precisa, portanto, criar essaestrutura e, para isso, precisa saber quem contém quem. Quando o parser SAX

Implementação 34chama a função OnStartElementL para o nó media, não existe qualquer formade saber se esse nó faz parte do body ou de um outro nó de contexto. O parserperde essa informação e, portanto, seria impossível criar a estrutura NCMrequerida. Esse problema não acontece no uso do parser DOM, uma vez que émontada uma árvore representando todo o documento XML. Nesse caso, bastafazer uma busca em profundidade nessa árvore para criar toda a estrutura domodelo NCM.No caso do parser SAX, a solução para o problema foi pensar noprocedimento de parser, que percorre o arquivo do início até o seu fim, comouma busca em profundidade propriamente dita. A Figura 4, baseada na NCL daFigura 3, ajuda a ilustrar esse pensamento onde a estrutura do documento NCLé vista como uma árvore.Figura 4: Documento NCL como uma árvore.Para tratar a estrutura do documento NCL como uma árvore, duasinformações são importantes: o início e o fim de uma tag. Pode-se dizer como astags estão compostas (aninhadas) no documento NCL usando apenas essasduas informações. Por exemplo, olhando a Figura 4, sabe-se que “regionBase” e“descriptorBase” fazem parte do “head”, porque essa tag começa antes etermina depois das outras duas. Em suma, toda tag pai da composição iniciaantes e termina depois das suas tags filhas. Assim, bastariam essas duas

Implementação 35informações para que se fosse possível enxergar o documento como umaárvore. As funções OnStartElementL e OnEndElementL do parser SAX emquestão podem ser usadas exatamente para alcançar esse objetivo, pois aprimeira informa o início, e a segunda, o fim de uma tag. Levando-se em conta oque já foi dito, é possível perceber que o procedimento de parser, que lê oarquivo NCL de cima para baixo, age, portanto, da mesma forma que uma buscaem profundidade.Como já foi dito, para montar a estrutura NCM corretamente, é precisosaber quem contém quem, e o primeiro passo para se descobrir isso é tratar oparser SAX como uma busca em profundidade, como apresentado.É possível usar uma estrutura de pilha para o armazenamento docaminhamento feito por uma busca em profundidade. Esse procedimento, em si,é bem conhecido e, se aplicado, quando a busca exemplificada alcançar oelemento desejado, teremos na pilha dos elementos todos os seus ancestrais.Essa é exatamente a informação necessária para a construção da estruturaNCM. Basta, portanto, acessar a pilha para descobrir a qual nó o elementocorrente pertence.Quando uma tag é tratada, o objeto NCM correspondente deve ser inseridona pilha. Quando a tag termina, culminando na chamada da funçãoOnEndElementL, o elemento do topo da pilha deve ser removido. É garantidoque o topo da pilha sempre corresponde ao elemento que está terminando, poistoda tag que é aberta deve ser fechada, caso contrário, o documento NCL estaráinválido (mal formado). Ressalta-se que, para passar pelo procedimento deparser aqui descrito, o documento NCL precisa ter sido validado antes.Considerando a NCL presente na Figura 3 sem a tag “head” e suas filhas,o procedimento parser descrito funcionaria da seguinte forma:1- Início do Parser.2- OnStartElementL da tag “ncl”. O elemento NCM NclDocument éarmazenado na pilha.3- OnStartElementL da tag “body”. O elemento NCM Context é inseridodentro do elemento que se encontra no topo da pilha, que, no caso, é oelemento NclDocument. Depois disso, Context é inserido na pilha.4- OnStartElementL da tag “port”. O elemento NCM Port é inseridodentro do elemento que se encontra no topo da pilha, que, no caso, é oelemento Context. Depois disso, Port é inserido na pilha.5- OnEndElementL da tag “port”. O topo da pilha, que contém o elementoPort, é removido.

Implementação 366- OnStartElementL da tag “media”. O elemento NCM ContentNode éinserido dentro do elemento que se encontra no topo da pilha, que nocaso é o elemento Context. Depois disso, ContentNode é inserido napilha.7- OnEndElementL da tag “media”. O topo da pilha, que contém oelemento ContentNode, é removido.8- OnEndElementL da tag “body”. O topo da pilha, que contém o elementoContext, é removido.9- OnEndElementL da tag “ncl”. O topo da pilha, que contém o elementoNclDocument, é removido.10- Fim do parser.O procedimento descrito estaria correto se não fosse por um segundoproblema. A tag “media” precisa ser tratada antes da “port”, por ser referenciadapor ela. Existem, na NCL, algumas tags semelhantes a essa que dependem deoutras. Sendo a NCL uma linguagem declarativa baseada em XML, a ordem emque as tags aparecem no documento, exceto a “head” e a “body”, não deveinfluenciar no comportamento da aplicação resultante.Para contornar esse problema duas soluções foram pensadas. A primeiraseria realizar mais de uma vez o parser no documento NCL. O número de vezesseria determinado pelo nível de dependência das tags. Por exemplo, uma tag“port” depende da “media”, porque faz referência a um elemento desse tipo.Nesse caso, seriam necessárias duas passadas completas pelo documentoNCL, uma para identificar as tags “media” e outra para tratar a tag “port”. A fimde evitar uso desnecessário de processamento, essa opção foi descartada. Asegunda solução seria armazenar, temporariamente, as tags dependentesencontradas, que seriam tratadas depois, em um momento mais oportuno. Essaopção foi implementada devido ao fato da estrutura de armazenamento serpequena e do seu descarte ser completamente efetuado após o tratamento dastags dependentes.Para entender o funcionamento da solução proposta, é preciso saber comofuncionam as relações de dependência entre tags NCL. As relações dedependência são sempre entre duas irmãs de uma mesma relação decomposição, onde uma delas é sempre independente. Existe uma exceçãodessa regra para as tags “medias” que usam o parâmetro “refer”. Nesse caso, arelação de dependência pode ocorrer entre tags de composições diferentes. Aimplementação do Ginga-NCL para dispositivos fixos já possui um tratamento

Implementação 37especial específico para esse caso que evita o acontecimento de erros e que foi,portanto, mantido.Uma outra exceção é a dependência que tags contidas no elemento possuem de outras pertencentes ao elemento . Isso não geraproblemas, pois é garantido que todas as tags contidas no head serão tratadasantes daquelas pertencentes ao body. Isso é verdade porque o nó head deveobrigatoriamente ser sempre declarado antes do body, e o procedimento deparser é sempre feito do início até o fim do documento ncl.Para o caso geral de dependência, onde tags do nó body dependem deoutras tags do nó body ou onde tags do nó head dependem de outras do nóhead, é preciso esperar que o objeto ao qual a tag dependente faz referênciaseja tratado para, somente então, lidar com ela. Considerando, portanto, o casogeral, é garantido que, ao término do tratamento da tag pai de uma composição,todas as suas tags filhas independentes tenham sido criadas. Restariam as suasfilhas dependentes, mas, como as suas irmãs já foram tratadas, é seguro, nessemomento, cuidar delas. Sendo assim, tags dependentes são sempre tratadas nomomento em que a sua tag pai na relação de composição esteja terminando.Para isso, é usada a estrutura de armazenamento representada na Figura 5.Figura 5: Diagrama de Classes da estrutura usada para resolver o problema dasdependências entre tags.A classe HandledTag armazena o objeto NCM referente à uma tag que játenha sido tratada na sua propriedade de nome NCLElement e é, então, inserida

Implementação 38na pilha. Quando uma tag filha dependente é encontrada, uma instância daclasse DependentTag é criada para armazená-la. Esse objeto é, por sua vez,inserido na lista de pendências da HandledTag que armazena o objeto NCM dasua tag pai na composição. Uma DependentTag também possui uma lista dependências, pois, enquanto a tag dependente não tiver sido tratada, todas assuas tags filhas também não poderão ser e, portanto, deverão ser colocadas nasua lista de pendências como tags dependentes. Quando uma tag paiindependente termina, a sua lista de pendências é tratada. O mesmo é feito coma lista de pendências de cada tag dependente que for tratada. Para exemplificaro procedimento de parser, agora sem erros, considere novamente a NCLpresente na Figura 3. O parser, apenas para a tag “body”, funcionaria daseguinte forma:1- Início do Parser.2- OnStartElementL da tag “ncl”. O elemento NCM NclDocument éarmazenado na pilha.3- OnStartElementL da tag “body”. O elemento NCM Context éinserido dentro do elemento que se encontra no topo da pilha,que, no caso, é o elemento NclDocument. Depois disso, Contexté inserido na pilha.4- OnStartElementL da tag “port”. O elemento NCM Port é umatag dependente e é inserido na lista de pendências do objetoContext, que representa a tag “body”. Depois disso, Port éinserido na pilha.5- OnEndElementL da tag “port”. O topo da pilha, que contém oelemento Port, é removido. Como esta é uma tag dependente, alista de pendências não é tratada agora.6- OnStartElementL da tag “media”. O elemento NCMContentNode é inserido dentro do elemento que se encontra notopo da pilha, que no caso é o elemento Context. Depois disso,ContentNode é inserido na pilha.7- OnEndElementL da tag “media”. O topo da pilha, que contém oelemento ContentNode, é removido. Sua lista de pendências estávazia, portanto nada é feito.8- OnEndElementL da tag “body”. O topo da pilha, que contém oelemento Context, é removido e a sua lista de pendências éresolvida. O único elemento existente é o “port”, que pode sertratado agora, uma vez que “media” já foi resolvida. A lista de

Implementação 39pendências do “port” também deve ser resolvida nesse momento,mas, como ela está vazia, nada é feito.9- OnEndElementL da tag “ncl”. O topo da pilha, que contém oelemento NclDocument, é removido. Sua lista de pendências estávazia, portanto nada é feito.10- Fim do parser.3.4.O Uso de Threads“Uma thread pode ser definida como uma sub-rotina de um programa quepode ser executada de forma assíncrona, ou seja, executada paralelamente aoprograma chamador”. (Berenger, Maia, 2002: 86) Em um ambiente multithread,um processo associado a uma aplicação possui pelo menos uma thread,chamada de thread principal. Uma aplicação pode ser totalmente executada nathread principal, ou ter o seu processamento dividido em duas ou mais threadsdiferentes. As diferentes threads de uma aplicação podem ser executadasconcorrentemente ou, no caso de existirem múltiplos processadores,paralelamente.“O conceito de concorrência é o princípio básico para o projeto e aimplementação dos sistemas multiprogramáveis” (Berenger, Maia, 2002: 40) oumultitarefa, onde os programas compartilham os recursos computacionaisdisponíveis. O Symbian é um sistema operacional multitarefa que implementa assuas threads em modo kernel (Harrison, Richard et al, 2004). Além dasthreads, o Symbian também oferece os Active Objects, que podem ser usadoscom o mesmo objetivo das threads. A diferença entre os dois recursos é que osActives Objects são como threads implementadas em modo usuário e que nãosofrem qualquer tipo de preempção (Harrison, Richard et al, 2004).A implementação do Ginga-NCL para terminais fixos faz muito uso dethreads por meio das API’s POSIX. Essas threads são usadas tanto parapermitir ações que executam em paralelo, importantes em aplicações que exijamsincronismo, quanto para resolver outros problemas, como o do tratamento deâncoras temporais, detalhado na Seção 3.6. As API’s de criação e manipulaçãodas threads no Symbian, entretanto, são diferentes daquelas oferecidas peloPOSIX. Como visto na Seção 3.2, o uso de threads POSIX no Symbian só foipossível graças ao P.I.P.S e ao Open C. Assim, o porte das classes que seutilizam de threads POSIX pôde ser feito de forma direta, ou seja, nada da

Implementação 40implementação de referência do Ginga-NCL para dispositivos fixos teve que sermudado.O uso de threads, entretanto, consome muitos recursos, principalmenteos de memória, pois, para cada nova thread, uma nova pilha de execução écriada. Por isso, em um ambiente de dispositivos com limitações de recursos, ouso de threads normalmente não é recomendado. No sistema operacionalSymbian, em específico, a forma preferencial de se implementar uma aplicaçãomultitarefa, como o Ginga-NCL, não é com o uso das threads, mas sim com ouso dos Actives Objects (Harrison, Richard et al, 2004: 41). Entretanto, a fim dese facilitar o procedimento de porte, tentou-se manter o uso das threads. Assimseria possível acelerar o processo de desenvolvimento e garantir a correção doprograma, uma vez que as características da implementação anterior do Ginga-NCL, amplamente testado, seriam mantidas.Um primeiro obstáculo encontrado para manter o uso das threads é o fatode que muitos dos recursos oferecidos pelo Symbian só podem ser usados nathread principal do processo de uma aplicação. Esse problema tem relação como modelo Client-Server Framework (Stichbury, 2004: 167) amplamente utilizadono Symbian para a obtenção, manipulação e posterior liberação de recursos dosistema. Muitos dos recursos só podem ser acessados através desse modelo,onde um cliente solicita a um servidor um objeto que poderá ser usado namanipulação de um recurso qualquer. Esse objeto só pode ser usado na threadonde foi requisitado, e é somente através dele que o recurso associado pode seracessado. Vídeo, áudio e imagem são alguns exemplos de recursos geridos peloClient-Server Framework. Uma lista mais detalhada de recursos geridos por essemodelo é encontrada em (Harrison, Richard et al, 2003: 501).Ao iniciar uma aplicação Symbian, todo um ambiente de execuçãopredefinido é carregado (Harrison, Richard et al, 2004: 99). Esse ambiente inclui,dentre outras coisas, controles para entrada de dados pelo usuário, gráficos eacesso ao sistema de arquivos. Assim, recursos como os de acesso à tela dodispositivo e exibição de gráficos em geral já são carregados por padrão nathread principal do processo de qualquer aplicação Symbian (Harrison, Richardet al, 2004). Como estes são recursos que são usados seguindo o modeloClient-Server Framework, outras threads do processo não podem manipulá-los.Assim, a instanciação e manipulação de objetos específicos de exibição doGinga-NCL, como o exibidor de vídeo, precisam ser feitas na thread principaldo processo de uma aplicação Symbian. Como a implementação de referênciado Ginga-NCL para dispositivos fixos lança diversas threads ao longo da sua

Implementação 41execução, e muitas delas são responsáveis exatamente por instanciar emanipular objetos de exibição, introduziu-se um problema que teve de sercontornado.Para solucionar o problema, e para manter o uso das threads, foi criadoum esquema de requisição entre as threads genéricas do processo e a threadprincipal, onde as primeiras requisitariam instanciações ou ações pré-definidasde objetos, e a segunda as atenderia. A idéia consiste em deixar a threadprincipal em espera pelas requisições, enquanto as outras threads sãoexecutadas e realizam essas requisições durante o seu processamento.A implementação desse mecanismo faz uso de um vetor de requisiçõescompartilhado entre todas as threads. Uma ou mais threads podem, então,armazenar uma ou mais requisições nesse vetor, sinalizando apropriadamente asua ação. Ao ter conhecimento dessa ação, a thread principal trata todas asrequisições pendentes na lista em questão. Ao final, a thread principal volta aaguardar por novas requisições.As threads podem fazer requisições a funções sem retorno, como a deuma ação de “play” de vídeo, e depois continuar a sua execução normalmente.Se for necessária uma requisição a funções com retorno de valor, como métodosdo tipo get, ou a instanciação de objetos, a thread deve, obrigatoriamente,esperar pelo término da requisição, a fim de obter o retorno da função ou oobjeto instanciado. Nesses casos, a thread principal armazena, em umavariável compartilhada, o retorno da função ou o objeto instanciado tão logo arequisição for finalizada. Através dessa variável compartilhada, a threadrequisitante é capaz de recuperar a informação requerida.A solução, embora tenha resolvido o problema, não foi suficiente paramanter o uso das threads na implementação do Ginga-NCL para dispositivosportáteis. Na prática, a implementação das threads fazendo uso da soluçãodescrita mostrou-se extremamente lenta. Isso aconteceu a tal ponto de não serpossível manter o sincronismo em aplicações muito simples, como, por exemplo,a exibição de três imagens na tela. Infelizmente, a compatibilidade com a versãoanterior do Ginga-NCL no uso de threads não pôde ser mantida naimplementação proposta. Em seu lugar, os Active Objects foram usados,conforme descrito na seção seguinte.

Implementação 423.5.Active ObjectsComo foi abordado na seção anterior, o uso de threads não pode sermantido pela implementação proposta. Ao invés delas, optou-se por fazer usodos Actives Objects (Stichbury, 2004). Fazendo uma comparação entre os doisrecursos, é possível perceber a vantagem de se usar os Actives Objects. Atransferência do controle de um Active Object para outro, por exemplo, pode seraté dez vezes mais rápida do que no caso de uma thread (Stichbury, 2004:113). O consumo de memória é outra vantagem: enquanto uma thread podeconsumir, aproximadamente, 4Kb de memória de kernel e 8 Kb de pilha deexecução; um Active Object consome, em média, algumas centenas de Bytes ouaté menos (Stichbury, 2004: 113). A última vantagem que pode ser citada é quenão existe a preocupação com a proteção de dados compartilhados, uma vezque os Active Objects se encontram em uma mesma thread (Harrison, Richardet al, 2004). O único caso onde o uso dos Active Objects não é apropriado équando se deseja criar aplicações de tempo real que exigem tempos de respostamuito pequenos. Nesses casos, o melhor é implementar a aplicação de temporeal em uma thread de alta prioridade (Stichbury, 2004).Em Symbian C++, entretanto, os Active Objects são usados normalmentecom o objetivo de controlar as chamadas às funções assíncronas e o seutérmino. Portanto, para entender melhor o funcionamento dos Active Objects éinteressante entender, antes, o que são funções assíncronas. Uma funçãoassíncrona é aquela que retorna imediatamente após a sua chamada e executaem paralelo ao procedimento que a chamou, normalmente em uma threadseparada. Esse procedimento chamador pode bloquear o seu processamento oucontinuar e realizar outras ações enquanto aguarda pelo fim da funçãoassíncrona. Quando a função assíncrona termina, um evento é lançadoindicando o seu sucesso ou erro. Esse evento deve ser capturado e tratado peloprocedimento que chamou a função assíncrona.Um Active Object é um objeto que estende a classe CActive (Symbian Ltd,Nokia, 2006). As funções assíncronas controladas por um Active Object são neleencapsuladas, e só devem ser chamadas através dele. Embora um Active Objectpossa encapsular mais de uma função assíncrona, apenas uma pode serexecutada por vez. Ou seja, enquanto uma função assíncrona de um ActiveObject estiver sendo processada, uma outra do mesmo objeto não pode serchamada. Se essa restrição for desrespeitada, existem três comportamentos

Implementação 43possíveis: a aplicação é finalizada, a nova chamada não é realizada ou oprocessamento da última função assíncrona é finalizado dando lugar à nova.No Active Object também é implementado o método RunL, que éresponsável por tratar o término das suas funções assíncronas. Esse métodopode ser usado para analisar o resultado da chamada à função assíncrona,realizar algumas finalizações ou até mesmo fazer outra chamada. Em suma,pode-se fazer qualquer ação que se faça necessária.Um Active Object é, portanto, de forma simplificada, um objeto que possuium ou mais métodos que implementam ou realizam chamadas a quaisquerfunções assíncronas, e um outro método responsável por tratar das suasfinalizações. Uma API de vídeo, por exemplo, pode ser um Active Object, sendoa sua função de Open assíncrona. Ao ser chamada pela aplicação, a função emquestão tem iniciada a sua execução em paralelo. A aplicação continua o seuprocessamento e, em um determinado momento, a função Open termina a suaexecução. Então, o método RunL da API de vídeo em questão é chamado, e fazas finalizações necessárias. Ele pode, por exemplo, emitir uma mensagem deerro ao usuário caso o processamento da função Open tenha falhado.Um outro objeto, o Active Scheduler, tem como responsabilidade chamar ométodo RunL do Active Object quando uma das funções assíncronas desseelemento tiver terminado. Quando isso acontece, diz-se que o Active Schedulerfez o escalonamento de um Active Object. Existe apenas uma instância doActive Scheduler por thread e o seu funcionamento é muito parecido com o deum escalonador comum, tendo como diferença básica o fato dele não realizarqualquer tipo de preempção.Para fazer o procedimento descrito, o Active Scheduler define umsemáforo global à thread em que ele se encontra. Esse semáforo deve sersinalizado pelas funções assíncronas quando o processamento delas tiverterminado. Dessa forma, o Active Scheduler sabe quando uma funçãoassíncrona terminou e que, portanto, um Active Object deve ser escalonadoatravés da chamada ao seu método RunL. A função assíncrona também precisaalterar o valor de uma variável interna do seu Active Object associado,denominada iStatus. Essa variável indica se o Active Object tem uma funçãoassíncrona finalizada ou ainda em execução. Essa ação é necessária porque épossível existir mais de um Active Object gerido por um Active Scheduler, e asimples sinalização do semáforo em si não indica qual Active Object teve a suafunção assíncrona finalizada. Ao alterar o valor da variável em questão,

Implementação 44indicando que o Active Object possui uma função assíncrona já finalizada, oActive Scheduler é capaz de descobrir qual Active Object pode ser escalonado.O Active Scheduler fica, então, aguardando até que uma ou mais funçõesassíncronas terminem e façam a sinalização. É importante ressaltar que,existindo mais de um Active Object, mais de uma função assíncrona pode estarsendo processada ao mesmo tempo. Em um cenário desses, duas ou maisdessas funções podem ter terminado antes que o Active Scheduler tenha tido aoportunidade de tratar a primeira delas. Por conta disso, quando o ActiveScheduler for tratar o término de uma função assíncrona, é normal que existamais de um Active Object elegível a ter a sua função RunL executada. Éinteressante, portanto, que o Active Scheduler faça o escalonamento daqueleActive Object que for mais crítico para o sistema, ou seja, aquele que for maisprioritário. Dessa forma, todo Active Object precisa determinar, no momento dasua construção, uma prioridade para si mesmo de tal forma que o ActiveScheduler possa usar essa informação no momento em que estiver fazendo oescalonamento. Um outro ponto importante é que os Active Objects devem serregistrados junto ao Active Scheduler para que possam ser escalonados.Normalmente, um Active Object faz esse registro logo na sua construção, masisso pode ser feito em qualquer momento, desde que antes da chamada a umafunção assíncrona. O Active Scheduler, por sua vez, mantém uma lista de ActiveObjects registrados com base nas suas prioridades, e faz o escalonamento combase nessa lista.Uma vez tendo recebido a sinalização do término de uma funçãoassíncrona, o Active Scheduler escalona o Active Object mais prioritário quepossui uma função desse tipo finalizada e faz a chamada ao seu método RunL.Esse método será executado sem interrupções, até o seu fim, uma vez que nãoexiste preempção no uso dos Actives Objects. Quando o método RunL termina, oActive Scheduler volta a aguardar por novas sinalizações. O funcionamento doActive Scheduler pode ser, portanto, resumido em um loop pelo qual ele:1- Aguarda por uma sinalização de uma função assíncrona que tenhaterminado;2- Recebe a sinalização e busca pelo Active Object de maiorprioridade que possui uma função assíncrona finalizada, o que épossível de se descobrir ao se consultar o valor da variáveliStatus dos Actives Objects;3- Ao final da busca, chama o método RunL do objeto escalonado;

Implementação 454- Quando o método RunL terminar, volta a aguardar por uma novasinalização.A qualquer momento nesse loop, novos Active Objects podem se registrarjunto ao Active Scheduler. Informações mais detalhadas sobre os Active Objectspodem ser encontradas em (Stichbury, 2004: 127).Na implementação apresentada, entretanto, o mais interessante é sabercomo fazer uso do Active Object com o objetivo de suprimir o uso das threadsPOSIX tão utilizadas na implementação de referência do middleware Ginga-NCLpara dispositivos fixos. Para tanto, é recomendado fazer uso dos BackgroundActive Objects (Symbian Ltd, Nokia, 2006), que são Active Objects de baixaprioridade.A idéia é encarar o Background Active Object como uma thread em si. Noseu método RunL deve ser implementado o procedimento que seriaimplementado na função run da thread POSIX. Como não existe preempção nouso dos Active Objects, o método RunL não pode gastar muito tempo durante oseu processamento, pois isso impediria que outros Active Objects, alguns talvezmais prioritários, fossem escalonados por um longo período de tempo. Oprocedimento deve, então, ser implementado no método RunL do BackgroundActive Object de modo que não consuma muito tempo de processamento. Se oprocedimento for muito pesado, ele deve ser dividido em N partes diferentes.Cada uma dessas N partes deve ser leve o suficiente para não consumir muitotempo de processamento do método RunL. A idéia é que a execução dessas Npartes seja feita de forma intercalada, com o objetivo de dar ao Active Schedulera oportunidade de escalonar um outro Active Object de maior prioridade. Porisso que é importante que o Background Active Object possua uma prioridadebaixa, assim, entre a execução de uma das N partes do procedimento e outra, égarantido que outros Actives Objects mais prioritários serão escalonados. Caso oprocedimento seja leve o suficiente para ser executado todo de uma vez, essescuidados não precisam ser tomados.Como já mencionado, um Active Object só fica elegível pelo ActiveScheduler quando o semáforo desse elemento é sinalizado por uma funçãoassíncrona e quando o valor da sua variável iStatus é modificado de formaapropriada. Dessa forma, para iniciar a execução do procedimentoimplementado no método RunL de um Background Active Object, um outrométodo, que aqui será chamado de start, deve ser implementado emsubstituição a função assíncrona. A chamada ao método start deve fazer comque o Background Active Object em questão fique elegível pelo Active

Implementação 46Scheduler. Para isso, o método em questão precisa apenas sinalizar o semáforocontrolado pelo Active Scheduler e atualizar a variável iStatus como já descritonesta seção. Ao chamar esse método, o Background Active Object fica elegívelpelo Active Scheduler e o seu método RunL será chamado assim que nenhumActive Object mais prioritário estiver na fila.Quando o método RunL é chamado, o procedimento implementado nelecomeça a ser executado. Se houve a necessidade de dividi-lo em N partes, umadessas partes é executada e, então, o método start deve ser novamentechamado, fazendo o Background Active Object ficar mais uma vez elegível peloActive Scheduler. Isso permite que o método RunL seja chamado novamentepara que uma outra das N partes do procedimento em questão seja executada.Esse procedimento todo se repete até que todo o método RunL tenha sidoexecutado e o procedimento implementado nele tenha, conseqüentemente,terminado. Se não houve a necessidade de dividir o procedimento em mais deuma parte, então ele é completamente executado logo na primeira chamada aométodo RunL.O único problema da técnica apresentada é modelar, quando necessário, oprocedimento a ser implementado no método RunL adequadamente de tal formaque se possa dividi-lo em N partes.Na implementação Ginga-NCL para dispositivos fixos, o uso de threadsPOSIX possui uma abstração que é representada por uma classe chamadaThread. Essa classe é usada pela máquina de apresentação quando énecessário executar ações concorrentemente. Um exemplo é quando se desejaimplementar um conector onde estejam definidas ações que devem serexecutadas em paralelo (ABNT/CEET-00:001.85, 2007: 54). Nesse caso, amáquina de execução cria e lança, para cada ação, um objeto da classe Thread.Assim, a máquina de apresentação não precisa se preocupar em como essaclasse é implementada, sendo sua única exigência que a classe Thread ofereçapelo menos algum nível de concorrência.O único ponto da implementação original que teve que ser modificado como objetivo de se remover o uso das threads POSIX foi, portanto, aimplementação da classe Thread. No Ginga-NCL para dispositivos portáteis, aclasse abstrata Thread é, na verdade, um Background Active Object. Essasubstituição foi o suficiente para fazer com que as aplicações fossem executadascom maior velocidade. O sincronismo se tornou, então, possível, e aplicaçõesaté dez vezes maiores puderam ser desenvolvidas. Ressalta-se que, embora oBackground Active Object tenha sido utilizado, em nenhum caso houve a

Implementação 47necessidade de se dividir o procedimento implementado no método RunL emmais de uma parte. Ou seja, todos os procedimentos eram leves o suficientepara serem executados de uma só vez.Existe, porém, o caso do tratamento de âncoras temporais, que tambémfaz uso da classe Thread, onde a substituição da implementação das threadsPOSIX pelo Background Active Object introduziu, nesse caso específico, umerro. Esse problema é apresentado juntamente com a sua solução na próximaseção.3.6.O Tratamento de Âncoras TemporaisA substituição das threads POSIX pelos Active Objects introduziu um errono tratamento das âncoras temporais.Para entender como esse erro foi gerado e a sua solução, é necessário,antes, introduzir o conceito de âncoras temporais. Também é importanteapresentar como foi feita a sua implementação na versão do Ginga-NCL paradispositivos fixos.Uma âncora temporal define um intervalo de tempo dentro da duração daapresentação de um elemento de mídia qualquer. Para criar uma âncoratemporal, usa-se o elemento — como em toda a criação de ancoras — eespecifica-se os seus atributos “begin” e “end”. Esses atributos representam,respectivamente, o início e o fim do intervalo relativos ao início da apresentaçãodo conteúdo de mídia. Essa tag deve ser definida como um elemento do nó demídia em que se quer definir um intervalo temporal. Como exemplo, a Figura 6ilustra um cenário onde várias âncoras temporais são definidas.

Implementação 48Figura 6: Exemplo de um documento NCL com âncoras temporais.Um elemento definido em um nó de mídia () pode serreferenciado como uma interface do objeto de mídia, como exemplifica o linklnk1 da Figura 6. Âncoras temporais podem, assim, serem usadas com oobjetivo de se fazer sincronismo temporal entre trechos de mídias. Na Figura 6,quando o vídeo definido tiver completado 5 segundos, uma transição de estadode evento de ”start”, associado à sua primeira âncora, ocorre, indicando o iníciodo intervalo. Analogamente, quando o vídeo alcançar os dez segundos, umatransição de estado de evento de ”stop”, associada a mesma âncora, ocorre,indicando o fim do intervalo. A máquina de apresentação capta essas transiçõesde estados de eventos e, se houver uma ação associada a uma dessastransições, essa ação é executada. Como exemplo, no link lnk1 da Figura 6, é

Implementação 49especificado que a apresentação da imagem1 deve ser iniciada quando aprimeira âncora definida para o vídeo começar sua exibição. A máquina deapresentação capta a transição de estado de evento de início da âncora e iniciaa apresentação da imagem1, conforme especificado.Para implementar uma âncora temporal, precisa-se, basicamente,contabilizar o tempo decorrido da exibição da mídia, lançando as transições deestados de eventos “start” e “stop” nos momentos definidos pelas suas âncoras.Na implementação de referência do Ginga-NCL para dispositivos fixos, amáquina de apresentação dispara, para cada mídia possuidora de âncorastemporais, uma thread separada. Essa thread fica responsável por organizaruma fila crescente com os tempos definidos pelos elementos associados.Essa fila é usada para descobrir os momentos em que as transições de estadosde eventos devem ser disparadas. A Figura 7 ilustra como fica,simplificadamente, a fila do exemplo apresentado na Figura 6:Figura 7: Exemplo de fila de tempos definidos em âncoras temporais.De posse dessa lista, resta à thread contabilizar o tempo da mídia elançar as transições de estados de eventos nos tempos definidos pela fila. Acontagem do tempo decorrido das mídias é sempre feita nos próprios objetos deexibição. No caso de mídias com tempo de duração pré-estabelecido, como asde vídeo ou de áudio, suas API’s de exibição normalmente possuem uma funçãoque retorna o tempo decorrido de apresentação. Quando as mídias nãopossuem tempo de duração definido, ou quando as suas API de exibição nãofornecem uma função que retorne o tempo decorrido de apresentação, aimplementação dos seus exibidores deve, obrigatoriamente, criar um contadorpróprio. Com a fila criada e com a informação do tempo decorrido deapresentação da mídia, a thread realiza o seguinte procedimento de quatropassos:1- Remove o primeiro elemento da fila;2- Calcula a diferença entre o tempo do elemento removido da fila e otempo corrente da mídia. Essa diferença é exatamente o tempo queserá necessário aguardar até que o tempo definido por uma dasâncoras seja alcançado;3- Usa diferença encontrada em um comando de sleep.

Implementação 504- Acorda do comando de sleep. Nesse momento, o tempo definidopor uma das âncoras foi alcançado. A implementação lança,portanto, uma transição de estado de evento de start ou stopdependendo se o tempo alcançado foi de início ou término de umaâncora;Esse procedimento se repete até que a fila tenha se esvaziado. Isso bastapara que o uso de âncoras temporais seja tratado corretamente. Naimplementação apresentada nesta dissertação, no entanto, o uso das threads,como já foi apresentado em seções anteriores, é proibitivo. No lugar delas, foifeito o uso dos Active Objects, que executam todos na thread principal doprocesso associado a aplicação Ginga-NCL.Pelo fato dos Actives Objects se encontrarem em uma mesma thread, achamada a uma função de sleep dentro das funções RunL dos Actives Objectscolocaria todo o processo da aplicação Ginga-NCL em espera, impedindo queoutras ações pudessem ser feitas. O tratamento das âncoras temporais tem,então, de ser feito sem a necessidade de bloquear o Active Object e,conseqüentemente, a aplicação como um todo.A solução para esse problema foi usar um Active Object especial, oCTimer (Symbian Ltd, Nokia, 2006), e implementá-lo como um BackgroundActive Object. CTimer é como um Active Object normal, a não ser pelo fato delejá possuir métodos que encapsulam funções assíncronas de contagem detempo. O mais importante deles é o After, que recebe como parâmetro umtempo a ser aguardado. Quando chamado, esse método chama uma funçãoassíncrona de sistema passando no seu parâmetro o tempo a ser aguardado.Essa função, por sua vez, executa em paralelo ao Active Object e aguarda pelapassagem do tempo especificado no seu parâmetro. Quando o tempo termina, afunção notifica o fato, sinalizando o semáforo do Active Scheduler. Isso faz comque, em algum determinado momento, o método RunL do Active Object emquestão seja chamado pelo Active Scheduler.A solução encontrada para o tratamento das âncoras temporais foi,portanto, realizar a sua implementação no método RunL de um CTimer. Parafazer essa implementação, foi preciso analisar o procedimento de quatro passosnecessário para o tratamento de âncoras temporais. Se observado com cuidado,esse procedimento pode ser dividido em duas partes: A primeira (1) compreendeos passos 1, 2 e 3 do procedimento, sendo que, no passo 3, o método After doCAtive deve ser usado ao invés do sleep. A segunda parte (2) compreende o

Implementação 51passo 4, que ocorre logo depois que o tempo de espera tiver terminado. Essasduas partes foram implementadas separadamente no método RunL do CTimer,que controla o procedimento de âncoras temporais.Para iniciar a execução do método RunL, um outro método teve que serimplementado com o objetivo de fazer com que o CTimer ficasse elegível peloActive Scheduler, como descrito na Seção 3.5. Ao fazer a chamada dessemétodo, o CTimer fica elegível pelo Active Scheduler e, em algum determinadomomento, o método RunL do CTimer é chamado. Quando a função RunL éfinalmente chamada, somente (1) é executado. Assim que o tempo de esperatermina, RunL é novamente escalonado e, dessa vez, (2) é executado com oobjetivo de lançar o evento de “start” ou de “stop” da ancora temporal. Seexistirem mais elementos na fila de tempos definidos pelas ancoras temporais deuma mídia, (1) é chamado novamente, e o ciclo é reiniciado.Implementado dessa forma, o tratamento de âncoras temporais naimplementação do Ginga-NCL para dispositivos portáteis foi minimamentealterado, mantendo as características base da implementação para dispositivosfixos, com a vantagem que o uso de threads foi completamente removido,contribuindo para o funcionamento adequado e otimizado da novaimplementação.3.7.Exibidores no Symbian C++Os exibidores são os elementos responsáveis pela apresentação doconteúdo dos objetos de mídia. Os exibidores dependem da plataforma dedesenvolvimento e, portanto, representam a parcela com mais problemas deportabilidade do middleware Ginga-NCL.Para facilitar o procedimento de porte do Ginga-NCL, uma camada deabstração de exibidores foi desenvolvida desde sua implementação dereferência para dispositivos fixos. Essa camada implementa uma série defunções que devem ser mapeadas nas API’s específicas dos exibidores daplataforma implementada. A máquina de apresentação precisa acessar apenasessa camada a fim de controlar a execução de um exibidor, não tendo anecessidade de se preocupar com as características específicas da plataformade desenvolvimento.

Implementação 52No controle da execução dos exibidores, a máquina de apresentaçãoprecisa associar os objetos de exibição às regiões especificadas pelo documentoNCL. Esse procedimento, em si, exige o acesso ao display do dispositivo, o quetambém é um procedimento específico de plataforma. Pelo mesmos motivos docaso dos exibidores, uma camada de abstração para o acesso ao display dodispositivo foi definida. De forma similar, suas funções devem ser mapeadas emAPI’s específicas da plataforma. A máquina de apresentação usa essa camadapara gerenciar as regiões da aplicação NCL e, assim como no caso dosexibidores, não precisa se preocupar com as características específicas daplataforma de desenvolvimento.Em uma apresentação de uma aplicação NCL, a máquina de apresentaçãocria, primeiro, as regiões definidas no documento NCL. Depois, ao longo daapresentação da aplicação, solicita ao Gerenciador de Exibidores, visto naSeção 3.1, a instanciação dos elementos de mídia e os associa às regiõespreviamente criadas.A máquina de apresentação também pode acessar os exibidores atravésda sua camada de abstração. Isso é necessário para, por exemplo, iniciar,pausar ou parar um vídeo, aumentar ou diminuir o som de um áudio, dentreoutras ações desse tipo. A Figura 8 ilustra o procedimento que acaba de serdescrito, levando em conta as camadas de abstração mencionadas.

Implementação 53Figura 8: Acesso das camadas de abstração dos exibidores e do Display do dispositivopor parte da máquina de apresentação.O procedimento, como um todo, é independente de plataforma, e nãonecessitou sofrer alterações. O que precisou ser feito na implementação correntefoi o mapeamento das camadas de abstração de display e de exibidores para asAPI’s específicas do Symbian.Em Symbian, o acesso ao display é feito através de objetos chamados deWindow. Entretanto, a apresentação de mídias na tela normalmente não é feitaatravés desse recurso. Ao invés dele, usam-se os Controls, já que o uso diretode uma Window consome muitos recursos e é muito complexo. Os Controls, porsua vez, abstraem o uso das API’s providas pela Window e compartilham esserecurso entre si, ou seja, dois ou mais Controls podem fazer uso de uma mesmaWindow. Normalmente, uma aplicação Symbian possui apenas uma Windowassociada, pois a criação de mais objetos desse tipo causaria uma degradaçãodo sistema. Os Controls, portanto, são usados para implementar as diferentesinterfaces de uma aplicação e normalmente compartilham uma única Window.Por exemplo, um Control poderia ser responsável por mostrar uma lista deopções na tela e, um outro, por apresentar uma imagem de fundo. Ambospodem compartilhar a mesma Window, economizando, assim, recursos.

Implementação 54Para implementar um Control, é preciso estender a classe CCoeControl(Symbian Ltd, Nokia, 2006) implementando alguns dos seus métodos abstratos.O mais importante deles é o Draw, que é usado para aplicar alterações na telado dispositivo. Quando um Control é iniciado ou quando o seu método DrawNowé utilizado, a função Draw é chamada. Dentro da função Draw, o objetoCWindowGc (Symbian Ltd, Nokia, 2006), que pode ser obtido através da chamadaa função SystemGc pertencente ao Control, deve ser usado para fazer o desenhona tela. Nesse objeto estão encapsuladas todas as funções de desenho, comodefinição de cor, estilo do pincel, criação de formas geométricas, dentre outras.A apresentação de objetos no display de qualquer dispositivo com o Symbian OSinstalado é feita, portanto, na função Draw dos Controls da aplicação por meio doobjeto CWindowGc. Quando a máquina de apresentação associa, naimplementação proposta, um exibidor a uma região NCL, estará, na verdade,associando-o a um Control criado para aquela região.Uma limitação que pode ser citada na forma como é feito o gerenciamentográfico no Symbian, é a existência de apenas uma camada gráfica deapresentação. Isso significa que imagens e vídeos, ou quaisquer outros objetosde exibição, serão sempre apresentados em uma mesma camada. Umadiferença da implementação aqui exposta em comparação à implementação dereferência para dispositivos fixos é que, para dispositivos portáteis, nenhumobjeto pode ser apresentado por cima de um vídeo. Essa limitação ocorrejustamente por causa da limitação da existência de uma única camada.Entre os vários exibidores de tipos de mídias diferentes, já foramimplementados os de imagem estática, áudio, vídeo e HTML.Para apresentar uma imagem na tela do dispositivo, é preciso usar, dentrodo método Draw de um Control, o método DrawBitmap pertencente à classeCWindowGc. Esse método recebe como parâmetro a posição onde a imagemdeve ser desenhada, além de um objeto do tipo CFbsBitmap, que é usado paracarregar, através do seu método Load, imagens estáticas armazenadas dentrode um buffer ou de algum arquivo em disco. O CFbsBitmap, entretanto, só écapaz de carregar imagens do tipo mbm (Multi-BitMaps), que é um tipoespecífico de imagem usada na plataforma Symbian.O vídeo e o áudio são providos com o uso da Multi Media Framework(MMF), onde são definidas as classes CVideoPlayerUtility eCMdaAudioPlayerUtility, usadas, respectivamente, para tocar vídeos eáudios. O funcionamento dessas duas classes é muito similar. Ambas oferecemfunções idênticas capazes de carregar um vídeo ou um áudio de origens

Implementação 55diferentes. Um exemplo é a função OpenFileL, que abre um vídeo ou áudio deuma arquivo salvo em disco. Caso a abertura do arquivo seja bem sucedida, ométodo Play das classes CVideoPlayerUtility e CMdaAudioPlayerUtilitypode ser usado para começar a tocar o objeto de mídia. Existem outras funçõesnessas classes que podem ser usadas na manipulação das propriedades dovídeo ou do áudio. O vídeo, especificamente, pode ter as suas dimensõesmodificadas pelo seu Control associado, ou seja, o Control pode fazer, quandonecessário, uso das funções de redimensionamento providas peloCVideoPlayerUtility. O áudio, por outro lado, não possui características devisualização e, portanto, não precisaria ter um Control associado, mas essaassociação foi feita mesmo assim com o objetivo de manter a padronização naimplementação.Os dispositivos Symbian possuem uma lista de tipos de áudio e vídeo quepossuem plug-ins associados. As classes CVideoPlayerUtility eCMdaAudioPlayerUtility, quando tentam carregar um objeto de áudio ou devídeo, acessam essa lista para descobrir se o dispositivo possui o plug-inadequado para tocar o elemento que está sendo carregado. Se o dispositivopossuir o plug-in apropriado, quando o comando Play for executado, as classesCVideoPlayerUtility e CMdaAudioPlayerUtility associarão o objeto demídia carregado a esse plug-in, e começarão a tocá-lo. Dessa forma, essasclasses abstraem os tipos de áudio e vídeo que podem ser tocados, ou seja, elaspodem ser usadas para tocar qualquer tipo de mídia de áudio ou vídeo, bastandoapenas que o dispositivo possua os plug-ins necessários.Finalmente, o exibidor HTML também foi implementado. Não existe APIgenérica para a apresentação de documentos HTML no Symbian, portanto foinecessário fazer uso de uma API específica da plataforma S60. Isso significaque o exibidor HTML funcionará apenas em dispositivos específicos dessaplataforma. A classe usada foi a CBrCtlInterface, sendo o mais importantedos seus métodos o LoadUrlL, que carrega uma página HTML de uma URLqualquer. Para criar um objeto da classe CBrCtlInterface é necessário usar afunção estática CreateBrowserControlL, passando o Control associado a esseexibidor em um dos seus parâmetros. Qualquer alteração nesse Control vai, apartir de então, refletir no exibidor HTML.A existência das camadas de abstração descritas facilitou muito oprocedimento de porte dos exibidores, que se tornou algo bem simples e direto.O maior problema encontrado na implementação dos exibidores foi que, apesarde existir documentação para as API’s específicas Symbian, a informação

Implementação 56provida normalmente é muito sucinta e, em alguns casos, insuficiente. Osexemplos encontrados também são muito complexos e acabavam dificultandoainda mais o procedimento de aprendizagem.3.8.Considerações FinaisDurante a implementação do Ginga-NCL para dispositivos portáteis, ficouclara a importância que um sistema aberto e padronizado tem no processo dedesenvolvimento.A plataforma nativa do Symbian, e seu ambiente de desenvolvimentoSymbian C++, foi projetada especificamente para os dispositivos portáteis e émuito particular. As API’s de desenvolvimento Symbian C++, por exemplo,guardam poucas semelhanças com as API’s padrões de desenvolvimento C++,linguagem da qual Symbian C++ se baseia. Isso dificulta qualquer procedimentode porte e força os programadores a aprenderem um novo conjunto de API’s dedesenvolvimento bem diferente daqueles que estão acostumados. Dessa forma,o procedimento de desenvolvimento torna-se muito complexo e pouco atrativopara a plataforma em questão. O fato da plataforma Symbian ser aberta contribuipara a observância desses problemas de padronização e especificidade daplataforma Symbian, e, principalmente, para sua melhora.Com o apoio da comunidade, a Symbian Ltd, criadora do sistemaoperacional Symbian, foi capaz de perceber a importância da padronização deuma plataforma e ofereceu o P.I.P.S.. Mais tarde, a Nokia, que desenvolve a APIespecífica S60, disponibilizou o Open C, o que contribuiu ainda mais para apadronização e, conseqüentemente, para o porte de aplicações desenvolvidasem outras plataformas. A falta da biblioteca STL, usada comumente emprogramas desenvolvidos em C++, também prejudicava o procedimento deporte. Mais uma vez, por ser uma plataforma aberta, um integrante dacomunidade Symbian pôde fazer, com a ajuda da já disponibilizada P.I.P.S., oseu próprio porte de uma implementação STL para o Symbian OS.Os esforços em torno da disponibilização das bibliotecas P.I.P.S, Open C eSTL contribuem muito para o desenvolvimento e o porte de aplicações para aplataforma Symbian, e, conseqüentemente, contribuíram muito para o porte e odesenvolvimento do Ginga-NCL para dispositivos portáteis. No início daimplementação, essas bibliotecas não foram utilizadas, como é descrito naSeção 3.2. A opção foi implementar mapeamentos das API’s utilizadas na

Implementação 57implementação de referência para dispositivos fixos em API’s específicas daplataforma Symbian, o que se demonstrou ser muito complexo e demorado.Quando as bibliotecas P.I.P.S., Open C e STL passaram a ser utilizadas, odesenvolvimento tornou-se mais simplificado. Sem essas bibliotecas, odesenvolvimento completo do Ginga-NCL para dispositivos portáteis seria, semdúvida, muito mais complicado além do que demoraria muito mais tempo.Em outros sistemas abertos, como o Linux, espera-se ter uma facilidade deporte e de desenvolvimento igual ou talvez até mesmo maior do que noSymbian. Por outro lado, sistemas de plataforma fechada, como o BlackBerry,possuem sua própria plataforma de desenvolvimento e provavelmente nãodevem oferecer suporte à maioria das bibliotecas padrão. Isso certamentedificultaria muito o porte e desenvolvimento do Ginga-NCL, como de qualqueroutra aplicação.Outra questão que deve ser mencionada é a alteração do móduloConversor na implementação do Ginga-NCL para dispositivos portáteis. Essatarefa consumiu muito tempo, uma vez que praticamente todo o módulo emquestão teve que ser re-implementado, mantendo-se inalteradas somente assuas interfaces com o resto da arquitetura Ginga-NCL. A experiência obtida coma implementação do módulo Conversor evidenciou que não seria necessáriofazer uso dos recursos oferecidos pelo modelo DOM. Normalmente, o parserDOM é usado quando a estrutura do documento XML é muito complexa, commuitos níveis e muitas referências entre objetos de níveis diferentes, quando énecessário fazer uso pontual da estrutura XML em diversos momentos daexecução do programa, quando é preciso acessar elementos diferentes daestrutura XML em um mesmo momento, ou quando é necessário alterar odocumento XML.Foi possível avaliar, entretanto, que a NCL em si não é suficientementecomplexa a ponto de exigir o uso do DOM na implementação do móduloConversor, que foi re-projetado utilizando a API SAX na versão para dispositivosportáteis. Documentos NCL normalmente não possuem tantos níveis e asreferências entre elementos podem ser resolvidas sem muitas dificuldades.Portanto, nenhuma característica dessa linguagem impede, aparentemente, ouso do SAX, ou exige que o DOM seja usado. Outro ponto que deve serobservado é que também não há a necessidade de fazer acessos repetidos àestrutura do documento NCL. No Ginga NCL, o documento NCL recebido daemissora ou de qualquer outra fonte deve ser convertido em uma estrutura dedados baseada no modelo NCM. A partir de então, somente essa estrutura é

Implementação 58usada, sendo desnecessário acessar novamente o documento NCL e,conseqüentemente, manter a estrutura montada por um parser DOM.Existe, entretanto, um recurso do Ginga-NCL que lida com elementos dalinguagem NCL e que não foi implementado na versão desse middleware paradispositivos portáteis. Esse recurso é o tratamento de edição ao vivo deaplicações NCL. O Ginga-NCL permite que sejam feitas edições ao vivo emqualquer aplicação NCL que esteja sendo apresentada. Para fazer uma edição,um documento NCL específico deve ser entregue ao Ginga-NCL, que, por suavez, o processa e aplica as alterações na estrutura NCM da aplicação que estásendo apresentada. Dessa forma, igualmente para o caso das edições, o uso doDOM parser também não se faz necessário. Sem a necessidade de uso doparser DOM, ficou evidenciado que o SAX demonstra-se muito mais vantajosopela sua eficiência e pelo seu baixo consumo de memória, não só emdispositivos portáteis, mas também em terminais fixos.Uma outra questão interessante que deve ser salientada diz respeito aouso das threads na implementação para dispositivos portáteis, o quedemonstrou claramente o problema das limitações de recursos encontradasnesses dispositivos. Como foi apresentado nesta dissertação, o uso de threadsPOSIX na implementação do Ginga-NCL para dispositivos portáteis tornou-seproibitivo, fazendo com que a execução das aplicações NCL ficasseextremamente lenta. Para contornar o problema, as threads foram substituídaspelos Active Objects, permitindo a execução das aplicações de forma correta eeficiente, mesmo sem o paralelismo das threads. Em outras plataformas, apossibilidade do uso das threads vai depender de como esse recurso éimplementado e de como é o seu consumo de recursos. Todavia, se o uso dethreads em qualquer outra plataforma também for proibitivo, é possível definiroutras formas de escalonamento que viabilizem a execução do Ginga-NCL,como já foi demonstrado com o uso dos Active Objects no Symbian.A implementação dos exibidores, por sua vez, é muito dependente deplataforma. O fato do Ginga-NCL possuir uma abstração do uso desseselementos facilitou muito a implementação, algo que certamente deve se repetirna implementação do Ginga-NCL em outras plataformas. Em Symbian, osexibidores de vídeo e de HTML foram os mais complicados de se implementar.O exibidor de texto certamente é o mais problemático de todos, tanto que não foipossível, ainda, implementá-lo na versão atual do Ginga-NCL para dispositivosportáteis. Por conta disso, a sua implementação é citada nos trabalhos futuros

Implementação 59desta dissertação. A implementação dos exibidores em outras plataformasdepende muito de como são as suas API’s específicas de exibição.A implementação do Ginga-NCL para dispositivos portáteis resultante dotrabalho apresentado nesta dissertação foi testada em um emulador dedispositivo Symbian S60 e em dois dispositivos portáteis. Os testes sãodetalhados no Capítulo 4.Em relação à implementação do Ginga-NCL para dispositivos fixos,algumas limitações devem ser observadas. A primeira delas é que não épossível apresentar uma imagem sobre um vídeo por causa da existência deuma única camada gráfica de apresentação, como é descrito na Seção 3.7. Asegunda limitação que pode ser citada, é a impossibilidade de se definir níveisde transparência para os vídeos. Como última limitação, pode-se citar que asoma total dos tamanhos das mídias apresentadas ao mesmo tempo em umaaplicação NCL não pode ser muito alta. O limite para isso depende muito dodispositivo em que a aplicação NCL está executando, mas, nos testesrealizados, somas maiores que 2Mb causaram o término da aplicação por faltade recursos.Como é descrito no Capítulo 4, o funcionamento do Ginga-NCL foi testadoem diferentes aplicações NCL, sendo que o funcionamento delas ocorreu deforma idêntica no emulador e nos dispositivos portáteis, e não foi observadaqualquer degradação do sistema. As aplicações NCL executaram sem aparenteperda de eficiência e o sincronismo funcionou adequadamente. Dessa forma,pode-se concluir que a implementação apresentada nessa dissertação foi bemsucedida.As ferramentas necessárias para a compilação do Ginga-NCL, o emuladore os dispositivos usados, bem como o procedimento de instalação do Ginga-NCL, são apresentados no Apêndice A desta dissertação.

4Testes SistêmicosO objetivo deste capítulo é apresentar os testes realizados para ajudar aidentificar erros na implementação do Ginga-NCL em dispositivos portáteis.Foram realizados apenas testes sistêmicos, onde várias funcionalidades sãotestadas em conjunto. O objetivo foi verificar o comportamento da execuçãolevando-se em conta a conjunção das funcionalidades, ao invés de se avaliarapenas o funcionamento pontual de cada uma delas, como é feito nos testesunitários. A melhor forma de se fazer esse tipo de teste é desenvolver umaaplicação NCL propriamente dita, onde vários recursos são exercitados aomesmo tempo. Por exemplo, uma simples aplicação NCL pode por a teste aexecução do parser e a criação de regiões, descritores, mídias e portas.Os testes realizados, portanto, consistem na execução de aplicações NCLque, ao final, também servem como prova de conceito da implementação. Paracada uma das aplicações, serão apresentados a sua dinâmica, os exibidoresusados e os problemas mais relevantes identificados, juntamente com as suasrespectivas soluções. Também serão apresentadas telas ilustrativas de cadauma dessas aplicações quando executadas em um emulador de dispositivoSymbian S60. Além do emulador, os testes também foram executados em doisdispositivos reais, como descrito no Anexo A.4.1.Formula 1A primeira aplicação desenvolvida para a implementação do Ginga-NCLpara dispositivos portáteis foi uma sobre corrida de Fórmula 1. Nela, um vídeo defórmula 1 é exibido em um pouco mais da metade da tela do dispositivo. O restodo espaço é usado para apresentar três opções de interação. A Figura 9 mostraesse cenário.

Testes Sistêmicos 61Figura 9: Aplicação Fórmula1.As interações podem ser feitas pressionando-se as teclas 1, 2 ou 3 dodispositivo. O uso da tecla 1 resulta na apresentação de informações sobrepilotos de fórmula 1. No caso do uso da tecla 2, informações sobre as escuderiassão exibidas. Já o uso da tecla 3 mostra a pista de Interlagos. Em todos oscasos, o vídeo passa a ocupar um quarto de tela, quando uma nova opção deinteração é exibida, como pode ser visto na Figura 10.

Testes Sistêmicos 62Figura 10: Os três casos de interação da aplicação Fórmula1.Ao se pressionar a tecla 9, a aplicação volta ao estado inicial.Os exibidores usados na aplicação Fórmula 1 foram os de vídeo eimagem. A grande maioria dos problemas tidos com esses exibidores foramencontrados e solucionados durante a fase de testes feita com a aplicação emquestão. No caso do exibidor de imagem, foi observada a limitação dos tipos deimagens suportados, como descrito no Capítulo 3. Além dessa limitação, oexibidor de imagem não apresentou muitos problemas.O exibidor de vídeo mostrou-se mais problemático. O maior problemaobservado ocorreu porque a função de Open de vídeo, no Symbian, éassíncrona. Logo depois de ordenar a abertura de um vídeo, através dachamada à função Open, a máquina de apresentação solicita informações doexibidor, como o tempo de duração e o volume. Nesse momento, pode ser que ovídeo não tenha sido completamente carregado, o que causaria um erro.A forma mais simples de se resolver esse problema é aguardar até que afunção Open termine o seu processamento e, somente então, continuar aexecução. Symbian oferece uma API que é capaz de fazer isso, ou seja, elaprovê uma forma de se aguardar pelo término de funções assíncronas. Essa API

Testes Sistêmicos 63é, entretanto, complexa, de uso restrito, o que exige um bom conhecimento dosActives Objects. Apesar da sua complexidade, o uso dessa API solucionou oproblema adequadamente.Como a API do exibidor de vídeo é muito similar à do exibidor de áudio,acredita-se que muitos dos problemas que poderiam ocorrer na implementaçãodo exibidor de áudio foram evitados durante a fase dos testes em questão.Erros no módulo Conversor também foram encontrados. Os maioresproblemas foram aqueles relacionados ao novo procedimento de parser e aotratamento das tags dependentes. Esses erros foram corrigidos e nenhum outroproblema referente aos procedimentos descritos foi encontrado nesse ou emoutros testes.Durante a execução da aplicação Formula1, também foi possível percebero problema do uso das threads no Symbian. As imagens demoravam muitotempo para serem exibidas, mesmo sem a apresentação do vídeo. Foi nessemomento que se iniciou o estudo para a substituição das threads pelos ActiveObjects. Quando a substituição foi feita, o problema foi solucionado e a aplicaçãopassou a ser apresentada eficientemente.Foi também durante a execução da aplicação Formula1 que ficou evidentea limitação da soma total das mídias que poderiam ser apresentadas ao mesmotempo em uma aplicação NCL. As três imagens que representam as opções deinteração ocupavam, inicialmente, muito espaço de memória. Por causa disso, asoma dos tamanhos dos conteúdos acabava sendo muito grande, e a execuçãoda aplicação no dispositivo era finalizada por falta de recursos.4.2.MatrixA segunda aplicação desenvolvida e testada na implementação do Ginga-NCL para dispositivos portáteis foi a Matrix_Mobile. O objetivo principal dessaaplicação foi testar o sincronismo temporal. Ao ser iniciada, a aplicação exibe umtrecho do filme Matrix em toda a área disponível do dispositivo, como pode servisto na Figura 11.

Testes Sistêmicos 64Figura 11: Aplicação Matrix_Mobile.Em um determinado momento, um dos protagonistas mostra uma pilha.Nesse instante, a aplicação reduz o tamanho do vídeo e apresenta, no espaçorestante, uma propaganda de pilha por um determinado período de tempo.Quando esse tempo termina, a propaganda é removida e o vídeo é restauradoao seu tamanho original. A Figura 12 ilustra esse cenário.Figura 12: Primeiro caso de sincronismo da aplicação Matrix_Mobile.Em um outro momento, o mesmo ator fica próximo à câmera, realçando osseus óculos. Nesse instante, o vídeo é reduzido a fim de oferecer espaço parauma opção de interação, que fica disponível por um período fixo tempo. Depoisdesse tempo, a imagem é removida, o tamanho do vídeo é restaurado e o

Testes Sistêmicos 65usuário não poderá mais realizar a interação. Esse cenário é apresentado naFigura 13.Figura 13: Segundo caso de sincronismo da aplicação Matrix_Mobile (Sem interação).Se o usuário optar por fazer a interação, realizada ao se pressionar a tecla1, o vídeo terá as suas dimensões ainda mais reduzidas e uma propaganda deóculos escuros será apresentada. Poucos segundos depois, a propaganda éremovida e o vídeo é restaurado ao seu tamanho original. A Figura 14 ilustraesse cenário.Figura 14: Segundo caso de sincronismo da aplicação Matrix_Mobile (Com interação).Os exibidores usados nessa aplicação foram os de imagem e vídeo.Nenhum problema novo foi observado para esses exibidores.Como já mencionado, o objetivo do teste feito com o uso da aplicaçãoMatrix_Mobile foi verificar se o sincronismo estava funcionando corretamente.Foi nesse momento, portanto, que se observou o problema do tratamento dasâncoras temporais, descrito na Seção 3.6. Depois que esse problema foisolucionado, a aplicação Matrix_Mobile passou a funcionar corretamente, enenhum outro erro relevante foi encontrado.

Testes Sistêmicos 664.3.CarnavalA terceira aplicação desenvolvida e testada foi a Carnaval. O seu objetivofoi realizar o uso mais intenso do sincronismo e forçar um pouco mais o uso derecursos. Quando iniciada, Carnaval exibe um vídeo, em tela cheia, de umaescola tocando o seu samba-enredo, como pode ser visto na Figura 15.Figura 15: Aplicação Carnaval.Depois de um curto período de tempo, o vídeo tem o seu tamanhoreduzido e o espaço restante é preenchido com duas informações: a legenda dosamba-enredo sincronizada com o vídeo e duas opções de interação. A Figura16 ilustra essa situação.

Testes Sistêmicos 67Figura 16: Aplicação Carnaval com legenda e com as duas opções de interação.A legenda é composta por trinta imagens sincronizadas com o vídeo aolongo do tempo. Uma das interações é ativada pela tecla 1 e a outra pela 2. Aprimeira interação exibe a bandeira da escola de samba e a segunda exibe umafoto do intérprete, como pode ser visto na Figura 17.

Testes Sistêmicos 68Figura 17: Os dois casos de interação da aplicação Carnaval.Em ambos os casos, uma nova opção de interação — ativada pela tecla 9— é oferecida para permitir ao usuário voltar às opções de interação iniciais.Nenhum problema relevante foi encontrado com a execução da aplicaçãoCarnaval. O sincronismo da legenda funcionou corretamente e de formaeficiente. Não foi observada perda de sincronismo nem mesmo quando asinterações eram muito exercitadas. Apesar de ser uma aplicação pesada, o seufuncionamento se deu de forma adequada e eficiente.

Testes Sistêmicos 694.4.Exibidor HTML com Canal de RetornoA última aplicação testada não foi baseada em nenhum tema. O seuobjetivo foi o de apenas testar a integração com o exibidor HTML, e ofuncionamento do recurso de foco e seleção da NCL. Essa aplicação,diferentemente das apresentadas anteriormente, só foi testada em um dosdispositivos disponíveis. Isso porque o outro não possuía uma interface de redea ser usada com o objetivo de se estabelecer uma conexão com a Internetnecessária para o teste do exibidor de HTML. Maiores detalhes sobre osdispositivos são apresentados no Apêndice A desta dissertação.Ao ser iniciada, a aplicação em questão divide a tela do dispositivo emdois. Na parte superior é exibida uma página HTML e, na parte inferior, quatroimagens de botões, como pode ser observado na Figura 18.Figura 18: Aplicação 4.É possível navegar com o foco entre todos os cinco elementos daaplicação. A navegação dentro da página HTML se dá após ela ter sidoselecionada. Na aplicação em questão, quando um elemento está focado, umaborda azul é desenha em seu contorno. Já quando o elemento é selecionado, acor verde é aplicada à borda. A Figura 19 mostra o momento em que a páginaHTML está focada, depois a sua seleção e, por fim, a navegação dentro dela.

Testes Sistêmicos 71Figura 20: Botão pressionado.A seleção da imagem que se encontra no canto inferior direito causa otérmino da aplicação. Já a seleção das outras imagens inicia diferentesconteúdos de áudio.Os exibidores usados na aplicação foram os de imagem, áudio e HTML. Oexibidor de áudio praticamente não ofereceu problemas, assim como o deimagem que já havia sido testado previamente. Já o exibidor de HTML causoumuitos problemas. O maior deles, entretanto, é o que fazia com que uma lista deconexões fosse apresentada ao usuário. Isso é feito porque a API que trata daspáginas HTML não seleciona uma conexão padrão para estabelecercomunicação com a Internet. Assim, existe a necessidade de se perguntar ao

Testes Sistêmicos 72usuário qual conexão deve ser usada. O problema que ocorreu deveu-se ao fatoque, no Symbian, normalmente uma mesma camada gráfica é usada para sedesenhar quaisquer elementos na tela. O uso de janelas separadas, onde aexibição de um elemento em uma janela não interfere na outra, é evitado, poisexigiria o uso de mais de um elemento Window. Como já foi explicado na Seção3.7, o uso de Windows não é recomendado. Dessa forma, a API da páginaHTML mostra a lista de conexões por cima da aplicação NCL que está sendoapresentada.A solução mais simples para esse problema foi implementar uma forma dese selecionar uma conexão padrão para a API, evitando, com isso, que a listafosse apresentada. Uma conexão deve, então, ser inicialmente estabelecida eentregue a API. Essa solução funcionou no emulador, mas não foi suficiente. Nodispositivo testado, a API parecia ignorar a conexão estabelecida e voltava aapresentar a lista ao usuário.Uma segunda solução foi fazer com que a API em questão lançasse a listade conexões antes da aplicação NCL ser efetivamente iniciada. Assim, a lista éapresentada, o usuário seleciona a opção mais conveniente, a tela é limpa e aaplicação NCL pode, então, ser iniciada sem problemas. Isso resolveu oproblema causado pela API que tratava da página HTML. Essa API apresentou,ainda, outros problemas menos relevantes que foram tratados de formaapropriada.A implementação do exibidor de HTML foi, portanto, como já descrito noCapítulo 3, uma das mais complicadas. O tratamento do recurso de foco eseleção, por outro lado, funcionou corretamente e causou poucos problemas.

5Conclusões e Trabalhos FuturosEste trabalho apresenta a primeira implementação de referência do Ginga-NCL para dispositivos portáteis, que foi baseada em sua implementação paraterminais fixos apresentada resumidamente na Seção 3.1.Antes de iniciar a implementação, foi necessário escolher uma plataformade desenvolvimento para dispositivos portáteis adequada. A Seção 2.3apresentou um estudo comparativo dos sistemas operacionais e das suasrespectivas plataformas de desenvolvimento. Chegou-se à conclusão que osistema operacional Symbian, juntamente com a sua plataforma dedesenvolvimento nativa, era a melhor opção para a realização de uma primeiraimplementação de referência do Ginga-NCL para os dispositivos portáteis.Durante a realização dessa implementação foram encontrados diversosproblemas. Esses problemas são apresentados no Capítulo 3 desta dissertaçãoe têm as suas várias soluções apresentadas, analisadas e, quando havia maisde uma solução para um mesmo problema, comparadas. Por fim, foramdescritas as soluções que foram realmente adotadas.A implementação resultante de todo o trabalho descrito nesta dissertaçãofoi testada em um emulador de dispositivos portáteis Symbian, e em doisdispositivos portáteis diferentes. Em ambos os casos, o funcionamento doGinga-NCL se deu de modo correto e eficiente, sem a necessidade de serealizar qualquer modificação na especificação. Isso mostra que a especificaçãodo Ginga-NCL é suficientemente leve para ser embarcada em dispositivosportáteis — mesmo que estes não tenham sido desenvolvidos para seremusados especificamente como receptores de TV — e que é, portanto, adequadaa esse tipo de dispositivo. Assim, o principal objetivo almejado pelo estudoapresentado nesta dissertação foi alcançado. A demonstração de que aespecificação do Ginga-NCL é adequada ao contexto dos dispositivos portáteistambém é a maior contribuição oferecida pelo estudo apresentado.Uma outra contribuição que pode ser citada é decorrente da novaimplementação do módulo Conversor. Essa implementação demonstrou que ouso do parser DOM é desnecessário para o processamento de documentos NCL

Conclusões e Trabalhos Futuros 74— tanto no escopo dos dispositivos portáteis quanto para os terminais fixos — eque, por isso, o uso do parser SAX é mais vantajoso.Salvo as contribuições citadas, algumas outras conclusões podem sertiradas do trabalho apresentado. Acredita-se que muitos dos problemasobservados e apresentados nesta dissertação também podem ocorrer em outrasplataformas de desenvolvimento, em especial naquelas que forem fechadas. Osresultados aqui obtidos, portanto, podem ser usados como referência emimplementações futuras do Ginga-NCL feitas em outras plataformas dedesenvolvimento.A arquitetura da implementação de referência do Ginga-NCL, apresentadana Seção 3.1, foi desenvolvida com o objetivo de facilitar o procedimento deporte para diversas plataformas. Essa arquitetura foi, portanto, desenvolvida deforma modular e abstrata o suficiente para que as partes específicas deplataforma pudessem ser isoladas das partes gerais e independentes deplataforma. Entretanto, nenhum porte da implementação havia sido realizado, ouseja, a arquitetura em questão ainda não tinha sido validada nessa questão. Oresultado do trabalho apresentado nesta dissertação foi, de fato, o primeiropasso para realizar essa validação.Ao longo de toda a implementação do Ginga para dispositivos portáteis,foram encontradas, na implementação de referência, abstrações no uso derecursos específicos de plataforma. Essas abstrações permitiram que apenasparcelas específicas e pontuais da implementação de referência tivessem queser modificadas, mantendo intacta a já funcional estrutura genérica domiddleware. Isso facilita o procedimento de porte na medida em que ofuncionamento geral do middleware não precisa ser modificado, evitando erros epermitindo que um maior foco pudesse ser dado às especificidades daplataforma. A modularização da arquitetura também é um fator que contribuiupara o porte. Na implementação apresentada, por exemplo, o módulo Conversorfoi quase que completamente modificado sem que isso interferisse nofuncionamento do middleware como um todo. Isso só foi possível graças à boadelineação dos módulos na arquitetura. Assim, é possível concluir, através doestudo apresentado, que a forma como a arquitetura da implementação dereferência do Ginga-NCL foi desenvolvida de fato facilita o procedimento deporte.Existem alguns possíveis trabalhos futuros que poderão ser desenvolvidosa fim de se incrementar o trabalho apresentado nesta dissertação. O primeirotrabalho sugerido diz respeito ao procedimento de parser do Ginga-NCL. Nesta

Conclusões e Trabalhos Futuros 75dissertação foi apresentada a substituição do parser DOM pelo SAX, levando-seem consideração o fato de que testes realizados em (Violleau, 2002), (Oren,2002), (Devsphere, 2007) e (Franklin, 2007) entre esses dois tipos de parserindicam, de forma genérica, uma eficiência maior por parte do SAX. Entretanto,nenhum estudo comparativo foi feito entre uma implementação do móduloConversor que use SAX e outra que use DOM. Seria interessante, portanto,realizar esse estudo a fim de se ter uma comparação entre o DOM e o SAXdentro do contexto do Ginga-NCL. Um outro trabalho que pode ser feito emrelação ao parser é implementar o tratamento dos comandos de edição ao vivo,que não foi feito na versão do Ginga-NCL para dispositivos portáteisapresentada.Um segundo trabalho futuro é a implementação do modelo para aespecificação temporal de aplicações hipermídia descrito em (Costa e Soares,2007). Esse modelo viabiliza, dentre outras coisas, a interrupção daapresentação de uma aplicação NCL como um todo e a sua posterior retomadaa partir do mesmo instante temporal. Considerando, ainda, o universo dosdispositivos portáteis, uma vantagem é que esse modelo foi especificado de talforma que é possível descartar parcelas suas que já tenham sido usadas ou quenunca mais serão utilizadas. Isso pode ser feito em qualquer momento de umaapresentação NCL, o que possibilita a otimização do uso dos recursos dememória, que são muito limitados na maioria dos dispositivos portáteis.Um outro trabalho sugerido é a execução testes de desempenho naimplementação de referência do Ginga-NCL para dispositivos portáteis,verificando o nível do consumo de recursos utilizados, como bateria, memória eCPU. O objetivo é verificar a carga imposta pela implementação ao sistemaoperacional, determinando se, por exemplo, outras aplicações podem serexecutadas ao mesmo tempo em que uma aplicação NCL é exibida.É sugerida, também, a implementação da funcionalidade de adaptação daNCL em função da disponibilidade de recursos do aparelho, o que não foi feitona implementação apresentada nesta dissertação. Com essa funcionalidade, umaplicação pode ser desenvolvida de maneira que funcione em dispositivos comrestrições de recursos diferentes.Um outro trabalho que pode ser feito diz respeito aos exibidores de mídia.Novos exibidores, o de texto e Lua, podem ser implementados e o exibidor deimagem pode ser melhorado. A API específica de tratamento de texto emSymbian possui documentação insuficiente e, até o término da implementaçãoque é apresentada neste estudo, era pouco utilizada — o que significa que

Conclusões e Trabalhos Futuros 76poucas pessoas da comunidade de desenvolvimento sabiam como utilizá-la. Amelhor opção para o início da implementação desse exibidor é começar pelabusca de códigos exemplo que possam ser usados no entendimento do uso daAPI Symbian de texto. Espera-se, portanto, que a implementação desse exibidorofereça alguns problemas. É incerto, entretanto, se a implementação do exibidorde texto em outras plataformas de desenvolvimento também apresentarãoproblemas.No que diz respeito ao exibidor Lua, será necessário portar o interpretadorLua, que é todo implementado em ANSI C, as interfaces do Ginga-NCL comesse interpretador e algumas bibliotecas Lua desenvolvidas especificamentepara o Ginga-NCL. Em Symbian, portar o interpretador Lua não deve oferecermuito trabalho por conta da existência das bibliotecas P.I.P.S. e Open C. Já emplataformas fechadas, o ANSI C pode estar apenas parcialmente implementado,ou nem sequer isso. Portar o interpretador Lua para esse tipo de plataformapode ser mais problemático. As interfaces e as bibliotecas feitas para o Ginga-NCL, porém, possuem algumas características específicas de plataforma quepodem introduzir um nível de dificuldade maior, tanto no Symbian quanto emqualquer outra plataforma.O incremento ao exibidor de imagem é sugerido a fim de que ele possaoferecer suporte à apresentação de outros tipos de imagem além da mbm. Seránecessário, entretanto, fazer uso de uma classe que converta outros tipos deimagem, como png, bmp ou gif, em imagens mbm. Isso porque a classeapresentada na Seção 3.7 capaz de carregar imagens no Symbian, aCFbsBitmap, só consegue carregar imagens do tipo mbm. O problema é que adocumentação da classe que faz a conversão é confusa, e também existempoucos exemplos do seu uso.Por fim, o último trabalho futuro sugerido é a implementação dos módulosSintonizador, Filtro de Seções e Processador de Fluxos de Dados, que sãodescritos na Seção 3.1, em uma plataforma com recepção SBTVD.

6Referências BibliográficasABNT/CEET-00:001.85. Televisão digital terrestre - Codificação de dados eespecificações de transmissão para radiofusão digital – Parte 2: Ginga-NCL parareceptores fixos e móveis – Linguagem de aplicação XML para codificação deaplicações. Setembro 2007.Babin, Steve, Harrison, Richard. Developing Software for Symbian OS AnIntroduction to Creating Smartphone Applications in C++. Jonh Wiley & Sons Ltd,2006.Berenger, Francis Machado, Maia, Luiz Paulo. Arquitetura de SistemasOperacionais. 3ª edição. LTC, 2002.Costa R.M.R., Soares L.F.G.. Modelo Temporal Hipermídia para Suporte aApresentações em Ambientes Interativos. Rio de Janeiro: PUC-Rio -Departamento de Informática. 2007.Cruz, Vitor Medina, Moreno, Marcio Ferreira, Luiz Fernando Gomes,Soares. TV Digital Para Dispositivos Portáteis – Middlewares. Relatório Técnico;Rio de Janeiro: PUC-Rio – Departamento de Informática, jan. 2008.Devsphere. SAX versus DOM. Benchmark performed with Xerces andCrimson. Disponível em: http://www.devsphere.com/xml/benchmark/method.html.2007. Último acesso em Fevereiro de 2008.directfb.org | Main. Disponível em: http://www.directfb.org/. mar. de 2008.Último acesso em Março de 2008.Digital TV Facts. DTV Guide Transmission. Disponível em:http://dtvfacts.com/latest/250/as-digital-tv-reception-controversy-dims-e-vsb-getsanother-look/.maio 2006. Último acesso em janeiro de 2008.Farwick, Matthias, Hafner ,Michael. XML.com: XML Parser Benchmarks:Part 1. Disponível em: http://www.xml.com/pub/a/2007/05/09/xml-parserbenchmarks-part-1.html.Maio de 2007. Último acesso em Fevereiro de 2008.Forum Nokia. Open C for S60:Increasing Developer Productivity, Version1.2. mar 2007.Franklin, Steve. XML Parsers: DOM and SAX Put to the Test. Disponívelem: http://www.devx.com/xml/Article/16922/1954?pf=true. 2007. Último acessoem Fevereiro de 2008.

Referências Bibliográficas 78Harrison, Richard et al. Symbian OS C++ for Mobile Phones. Volume 1.John Wiley & Sons, 2003.Harrison, Richard et al. Symbian OS C++ for Mobile Phones. Volume 2.John Wiley & Sons, 2004.Java Technology. Disponível em: http://java.sun.com/. Último acesso emSetembro de 2007.Jez, Marco. Disponível em:http://marcoplusplus.blogspot.com/2007/05/stlport-for-symbian-os-released.html.maio 2007. Último acesso em Fevereiro de 2008.Moreno, Marcio Ferreira. Um Middleware Declarativo para Sistemas de TVDigital Interativa. Dissertação de mestrado; Rio de Janeiro: PUC-Rio –Departamento de Informática, abril de 2006.Morley, Jason. Leaves and Exceptions Version: 1.3.1. Published by theSymbian Developer Network, set 2007.Nokia. Device Details -- Nokia 5700 XpressMusic. Disponível em:http://www.forum.nokia.com/devices/5700_XpressMusic. 2008. Último acesso emJulho de 2008.Nokia. Device Details -- Nokia N81. Disponível em:http://www.forum.nokia.com/devices/N81. 2008. Último acesso em Julho de2008.Nokia. S60 Platform SDKs for Symbian OS, for C++. Disponível em:http://www.forum.nokia.com/info/sw.nokia.com/id/4a7149a5-95a5-4726-913a-3c6f21eb65a5/S60-SDK-0616-3.0-mr.html. 2008. Último acesso em Fevereiro de2008.Nokia. Open C SDK Plug-In for S60 3rd Edition SDKs, for Symbian OS, forC++. Disponível em: http://www.forum.nokia.com/info/sw.nokia.com/id/91d89929-fb8c-4d66-bea0-227e42df9053/Open_C_SDK_Plug-In.html. 2008. Último acessoem Fevereiro de 2008.Nokia. Carbide.c++ v1.2, the development tool for C++ for Symbian OS andOpen C developers. Disponível em:http://www.forum.nokia.com/info/sw.nokia.com/id/dbb8841d-832c-43a6-be13-f78119a2b4cb.html. 2008. Último Acesso em Fevereiro de 2008.Oren, Yuval. SAX Parser Benchmarks. Disponível em:http://piccolo.sourceforge.net/bench.html. 2002. Último acesso em Fevereiro de2008.

Referências Bibliográficas 79SDN. P.I.P.S. - Symbian Development Public Wiki – SDN Wiki. Disonívelem: http://developer.symbian.com/wiki/display/pub/P.I.P.S. Fevereiro de 2008.Último acesso em Fevereiro de 2008.Silva , Heron V. O., Rodrigues, Rogério Ferreira, Soares, Luiz FernandoGomes. Frameworks para Processamento de Documentos XML. Rio de Janeiro:Departamento de Informática, PUC-Rio. 2005.Smil 2.1 – Timing and Syncronization. Disponível em:http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html. dec. 2005.Último acesso em fevereiro de 2007.Soares, L.F.G., Rodrigues, R.F., Moreno, M.F. Ginga-NCL: the DeclarativeEnvironment of the Brazilian Digital TV System. Rio de Janeiro: PUC-Rio -Departamento de Informática. abril 2007.SOARES, L.F.G., RODRIGUES, R.F., MUCHALUAT-SAADE, D.C. Modelode Contextos Aninhados – versão 3.0, Relatório Técnico, Laboratório TeleMídia,Departamento de Informática, PUC-Rio, 2003.Stichbury, Jo. Symbian OS Explained. Effective C++ Programming forSmartphones. John Wiley & Sons Ltd, 2004.STLPort. Disponível em: http://www.stlport.org/. 2001. Último acesso emFevereiro de 2008.Symbian Ltd. P.I.P.S. Home - P.I.P.S. - Symbian Wiki. Disponível em:http://developer.symbian.com/wiki/display/oe/P.I.P.S.+Home. fev de 2008. Últimoacesso em Fevereiro de 2008.Symbian Ltd. Using Symbian OS GETTING STARTED, 2007 2nd edition.2-6 Boundary Row, London SE1 8HP, UK, jan. de 2007.Symbian Ltd. Using Symbian OS P.I.P.S. fev de 2007.Symbian Ltd, Nokia. S60 3rd Edition SDK for Symbian OS, SupportingFeature Pack 1, for C++. SDK Help. out. de 2006.Violleau, Thierry. Java Technology and XML-Part Two. Disponível em:http://java.sun.com/developer/technicalArticles/xml/JavaTechandXML_part2/.Março 2002. Último Acesso em Fevereiro de 2008.

Apêndice A – Instalação e Dispositivos TestadosEste apêndice tem como objetivo servir como um manual para a criação doambiente necessário à compilação dos pacotes Ginga-NCL, bem como para aexecução da aplicação resultante em um emulador de dispositivo Symbian oupara a instalação dessa aplicação em um dispositivo Symbian real. Ao final,também serão apresentados os dispositivos onde o Ginga-NCL foi instalado e osresultados obtidos.Todas as ferramentas Symbian são disponibilizadas, oficialmente, apenasnas plataformas Windows XP e Windows 2000. Sendo assim, todas asinstalações especificadas por esta seção devem ser feitas em um desses doissistemas.O primeiro elemento que precisa ser instalado para a criação do ambientenecessário a compilação e execução do Ginga-NCL é o S60 3rd Edition SDK F1,que é um SDK específico para a versão 9.2 do sistema operacional Symbian.Esse SDK pode ser encontrado em (Nokia, 2008c). O procedimento deinstalação é simples e envolve a leitura e aceitação da licença, além de algumasescolhas típicas de instalação. Em seguida, precisam ser instaladas asbibliotecas P.I.P.S., Open C e STLPort para Symbian, que podem serencontradas, respectivamente, em (SDN, 2008), (Nokia, 2008d) e (Jez, 2007). Aprimeira foi desenvolvida pela Symbian e é usada na realização do porte decódigos redigidos em C. A segunda é uma extensão (superset) da P.I.P.S., ouseja, oferece uma capacidade de porte ainda maior, mas funciona somente paraa plataforma do Symbian S60. A terceira é um porte, feito por um membro dacomunidade Symbian, de uma implementação da biblioteca STL que foioriginalmente desenvolvida para dispositivos embedded. A necessidade dessasAPI’s foi explicada na seção 3.2. O procedimento de instalação dessasbibliotecas pode ser resumido nas seguintes etapas:• Descompactar os arquivos zip do PIPS do Open C e da STLPortem três pastas separadas;• Copiar o conteúdo da pasta epoc32 presente em cada uma das trêspastas e colá-lo dentro da pasta\Epoc32\.Quando solicitado, é preciso selecionar a opção de substituir todosos arquivos repetidos pelos os que estão sendo copiados.

Apêndice A – Instalação e Dispositivos Testados 81Depois que essas três bibliotecas estiverem instaladas, o próximo passoconsiste em instalar um ambiente de desenvolvimento apropriado. Como oCarbide C++ Free 1.2 foi utilizado ao longo de todo o processo dedesenvolvimento do Ginga-NCL, e como os projetos da implementação Ginga-NCL para dispositivos portáteis estão no formato dessa ferramenta, recomendaseo uso do Carbide C++ Free 1.2 ou, ainda, uma versão sua paga. O CarbideC++ Free 1.2 pode ser encontrado em (Nokia, 2008e) e a sua instalação tambémé trivial. Ressalta-se, entretanto, que, para o seu correto funcionamento, oActivePerl-5.6.1.635 deve ser instalado. Se uma versão mais nova ou maisantiga desse elemento for instalada, o Carbide não funcionará corretamente.Para fazer uso das bibliotecas P.I.P.S. Open C e STLPort nessa ferramenta, osseguintes procedimentos devem ser realizados:1. Dada a existência de um projeto Carbide 1.2, abrir o arquivo.mmp que se encontra dentro da pasta "group"do projeto. Nele são definidos todos os includes e as bibliotecasusadas pelo projeto;2. Adicionar "/epoc32/include/stdapis" em System Include para fazeruso do PIPS e do OpenC;3. Adicionar "/epoc32/include/stlport" em System Include para fazeruso da STLPort;4. Adicionar a "libc" e a "stlport_s" na guia de bibliotecas. A primeiradeve ser ligada dinamicamente enquanto que a segunda deve serligada estaticamente.A implementação do Ginga-NCL é dividida em seis pacotes: telemidiautil_Symbian,ncl30_Symbian, ncl30-converter_Symbian, gingaccio_Symbian,gingacc-player-Symbian e gingancl_Symbian. O primeiroimplementa algumas funções auxiliares que são muito usadas nos outrospacotes. O segundo, a estrutura NCM da qual o documento NCL deverá serconvertido, e o terceiro pacote é o que fica responsável por realizar a conversãopropriamente dita, sendo nele, portanto, onde é encontrado o parser SAX. Oquarto pacote implementa o controle de tela e dos gráficos, enquanto que oquinto, os exibidores. O último pacote corresponde a máquina de apresentação,e é, portanto, aquele que gera a aplicação Ginga-NCL.Para importar um projeto Symbian no Carbide C++, basta selecionar omenu File->Import dessa ferramenta para que uma janela de importaçãoapareça com uma série de opções, incluído duas para projetos Symbian: a“Symbian OS Bdl.inf file” e a “Symbian OS Executable”. A primeira opção deve

Apêndice A – Instalação e Dispositivos Testados 82ser selecionada. Em seguida, será necessário selecionar um arquivo bdl.inf paraser importado, que normalmente encontra-se dentro da pasta “group” de umprojeto Symbian. Esse tipo de arquivo guarda informações sobre a organizaçãodo projeto. Depois disso, será preciso escolher as configurações de “Build”.Cada SDK oferece duas opções desse tipo, uma que gera binários paraexecução no emulador e outra para execução nos dispositivos portáteis. Ambasdevem ser selecionadas. Em seguida, deverão ser escolhidos os arquivos decompilação que devem ser importados. Todos os disponíveis devem serselecionados. Por fim, será solicitado o nome a ser dado para o projetoimportado no Carbide C++ e em que pasta ele será copiado. Recomenda-seaceitar os valores padrões. Esse procedimento deve ser feito para todos os seispacotes do Ginga-NCL para que a sua compilação possa ser efetuada.A compilação pode ser feita de forma a gerar binários tanto para oemulador quanto para dispositivos Symbian S60. Para escolher uma dessasopções, é necessário clicar com o botão direito do mouse no projeto e ir emActive Build Configuration. Serão dadas as duas opções de Build: “EmulatorDebug” e “Phone Release”, sendo que a primeira gera um binário do programapara o emulador, e a segunda, o binário para um dispositivo Symbian S60. Sejaqual for a opção escolhida, a ordem correta de compilação dos pacotes ételemidia-util_Symbian, ncl30_Symbian, ncl30-converter_Symbian,gingacc-io_Symbian, gingacc-player-Symbian e gingancl_Symbian,respectivamente.Para executar o Ginga-NCL no emulador provido pelo SDK, basta clicarcom o botão direito do mouse no projeto gingancl_Symbian e selecionar aopção RunAs-> Run Symbian OS Application. O emulador será iniciado e aaplicação Ginga-NCL poderá ser encontrada dentro do sub-menu “Installed” domenu do celular emulado.Para instalar a aplicação Ginga-NCL em um dispositivo S60 que possua oSymbian 9.2, é necessário usar o arquivo de instalação .sisx que é geradodentro da pasta sis do pacote gingancl_Symbian após o término da compilação.Para realizar a instalação, um software de sincronismo, como o Nokia PC Suit,deve ser usado com o objetivo de se estabelecer uma conexão entre umdispositivo portátil e um computador que possua o arquivo de instalação sisx.Uma vez estabelecida essa conexão, basta clicar duas vezes sobre o arquivo.sisx de instalação do Ginga-NCL que um wizzard de instalação vai aparecer natela do dispositivo conectado. Por fim, basta seguir as instruções do wizzard e aaplicação será instalada. As bibliotecas P.I.P.S. e Open C também precisam ser

Apêndice A – Instalação e Dispositivos Testados 83instaladas no dispositivo. Os arquivos de instalação dessas bibliotecas podemser encontrados na pasta S60Opensis do arquivo .zip baixado de (Nokia, 2008d).Antes de executar o Ginga-NCL, tanto no dispositivo como no emulador, épreciso criar uma pasta de nome “Ginga” na raiz do sistema. No dispositivoportátil, a raiz é a pasta “Data”. No emulador, a raiz do dispositivo é emulada napasta \Epoc32\winscw\c\Data. Apasta “config”, que se encontra dento da pasta “data” do pacotegingancl_Symbian, deve ser colocada dentro da pasta “Ginga” recém criada. A“config” possui uma série de arquivos de configuração do Ginga-NCL que sãonecessários para a sua execução. Dentro da pasta Ginga também devem sercolocadas todas as aplicações interativas e um arquivo de nome ginga.conf.Esse arquivo deve possuir, em seu conteúdo, referências às ncls das aplicaçõesinterativas que se encontram dentro da pasta Ginga. Cada linha desse arquivodeve possuir apenas uma referência para uma ncl. Por exemplo, imagine queexistam duas aplicações interativas dentro da pasta “Ginga”: matrix e formula1.Dentro da pasta “matrix” existe uma ncl chamada “matrix.ncl”, e dentro da pasta“formula1”, uma outra ncl chamada “formula1.ncl”. Nesse contexto, o arquivoginga.conf deverá ser criado da seguinte forma:matrix/matrix.nclformula1/formula1.nclDessa forma, quando o Ginga-NCL for executado, uma lista com essasduas aplicações será apresentada. Aquela que for selecionada será tocada pelomiddleware.A implementação do Ginga-NCL para dispositivos portáteis foi instalada etestada em dois dispositivos: o Nokia 5700 Express Music e o Nokia N81 1G.O Nokia 5700 Express Music possui 369 Mhz e 64 Mb de memória RAMcom aproximadamente 18 Mb livres para o uso em aplicações. Já o Nokia N811G possui 369 Mhz e 96 Mb de memória RAM com aproximadamente 42 Mblivres para o uso em aplicações. Ambos os aparelhos suportam os seguintesformatos de vídeo e áudio: 3GPPH.263, H.264/AVC, MPEG-4 AAC, eAAC+,MP3, MP4, M4A, WMA, AMR-NB, AMR-WB, Mobile XMF, SP-MIDI, MIDI Tones(poly 64) e WAV (Nokia, 2008a) e (Nokia, 2008b). Somente o Nokia N81 1Gpossui suporte a WLAN, que é oferecido através de interfaces 802.11 b/g, WPAou WPA2 (AES/TKIP) (Nokia, 2008b).

Apêndice A – Instalação e Dispositivos Testados 84Em ambos dispositivos testados, o Ginga-NCL funcionou corretamentesem qualquer problema aparente de desempenho e da mesma forma que noemulador.