UNIVERSIDADE REGIONAL INTEGRADA DO ALTO URUGUAI E DAS MISSÕES
URI - CAMPUS DE SANTO ÂNGELO
DEPARTAMENTO DE ENGENHARIAS E CIÊNCIA DA COMPUTAÇÃO
CURSO DE CIÊNCIA DA COMPUTAÇÃO
VINÍCIUS MARAN
UMA API GRÁFICA DE AUXÍLIO AO
DESENVOLVIMENTO DE APLICAÇÕES
INTERATIVAS PARA A TELEVISÃO
DIGITAL BASEADA EM PRINCÍPIOS DE
USABILIDADE
Trabalho de Conclusão do Curso de Ciência da
Computação
Prof. M. Sc. Denílson Rodrigues da Silva
Santo Ângelo, 12 de dezembro de 2008
UNIVERSIDADE REGIONAL INTEGRADA DO ALTO URUGUAI E DAS MISSÕES – URI
Campus de Santo Ângelo
Reitor: Bruno Ademar Mentges
Pró-Reitora de Ensino: Helena Confortin
Pró-Reitor de Ensino, Extensão e Pós-Graduação: Sandro Rogério Vargas Ustra
Pró-Reitor de Administração: Clóvis Quadros Hempel
Diretor Geral: Gilberto Pacheco
Diretora Acadêmica: Dinalva Agissé de Souza
Diretora Administrativa: Rosane Maria Seibert
Coordenador do Departamento de Engenharias e Ciência da Computação: Paulo Betencourt
Coordenadora do curso de Ciência da Computação: Cristina Paludo Santos
AGRADECIMENTOS
À Deus que me deu a vida e a capacidade para estar aqui hoje.
Aos meus pais, Paulino e Leda, que sempre me estimularam durante todas as minhas
fases de vida. Vocês sempre foram a base de tudo para mim.
A minha irmã Ana Paula, pelo companheirismo e paciência.
A minha namorada Francine, pela compreensão, disponibilidade e pelo imenso
carinho dedicado.
Ao meu orientador Denílson, que com paciência muito ajudou e incentivou para
chegar com êxito a este momento.
SUMÁRIO
AGRADECIMENTOS ............................................................................................................................... 3
RESUMO .................................................................................................................................................... 6
ABSTRACT ................................................................................................................................................ 7
LISTA DE ABREVIAÇÕES ..................................................................................................................... 8
LISTA DE FIGURAS ................................................................................................................................ 9
LISTA DE TABELAS .............................................................................................................................. 10
1
INTRODUÇÃO ............................................................................................................................... 11
2
TELEVISÃO DIGITAL ................................................................................................................. 13
2.1 PADRÕES .......................................................................................................................................... 14
2.2 MIDDLEWARES ................................................................................................................................. 16
2.2.1
Middleware MHP ............................................................................................................... 17
2.2.2
Middleware DASE .............................................................................................................. 19
2.2.3
Middleware ARIB ............................................................................................................... 19
2.2.4
Middleware GINGA ............................................................................................................ 20
3
LINGUAGEM NCL........................................................................................................................ 23
3.1 SCRIPTS LUA ................................................................................................................................... 24
4
A LINGUAGEM JAVA E O AMBIENTE DE TELEVISÃO .................................................... 26
4.1 API JAVATV .................................................................................................................................... 27
4.2 API HAVI ........................................................................................................................................ 29
4.2.1
Componentes Gráficos ....................................................................................................... 31
4.2.2
Manipulação de Eventos .................................................................................................... 33
5
USABILIDADE NA TV DIGITAL INTERATIVA ..................................................................... 35
5.1 USABILIDADE ................................................................................................................................... 36
5.2 PRINCÍPIOS DE USABILIDADE PARA O AMBIENTE DE TV DIGITAL INTERATIVA ................................ 36
6
PROJETO E IMPLEMENTAÇÃO DA API ................................................................................ 40
6.1 DEFINIÇÕES ...................................................................................................................................... 40
6.2 DOUBLE BUFFERING ......................................................................................................................... 41
6.3 EVENTOS....................................................................................................................................... 42
6.3.1 Interface MActive ..................................................................................................................... 42
6.3.2 Classe MControllerEvent......................................................................................................... 43
6.4 PACOTES ....................................................................................................................................... 44
6.4.1 Pacote Maran.Component ....................................................................................................... 44
6.4.2 Pacote Maran.Event ................................................................................................................ 45
6.5 COMPONENTES ............................................................................................................................. 45
6.5.1 MLabel ..................................................................................................................................... 45
6.5.2 MImageItem ............................................................................................................................. 46
6.5.3 MAnimation ............................................................................................................................. 47
6.5.4 MSlider..................................................................................................................................... 48
6.5.5 MPanel ..................................................................................................................................... 49
6.5.6 MColoredPanel ........................................................................................................................ 51
6.5.7 MColoredControlButton .......................................................................................................... 52
6.5.8 MImageButton.......................................................................................................................... 52
6.5.9 MTextButton............................................................................................................................. 53
6.5.10 MAnimationButton ................................................................................................................. 54
6.5.11 MImageRender....................................................................................................................... 54
6.5.12 MDateChoice ......................................................................................................................... 55
6.5.13 MVirtualKeyboard ................................................................................................................. 55
6.5.14 MTextField ............................................................................................................................. 56
6.6 INTEGRAÇÃO DE PRINCÍPIOS DE USABILIDADE .............................................................................. 57
7
ESTUDO DE CASO ....................................................................................................................... 59
7.1
7.2
8
TESTES .......................................................................................................................................... 61
RESULTADOS ................................................................................................................................ 62
CONCLUSÃO ................................................................................................................................. 64
8.1 SUGESTÕES PARA TRABALHOS FUTUROS .......................................................................................... 65
9
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................................... 66
RESUMO
O início das atividades de transmissão da televisão digital de padrão aberto no Brasil
tem sido assunto constantemente discutido em fóruns pelo país inteiro. Isto se deve ao
fato de que é inegável que a televisão de um modo geral tem papel fundamental na
socialização e na cultura do povo brasileiro.
Atualmente, há padrões definidos para o ambiente de televisão digital, onde o sinal
já está sendo transmitido. No Brasil os padrões não estão completamente definidos.
Apesar disso, o desenvolvimento de componentes e aplicações baseadas para o
ambiente televisivo tem aumentado consideravelmente nos últimos meses. Porém
mesmo existindo padrões e frameworks de desenvolvimento, novos frameworks
precisam ser criados para atender as necessidades dos desenvolvedores. Este trabalho
propõe a construção de um framework de desenvolvimento para a linguagem Java no
ambiente de televisão digital.
A construção deste framework foi baseada em características que não são
encontradas nos frameworks de desenvolvimento atuais e em alguns princípios de
usabilidade específicos para o ambiente de televisão digital interativa.
Desta forma, a construção do framework trouxe como resultado um conjunto de
componentes leves, de fácil utilização e que oferecem recursos para que os princípios de
usabilidade estudados neste trabalho sejam utilizados na construção de interfaces para
aplicativos específicos para o ambiente de televisão digital.
Palavras chave: API, framework, televisão digital, interatividade, usabilidade.
ABSTRACT
The beginning of activities for transmission of digital television in Brazil to open
standard has been constantly discussed topic in the forums for the whole country. This
is due to the fact that it is undeniable that television in general has key role in
socialization and culture of the Brazilian people.
Currently, there are standards for digital television environment, where the signal is
being transmitted. In Brazil the standards are not fully defined.
Nevertheless, the development of components and applications based on the
environment television has grown considerably in recent months. But even if there are
patterns and frameworks for development, new frameworks must be created to meet the
needs of developers. This paper proposes the creation of a framework for development
of the Java language in the environment of digital television.
The construction of this framework is based on characteristics that are not found in
the frameworks of development in current and principles of usability for the specific
environment of interactive digital television.
Thus, the construction of the framework as a result has brought a set of lightweight
components, easy to use and providing resources to the principles of usability included
in this study are used in the construction of interfaces for applications specific to the
environment of digital television.
Key words: API, framework, digital television, interactivity, usability.
8
LISTA DE ABREVIAÇÕES
API – Application Programming Interface
ATSC – American Television Standards Committee
AWT – Abstract Window Toolkit
CDC – Connected Device Configuration
CLDC - Connected Limited Device Configuration
DAVIC – Digital Audio Video Council
DASE – Digital TV Application Software Environment
DVB – Digital Video Broadcasting.
DVB-C – Digital Video Broadcasting standard for cable delivery systems.
DVB-S - Digital Video Broadcasting standard for satellite delivery systems.
DVB-T – Digital Video Broadcasting standard for terrestrial delivery systems.
GEM – Globally Executable MHP
HAVi – Home Audio/Video Interoperability
HDTV – High Definition Television.
IDE – Integrated Development Environment
ISDB – Integrated Services Digital Broadcasting.
ISDTV-T – International Standard for Digital Television Terrestrial
JAR – Java Archive
JDK – Java Development Kit
JMF – Java Media Framework
JVM – Java Virtual Machine
MHP – Multimedia Home Platform
OCAP – OpenCable Application Platform
PC – Personal Computer
SBTVD – Sistema brasileiro de Televisão Digital
9
LISTA DE FIGURAS
Figura 2.1 – Arquitetura de um sistema de IDTV. [SUF04]
Figura 2.2 – Distribuição mundial dos padrões de middlewares existentes. [ASS08]
Figura 2.3 – Arquitetura do middleware para IDTV. [SOU03]
Figura 2.4 – MHP Profiles. [MHP08]
Figura 2.5 – Arquitetura do middleware Ginga. [ABN07]
Figura 3.1 - Modelo conceitual NCM básico. [DIN08]
Figura 3.2 – Estrutura básica de um documento NCL. [DIN08]
Figura 4.1 – Divisões de perfis, configurações e Máquinas Virtuais da plataforma
J2ME.
Figura 4.2 – Ciclo de vida de um xlet. [OLI05]
Figura 4.3 – Organização de layers utilizada pela API HAVi. [EDW03]
Figura 4.4 – Comparação de hierarquias utilizando a interface HMatte. [HAV01]
Figura 6.1 – Componentes base para a construção da API.
Figura 6.2 – Diagrama de estados possíveis de um componente que implementa a
interface MActive.
Figura 6.3 – Diagrama de classes do pacote Maran.Component.
Figura 6.4 – Diagrama de classes do pacote Maran.Event.
Figura 6.5 – Exemplo de uso da classe MLabel.
Figura 6.6 – Exemplo do uso da classe MImageItem.
Figura 6.7 – Exemplo de utilização da classe MAnimation.
Figura 6.8 – Exemplo de utilização do componente MSlider com a forma de desenho
padrão.
Figura 6.9 – Exemplo de utilização do componente MSlider com a forma de desenho
associado a imagens.
Figura 6.10 – Construção e resultado de um MPanel contendo alguns componentes
desta API.
Figura 6.11 – Construção e resultado de um MColoredPanel contendo quatro MPanels.
Figura 6.12 – Construção e resultado de um componente MColoredControlButton.
Figura 6.13 – Construção e resultado de um componente MImageButton.
Figura 6.14 – Construção e resultado de um componente MTextButton.
Figura 6.15 – Construção e resultado de um componente MAnimationButton.
Figura 6.16 – Construção e resultado de um componente MDateChoice.
Figura 6.17 – Construção e resultado de um componente MVirtualKeyboard.
Figura 6.18 – Construção e resultado de um componente MTextField.
Figura 7.1 – Interface do software xletview.
Figura 7.2 – Emulação dos componentes no software xletview.
Figura 7.3 – Resultados dos testes de ocupação de memória dos componentes
construídos.
Figura 7.4 – Testes de ocupação de memória dos componentes da API AWT.
10
LISTA DE TABELAS
Tabela 2.1 – Middlewares atuais. [DIN08]
Tabela 2.2 – Divisões do middleware DASE. [OLI05]
Tabela 2.3 – Relação de versões do MHP e dos anos de criação destas versões.
Tabela 2.4 – Divisão da especificação do ARIB STD-B24. [OLI05]
Tabela 4.1 – Classes do pacote Java.awt disponíveis para o framework HAVi. [HAV01]
Tabela 4.2 – HUI Events. [HAV01]
Tabela 5.1 – Televisão Convencional X Computador. [PIC06]
Tabela 6.1 – Constantes de controle de entrada de dados definidas na interface MActive.
Tabela 6.2 – Nomes de constantes e valores de teclas da classe MControllerEvent.
Tabela 6.3 – Relação entre princípios de usabilidade e os componentes construídos.
Tabela 7.1 – Comparação de tamanhos de pacotes.
11
1 INTRODUÇÃO
A televisão digital já é uma realidade que se faz presente na maioria dos países
desenvolvidos, porém somente agora os padrões de transmissão e programação
começam a ser consolidados no Brasil. Além disso, a televisão digital começa a criar
um novo mercado de aplicações e junto com o início das atividades relacionadas à
televisão digital, alguns problemas acabam surgindo em decorrência da definição dos
padrões que serão adotados para a programação de aplicações interativas.
Um destes problemas é que atualmente no cenário mundial, apesar de termos a
plataforma Java implementada por todos os padrões de middlewares, não temos um
padrão definido de APIs (Application Programming Interface) de auxílio à
programação, seja na área de comunicação ou na área de componentes gráficos para
aplicativos feitos especificamente para o ambiente de televisão digital interativa.
Atualmente o padrão GEM (Globally Executable MHP) [DVB07] define um padrão de
middleware mundial, porém este não é adotado por todos os países que já
implementaram a televisão digital.
Para a construção de interfaces gráficas, a única API implementada por todos os
padrões de middlewares que suportam a linguagem Java é a API AWT (Abstract
Window Toolkit), que faz parte de um conjunto de APIs chamado JavaTV, porém, a
AWT foi construída para ser utilizada no ambiente desktop e não leva em consideração o
novo paradigma de programação que é utilizado em aplicações feitas para o ambiente de
televisão digital interativa.
Portanto, uma nova API de desenvolvimento de componentes gráficos foi criada a
partir do estudo das soluções existentes atualmente, dos princípios de usabilidade de
uma forma geral, e dos princípios que podem ser aplicados somente ao ambiente de
televisão digital interativa.
Além disso, outra grande contribuição deste trabalho é trazer as discussões sobre o
ambiente de televisão digital para dentro do ambiente acadêmico e que desta forma se
mantém atualizado sobre os padrões brasileiros, que já estão sendo discutidos em outras
universidades pelo Brasil afora.
Este trabalho propõe a implementação de uma API que baseada na API AWT,
consiga garantir a compatibilidade com os padrões de middlewares atuais e que
implemente soluções que contemplem os princípios de usabilidade desejáveis para o
ambiente de televisão digital interativa.
Este documento está organizado da seguinte maneira: no próximo capítulo são
apresentados os conceitos básicos sobre um sistema de televisão digital, os padrões que
já estão definidos para o uso e construção de aplicativos para este ambiente e as
principais inovações oferecidas por cada um destes padrões. O capítulo três descreve
12
um breve estudo feito sobre a linguagem declarativa NCL, que se trata de uma inovação
implementada pelo middleware brasileiro Ginga, e que oferece a integração de
aplicações declarativas e aplicações procedurais construídas na linguagem LUA ou na
linguagem Java. O capítulo quatro apresenta os estudos realizados sobre a linguagem
Java e o seu uso no ambiente de televisão digital interativa, assim como os frameworks
criados especialmente para este ambiente. O capítulo cinco apresenta um estudo
específico sobre princípios de usabilidade aplicáveis ao ambiente de televisão digital
interativa e de que forma estes princípios poderiam ajudar no resultado da utilização dos
componentes gráficos construídos neste trabalho. O capítulo seis descreve as definições
e etapas de construção da API proposta, além de descrever o uso e os resultados de uso
dos componentes gráficos construídos. O capítulo sete por sua vez, descreve um estudo
de caso criado para avaliar os componentes criados.
13
2 TELEVISÃO DIGITAL
A televisão é uma das principais fontes de informação existentes atualmente,
oferecendo entretenimento e cultura a seus utilizadores. Após a transmissão em cores, a
televisão está sofrendo mais uma nova grande mudança com a digitalização do sinal e
conseqüentemente a inclusão da capacidade de interação com o usuário em tempo real.
Apesar da produção e armazenamento das informações já serem digitais, a transmissão
ainda se dá via sinal analógico na televisão aberta.
A digitalização do sinal da televisão traz muitos benefícios ao usuário final, entre
eles estão:
•
Possibilidade de transmissão de imagens em alta definição com maior imunidade
a ruídos e distorções.
•
Possibilidade de transmissão de áudio de melhor qualidade, com menor ruído e
com utilização de mais de dois canais.
•
Possibilidade de transmissão de programas interativos junto com as imagens e o
som dos programas, fazendo com que a pessoa que assiste à televisão deixe de
ser apenas um expectador e se torne um usuário, que consegue interagir com a
programação da televisão.
•
Possibilidade de transmissão de vários programas por um único canal.
•
Possibilidade de recepção de sinais de televisão em dispositivos móveis
(celulares, pdas, etc).[MON05]
Porém a característica mais interessante da TV digital combinada com um canal de
retorno é a possibilidade de criação de serviços interativos como, por exemplo, vídeo
sob demanda, pay-per-view, exibir programas esportivos em vários ângulos, jogos, chat,
além da possibilidade de uso da televisão na educação à distância. [TEI06]
“A TV Interativa está causando uma revolução no mundo todo por causa do
seu poder de feedback. A emissora, que antes contava apenas com estimativas de
audiência (como a que é feita pelo IBOPE no Brasil), agora possui dados estatísticos
precisos e reais sobre seus produtos e sobre a preferência de seus usuários que
puderam se segmentar para produtos audiovisuais um pouco mais específicos e ligados
ao seu interesse.” [TEI06]
Esta nova forma de interatividade tem grande importância para a sociedade como
um todo, principalmente pelo grande número de pessoas que possuem televisão em suas
residências. Em 2004 a televisão existia em 91,4% dos domicílios e o rádio em 88,0%,
enquanto o microcomputador estava disponível em 18,6% das residências. [IBG05]
14
Além de oferecer interatividade, a televisão digital oferece uma nova forma de
transmissão de sinal, o sinal digital pode ser emitido via satélite, via cabo ou broadcast
terrestre, nas residências o sinal é decodificado no set-top-box1, que são aparelhos
ligados ao televisor. Em cada set-top-box um middleware faz o controle das operações
de entrada e saída, além de oferecer capacidade de processamento para aplicações que
são recebidas através do sinal que é transmitido junto com o vídeo e o áudio dos
programas de televisão. Além da possibilidade de recepção de sinais televisivos em
residências com o uso de antenas e set-top-boxes ligados a televisores, o conteúdo da
televisão digital pode ser visto em carros, trens e telefones celulares. Com isso a
complexidade dos programas interativos deve ser tratada como fator fundamental no
sucesso do programa, já que a aplicação não será executada necessariamente em um settop-box. [TEI06]
Esta nova forma de transmissão tem uma arquitetura básica, que é definida pelo
termo “sistema de televisão digital”, que nada mais é que um conjunto de definições
criadas para servirem como referência, seja para a construção de aparelhos eletrônicos,
construção de novas linguagens para a televisão digital ou padronização de codificações
de vídeo ou áudio. Como podemos observar na Figura 2.1, a arquitetura de um sistema
de televisão digital é composta de cinco camadas, são elas: Transmissão, transporte,
compressão, middleware e aplicativos. [SUF04]
Figura 2.1: Arquitetura de um sistema de IDTV. [SUF04]
Após a definição das camadas básicas de um sistema de televisão digital, padrões
foram criados pelos consórcios formados pelos governos e por empresas do ramo de
televisão.
2.1 Padrões
Atualmente existem três padrões mundiais de televisão digital, o padrão europeu, o
padrão americano e o padrão japonês. Além destes três padrões, o Brasil optou pela
criação de um novo padrão, que utiliza como base para transmissão o padrão japonês,
mas a codificação de vídeo e o middleware usados são diferentes de todos os outros
padrões, assim o padrão brasileiro se tornou um padrão “híbrido”, unindo características
1
Set-top-box – Conversor
15
de transmissão do padrão japonês com um middleware brasileiro e com outros padrões
de codificação de vídeo e de áudio. [OLI05]
O padrão europeu é denominado como DVB (Digital Video Broadcasting)
[MHP08], o norte-americano é denominado como ATSC (Advanced Television Systems
Committee) [ATS08], o padrão japonês é denominado como ISDB (Integrated Services
Digital Broadcasting) [DIB08], já o padrão “brasileiro” é denominado como ISDTV-T
(International System for Digital TV). Cada um destes padrões define como será feita a
codificação de vídeo e áudio, além de padrões para a transmissão de dados e um
middleware específico, que rodará nos set-top-boxes compatíveis com o seu padrão.
[OLI05]
Na figura 2.2, podemos ver alguns dos padrões definidos mundialmente para os
sistemas de televisão digital.
Figura 2.2: Distribuição mundial dos padrões de middlewares existentes. [ASS08]
O padrão DVB é utilizado em países da Europa, áfrica, Oceania e Ásia. Ele define
como padrão de transmissão via satélite o padrão DVB-S, como padrão para transmissão
via terrestre o padrão DVB-T e via cabo o padrão DVB-C. Assim como o ISDB, o
ISDTV-T definiu três padrões de transmissão via terrestre, satélite e cabo. Já o ATSC
possui apenas a transmissão via broadcast terrestre e via cabo. Os padrões DVB, ISDB e
ATSC utilizam o MPEG-2 para codificação de vídeo, já o ISDTV-T utiliza o MPEG-4
como padrão para codificação de vídeo. [DIN08]
Dentro do padrão DVB existe o middleware MHP (Multimedia Home Platform)
[MHP08], criado pelo consórcio DVB e que define um conjunto de tecnologias para
aplicações interativas digitais, este middleware visa adaptar a Internet à televisão
digital, provendo assim, conteúdo interativo digital no terminal do usuário. Possui dois
tipos de aplicações: DVB-HTML e DVB-J, sendo a última a mais popular. Esta é escrita
em Java usando um conjunto de APIs definidas pelo MHP. [DIN08]
O padrão ATSC é utilizado nos Estados Unidos, Canadá, México e na Coréia do Sul.
Ele definiu o DASE como middleware do padrão norte americano. As aplicações
desenvolvidas tanto para o MHP quanto para o DASE são compatíveis com a tecnologia
Java. [DIN08]
16
O Padrão japonês ISDB é utilizado apenas no Japão, e o padrão de transmissão é
utilizado no Brasil, este padrão define o ARIB como middleware e tem como
característica principal oferecer melhor distribuição do sinal, porém exigindo melhores
condições de infra-estrutura que os outros padrões mundiais. [DIN08]
Já o padrão brasileiro IDSTV-T utiliza o Ginga como padrão de middleware, o Ginga
é dividido em duas plataformas principais: Ginga-NCL e Ginga-J. [DIN08]
Ginga-NCL é o framework utilizado para a execução de aplicativos NCL e
aplicativos escritos na linguagem LUA. Já o Ginga-J é o framework responsável pela
implementação da máquina virtual Java e das APIs que possibilitarão a construção e
execução de xlets.
O middleware é uma das partes mais importantes em um ambiente de televisão
digital, pois é ele quem define o conjunto de tecnologias que serão implementadas e
como estas tecnologias serão empregadas.
2.2 Middlewares
O middleware é uma das camadas mais importantes no contexto de um sistema de
televisão digital. De uma forma genérica, middlewares são definidos como uma camada
de software que liga dois sistemas separados, um deles sendo software e o outro sendo
hardware. No caso da televisão digital, ele liga o hardware do set-top-box e o sistema
operacional do set-top-box às aplicações. [SOU03]
Além de exercer a função de ligar dois sistemas distintos, ele oferece APIs de
desenvolvimento para auxiliar os desenvolvedores na construção de aplicações que
utilizem os recursos que a televisão digital propicia, por exemplo, manipulação de
gráficos, faixas de áudio e vídeo, acesso ao canal de retorno, construção de interfaces,
acesso as informações do serviço, entre outros. A figura 2.3 demonstra como a
arquitetura de um middleware para IDTV é dividida e como os componentes são
organizados.
Figura 2.3: Arquitetura do middleware para IDTV [SOU03]
17
Os padrões de middlewares foram definidos por consórcios formados por empresas
que trabalham no meio televisivo e alguns foram desenvolvidos em conjunto com o
governo de seus países. Na Tabela 2.1 podemos ver quais linguagens de programação
são suportadas pelos padrões de middlewares existentes até o momento e quais
frameworks são compatíveis com estes padrões de middlewares.
Além disso, a tabela 2.1 apresenta quais normas estão relacionadas com os padrões
estabelecidos para programação nos middlewares e quais linguagens estas normas
contemplam.
Tabela 2.1: Middlewares atuais [DIN08]
Os ambientes declarativos geralmente são utilizados em aplicações mais simples e
que não precisam de muitos recursos, ocupam menos memória que os aplicativos
procedurais.
Em contrapartida, o ambiente procedural é implementado a fim de proporcionar
mais recursos se comparado ao ambiente declarativo. As aplicações procedurais
precisam de mais memória para serem executadas se comparadas as aplicações
declarativas, além disso, as aplicações procedurais são usadas em programas maiores e
mais robustos, que além de utilizarem componentes gráficos, precisam utilizar
esquemas de segurança de dados ou manipulação de dados.
2.2.1 Middleware MHP
O middleware MHP surgiu da necessidade de criação de um padrão europeu de
middleware pelo consórcio DVB para que uma plataforma de middleware fosse
compatível com as diversas marcas de set-top-boxes que já estavam disponíveis no
mercado. A sua especificação teve início no ano de 1997 e em junho de 2000 a
especificação da plataforma deu origem ao middleware MHP, nos anos seguintes foram
lançadas novas especificações para este middleware, e o seu nome foi revisado para
DVB-MHP. A tabela 3 demonstra a relação de versões do middleware MHP e o ano de
criação das versões. [OLI05]
Na tabela 2.3 encontramos a relação entre as versões do middleware MHP e seus
respectivos anos de criação.
18
Versão
1.0
1.1
1.1.1
1.1.2
Ano
2000
2001
2003
2005
Tabela 2.3: Relação de versões do MHP e dos anos de criação destas versões.
A principal característica do MHP é a definição de uma interface genérica entre as
aplicações interativas e o terminal, deste modo, o programador não precisa se preocupar
com detalhes específicos de hardware ou em qual marca de set-top-box a sua aplicação
irá rodar. [DVB07a]
“O MHP introduziu o conceito de Profile para ajudar na implementação das
padronizações. Um profile consulta uma área da aplicação e, conseqüentemente, as
potencialidades do set-top Box em operar com os diferentes tipos de funcionalidades
habilitadas pelo DVB”[OLI05]
Como podemos ver na figura 2.4, o DVB-MHP define três profiles distintos de
acordo com a capacidade dos dispositivos.
Figura 2.4: MHP Profiles [MHP08]
O perfil Enhanced Broadcast Profile foi definido já na primeira especificação do
MHP, ele é um profile básico e com recursos limitados, como um canal de retorno
limitado e não oferece suporte para conexão IP.
O perfil Interactive TV Profile também foi definido desde a primeira versão da
especificação do MHP. Este perfil é mais avançado que o perfil anterior em matéria de
desempenho, pois apresenta no terminal um canal de interação mais significativo,
além de que neste perfil, há possibilidade de realização de downloads, o que não é
possível com o perfil Enhanced Broadcast Profile.
O perfil Internet Access Profile foi definido na especificação MHP 1.1. É o profile
mais utilizado atualmente na especificação MHP, pois foi construído pensando em
19
execução em hardware com poder de processamento e memória maior do que os que
eram usados com os primeiros profiles definidos na especificação MHP. Ele oferece
suporte às aplicações com acesso a conteúdos da internet. Além disso, esse profile
contém o elemento DVB-HTML, no qual a informação é apresentada através de
conteúdo hipermídia.
O MHP é capaz de executar aplicações procedurais através do padrão DVB-J, que
define um conjunto de APIs para a construção de aplicativos, entre estas APIs estão a
JavaTV (desenvolvida pela Sun Microsystems), a API HAVi, criada por um consórcio de
marcas ligadas a televisão e que oferece componentes para a criação de interfaces com o
usuário e a API DAVIC, criada para especificar um padrão para interoperabilidade
fim-a-fim de informações audiovisual digital interativa e por difusão, além de uma
comunicação multimídia. [OLI05]
2.2.2 Middleware DASE
Nos países da América do norte temos como padrão de middleware o DASE, que foi
definido e implementado pelo consórcio ATSC no ano de 1982. O middleware DASE é
dividido em oito partes, como é mostrado na tabela 2.2. [OLI05]
Tabela 2.2: Divisões do middleware DASE [OLI05]
O middleware DASE é capaz de executar aplicações procedurais escritas na
linguagem Java e que façam uso da API JavaTV, além disso, o middleware DASE
oferece suporte a aplicações declarativas através de uma versão estendida de HTML e da
linguagem Java Script. Apesar de o DASE ter um modelo semelhante ao MHP, as duas
plataformas não são compatíveis, ou seja, os serviços desenvolvidos para uma
plataforma não serão compatíveis com a outra plataforma. [OLI05]
2.2.3 Middleware ARIB
No ano de 1999, o grupo japonês DiBEG promoveu o padrão japonês para a
televisão digital japonesa transmitida de forma terrestre, este padrão foi denominado
20
ISDB-T, alguns anos mais tarde, foram feitas especificações para mais dois padrões, o
ISDB-S e o ISDB-C. [OLI05]
Dentro da especificação ISDB, foi definido o ARIB como middleware, ele adota um
modelo de aplicação que permite a programação de conteúdo e aplicações.
O middleware ARIB é dividido em duas especificações:
•
ARIB STD-B24: É a principal especificação estabelecida pelo ARIB e é a mais
utilizada nos set-top-boxes, ela é organizada em três volumes, como podemos
ver na tabela 2.4, que descreve quais são os volumes existentes nesta
especificação e qual é o título que contempla cada volume:
Tabela 2.4: Divisão da especificação do ARIB STD-B24 [OLI05]
O primeiro volume trata das especificações de codificação de áudio e vídeo,
além disso, trata das especificações de transmissão.
O segundo volume e o terceiro volume tratam das especificações de uma
linguagem BML2, que é baseada na linguagem XML, mas com componentes
específicos para o ambiente de televisão digital interativa. Esta linguagem é
definida pelos componentes descritos pelo W3C: XHTML, CSS, DOM e
ECMAScript.
•
ARIB STD-B23: Especificação baseada no DVB-MHP, é considerada uma
especificação opcional, que oferece compatibilidade entre os padrões MHP e
DASE, deste modo compartilhando uma mesma plataforma “global”, deste modo
em conjunto com o consórcio DVB, foi criado o padrão GEM. [DVB07]
O padrão GEM foi criado com intuito de permitir que as organizações pudessem
definir especificações baseadas no MHP junto com o consórcio DVB e desta
forma oferecerem serviços compatíveis entre plataformas diferentes, desde que
estas utilizem o middleware MHP, que foi definido como middleware padrão
para a especificação GEM. [DVB07]
2.2.4 Middleware GINGA
O Brasil apresenta grandes diferenças sócio-econômicas em relação aos países
que já propuseram seus próprios sistemas de televisão digital, por isso a adoção integral
de qualquer um dos três padrões existentes não atende plenamente às condições
particulares e prioridades do país. Assim, o Brasil está desenvolvendo o seu sistema,
2
BML (Broadcast Markup Language) – Linguagem baseada na linguagem XML, foi desenvolvida pelo
ARIB no ano de 1999 e é utilizada no framework de desenvolvimento de aplicações declarativas no
padrão ARIB STD B-24. [ARI99]
21
modelo e padrão de TV digital no serviço de radiodifusão (televisão aberta),
denominado de Sistema Brasileiro de Televisão Digital (SBTVD). [DIN08]
O SBTVD envolve diversos setores do País, como universidades, empresas de
tecnologia e o próprio governo, que estão trabalhando para criar um modelo que possa
suprir os requisitos tecnológicos, mercadológicos, econômicos e sociais do Brasil.
[OLI05]
Entre as diversas atividades exercidas por este consórcio, estão a definição de
padrões e a organização de atividades relacionadas com televisão digital no Brasil.
Os padrões para a transmissão da televisão digital já foram definidos pelo
governo federal e pelo SBTVD. Apesar de ter adotado o padrão japonês de transmissão
(ISDB), os padrões de codificação de vídeo e o middleware usado são características
diferenciadas do padrão brasileiro de middleware em comparação com outros padrões
mundiais. [DIN08]
Como middleware, o Brasil definiu o Ginga, resultado de uma parceria entre o
governo federal com a universidade PUC do Rio de Janeiro [PUC08] e a Universidade
federal da Paraíba [UFP08]. A escolha destas universidades como centros de
desenvolvimento do middleware brasileiro se deve ao fato de que estas universidades
têm apresentado projetos focados na proposta de implementação de middlewares.
Como podemos ver na figura 2.5, o Ginga é dividido basicamente em duas
partes, a primeira é chamada de Ginga-NCL, já a segunda é conhecida como Ginga-J.
Essas duas partes são separadas pelo seu tipo de programação. O Ginga-NCL trata da
parte de linguagens declarativas que podem ser executadas no middleware, e o Ginga-J
controla a parte de programas procedurais que podem ser executados no middleware.
[ABN07]
Figura 2.5: Arquitetura do middleware Ginga [ABN07]
“Nas linguagens declarativas, o programador fornece apenas o conjunto das
tarefas a serem realizadas, não estando preocupado com os detalhes de como o
executor da linguagem (interpretador, compilador ou a própria máquina real ou virtual
de execução) realmente implementará essas tarefas. Em outras palavras, a linguagem
enfatiza a declaração descritiva de um problema ao invés de sua decomposição em
implementações algorítmicas, não necessitando, em geral, de tantas linhas de código
para definir uma certa tarefa.” [ROG06]
“Numa programação procedural deve-se informar ao computador cada passo
a ser executado. Pode-se afirmar que, em linguagens procedurais, o programador
22
possui um maior controle do código, sendo capaz de estabelecer todo o fluxo de
controle e execução de seu programa. Entretanto, para isso, ele deve ser bem
qualificado e conhecer bem os recursos de implementação.” [ROG06]
O Ginga-NCL é um framework que define um ambiente de apresentação para
aplicações declarativas escritas em NCL. NCL é uma linguagem de programação
declarativa, que foi derivada da linguagem XML e que oferece facilidades para a
especificação de aspectos de interatividade, além disso, o Ginga-NCL implementa uma
máquina virtual capaz de executar programas feitos na linguagem LUA. [SOU03]
O outro framework presente na especificação Ginga é chamado de Ginga-J e é
responsável pela implementação da máquina virtual que é capaz de executar programas
criados em Java, ao contrário do Ginga-NCL, o Ginga-J ainda não está totalmente
implementado devido a questões de royalties de APIs. [SOU03]
Além de implementar codificação de vídeo mais avançada que os outros
middlewares (o Ginga utiliza o padrão de codificação MPEG-4 enquanto os outros
utilizam MPEG-2), outra funcionalidade que não é implementada por outros
middlewares é a capacidade de carregar um programa de outra linguagem em tempo de
execução. Esta funcionalidade é possível graças a implementação de uma “ponte”, que
realiza as chamadas aos programas que serão executados sob o middleware. [ROG06]
Através da “ponte” implementada pelo middleware Ginga, as aplicações
construídas em linguagem declarativa podem ser executadas juntamente com as
aplicações procedurais através de chamadas feitas pelos aplicativos, desta forma os
desenvolvedores podem controlar uma determinada funcionalidade do aplicativo na
linguagem NCL e outras partes em linguagem Java ou LUA. [ROG06]
No escopo deste trabalho é importante destacar que, através dos estudos
realizados sobre os padrões de middlewares implementados até o momento podemos
definir que a maioria dos middlewares implementam dois ambientes de programação:
Um declarativo e outro procedural, e que todos os middlewares tem a linguagem Java
como padrão para aplicações procedurais.
Desta forma a API proposta por este trabalho torna-se compatível com qualquer
padrão de middleware existente e ainda possibilita a utilização de componentes em
programas escritos na linguagem NCL, já que esta pode utilizar aplicações Java em
tempo de execução.
23
3 LINGUAGEM NCL
A linguagem NCL (Nested Context Language) é uma linguagem de aplicação XML
que permite aos autores escreverem apresentações multimídia interativas. Ela é parte
das especificações de codificação de dados para o padrão brasileiro de televisão digital e
compreende a especificação da linguagem utilizada pela máquina de apresentação
Ginga-NCL do middleware Ginga. [SOU03]
Utilizando a linguagem NCL, um autor pode descrever o comportamento temporal
de uma apresentação multimídia, associar hyperlinks (interação do usuário) a objetos de
mídia, definir alternativas para apresentação (adaptação) e descrever o leiaute da
apresentação em múltiplos dispositivos. [SOA06]
A linguagem NCL é declarativa e tem como base o modelo NCM, que tem como
entidades básicas as entidades representadas na figura 3.1.
Figura 3.1: Modelo conceitual NCM básico [DIN08]
A figura 3.2 apresenta a estrutura básica de um aplicativo escrito na linguagem NCL,
quais conectores e quais regiões foram definidas na construção do aplicativo.
“Um programa criado em NCL é um arquivo escrito em XML. Todo
documento NCL possui a seguinte estrutura:
Um cabeçalho de arquivo NCL (linhas 1 e 2); uma seção de cabeçalho do
programa (seção HEAD, linhas 3 e 13), onde se definem as regiões, os descritores, os
conectores e as regras utilizadas pelo programa; o corpo do programa (seção BODY,
linhas 14 a 17), onde se definem os contextos, nós de mídia, elos e outros elementos que
definem o conteúdo e a estrutura do programa; pelo menos uma porta que indica por
24
onde o programa começa a ser exibido (PORT PINICIO, linha 15); e a conclusão do
documento (linha 18).” [DIN08]
Figura 3.2: Estrutura básica de um documento NCL. [DIN08]
Além de oferecer suporte ao controle de mídias, a linguagem NCL pode ainda
chamar scripts escritos na linguagem LUA e xlets escritos na linguagem Java para serem
executados em uma determinada região de uma mídia definida em um programa escrito
em NCL. [SWP08]
Os xlets criados para a execução cooperativa com a linguagem NCL precisam ser
construídos garantindo a compatibilidade com o padrão JSR-1217 [JCP06] e com as
APIs definidas pelo SBTVD. Da mesma forma, os scripts construídos na linguagem
LUA precisam seguir os padrões definidos pela norma ABNT NBR 15606-2 [ABN07],
que define um conjunto de módulos que podem ser utilizados para a programação de
scripts.
3.1 Scripts LUA
A linguagem LUA é amplamente utilizada em ambientes gráficos, principalmente
em jogos e aplicações de tratamento de imagens, sendo caracterizada por ser uma
linguagem de grande poder computacional, por ser relativamente leve se comparada a
outras linguagens de programação como o Java e por ser uma linguagem de código
aberto. [LUA08]
25
A primeira revisão da linguagem foi apresentada no ano de 1983, pelo Telegraf, que
se trata do Grupo de Computação Gráfica da PUC-RJ [TEL08], atualmente a linguagem
está na versão 5.0.2, mas a versão 5.1 já está sendo implementada e testada. [CEL08]
Para a construção de interfaces no ambiente de televisão digital, a norma ABNT
NBR 15606-2[ABN07] define que é obrigatória a implementação do módulo canvas,
que se trata de uma API para desenhar primitivas gráficas e manipular imagens.
O módulo canvas oferece controles sobre cores, desenhos geométricos e
carregamento de imagens que serão utilizadas por um programa construído na
linguagem LUA. [ABN07]
Além de definir as funções que devem ser implementadas para realizar o tratamento
gráfico pela linguagem LUA, a norma ABNT NBR 15606-2 [ABN07] define que um
módulo event deve ser implementado pelo middleware, para realizar o tratamento de
eventos realizados pelo usuário.
Graças a implementação do módulo event, um formatador NCL pode se comunicar
de forma assíncrona com uma aplicação em LUA. Portanto, o uso mais comum para este
módulo resume-se em tratar eventos de usuário (controle remoto, interação com
componentes) e tratar eventos NCL. [ABN07]
“As relações em NCL são baseadas em eventos. Um evento é uma ocorrência
no tempo que pode ser instantânea ou ter duração mensurável.” [ABN07]
Apesar de a linguagem LUA oferecer grande poder computacional e ser leve, ela
não é implementada por todos os padrões de middlewares atuais, para ter
compatibilidade com todos os padrões, o desenvolvedor precisa utilizar a linguagem
Java, que será apresentada no estudo feito no próximo capítulo.
26
4 A LINGUAGEM JAVA E O AMBIENTE DE TELEVISÃO
A linguagem Java [SUN08a] sempre foi caracterizada pela compatibilidade com as
mais diversas plataformas existentes, desde servidores e aplicações web até sistemas
embarcados, como acontece em um ambiente de televisão digital.
Enquanto os padrões de transmissão dos sistemas de televisão digital eram criados, a
plataforma Java era consolidada como a linguagem que seria utilizada pelos set-topboxes, isto porque o Java já oferecia a plataforma J2ME (Java Micro Edition)
[SUN08b], que se trata de uma plataforma definida para sistemas embarcados ou que
oferecem pouco processamento e tem conectividade limitada.
Como podemos ver na figura 4.1, a plataforma Java oferece dois perfis para sistemas
restritos em capacidade de processamento e conectividade. O perfil CLDC (Connected
Limited Device Configuration) é destinado a sistemas com grandes restrições de
processamento e conectividade, além disso, este perfil é indicado para sistemas que
tenham limite de 512Kb de memória disponível para execução. Este perfil é
amplamente utilizado em telefones celulares. [KNU05]
Figura 4.1: Divisões de perfis, configurações e Máquinas Virtuais da plataforma
J2ME.
Além de oferecer o CLDC, a plataforma Java define o CDC (Connected Device
Configuration) [SUN05] como perfil para sistemas embarcados que possuem
capacidade de processamento maior que os sistemas que utilizam o CLDC, porém não
possuem as capacidades de um sistema definido na plataforma J2SE (Java Standard
Edition). Este perfil é utilizado em sistemas que não possuem mais de 2MB de memória
disponível para a execução de aplicativos Java e define um conjunto mais restrito de
APIs de desenvolvimento se comparada à versão J2SE do Java. [KNU05]
27
Os set-top-boxes rodam aplicações Java baseadas na configuração CDC, porém
como a configuração CDC possui APIs limitadas para desenvolvimento de aplicações,
cada padrão de middleware implementa o conjunto de APIs denominado JavaTV, que se
trata de um perfil que é vinculado à configuração CDC e oferece recursos adicionais
para que as aplicações Java possam desfrutar dos serviços oferecidos pelo sistema de
televisão digital. [OLI05]
Além disso, cada padrão de middleware implementa um conjunto de APIs auxiliares
ao desenvolvimento de aplicativos para a televisão digital, por este motivo as aplicações
que foram desenvolvidas em uma plataforma de middleware não são compatíveis com
outra plataforma de middleware. [OLI05]
Para auxiliar a criação de aplicações e garantir que a plataforma Java possa usufruir
de todas as funcionalidades que o middleware proporciona, cada padrão de middleware
implementa conjuntos de APIs que podem ser utilizadas na construção de aplicações.
No middleware MHP, há um padrão chamado DVB-J, que define um conjunto de
APIs para a construção de aplicativos Java, entre eles estão à biblioteca HAVi, o
framework DAVIC e a API JavaTV. [OLI05]
No middleware DASE, há uma divisão de ambientes, um destes ambientes é
denominado Procedural Application Environment, neste ambiente é definida uma JVM
(Java Virtual Machine) e o conjunto de APIs implementadas pelo middleware DASE,
entre estas APIs se encontra a API JavaTV. [OLI05]
No middleware japonês ARIB, é definida uma especificação chamada ARIB STDB23, que define uma JVM e um conjunto de APIs para desenvolvimento baseadas nos
padrões definidos pelo middleware DVB-MHP. [OLI05]
No middleware brasileiro Ginga, o framework Ginga-J é o responsável pela
especificação das APIs implementadas e pela definição da JVM, porém até o presente
momento o SBTVD não confirmou quais APIs serão implementadas pelo Ginga-J, nem
mesmo as especificações da JVM que será utilizada neste middleware. [DIN08]
4.1 API JavaTV
A API JavaTV [JTV00] foi desenvolvida pela Sun Microsystems para suprir as
necessidades dos desenvolvedores por programas interativos para que conseguissem
unir a capacidade de realizar interatividade com o usuário e controlar as operações de
segurança e de tratamento de dados.
Esta API foi desenvolvida de modo que cada programa de televisão seja tratado
como um serviço, e que em conjunto com a API Java Media Framework e um
subconjunto da API AWT, a API consiga fazer manipulação do vídeo e do áudio de
forma independente dos dados que são transmitidos junto com a mídia. [JTV00]
Além disso, a API JavaTV introduz um novo conceito de ciclo de vida das
aplicações feitas em Java, além de definir um gerenciador de ciclo de vida das
aplicações. No ambiente desktop, uma aplicação pode ser iniciada e finalizada, já em
um ambiente J2ME, uma classe que estende a classe MIDlet tem um ciclo de vida
28
diferente das aplicações desktop e das aplicações baseadas na configuração CDC.
[JTV00]
Como podemos ver na figura 4.2, um xlet3 tem um ciclo de vida que possui os
seguintes estados:
•
Loaded (Carregado)
•
Paused (Pausado)
•
Active (Ativo)
•
Destroyed (Destruído)
Figura 4.2: Ciclo de vida de um xlet [OLI05]
“Inicialmente, o gerenciador de aplicação carrega o Xlet principal,
instanciando através de um método new, para depois colocá-lo no estado Loaded.
A partir daí, o Xlet já está pronto para ser inicializado, seja pelo próprio
usuário, seja automaticamente. Para tanto, o gerenciador de aplicações usa o
método initXlet(), passando como parâmetro o objeto XletContent. Este objeto que se
comunica com o gerenciador de aplicações para solicitar uma mudança de estado do
Xlet. Usando o objeto XletContent, o Xlet consegue obter propriedades do
ambiente de execução e comunicar ao gerenciador de aplicação sobre as
mudanças de estado. Assim, o estado do Xlet pode ser alterado tanto por ele mesmo,
quanto pelo gerenciador de aplicação.[OLI05]
“Encontrando-se no estado Paused, significa que o Xlet foi corretamente
inicializado, não podendo manter ou usar nenhum recurso compartilhado. Para
ser ativado, o método startXlet() é utilizado. Desta forma, passa ao estado Active,
no qual o Xlet ativa suas funcionalidades e provê seus serviços, proporcionando a
interação propriamente dita com o usuário. Nada impede que o Xlet retorne ao
estado Paused, bastando para isso utilizar o método pauseXlet(). Para ser
destruído um Xlet, não importa em qual estado, deve ser utilizado o método
destroyXlet(), que o move para o estado Destroyed e libera todos os recursos e finaliza
a execução.” [OLI05]
Os desenvolvedores que utilizarem esta API para a construção de aplicações têm a
disposição os seguintes pacotes:
3
Xlet – Especificação de programa projetado para ser executado na configuração CDC.
29
•
Javax.tv.carousel: conjunto de classes que juntamente com o pacote Java.io
provêm acesso a arquivos em broadcast e diretórios de dados.
•
Javax.tv.graphics: cria mecanismos de implementação de transparências.
•
Javax.tv.locator: implementa componentes capazes de referenciar o conteúdo
acessível por esta API.
•
Javax.tv.media: implementa extensões e derivações de classes da API Java
Media Framework para o gerenciamento de mídias em tempo real.
•
javax.tv.net: implementa componentes que permitem o acesso e a transmissão de
datagramas.
•
Javax.tv.service: implementa o controle sobre serviços e acesso a bases de
dados. [JTV00]
Logo após a definição da API JavaTV, os desenvolvedores de aplicativos e as
empresas que trabalham no ramo de televisão começaram a desenvolver frameworks,
visando obter facilidade e eficiência na programação de aplicativos e a possibilidade de
agregar funcionalidades a API JavaTV.
4.2 API HAVi
A API HAVi foi criada inicialmente com o intuito de oferecer uma API que
permitisse a intercomunicação de dispositivos, porém com o passar do tempo, foi sendo
cada vez mais utilizada para a construção de interfaces gráficas, pois ela estende
capacidade dos componentes da API AWT da linguagem Java, de modo que consiga
atender a necessidade dos programadores de aplicativos para a televisão interativa.
Esta biblioteca foi criada por um grupo de companhias de produtos eletrônicos, e é
proprietária, ou seja, para utilizar os componentes implementados por ela os
desenvolvedores precisam pagar royaties. Ela especifica uma arquitetura de software
distribuída que busca assegurar a interoperabilidade entre dispositivos de áudio e vídeo
digital, deste modo os desenvolvedores tem a garantia de que os componentes utilizados
em seus programas são compatíveis com as mais diversas arquiteturas de áudio e vídeo
digital. [HAV01]
“Os fabricantes desenvolvem dispositivos interoperáveis, de forma que os
desenvolvedores de aplicações possam prover aplicações usando uma API Java
padronizada pelo próprio HAVi.”[OLI05]
A API divide-se basicamente em dois pacotes, um deles, trata da implementação dos
mecanismos de tratamento de eventos e é definida como org.havi.ui.event, já o outro
pacote trata da implementação dos componentes gráficos em si e é chamada de
org.havi.ui. Para a construção de interfaces gráficas, a biblioteca HAVi estende os
componentes da API AWT, presente no JDK 1.1. Porém ela não oferece o pacote AWT
por completo, mas sim algumas classes, que estão listadas na tabela 4.1. [HAV01]
30
Java.awt
Java.awt.event
Java.awt.image
Adjustable(intf)
ActionListener(intf)
ImageConsumer(intf)
ItemSelectable(intf)
AdjustementListener(intf)
ImageObserver(intf)
LayoutManager(intf)
ComponentListener(intf)
ImageProducer(intf)
LayoutManager2(intf)
ContainerListener(intf)
ColorModel
MenuContainer(intf)
FocusListener(intf)
DirectColorModel
AWTError
ItemListener(intf)
IndexColorModel
AWTEvent
KeyListener(intf)
MemoryImageSource
AWTEventMulticaster
MouseListener(intf)
PixelGrabber
AWTException
MouseMotionListener(intf)
BorderLayout
TextListener(intf)
CardLayout
WindowListener(intf)
Color
ActionEvent
Component
AdjustementEvent
Container
ComponentAdapter
Cursor
ContainerEvent
Dimension
FocusAdapter
Event
FocusEvent
EventQueue
InputEvent
FlowLayout
ItemEvent
Font
KeyAdapter
FontMetrics
KeyEvent
Graphics
MouseAdapter
GridLayout
MouseEvent
IllegalComponentStateException MouseMotionAdapter
Image
PaintEvent
Insets
TextEvent
MediaTracker
WindowAdapter
Point
WindowEvent
Polygon
ComponentEvent
Rectangle
ContainerAdapter
Shape
Toolkit
Tabela 4.1: Classes do pacote Java.awt disponíveis para o framework HAVi
[HAV01]
Todos os componentes gráficos da biblioteca HAVi são componentes derivados da
classe HComponent, que por sua vez é derivada da classe Component, definida pelo
pacote Java.awt. [HAV01]
Porém isto não significa que para criarmos uma aplicação compatível com o HAVi
precisamos utilizar somente as classes definidas por este framework, os
desenvolvedores podem utilizar as classes do pacote Java.awt que estão presentes na
definição da biblioteca HAVi.
31
4.2.1 Componentes Gráficos
A biblioteca HAVi implementa uma série de componentes gráficos que trazem como
objetivo aumentar a capacidade de representação gráfica da API AWT e fornecer classes
de uso específico no ambiente de televisão interativa.
Para gerenciar questões relacionadas ao vídeo em si, a API implementa a classe
HScreen, cada instância desta classe representa um sinal independente do dispositivo,
que é composto por sinais de vídeo, sinais gráficos e planos de fundo, a partir desta
classe é possível obter o objeto instanciado da classe HScreenDevice, que faz controle
das propriedades do dispositivo de vídeo. [HAV01]
A forma de organização dos componentes é baseada em layers4 organizadas de
acordo com a sua função na interface gráfica do aplicativo. Como podemos ver na
figura 4.3, o sistema de camadas da API HAVi é dividido em quatro camadas, a
primeira, chamada de Background Image Plane é responsável pela imagem de fundo da
aplicação (se ela possuir), a segunda é chamada de Vídeo Plane, e é a camada onde os
vídeos e a mídia em si da televisão se encontra, a terceira é chamada de Application
Graphics Plane e comporta os componentes gráficos da API para a exibição de
aplicações e a quarta e última camada é chamada de Cursor Plane, que exibe os
cursores (se disponíveis). [HAV01]
Figura 4.3: Organização de layers utilizada pela API HAVi [EDW03]
A camada Application Graphics Plane é basicamente uma camada que contém um
container de alto nível implementado pela classe HScene, neste container, o
programador pode inserir qualquer componente gráfico, desde que ele seja derivado da
classe Component do pacote Java.awt ou derivado da classe HComponent, do pacote
havi.ui. [HAV01]
4
Layers – Camadas.
32
A API ainda define a interface HMatte que modifica a hierarquia de componentes
dentro da layer Application Graphics Layer e serve para incluir canais de transparência
no componente onde é implementada. [HAV01]
Na figura 4.4 podemos ver uma comparação de hierarquias de componentes em uma
interface construída com a classe HScene (representada por scene na figura), um
HContainer (representado por c3 na figura) e dois HComponents (representados por c1
e c3), e utilizando os mesmos componentes porém com interfaces HMatte
implementadas. [HAV01]
Figura 4.4: Comparação de hierarquias utilizando a interface HMatte [HAV01]
Então, basicamente para construirmos uma interface gráfica simples devemos seguir
os seguintes passos:
•
•
•
•
Criar um objeto da classe HScreen.
Após obter o objeto da classe HScreen, obter os objetos que correspondem as
camadas de fundo, de vídeo, e de aplicação gráfica.
Criar um objeto da classe HScene para o contexto da camada gráfica, este objeto
se comporta da mesma forma que um objeto Window ou Frame da API AWT, e
nele serão inseridos os componentes que irão compor a interface.
Inserir componentes gráficos e implementar o tratamento de eventos pelos
componentes. [POZ06]
Novos tipos de botões foram implementados a fim de melhorar as funcionalidades
da classe Button da API AWT. Os principais componentes implementados que
funcionam como botões são:
•
HGraphicButton: é a implementação de um botão compatível com diversos tipos
de listeners e que tem imagens associadas a este botão. Desta forma em cada um
dos estados deste botão uma imagem determinada pelo programador é mostrada
na tela. [HAV01]
Este componente implementa a interface HActionable, que permite as operações
de foco e associação de listeners com este componente.
•
HTextButton: implementa um botão que contém um texto simples no seu
interior. [HAV01]
33
•
HToggleButton: implementa um botão gráfico que tem comportamento
booleano, ou seja, pode estar no estado falso ou no estado verdadeiro, sendo
assim, tem o funcionamento semelhante a uma caixa de checagem.
Neste componente só uma imagem pode ser associada, se o programador precisa
utilizar um label como referência a este botão, terá que utilizar outro
componente da API HAVi. [HAV01]
Para realizar o controle de animações na tela, a API HAVi implementa os
componentes HAnimation e HStaticAnimation, o primeiro é capaz de transferir e receber
foco, já o segundo componente é estático e não pode ser acessado pelo usuário, os dois
funcionam basicamente da mesma forma quanto a forma de desenho, que se trata do
desenho de um vetor de imagens estáticas durante um período de tempo. [HAV01]
O controle de imagens é feito por classes específicas de acordo com o uso do
componente, para exibir uma imagem simples na tela as classes HStaticIcon e HIcon
devem ser usadas, sendo que na segunda há possibilidade de transmissão de foco pelo
componente. [HAV01]
Além das classes descritas anteriormente, a API HAVi implementa mais classes no
pacote havi.ui, que estão descritas no javadoc da API HAVi [HDO01].
Apesar de estender as capacidades de representação gráfica dos componentes da API
AWT, a biblioteca HAVi ainda necessita de melhorias que foram implementadas pela
Sun na construção da API Swing, como formas de desenhos com gradientes de cor e
suporte a transparência de forma natural pelos componentes, e não apenas através de
imagens com níveis de transparência.
Portanto, a API proposta neste trabalho traz como principal contribuição, a
construção de componentes totalmente compatíveis com os atuais padrões utilizados
nos middlewares, porém implementando algumas das funcionalidades presentes na API
swing e implementando novos componentes pensados de acordo com os princípios para
o ambiente de televisão digital interativa, e desta forma, complementando o número de
opções de componentes que podem ser usados, com componentes que contemplam
questões de usabilidade para a televisão digital e que são compatíveis com todos os
padrões de middlewares.
4.2.2 Manipulação de Eventos
Para a manipulação de eventos, a biblioteca HAVi implementa um pacote chamado
havi.ui.event, que contém classes derivadas das classes presentes no pacote
Java.awt.event, responsável pela manipulação de eventos na API AWT. [HAV01]
Os eventos podem ser gerados por um teclado, por mouse ou por um controle
remoto. Para detectar a presença de dispositivos como o teclado e o mouse, a API HAVi
implementa
a
classe
org.havi.ui.event.HKeyCapabilities,
a
classe
org.havi.ui.event.HMouseCapabilities e a classe org.havi.ui.event.HRcCapabilities.
[HAV01]
Os eventos de teclado são semelhantes aos eventos de teclado, porém possuem
alguns
identificadores
a
mais.
São
eles:
VK_COLORED_KEY_0,
VK_COLORED_KEY_1,
VK_COLORED_KEY_2,
VK_COLORED_KEY_3,
34
VK_COLORED_KEY_4 e VK_COLORED_KEY_5 para as teclas coloridas do controle
remoto, o identificador VK_POWER para a tecla de liga/desliga, além dos
identificadores VK_VOLUME_UP e VK_VOLUME_DOWN para as teclas de volume e
VK_CHANNEL_UP e VK_CHANNEL_DOWN para os botões de seleção de canal.
[HAV01]
Como podemos ver na tabela 4.2, o mecanismo de eventos da API HAVi é dividido
basicamente em sete classes, que complementam as classes que tratam eventos
presentes na API AWT padrão.
Classe HAVi
Uso
HActionEvent
Interage com um componente implementando a
interface HActionInputPreferred.
HFocusEvent
Interage com um componente implementando a
interface HNavigationInputPreferred.
HRcEvent
Possibilita a capacidade de captar eventos do
controle remoto.
HKeyEvent
Interage com um componente implementando a
interface HKeyboardInputPreferred.
HAdjustementEvent Interage com um componente implementando a
interface HAdjustementValue.
HItemEvent
Interage com um componente implementando a
interface HSelectionInputPreferred.
HTextEvent
Interage com um componente implementando a
interface HKeyboardInputPreferred.
Tabela 4.2: HUI Events [HAV01]
Estas classes correspondem aos tipos de eventos que qualquer classe derivada da
classe HComponent pode tratar, porém isto não significa que todas as classes da
biblioteca HAVi implementam todas as classes de tratamento de eventos.
O próximo capítulo trata de estudos realizados sobre alguns princípios de
usabilidade desejáveis para a construção de interfaces para a televisão digital e que
serão utilizados na construção dos componentes da API proposta por este trabalho.
35
5 USABILIDADE NA TV DIGITAL INTERATIVA
Junto com a melhoria da qualidade de som e imagem proporcionada pela recepção
de televisão digital, a possibilidade de transformar o telespectador, que até então era um
usuário passivo de televisão, ou seja, que só recebia informações e não era capaz de
interagir diretamente com a mídia, em um usuário de televisão tem importância
fundamental no contexto da televisão digital.
Essa importante mudança de conceitos, que transforma o telespectador em um
usuário capaz de interagir em tempo real com o sistema, precisa de atenção das
emissoras quanto ao desenvolvimento de aplicativos, pois estes serão usados por
pessoas de todas as faixas etárias e econômicas, que utilizam a televisão atualmente e
que virão a utilizar o sistema de televisão digital no futuro. [BEC06]
A importância da interatividade no ambiente de televisão fica evidente quando
lemos o decreto presidencial que definiu os objetivos a serem alcançados com o Sistema
Brasileiro de TV Digital, principalmente no trecho citado a seguir.
“promover a inclusão social, a diversidade cultural do país e a língua pátria
por meio do acesso a tecnologia digital, visando à democratização da informação”.
[DOU03]
Portanto, a preocupação com conceitos de usabilidade deve ser redobrada, pois
diversos fatores influenciam na complexidade do projeto de construção de interfaces,
como o nível de formação dos usuários, que é mais heterogêneo se comparado ao nível
de formação médio de usuários atuais de computadores. Além disso, o ambiente de
televisão digital visa ter a computação embarcada e invisível ao usuário, mostrando
apenas a interface de programas, mas não expondo questões computacionais ao usuário.
[BEC06]
Desta forma, a dificuldade na realização de projetos de aplicativos para o ambiente
de televisão digital fica evidente, pois os projetistas e desenvolvedores precisam manter
dois caminhos constantes no desenvolvimento: O primeiro deles visa proporcionar
recursos e interatividade para o usuário, seja de qualquer uma das seguintes formas:
•
•
•
Reativa: As opções são dirigidas pelo programa, havendo pouco controle do
usuário sobre a estrutura do conteúdo.
Coativo: O usuário tem a possibilidade de controlar a seqüência, ritmo e estilo da
interface.
Pró-ativo: O usuário pode controlar a estrutura e o conteúdo da interface.
[TEI06]
Já o outro caminho visa proporcionar interfaces simples, funcionais e de fácil
entendimento, visando sempre atender a qualquer tipo de usuário que virá a utilizar a
sua aplicação.
36
5.1 Usabilidade
Segundo NIELSEN [NIE08], a usabilidade tratada de um modo geral, trata-se de
uma medida de qualidade dos objetos e interfaces aliados a utilidade dos mesmos.
Porém, apesar de termos um conceito sobre o que é usabilidade, ainda não é possível
determinar a priori o conceito de uma boa interface, pois esta conceituação é dependente
de fatores externos, como tipos de usuários e das tarefas que estes usuários precisam
realizar em um determinado sistema.
Ainda segundo NIELSEN [NIE08], a usabilidade pode ser definida em cinco
componentes qualitativos:
•
Facilidade de aprendizado – A realização de tarefas e a exploração do sistema
são capazes de serem feitas rapidamente pelo usuário;
•
Eficiência de uso – A produtividade do usuário no sistema é elevada, uma vez
que este usuário esteja habituado com a interface do sistema;
•
Facilidade de memorização – O usuário utiliza o sistema de forma produtiva,
mesmo que este usuário não utilize o sistema freqüentemente.
•
Baixa taxa de erros – O usuário é capaz de realizar as tarefas necessárias no
sistema sem transtornos externos ao seu foco de trabalho e é capaz de reparar
erros caso seja necessário.
•
Satisfação subjetiva – O usuário interage com o sistema de forma simples,
porém funcional, considerando assim agradável a interação com este sistema.
Apesar de termos definições de usabilidade de um modo geral, cada tipo de sistema
requer a compreensão de princípios de usabilidade específicos, que podem ser aplicados
somente para aquele tipo de sistema, e com o ambiente de televisão digital isto não é
diferente.
Do ponto de vista tecnológico, a televisão interativa é tratada como uma combinação
de televisão digital com a tecnologia e os mecanismos de interatividade seja por
telefone, cabo, satélite ou mesmo sem possuir um canal de retorno. [BEC06]
5.2 Princípios de Usabilidade para o Ambiente de TV Digital Interativa
Apesar de NIELSEN [NIE08] ter enumerado e descrito componentes qualitativos
para a definição de usabilidade, cada sistema tem necessidades específicas, que são
definidas pelo tipo de usuário que o utiliza, pelo tipo de aplicação e ambiente desta
aplicação e pelas tarefas que são ou precisam ser realizadas neste sistema.
Portanto, pode haver princípios de usabilidade que são definidos e aplicados a um
determinado sistema, e a um tipo de usuário, mas que se usados em outro tipo de
sistema não irão obter o resultado esperado. O sistema brasileiro pode definir
determinados princípios a serem usados na construção de interfaces para o sistema de
37
televisão brasileiro, e que não teriam tanta eficácia caso fossem aplicados ao padrão
americano de televisão digital, por exemplo.
Na tabela 5.1, que é uma adaptação de NIELSEN [NIE97], são mostradas algumas
das diferenças mais significativas entre a televisão digital interativa e o computador.
Tabela 5.1: Televisão Convencional X Computador. [PIC06]
Mas mesmo tratando a televisão digital de uma forma única, desconsiderando a
questão da diferença entre os usuários, ainda há muitas diferenças de uma aplicação
para a televisão e uma aplicação para PCs comuns.
“Em relação a um PC, a TV interativa apresenta uma série de diferenças
importantes; tela de menor resolução e com área periférica sujeita a distorções, não
oferece rolagem horizontal, propõe dispositivos bastante limitados para o controle da
dados (...) a tecnologia atual ainda apresenta deficiências como lentidão nas respostas
e freqüentes bloqueios, com a necessidade de recarregar o sistema.” [BEC06]
Além de que, a principal proposta das aplicações para a televisão é oferecer
interatividade ocultando questões computacionais do usuário. Portanto, a grande
maioria dos erros devem ser detectados e corrigidos pelo próprio software evitando que
o erro chegue até a interface que interage com o usuário.
38
Quanto aos textos exibidos na tela, algumas considerações importantes devem ser
levadas em conta no projeto de construção de interfaces para a TV digital. BBC
[BBC08] sugere sete considerações importantes sobre legibilidade em monitores de
televisão, são eles:
•
Na maioria dos casos, se possível utilizar fontes maiores que 24 pontos;
•
Em nenhuma circunstância textos apresentados na tela devem ter menos de 18
pontos;
•
Preferencialmente utilizar textos com cores mais claras que a cor de fundo, pois
facilitam a legibilidade na tela;
•
Os textos precisam espaços nas entrelinhas maiores que textos impressos;
•
Se for possível, o espaço entre os caracteres de um texto deve ser aumentado em
30% em relação ao espaço normal;
•
Se for possível, uma tela completamente composta de textos deve conter no
máximo 90 palavras;
•
Para facilitar a leitura e aumentar a velocidade de leitura, os textos devem ser
divididos em pequenos blocos.
As cores têm papel fundamental na construção das interfaces, na televisão digital o
controle remoto por padrão traz quatro botões coloridos que servem para permitir o
acesso rápido a determinadas funções designadas pelo programador. [BEC06]
“Porém, apesar da eficiência da cor no processo de memorização, é
importante evitar excessos. Uma interface completamente ocupada por qualquer uma
das quatro cores, devido a sua saturação, poderia rapidamente causar fadiga visual em
seus usuários”. [BEC06]
A navegabilidade é outra característica importante na construção de interfaces, pois
ela define questões de como o usuário poderá alcançar o seu objetivo na interação com
o programa.
Segundo KRUG [KRU06], a navegação tem os seguintes objetivos:
•
Ela dá algo ao qual nos apoiamos - Opções de retornar, e informações de
localização do usuário na interface.
•
Ela nos diz o que existe no site – Mostra uma breve listagem do conteúdo total
da interface.
•
Ela diz como usar o site - Em uma navegação bem projetada é dito
implicitamente onde devemos começar ou quais são os locais onde podemos
encontrar o que queremos.
Ainda segundo KRUG, a navegação possui alguns conceitos básicos que, se
seguidos pelo desenvolvedor facilitam a navegação e a satisfação do usuário nas
interfaces construídas. São eles:
•
•
•
•
Sempre oferecer um caminho de volta ao usuário;
Oferecer um caminho de volta ao início;
Oferecer indicadores que mostrem aonde está o foco da interface e indiquem
onde o usuário se encontra no contexto da interface;
Limitar a profundidade de caminhos pela interface;
39
Com base nos estudos realizados sobre os conceitos gerais sobre usabilidade e sobre
as diferenças entre o ambiente de computadores pessoais e o ambiente de televisão
digital interativa, é possível considerar a implementação de uma API que ofereça
componentes gráficos flexíveis, ajudando o desenvolvedor a construir interfaces que
contemplem os princípios de usabilidade para a televisão digital.
40
6 PROJETO E IMPLEMENTAÇÃO DA API
A partir dos estudos feitos nos princípios de usabilidade e nas opções de frameworks
já existentes para a criação de interfaces para programas interativos, este trabalho traz
como proposta a construção de uma nova API que implemente novos componentes que
priorizem a compatibilidade com diversos padrões de middlewares e que ajudem na
construção de interfaces que contemplem os princípios de usabilidade estudados
anteriormente.
Estes componentes foram criados de forma a explorar a capacidade de representação
gráfica oferecida pela API AWT e, além disso, fornecer uma nova forma de interação
com os componentes utilizados nas interfaces criadas.
Esta API é totalmente compatível com o perfil JSR 217[JCP06], que é amplamente
utilizado pelos padrões de middlewares, desta forma esta API tem compatibilidade total
com todos os padrões de middlewares que implementam uma JVM até o presente
momento.
Uma lista foi criada para definir os principais princípios de usabilidade que serão
levados em conta na construção dos componentes gráficos da API proposta neste
trabalho.
• Facilidade de aprendizado
• Facilidade de memorização
• Baixa taxa de erros
• Satisfação subjetiva
• Utilização de cores mais escuras nos planos de fundo
• Espaço nas entrelinhas de textos maior que em textos impressos.
• Evitar saturação de cores na tela.
Após a definição da lista de prioridades de usabilidade que os componentes devem
ajudar a implementar, a estrutura básica da API foi construída, e os componentes foram
construídos. No final deste capítulo, há uma descrição completa de quais princípios de
usabilidade são implementados e onde eles foram implementados.
6.1 Definições
Para garantir a compatibilidade desta API com os padrões de middlewares atuais, foi
implementada a classe MComponent, que através da derivação da classe Component do
pacote java.awt, como mostrado na figura 6.1, garante a compatibilidade com as APIs
criadas que tem como base a API AWT, como por exemplo a API HAVi.
41
Para a construção de painéis e containeres, a classe Container do pacote Java.awt foi
utilizada como base para a construção da classe MContainer, que é a classe base para
todos os containeres implementados na API, desta forma os containeres construídos
nesta API são totalmente compatíveis com os gerenciadores de leiautes do pacote
Java.awt.
A principal característica criada pela classe MComponent e pela classe MContainer
é a implementação do mecanismo de double buffering, que evita o aparecimento de
erros durante o desenho dos componentes gráficos na tela.
Figura 6.1: Componentes base para a construção da API.
6.2 Double Buffering
Um dos problemas encontrados no início do desenvolvimento dos componentes
gráficos foi a dificuldade de redesenhar os componentes na tela sem que ocorresse
flickering, que se trata de um problema muito comum em componentes gráficos
definidos em APIs mais antigas.
Isso acontece porque um componente é desenhado na tela depois que a máquina
virtual faz uma requisição verificando se pode utilizar o objeto que desenha o
componente na tela. Se o método que realiza o desenho na tela faz muitas operações,
pode ser que quando uma requisição é feita apenas uma parte do componente seja
desenhada, e desta forma o componente pode ser desenhado em partes ou acontecem
piscadas quando o componente é desenhado, isto acontece em transições rápidas de tela
ou de componentes na tela. [SUN08]
Para resolver este problema, todos os componentes implementados nesta API
possuem dupla buferização, também conhecido como double buffering. Esta técnica
consiste na definição de um buffer e toda vez que um componente é desenhado,
primeiro o programa desenha todas as formas em um buffer, nesta API o buffer é um
objeto BufferedImage da API AWT, e o buffer é desenhado na tela, desta forma o
42
método de desenho dos componentes realiza somente uma operação, evitando o
flickering.
A dupla buferização já é implementada na API Swing [SUN08], mas como esta API
não é implementada pelos padrões de middlewares, esta funcionalidade foi
implementada integralmente para a API proposta.
6.3 Eventos
A implementação de um mecanismo de eventos internos e externos aos
componentes tem importância vital no trabalho, pois dita a facilidade de acesso aos
componentes e obtenção de resultados de suas ações.
6.3.1 Interface MActive
Para realizar o controle de eventos nos componentes da API, uma interface chamada
MActive foi criada. Esta interface define um conjunto de constantes que definem
possíveis estados que um componente da API pode ter.
O diagrama representado pela figura 6.2 representa os possíveis estados de um
componente, que inicialmente sempre é definido como desabilitado. Caso o
programador deseje que este componente possa responder a eventos externos e que
possa gerar eventos, ele deve mudar manualmente o estado deste componente para o
estado normal, caso o programador queira desabilitar o componente, ele deve mudar o
estado do componente para desabilitado de forma manual.
Quando um componente está em seu estado normal ele pode mudar para o estado
FOCUS_STATE caso ele receba foco do container no qual ele se encontra. Caso o
componente esteja no estado FOCUS_STATE, pode passar para o estado
NORMAL_STATE se ele perder o foco, ou pode ir para o estado LOCK_STATE caso o
usuário queira trancar o foco no componente e então a interação com este componente
pode ser realizada.
A partir do momento que o componente se encontra no estado LOCK_STATE, a
interação com este componente pode ser realizada, e quando uma interação com um
componente é realizada este componente passa a estar no estado ACTION_STATE, ou
seja, no estado que representa a realização de uma ação no componente.
Para evitar que o usuário tenha que clicar duas vezes em um botão (uma para travar
o foco neste botão e outro para realizar a ação), todos os botões criados nesta API
passam do estado FOCUS_STATE para o estado ACTION_STATE, desta forma o
usuário precisa interagir apenas uma vez com o componente para realizar uma ação e
estas definições otimizam o uso do controle remoto reduzindo ao mínimo possível o uso
de comandos pelo usuário.
Após a realização de uma ação por parte do componente, o estado do componente
volta automaticamente para o estado FOCUS_STATE.
A troca de foco entre os componentes é responsabilidade do container no qual o
objeto se encontra, desta forma o programador pode implementar novas formas de
43
trocar o foco mudando o comportamento de um único container, sem a necessidade de
mudar o modo de funcionamento de todos os componentes.
Figura 6.2: Diagrama de estados possíveis de um componente que implementa a
interface MActive
Além de definir constantes de estados dos componentes, a interface MActive define
constantes de definição do tipo de entrada de dados que os componentes podem
implementar.
Como
podemos
ver
na
tabela
6.1,
são
eles
MActive.MOUSE_COMPATIBLE,
MActive.KEY_COMPATIBLE
e
MActive.MOUSE_KEY_COMPATIBLE.
Constante da classe MActive
MOUSE_COMPATIBLE
KEY_COMPATIBLE
MOUSE_KEY_COMPATIBLE
Função da definição
Define que o componente é
compatível com mouse
Define que o componente é
compatível com teclado e/ou
controle remoto
Define que o componente é
compatível com mouse e
teclado/controle remoto
Tabela 6.1: Constantes de controle de entrada de dados definidas na interface MActive.
6.3.2 Classe MControllerEvent
A classe MControllerEvent é uma classe que foi construída basicamente para
estender a classe KeyEvent do pacote Java.awt.event e para definir os códigos das teclas
especiais do controle remoto que não estão definidas originalmente na classe KeyEvent.
A tabela 6.2 mostra quais são os códigos de teclas definidas que não estão presentes
na classe KeyEvent.
44
Nome da constante
RED_BUTTON
BLUE_BUTTON
GREEN_BUTTON
YELLOW_BUTTON
EXIT_BUTTON
OK_BUTTON
UP_BUTTON
DOWN_BUTTON
LEFT_BUTTON
RIGHT_BUTTON
MULTI_BUTTON
NUMBER_SIGN_BUTTON
Código da tecla (int)
403
406
404
405
27
10
38
40
37
39
151
520
Tabela 6.2 Nomes de constantes e valores de teclas da classe MControllerEvent.
6.4 Pacotes
6.4.1 Pacote Maran.Component
O pacote Maran.Component contém todas as classes que definem os componentes
gráficos da API, assim como as classes pai utilizadas para definições mais abstratas dos
componentes construídos.
Na figura 6.3 podemos observar as associações e as derivações das classes criadas
neste projeto no pacote Maran.Component
Figura 6.3: Diagrama de classes do pacote Maran.Component
45
6.4.2 Pacote Maran.Event
Como podemos ver na figura 6.4, o pacote Maran.Event define duas classes que
ajudam no tratamento de eventos e na definição de estados dos componentes
implementados pela API.
A classe MControllerEvent é derivada da classe KeyEvent do pacote Java.awt.event
e sua função é basicamente definir os códigos das teclas do controle remoto, estes
códigos foram obtidos através do emulador xletview [XLE08].
Já a interface MActive define um conjunto de constantes usadas para definir os
estados de um determinado componente que implemente esta interface, além disso,
define um conjunto de métodos que devem ser obrigatoriamente implementados pelos
componentes que implementam esta interface.
Os métodos definidos pela interface MActive basicamente tratam da inclusão ou
remoção do tratamento de eventos, sejam eles de foco, mouse, controle remoto ou
mesmo eventos internos que ocorrem através da classe ActionEvent, presente no pacote
Java.awt.event.
Figura 6.4: Diagrama de classes do pacote Maran.Event
6.5 Componentes
6.5.1 MLabel
O componente MLabel tem como proposta oferecer algumas funcionalidades
específicas para o ambiente de televisão que não estão presentes na classe Label da API
AWT padrão do Java.
46
A função do componente MLabel é praticamente a mesma da classe Label da API
AWT [JCP06] padrão, ou seja, apresentar uma determinada
determinad cadeia de caracteres em um
container gráfico.
Este componente implementa o mesmo mecanismo de alinhamento de texto presente
na classe Label.. Porém, possui algumas vantagens em relação a classe Label:
Label
•
Possibilidade de utilização de cores com níveis de transparência, tanto no plano
de fundo do texto quanto no próprio texto.
•
Os textos podem ter mais de uma linha. O que era uma limitação da classe Label
que apenas apresenta um texto com uma única linha.
•
O componente ajusta a sua área automaticamente de acordo com o texto e a
fonte utilizada. Na classe Label o tamanho do componente tinha que ser definido
manualmente.
•
Possibilidade de escrita do texto em uma determinada cor e ter o plano de fundo
de outra cor ou apresentar o texto sem plano de fundo.
•
Oferece dois estilos de plano de fundo:
o Rounded:: plano de fundo com uma determinada cor e com bordas
arredondadas;
o Normal: plano de fundo com uma determinada cor e com cantos retos.
Para a construção deste componente, foram utilizados
utilizados objetos da classe FontMetrics
[JCP06]] para a medição de fontes, objetos da classe Font [JCP06]] para controlar as
fontes associadas ao componente e da classe Color [JCP06]] para o controle das cores.
Na figura 6.5 mostramos um exemplo de implementação da
da classe MLabel
utilizando
lizando transparência na cor de fundo e utilizando cantos arredondados.
Figura 6.5: Exemplo de uso da classe MLabel.
6.5.2 MImageItem
O componente MImageItem tem como proposta oferecer um componente que
desenha uma imagem estática na tela e que não seja capaz de tratar eventos de foco.
foco
O usuário pode associar uma imagem ao componente ou um endereço de onde a
imagem se encontra e o componente
c
carrega a imagem. Após a construção do
47
componente ou da associação de uma nova imagem ao componente, ele calcula
automaticamente o tamanho necessário dentro de um container para que o componente
seja desenhado.
A principal vantagem deste componente em relação a um componente Image
[JCP06] comum da API AWT é o processo de desenho da imagem na tela. Neste
componente a imagem é transformada em um objeto da classe BufferedImage e então
desenhada na tela. Desta forma o flickering é evitado em transições de tela.
Este
ste componente não é capaz de modificar o nível de transparência de uma
determinada imagem associada a ele.
Na figura 6.6 mostramos um exemplo de uso da classe MImageItem utilizando uma
imagem de extensão PNG previamente carregada no programa.
Figura 6.6: Exemplo do uso da classe MImageItem.
MImageItem
6.5.3 MAnimation
O componente MAnimation define um componente que controla uma thread que
tem a função
ão exclusiva de controlar vetores de imagens que são mostrados na tela em
um determinado intervalo de tempo que é definido pelo programador.
A utilização de uma thread para a troca de imagens se deve pelo fato de que o
processo de desenho de um componente acontece através de threads e o desenho
d
que é
requisitado nem sempre pode ser atendido no momento pelo gerenciador gráfico.
gráfico
[SUN08]
O próprio componente trata erros que possam acontecer na execução da thread
criada especificadamente para a troca de imagens do componente, desta forma o
programador
gramador não precisa se preocupar com a propagação desses erros por outras partes
do programa que utiliza este componente.
Este componente pode realizar a troca de imagens na animação em um intervalo
de tempo definido pelo usuário da API, além disso, pode ter seu tempo de execução
variado, assim como pode ter a sua execução para sempre, ou seja, sem um limite de
tempo de execução que também é determinado pelo usuário da API,,a constante que
define a execução contínua e sem limite de tempo é a constante
MAnimation.FOREVER.
48
Na figura 6.7 podemos ver um exemplo de uso da classe MAnimation utilizando
uma animação de dez imagens no formato PNG sem limite de tempo de execução da
animação.
Figura 6.7 Exemplo de utilização da classe MAnimation.
MAnimation
6.5.4 MSlider
O componente MSlider define um componente que tem como principal função
registrar uma medida de acordo com a escolha do programador. O programador define
um valor mínimo e um valor máximo, enquanto o usuário pode interagir com este
componente movimentando um ponto horizontalmente por uma barra para a escolha de
um valor.
Para facilitar a integração deste componente com as interfaces que serão criadas pelo
programador, o componente foi construído permitindo que o programador utilize a
forma padrão de desenho do componente ou que associe imagens a este componente, e
desta forma permitindo uma maior integração deste componente com o ambiente da
aplicação em si.
A forma de desenho é baseada na área que o programador definiu para o
componente, desta forma o programador
programador só precisa se preocupar com os limites do
desenho do componente, pois as medidas de desenhos são calculadas automaticamente
pelo próprio componente.
Diferentemente da forma de desenho, na forma de associação de imagens o
programador apenas associa as
as imagens ao componente na construção do componente, e
o próprio componente calcula o tamanho necessário
necessário para o desenho das imagens. O
programador não precisa necessariamente utilizar uma imagem de ponto central maior
que a imagem da barra do MSlider, o componente
mponente irá calcular o tamanho necessário do
componente com qualquer combinação de tamanhos das imagens.
49
Na figura 6.8 podemos ver um exemplo de utilização do componente MSlider na
forma de desenho normal.
Figura 6.8: Exemplo de utilização do componente
component MSlider com a forma de desenho
padrão.
Na figura 6.9 podemos ver um exemplo de utilização do componente MSlider na
forma de desenho associado a imagens.
Figura 6.9:: Exemplo de utilização do componente MSlider com a forma de desenho
associado a imagens.
6.5.5 MPanel
O componente MPanel define um container capaz de transferir o foco entre os
componentes presentes dentro deste componente utilizando as teclas direcionais do
50
controle remoto da televisão. A troca de foco entre os componentes é implementada
implem
por
métodos que são
ão chamados pelos componentes presentes no MPanel.
Para integrar o componente ao conceito de troca de foco a cada interação de teclas
direcionais, o programador deve adicionar o código mostrado a seguir ao método que
trata os eventoss de teclado gerados para o seu componente.
“((MPanel)getParent()).choiceFocusComponent(TECLA_DE_DIREÇÃO);
((MPanel)getParent()).choiceFocusComponent(TECLA_DE_DIREÇÃO);
((MPanel)getParent()).choiceFocusComponent(TECLA_DE_DIREÇÃO);”
Quando este trecho de código é utilizado pelo componente, o MPanel requisita o
foco e controla qual será o próximo componente que receberá o foco.
O componente é compatível com qualquer classe que seja derivada da classe
Component do pacote Java.awt,
Java
, ou seja, é compatível com qualquer componente
compon
implementado pela API HAVi,
HAVi pela API AWT ou pelos componentes construídos nesta
API.
Além de implementar o mecanismo de troca de foco e trava de foco nos
componentes presentes no MPanel,
MPanel, este componente permite que o programador associe
uma imagem de fundo com transparência ou uma cor simples com transparência como
plano de fundo, deste modo este componente garante
garante uma integração maior com o
ambiente em si, se comparado a um Panel [JCP06] definido no pacote Java.awt.
Java
Na figura 6.10, mostramos um exemplo de construção de um MPanel e como este
MPanel é mostrado na aplicação.
Figura 6.10: Construção e resultado de um MPanel contendo alguns componentes
desta API.
51
6.5.6 MColoredPanel
O componente MColoredPanel é um componente que exibe o conteúdo de até quatro
containeres, e que responde a eventos do controle remoto quando estes eventos estão
relacionados com os botões coloridos do controle remoto.
Quando este componente é ativado, todos os MPanels associados a ele são mostrados
mostra
na tela e cada MPanel é associado a uma cor de botão do controle remoto,
remoto deste modo a
troca de MPanels na tela é feita de forma rápida e intuitiva,
intuitiva, aumentando a eficácia de
uso da interface pelo usuário.
usuário Os MPanels podem conter formulários, componentes
soltos, ou até mesmo ser um container de vídeo.
Este componente utiliza o componente MImageRender para redimensionar
redimensio
os
MPanels para que seu tamanho seja compatível com o tamanho do MColoredPanel
oloredPanel
Para acessar este componente,
omponente, ele deve ser associado a um componente
MColoredButtonControl.. Na figura 6.11 temos um exemplo de construção do
componente em uma aplicação e o resultado de exibição do componente depois de
ativado.
Figura 6.11: Construção e resultado de um MColoredPanel contendo quatro MPanels
52
6.5.7 MColoredControlButton
Button
O componente MColoredControlButton
MColored
é um botão com aparência fixa, que tem a
função exclusiva de acionar um MColoredPanel que é associado a este componente
quando ele é construído.
Este componente
onente deve ser inserido em cada MPanel que está presente em um
determinado MColoredPanel,
MColoredPanel, para que quando este objeto seja acionado, o
MColoredPanel seja acionado e ganhe o foco na tela.
O motivo de o botão ter a aparência sempre fixa é facilitar a memorização
ização do usuário
quanto a funcionalidade do componente. O desenho do componente é feito de forma de
que se ajuste ao tamanho do componente que é definido pelo usuário.
Na figura 6.12 podemos ver um exemplo de implementação e o resultado posterior
do uso do componente MColoredControlButton.
MColored
Figura 6.12: Construção e resultado de um componente MColoredControl
ControlButton.
6.5.8 MImageButton
O componente MImageButton implementa um botão que possui imagens associadas
a ele e que são exibidas em cada um dos estados possíveis em que o componente se
encontra.
O programador pode associar três imagens ao componente ou três caminhos para as
imagens desejadas e o próprio componente
com
carrega as imagens.
Caso alguma destas imagens seja inválida, o componente dispara uma exceção,
exceção desta
forma o programador pode tratar algum erro que aconteça no momento em que o objeto
é criado.
O cálculo do tamanho necessário para o desenho do componente
componente é calculado
automaticamente pelo componente baseando-se
baseando se nas figuras que estão associadas e no
estado atual do componente. Caso ocorra uma exceção e o componente não consiga
calcular o tamanho das imagens associadas a ele, o componente define um valor
v
positivo para o seu tamanho evitando futuros problemas nas rotinas de desenho deste
mesmo componente na interface criada pelo usuário da API.
53
Na figura 6.13 podemos ver um exemplo de implementação e o resultado posterior
do uso do componente MImageButton.
MImageBu
Figura 6.13: Construção e resultado de um componente MImageButton.
MImageButton
6.5.9 MTextButton
O componente MTextButton implementa um botão que possui um componente
MLabel associado ou um texto simples associado e mostra este texto na tela com a
funcionalidade de um botão.
Caso o programador queira, o botão pode conter apenas o texto ou ser envolvido por
uma caixa de cor definida pelo programador, além disso, o botão suporta transparências.
O programador não precisa se preocupar com o tamanho do componente, pois este é
calculado automaticamente pelo próprio componente de acordo com a fonte utilizada e
com o tamanho do texto
to que está presente no botão.
Na figura 6.14 podemos ver um exemplo de implementação e o resultado posterior
do uso do componente MTextButton.
MTextButton
Figura 6.14: Construção e resultado de um componente MTextButton.
MTextButton
54
6.5.10 MAnimationButton
O componente MAnimationButton
imationButton implementa um botão que possui animações e
uma imagem associadas a ele, o estado normal é representado por uma animação, o
estado focado é representado por outra animação e o estado de ação é representado por
uma imagem estática que o programador
programador define na construção do objeto.
O controle de como este componente é apresentado é feito por uma thread, que
controla o vetor de imagens formado pelas animações associadas ao componente.
Na figura 6.15 podemos ver um exemplo de implementação e o resultado
res
posterior
do uso do componente MAnimationButton.
MAnimationButton
Figura 6.15: Construção e resultado de um componente MAnimationButton.
MAnimationButton
6.5.11 MImageRender
Como não temos um padrão de resolução no ambiente de televisão digital, as
imagens utilizadas nas interfaces devem ser redimensionadas conforme a resolução e o
tamanho da tela. Para realizar esta tarefa o componente MImageRender foi
implementado.
Sua principal
cipal função é receber um objeto do tipo Image ou do tipo BufferedImage e
redimensionar esta imagem de acordo com o tamanho desejado, mantendo a escala
original da imagem
m ou utilizando uma nova escala que é definida pelo usuário.
Para realizar a tarefa de redimensionamento, o componente redimensiona cada pixel
da imagem para um tamanho menor ou maior e desenha estes novos pixels em uma
imagem auxiliar, que no final da operação é retornada.
55
6.5.12 MDateChoice
A escolha de uma data para uma finalidade em programas
programas que rodam em PCs
geralmente são feitas com um calendário que é mostrado ao usuário ou com múltiplas
caixas de seleção, porém para facilitar este processo para o usuário e tornar esta escolha
possível interagindo somente com um único objeto, o componente
comp
MDateChoice foi
implementado.
O funcionamento básico do componente acontece da seguinte forma:
• Uma vez no estado travado, o usuário pode trocar de campos (dia, mês e ano)
utilizando as teclas direcionais para a direita e para a esquerda do controle
remoto.
• Estando um dos campos em modo de seleção, o usuário pode alterar o valor deste
campo utilizando as teclas direcionais para cima e para baixo do controle
remoto.
• Conforme o usuário interage com o componente, os campos auxiliares são
atualizados, para
ra manter a consistência dos dados das datas apresentadas na tela.
Para realizar o controle da data atual e dos limites de datas, a classe
GregorianCalendar [JCP06
JCP06]] foi utilizada realizando os controles internos sobre as
datas.
Na figura 6.16 podemos ver um exemplo de implementação e o resultado posterior
do uso do componente MDateChoice.
MDateChoice
Figura 6.16: Construção e resultado de um componente MDateChoice.
MDateChoice
6.5.13 MVirtualKeyboard
A entrada de dados é feita de forma restrita no ambiente de televisão digital, pois o
usuário nem sempre tem um teclado completo a disposição no set-top-box
box e o principal
dispositivo usado para a entrada de dados é o controle remoto.
Para facilitar a entrada
da de dados o componente MVirtualKeyboard foi criado. Sua
principal função é, em conjunto com o componente MTextField,, oferecer um teclado
virtual para que o usuário navegue utilizando teclas direcionais para selecionar as letras
que irão compor palavras inseridas
nseridas no MTextField.
56
O teclado associa quatro operações às teclas coloridas do controle remoto, desta
forma o acesso a essas funções pode ser feito através de um toque em algum dos botões
associados pelas cores.
Na figura 6.17 podemos ver um exemplo de implementação e o resultado posterior
do uso do componente MVirtualKeyboard.
MVirtualKeyboard
6.17: Construção e resultado de um componente MVirtualKeyBoard
VirtualKeyBoard.
.
6.5.14 MTextField
Para ser utilizado exclusivamente em conjunto com o componente
MVirtualKeyboard,, o componente MTextField foi construído com o intuito de ser uma
caixa de texto simples, que quando acionada pelo usuário, mostra um objeto
MVirtualKeyboard que é associado a ele e se comunica com este objeto.
Este objeto se comunica com o objeto MVirtualKeyboard associado através do uso
da classe ActionEvent [JCP06]. Na figura 6.18 podemos ver um exemplo de
implementação e resultado do uso do objeto MTextField em conjunto com o
componente MVirtualKeyboard.
MVirtualKeyboard
6.18: Construção e resultado de um componente MTextField.
MTextField
57
6.6 Integração de princípios de usabilidade
Durante a construção dos componentes, alguns princípios de usabilidade foram
considerados para que os componentes fossem construídos a fim de ajudar os
desenvolvedores na criação de interfaces que contemplem estes princípios de
usabilidade.
Na tabela 6.3, há uma descrição de quais princípios foram levados em conta e onde
estes princípios foram aplicados na construção de quais componentes.
Componente
Princípio
usabilidade
de Como foi implementado
Todos
Baixa taxa de erros
MLabel
Espaço
entrelinhas
que
em
impressos.
MLabel
Utilização de cores Plano
de
fundo
se
ajusta
mais escuras nos automaticamente ao tamanho do texto,
planos de fundo.
desta forma a leitura fica mais fácil
quando uma cor escura é usada como
plano de fundo.
MSlider
Facilidade
memorização.
MPanel
Facilidade
de Implementação do mecanismo de
aprendizado.
/ troca de foco através de teclas
Satisfação subjetiva. direcionais.
MPanel
Utilização de cores Implementação da possibilidade de
escuras nos planos integração de uma imagem ou de uma
de fundo.
cor estática ao plano de fundo do
MPanel.
MColoredPanel
Evitar saturação de Utilização de cores menos saturadas
cores na tela.
nos desenhos pré definidos pelo
componente.
MColoredPanel
Facilidade
memorização.
Tratamento
de
exceções
nos
componentes e disparo de exceções
não tratadas permitindo o tratamento
pelo desenvolvedor que utiliza os
componentes.
nas Implementação de métodos que
maior aumentam o espaço de desenho entre
textos as linhas quando um MLabel possui
mais de uma linha.
de O componente oferece a possibilidade
de desenho fixo, e a flexibilidade de
desenho que facilita a integração com
a interface desenvolvida.
de Interatividade baseada nas cores do
controle remoto. Facilitando a
identificação pelo usuário.
58
MColoredControlButton Facilidade
memorização
de Método de desenho estático, facilita a
memorização da ação do componente.
MColoredControlButton Evitar saturação de Utilização de cores menos saturadas
cores na tela.
nos desenhos pré definidos pelo
componente.
MImageButton
Utilização de cores Flexibilização
mais escuras nos parte gráfica.
planos de fundo.
do
componente na
MTextButton
Espaço
entrelinhas
que
em
impressos.
MDateChoice
Utilização de cores Flexibilização na escolha das cores do
mais escuras nos componente.
planos de fundo.
MDateChoice
Espaço
entrelinhas
que
em
impressos.
MDateChoice
Facilidade
aprendizado.
Facilidade
memorização.
de Componente intuitivo, muda cores
/ conforme o estado, facilitando o
de aprendizado e a memorização.
MVirtualKeyboard
Facilidade
aprendizado.
de Interação realizada
direcionais.
MVirtualKeyboard
Facilidade
memorização.
de Ações pré definidas para os botões
coloridos do controle remoto.
MVirtualKeyboard
Evitar saturação de Utilização de cores menos saturadas
cores na tela.
nos desenhos pré definidos pelo
componente.
nas Implementação de métodos que
maior aumentam o espaço de desenho entre
textos as linhas quando um MLabel possui
mais de uma linha.
nas Textos utilizados com
maior entrelinhas aumentado.
textos
com
espaço
teclas
Tabela 6.3: Relação entre princípios de usabilidade e os componentes construídos.
Após a implementação e o teste de todos os componentes quanto as suas funções, um
caso de uso foi criado para realizar testes quanto ao consumo de memória dos
componentes.
O caso de uso criado para testar os componentes e os seus resultados serão
apresentados no capítulo a seguir.
59
7 ESTUDO DE CASO
Para realizar a validação dos componentes construídos neste projeto, um estudo de
caso foi definido para testar o uso dos componentes em uma aplicação para a televisão
digital, e em outro caso, avaliar o consumo de memória dos componentes quando
utilizados.
Na criação e desenvolvimento dos componentes, a IDE NetBeans [NET08] foi
utilizada, pois como a API construída neste projeto utiliza somente componentes
presentes na biblioteca padrão da linguagem Java, a IDE NetBeans é compatível com o
desenvolvimento dos componentes desta API.
Além disso, nos primeiros testes realizados com os componentes a própria IDE foi
utilizada como software de testes e os componentes eram testados em Frames da API
AWT, portanto, apesar de que os componentes criados nesta API tenham sido
construídos e implementados tendo como alvo principal o ambiente de televisão digital,
nada impede que eles sejam utilizados em aplicações compatíveis com a plataforma
J2SE.
Porém a realização de testes utilizando a IDE NetBeans não pode ser considerada
uma simulação de um ambiente de televisão digital interativa. Tendo como solução a
utilização de um emulador ou de um set-top-box real. Todavia, o teste de uso dos
componentes em um set-top-box real ainda não é possível, pois ainda não há no
mercado um set-top-box que implemente o middleware Ginga e ainda não há
emuladores ou simuladores compatíveis com o padrão de middleware brasileiro.
Por isso, para a validação dos componentes quando usados em uma aplicação para a
televisão digital, o emulador xletview [XLE08] foi utilizado. Este emulador é um
projeto open source que tem como objetivo emular o uso de xlets compatíveis com o
padrão de middleware MHP.
O emulador xletview permite que os desenvolvedores testem os seus xlets sem a
necessidade de simular o set-top-box completamente, ele apenas implementa as APIs
utilizadas no framework responsável pela execução de aplicativos Java no middleware
MHP.
Para iniciar a execução de um xlet, o usuário deve acessar o menu Applications e
posteriormente o sub menu ManageApplications. Acessando este sub menu, uma
pequena janela aparece e nesta tela o usuário escolhe um nome para a sua aplicação e
indica o local onde os aquivos de extensão class gerados na compilação do xlet se
encontram.
Após a realização desta etapa, o usuário escolhe o item que corresponde a sua
aplicação no menu Applications e o xlet é executado.
60
Para simular o uso de um controle remoto, o desenho de um controle remoto é
mostrado sempre no lado direito da janela do emulador, e os eventos de controle remoto
são gerados conforme o usuário clica com o mouse nos botões deste controle remoto.
A interface do emulador é simples e as configurações de execução são limitadas. Na
figura 7.1 podemos ver a interface básica do programa.
Figura 7.1: Interface do software xletview.
Além da definição do cenário de teste, foi definida uma lista de componentes desta
API que foram testados e inseridos na aplicação criada.
Os seguintes componentes foram utilizados no teste de uso:
•
•
•
•
•
•
•
•
•
•
•
MLabel
MPanel
MTextButton
MImageButton
MTextField
MVirtualKeyboard
MSlider
MDateChoice
MAnimationButton
MImageItem
MColoredControlButton
Como container principal, a classe HScene da API HAVi foi utilizada, pois o
emulador xletview foi construído sob as especificações no middleware MHP, que utiliza
o container HScene como container principal para a camada de aplicação.
61
7.1 Testes
Para a realização do teste de uso dos componentes, um projeto foi criado na IDE
NetBeans e o arquivo jar da API criada foi adicionado ao projeto. Por um problema de
ligação do emulador, os arquivos de extensão class também precisaram ser copiados,
isto não precisou ser feito no teste de consumo de memória, pois este teste foi realizado
na própria IDE, que realizou a ligação com o arquivo jar de forma correta, portanto, a
ligação trata-se de um problema do emulador xletview.
A figura 7.2 demonstra o uso dos componentes em seu estado inicial e em um
segundo estado, onde o MImageButton utilizado na primeira tela foi acionado, além
disso, a figura indica quais componentes foram utilizados e onde foram utilizados na
emulação feita pelo software xletview.
Figura 7.2: Emulação dos componentes no software xletview.
62
Além de testar o uso dos componentes, outro cenário foi criado para avaliar o
consumo de memória dos componentes criados, este teste foi realizado na própria IDE
através do uso de um profiler5 que mede o uso de memória dos componentes em tempo
de execução.
Neste cenário, os componentes foram inseridos dentro de um container Frame
[JCP06], pois o profiler funciona somente com projetos criados para o ambiente J2SE,
porém isto não interfere na medição de memória dos componentes e não diferencia o
uso de memória dos componentes quanto ao uso em uma aplicação no ambiente de
televisão digital.
7.2 Resultados
Com o estudo de caso implementado e testado, alguns resultados foram obtidos.
Talvez o resultado mais interessante tenha sido a facilidade de programação e
integração dos componentes com exemplos já construídos em outros frameworks.
Isso se deve ao fato de que os componentes da API seguem um padrão de nomeação
de métodos e de atributos, desta forma um desenvolvedor que já programa na
linguagem Java irá reconhecer o nome dos métodos dos componentes. Além disso, um
javadoc completo foi gerado a partir do código final dos componentes, podendo ser
consultado pelo programador caso haja alguma dúvida quanto a utilização dos
componentes.
A geração do javadoc da API proposta por este trabalho foi realizada através da IDE
NetBeans e contém a descrição de cada método público ou protegido das classes criadas
na API. Além disso, as constantes que podem ser utilizadas por outras classes são
descritas quanto a sua funcionalidade e onde essas constantes podem ser utilizadas na
API proposta.
Uma das vantagens detectadas após a realização dos testes é demonstrada na tabela
7.1, onde o tamanho do pacote gerado pela API proposta é muito menor se comparado
ao tamanho do pacote gerado por uma API gráfica de uso geral como a API swing.
Pacote
Tamanho do pacote
(KB)
Swing.jar
2420
MaranAPI.jar
91
Tabela 7.1: Comparação de tamanhos de pacotes.
Outro resultado importante obtido com o teste dos componentes em conjunto com o
profiler oferecido pela IDE NetBeans foi a quantidade de memória ocupada por cada
5
Profiler – Recurso de monitoração de utilização de recursos por programas construídos na linguagem
Java, é capaz de realizar medições em tempo de execução do programa que será analisado. [NET08]
63
instância de objeto utilizado em uma aplicação, os resultados obtidos neste teste podem
ser vistos na figura 7.3.
Figura 7.3:: Resultado dos testes de ocupação de memória doss componentes
construídos.
Além de medir a ocupação de memória de alguns dos componentes criados por este
trabalho, uma medição semelhante foi realizada utilizando componentes gráficos da API
AWT para que uma comparação fosse realizada entre a questão de ocupação de memória
dos componentes. Os resultados das medições realizadas nos componentes da API AWT
podem ser vistos na figura 7.4.
7.
Figura 7.4:: Resultado dos testes de ocupação de memória dos componentes da API
AWT.
Foram comparados apenas os componentes da biblioteca AWT que possuem
funcionalidade semelhante com alguns dos componentes criados pela API construída
neste projeto.
Os resultados doss testes mostram que a API construída é tão leve quanto os
componentes mais básicos da API AWT e os componentes construídos ocupam pouco
espaço em memória,, apesar de oferecerem funcionalidades extras se comparados aos
componentes testados da API AWT, além disso, o pouco espaço ocupado em memória
pelos componentes construídos se trata de uma característica importante pelo fato de
que set-top-boxes
boxes são dispositivos que possuem capacidade de processamento
pr
e
memória limitados, características típicas da plataforma J2ME.
64
8 CONCLUSÃO
O interesse sobre televisão digital interativa tem aumentado constantemente
conforme os padrões brasileiros têm sido definidos e as primeiras soluções de
desenvolvimento têm sido lançadas no mercado. Isto é visto claramente se
considerarmos o grande número de novos fóruns de desenvolvimento focados
especialmente no ambiente de televisão digital interativa.
Primeiramente, este trabalho mostrou alguns conceitos básicos e apresentou um
breve estudo sobre os principais frameworks utilizados para a construção de interfaces
em sistemas de televisão digital, analisando as possibilidades de utilização e as
limitações existentes nestes frameworks.
Após o estudo realizado sobre os frameworks existentes, um estudo mais
aprofundado foi realizado tendo como foco a usabilidade de um modo geral na criação
de interfaces e alguns princípios de usabilidade que são desejáveis na construção de
interfaces específicas para o ambiente de televisão digital interativa.
Foram enumerados alguns princípios de usabilidade que seriam utilizados para a
construção dos componentes gráficos da API e então a implementação da API gráfica
foi realizada e os componentes desta API foram testados no emulador xletview.
A compatibilidade com todos os padrões de middlewares foi garantida graças ao uso
de classes que integram a API AWT que é um padrão consolidado na linguagem Java,
porém apesar de ter como mérito a compatibilidade, traz alguns bugs e limitações que
foram constatados durante o desenvolvimento do trabalho, principalmente no que se
refere à falta de implementações de objetos 2d, o que com certeza ajudaria na
implementação dos desenhos dos componentes e na possível criação de animações entre
as transições feitas pelos componentes.
O estudo dos princípios de usabilidade para a televisão teve grande importância no
desenvolvimento dos componentes, pois estes foram concedidos de forma que ajudem
os desenvolvedores a criarem interfaces que contemplem estes princípios de
usabilidade.
Outro fator determinante na construção da API proposta foi a facilidade de uso que
esta oferece ao programador, que conta com uma ferramenta open source,
completamente documentada e com características de programação semelhantes aos
frameworks que já existem no mercado, desta forma uma possível mudança de
utilização de tecnologias ocorre mais facilmente.
Um ponto importante a ser destacado, é que este trabalho contribui com a
colaboração do meio acadêmico na criação de projetos e na definição de padrões que
serão utilizados no sistema de televisão digital brasileiro.
65
8.1 Sugestões para Trabalhos futuros
Ao longo do desenvolvimento deste trabalho alguns temas interessantes foram
identificados e considerados importantes para o aprofundamento e desenvolvimento de
trabalhos futuros. Desta forma como trabalhos futuros podemos sugerir:
•
•
•
•
•
Implementação de um módulo baseado em princípios de usabilidade para a
linguagem LUA e o ambiente de televisão digital: Realizar um estudo
aprofundado sobre princípios de usabilidade e aplicá-los na implementação de
um módulo open source que ofereça componentes gráficos prontos e flexíveis
para a criação de scripts feitos na linguagem LUA.
Implementação de um módulo de controle de animações compatíveis com os
componentes criados neste trabalho de conclusão: Realizar um estudo profundo
na API AWT e considerar a implementação de um módulo capaz de controlar e
integrar animações de transição a componentes construídos a partir da API AWT,
conseqüentemente sugerindo a integração deste módulo com a API criada neste
trabalho.
Criação de um ambiente de avaliação de usabilidade utilizando os componentes
criados neste trabalho: Através de estudos realizados sobre ambientes de
avaliação de usabilidade de interfaces, criar um estudo de caso utilizando os
componentes gráficos criados nesta API e realizar testes de usabilidade
avaliando os mesmos.
Criação de um conjunto de classes que implementem mecanismos de
acessibilidade que possam ser integrados aos componentes criados neste
trabalho.
Realização de um estudo detalhado sobre os princípios de usabilidade
específicos para o ambiente de televisão digital, ambiente desktop e ambiente
web; Realizar um comparativo entre estes princípios e elencar as principais
diferenças e semelhanças entre os ambientes do ponto de vista da usabilidade.
66
9 REFERÊNCIAS BIBLIOGRÁFICAS
[TEI06]
Teixeira, Lauro H. P. - Usabilidade e Entretenimento na TV Digital
Interativa.
Disponível
em:
http://www.unirevista.unisinos.br/_pdf/UNIrev_Teixeira.PDF. Acesso em: 12 de abr.
2008.
[IBG05]
Instituto Brasileiro de Geografia e Estatística – Comentários sobre a
pesquisa
nacional
por
amostra
de
domicílios.
Disponível
em:
http://www.ibge.gov.br/home/estatistica/populacao/trabalhoerendimento/pnad2005/com
entarios2005.pdf. Acesso em: 20 de abr. 2008.
[OLI05]
Oliveira, Carina T. – Um estudo sobre os padrões de middleware para
televisão
digital
interativa.
Disponível
em:
www.gta.ufrj.br/~carina/artigos/MonografiaCarina.pdf. Acesso em: 26 de abr. 2008.
[ROG06]
Rodrigues, Rogério F.;Soares, Luiz F.G.– Produção de Conteúdo
Declarativo
para
TV
Digital.
Disponível
em:
http://www.ncl.org.br/documentos/SEMISH2006.pdf. Acesso em: 15 de abr. 2008.
[SOU03]
Leite, L., Batista, C., Souza, G., Kuleza, R., Alves, L., Bressan, G.,
Rodrigues, R., Soares, L. - Ginga-J: The procedural middleware for the brazillian digital
TV
system.
Disponível
em:
http://www.lavid.ufpb.br/papers/artigo_GingaJ_Revista_SBC.pdf. Acesso em: 29 de abr. 2008.
[DVB07]
Digital Video Broadcast Group – Globally Executable MHP (GEM)
Specification
1.1.1.
Disponível
em:
http://dvb.org/technology/standards/a103r1.tm3567r1.GEM1.1.1.pdf. Acesso em: 10 de
abr. 2008.
[SUN05]
Sun Microsystems – CDC: Java platform technology for connected
devices.
Disponível
em:
http://java.sun.com/javame/technology/cdc/cdc_whitepaper.pdf. Acesso em: 02 de abr.
2008.
[JTV00]
BartCalder, JonCourtney, BillFoote, LindaKyrnitszke, DavidRivas,
ChihiroSaito, JamesVanLoo, TaoYe – The Java TV API Whitepaper. Disponível em:
http://java.sun.com/products/javatv/jtv-1_0-spec_overview.pdf. Acesso em: 25 de abr.
2008.
67
[ABN07]
Associação Brasileira de Normas Técnicas - Televisão digital terrestre Codificação de dados e especificações de transmissão para radiodifusão digital - Parte 2:
Ginga-NCL para receptores fixos e móveis - Linguagem de aplicação XML para
codificação
de
aplicações.
Disponível
em:
http://www.abnt.org.br/imagens/Normalizacao_TV_Digital/ABNTNBR156062_2007Vc_2008.pdf. Acesso em: 15 de maio 2008.
[MHP08]
Digital Video Broadcast Group - Official website for DVB-MHP and
DVB-GEM, Open middleware for Interactive TV. Disponível em: www.mhp.org/.
Acesso em: 05 de outubro de 2008.
[SUN08]
Sun Microsystems – Painting in AWT and SWING. Disponível em:
http://java.sun.com/products/jfc/tsc/articles/painting/#awt. Acesso em: 16 de setembro
de 2008.
[SUF04]
Subgrupo de Trabalho 2 do CAPDA - Comitê das Atividades de Pesquisa
e Desenvolvimento na Amazônia. - TV Digital Interativa. Versão 1.0. Disponível em:
http://www.suframa.gov.br/download/documentos/programa_tv_digital.pdf, Acesso em
: 28 de outubro de 2008.
[DIN08]
Barbosa, Simone D. J., Soares, Luis F. G. – TV Interativa no Brasil se faz
com ginga, fundamentos, padrões, autoria declarative e usabilidade. Disponível em:
www.ncl.org.br/documentos/JAI2008.pdf. Acesso em: 04 de outubro de 2008.
[HAV01]
HAVi, Inc - Specification of the Home Audio/Video Interoperability
(HAVi) Architecture, Chapter 8 – Level 2 User Interface. Disponível em:
http://www.havi.org/techinfo/docs/Chapter8-HAVi1.1-May15.pdf. Acesso em: 25 de
setembro de 2008.
[BEC06]
Becker, Valdecir; Fornari, Augusto; Filho, Günter H. Herweg; Montez,
Carlos - Recomendações de Usabilidade para TV Digital Interativa. Disponível em:
http://www.itvproducoesinterativas.com.br/pdfs/A-usabilidade_final-sbrc.pdf. Acesso
em: 08 de setembro de 2008.
[HDO01]
HAVi,
Inc
–
The
HAVi
Javadoc.
Disponível
em:
http://www.havi.org/techinfo/docs/JavadocL2V1.1.zip. Acesso em: 19 de abril de 2008.
[DOU03]
Diário Oficial da união. Decreto 4.901, de 26 de novembro de 2003.
Disponivel
em:
http://itvproducoesinterativas.com.br/pdfs/legislacao/decreto_4901_2003.pdf. Acesso
em: 02 de novembro de 2008.
[BBC08]
British Broadcasting Corporation - BBCi Style Guide. Disponível em:
www.bbc.co.uk/commissioning/bbci/pdf/styleguide2_1.pdf Acesso em: 11 de outubro
de 2008.
68
[POZ06]
Pozzo, Douglas Dal – Aplicativos para televisão digital interativa.
Disponível
em:
http://www.enapet.ufsc.br/anais/APLICATIVOS_PARA_TELEVISAO_DIGITAL_IN
TERATIVA.pdf. Acesso em: 15 de julho de 2008.
[EDW03]
Edward M. Schwalb (2003) - “iTV Handbook: Technologies and
Standards”, Prentice Hall PTR, Julho de 2003.
[PIC06]
Piccolo, Lara S. Godoy; Baranauskas, Maria Cecília C - Desafios de
Design
para
a
TV
Digital
Interativa.
Disponível
em:
http://portal.acm.org/citation.cfm?id=1298023.1298025&coll=GUIDE&dl=&CFID=42
75513&CFTOKEN=23447516. Acesso em: 14 de outubro de 2008.
[SOA06]
Soares, Luiz F. G.; Rodrigues, Rogério F.; Barbosa, Simone D. - Manual
de Construção de Programas Audiovisuais Interativos Utilizando a NCL 2.3 – Perfil
Básico. 1ª Edição. Disponível em: www.ncl.org.br/documentos/manualNCL2_3.pdf.
Acesso em: 17 de julho de 2008.
[JCP06]
Java Community Process - JSR 217: Personal Basis Profile 1.1 Javadoc.
Disponível em:http://java.sun.com/javame/reference/apis/jsr217/. Acesso em: 12 de
abril de 2008.
[LUA08]
The programming language LUA website. Diponível
http://www.lua.org/portugues.html. Acesso em: 23 de outubro de 2008.
em:
Grupo de Tecnologia em Computação Gráfica - Tecgraf website. Disponível
[TEL08]
em: http://www.tecgraf.puc-rio.br/. Acesso em: 19 de setembro de 2008.
[CEL08]
Celes, Waldemar; Figueiredo, Luiz H. de; Ierusalimschy, Roberto - A
Linguagem Lua e suas Aplicações em Jogos. Disponível em: http://www.tecgraf.pucrio.br/~lhf/ftp/doc/wjogos04.pdf. Acesso em 09 de novembro de 2008.
[SWP08]
Rodrigues, Rafael Ferreira – How to, Ginga-NCL com Java, Xlets como
objetos
de
mídia.
Disponível
em:
http://www.softwarepublico.gov.br/dotlrn/clubs/ginga/gingancl/xowiki/gingancl_java.
Acesso em: 02 de novembro de 2008.
[MON05]
MONTEZ, Carlos; BECKER, Valdecir. TV Digital Interativa: conceitos,
desafios e perspectivas para o Brasil. Florianópolis: Ed. da UFSC, 2005. 2ª edição.
[XLE08]
XleTView website. Disponível em: http://www.xletview.org/. Acesso
em: 25 de abril de 2008.
[ASS08]
Assis, Thiago Rocha de – Desenvolvendo aplicações para TV Digital e
Interativa
usando
Java.
Disponível
em:
http://www.youlabs.com.br/resources/tutorials/YouLabs-TVDigital-Desenvolvendo.pdf
Acesso em: 15 de abril de 2008.
[NIE08]
Nielsen, Jacob – Usability 101: Introduction to usability. Disponivel em:
http://www.useit.com/alertbox/20030825.html. Acesso em: 14 de setembro de 2008.
69
[NIE97]
Nielsen, J. (1997) WebTV Usability Review. Alertbox. Disponível em:
http://www.useit.com/alertbox/9702b.html . Acesso em 05 de novembro de 2008.
[KNU05]
Knudsen, Jonathank; Li, Sing - Beginning J2ME From novice to
Professional. 3ª Ed. 2ª Pg. , 2005, Editora Apress.
[SUN08a]
Sun
Microsystems
Java
website.
http://java.sun.com/java. Acesso em: 01 de novembro de 2008.
Disponível
em:
[SUN08b]
Sun Microsystems - Java Micro Edition website. Disponível em:
http://java.sun.com/javame/index.jsp. Acesso em: 03 de novembro de 2008.
[ATS08]
Advanced Television Systems Comitee - Atsc website. Disponível em:
http://www.atsc.org/. Acesso em 16 de novembro de 2008.
[DIB08]
Digital Broadcasting Experts Group - Isdb website. Disponível em:
http://www.dibeg.org/. Acesso em 16 de novembro de 2008.
[PUC08]
Pontífica Universidade Católica do Rio de Janeiro – Telemídia website.
Disponível em: http://www.telemidia.puc-rio.br/pt/index.html. Acesso em: 17 de junho
de 2008.
[UFP08]
Universidade Federal da Paraíba – LAVID website. Disponível em:
http://www.lavid.ufpb.br/. Acesso em 17 de junho de 2008.
[DVB07a]
Digital Video Broadcast Group – Multimedia Home Platform (MHP)
Specification 1.2. Disponível em: http://www.mhp.org/specs/a107_mhp_12.zip. Acesso
em: 15 de abril de 2008.
[NET08]
Netbeans
org.
–
Netbeans
website.
http://www.netbeans.org. Acesso em 12 de novembro de 2008.
Disponível
em:
[ARI99]
Association of Radio Industiries and Bisinesses (ARIB) - Overview of BXML/BML draft specification developed by ARIB. Disponível em:
http://lists.w3.org/Archives/Public/www-tv/1999OctDec/att-0031/01-BML-BXMLAbst2.htm. Acesso em 29 de novembro de 2008.
[KRU06]
Krug, Steve - Don’t make me think! - ISBN:8576081180 - 2º edição Alta Books – 2006.