Aplicações para TV baseadas em templates

Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Victor Manuel Da Cunha Aplicac¸ ˜ oes para TV baseadas em Templates December 2019 Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Victor Manuel Da Cunha Aplicac¸ ˜ oes para TV baseadas em Templates Master dissertation Master Degree in Computer Science Dissertation supervised by Ant´ onio Nestor Ribeiro December 2019 DIREITOS DE AUTOR E CONDIC¸ ˜ OES DE UTILIZAC¸ ˜ A O D O TRABALHO POR TERCEIROS Este ´ e um trabalho acad ´ emico que pode ser utilizado por terceiros desde que respeitadas as regras e boas pr ´ aticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licenc¸a abaixo indicada. Caso o utilizador necessite de permiss˜ ao para poder fazer um uso do trabalho em condi c¸ ˜ oes n ˜ ao previstas no licenciamento indicado, dever ´ a contactar o autor, atrav´ es do Reposit´ oriUM da Universidade do Minho. Licenc¸a concedida aos utilizadores deste trabalho Atribuic¸˜ ao-N˜ aoComercial CC BY-NC https://creativecommons.org/licenses/by-nc/4.0/ i AGRADECIMENTOS Gostaria de agradecer ` as pessoas que me ajudaram na Altice Labs de Aveiro, sendo de salientar os supervisores da empresa, Bernardo Cardoso e Hugo Dias, e o Arthur Neves que me ajudou a compreender os templates a implementar. Tamb ´ em quero agradecer ao meu orientador, o professor Ant ´ onio Nestor Ribeiro pela sua ajuda durante todo este processo. Finalmente agradec¸o ` a minha fam´ ılia por todo o suporte que me deram. ii DECLARAC¸ ˜ AO DE INTEGRIDADE Declaro ter atuado com integridade na elabora c¸˜ ao do presente trabalho acad ´ emico e confirmo que n ˜ ao recorri ` a pr ´ atica de pl ´ agio nem a qualquer forma de utiliza c¸˜ ao indevida ou falsifica c¸˜ ao de informa c¸ ˜ oes ou resultados em nenhuma das etapas conducente ` a sua elabora c¸˜ ao. Mais declaro que conhe c¸ o e que respeitei o C ´ odigo de Conduta ´ Etica da Universidade do Minho. iii RESUMO A empresa Altice Labs est ´ a a desenvolver uma nova plataforma Internet Protocol television (IPTV) para vir substituir aquela que hoje possui, sendo esta assente em tecnologias standards e normas abertas permitindo uma maior evolu c¸˜ ao e resili ˆ encia. Para verificar se esta ´ e capaz de incorporar servi c¸ os usados em produ c¸˜ ao, a empresa decidiu implementar um desses servi c¸ os na nova plataforma. O servi c¸ o escolhido foi um servi c¸ obackoffice, designado por Landing Pages (LP) que permite a cria c¸˜ ao de aplica c¸ ˜ oes baseadas em configura c¸˜ ao de templates pr ´ e-definidos. As aplica c¸ ˜ oes s ˜ ao apresentadas atrav ´ es de um interpretador presente no cliente, como nas suas set-top boxes. Esta disserta c¸˜ ao de mestrado tem como objetivo a implementa c¸˜ ao deste interpretador das aplica c¸ ˜ oes Landing Pages (LP) na nova plataforma, e tamb ´ em verificar se esta ´ e capaz de suportar os servi c¸ os que s ˜ ao atualmente disponibilizados. A implementa c¸˜ ao foi feita em JavaScript tendo sido usado o Google Chrome como web browser e a plataforma NW.js (node-webkit) como ambientes de testes, visto que a especificac¸˜ ao da set-top box, onde a plataforma dever´ a correr, ainda ´ e desconhecida. Uma an ´ alise do servi c¸ o e dos seus templates levou ` a divis ˜ ao desses em grupos. Cada grupo foi depois implementado sequencialmente num processo iterativo e incremental. A implementa c¸˜ ao revelou que a plataforma ´ e capaz de incorporar as funcionalidades pretendidas mas apresenta falhas que devem ser corrigidas. Nesta disserta c¸˜ ao apresenta-se o processo seguido para recriar todos os templates na nova plataforma e correspondente an ´ alise das suas funcionalidades na nova plataforma. Este processo forneceu indica c¸ ˜ oes sobre a forma como o interpretador e a plataforma dever ˜ ao evoluir para permitir a implementa c¸˜ ao dos servic¸os que a Altice Labs pretende ver disponibilizados. Palavras-Chave: plataforma Internet Protocol television (IPTV), desenvolvimento de aplicac¸ ˜ oes, templates. iv ABSTRACT Altice Labs is developing a new Internet Protocol television (IPTV) platform to replace the one it currently possesses, being based on standard technologies and open standards allowing for greater evolution and resilience. To check if it is capable of incorporating services used in production, the company decided to implement one of these services on the new platform. The chosen service was a back office service, designated by Landing Pages (LP) that allow the creation of applications based on predefined templates. Applications are then presented through an interpreter present on the client, as in their set-top boxes. This master’s dissertation aims to implement this interpreter of LP applications on the new platform, and also check if it is able to support the services that are currently available. The implementation was made in JavaScript using Google Chrome as a web browser and the NW.js platform (node-webkit) as tests environments, since the specification of the set-top box, where the platform should run, is still unknown. An analysis of the service and its templates led to their division into groups. Each group was then implemented sequentially in an iterative and incremental process. The implementation revealed that the platform is capable of incorporating the intended features but it has flaws that must be corrected. This dissertation presents the process followed to recreate all templates on the new platform and corresponding analysis of its features on the new platform. This process provides pointers on how the interpreter and platform should evolve to enable deployment of the services that the company Altice Labs intends to make available. Keywords: IPTV platform, applications, templates. v CONTENTS 1 introduc¸˜ ao 1 1.1Contexto 2 1.2Problema 3 1.3Desafios 3 1.4Objetivos 3 1.5Estrutura da dissertac¸˜ ao 4 2 estado da arte 6 2.1Uma vis˜ ao global sobre IPTV 6 2.2Soluc¸ ˜ oes IPTV 7 2.2.1Soluc¸˜ ao IPTV do Open IPTV Forum 8 2.2.2Nagra OpenTV 11 2.2.3MediaKind Mediaroom 14 2.3Desenvolvimento de aplicac¸ ˜ oes para televis˜ ao 16 2.3.1Desenvolvimento de User Interface (UI) para a Samsung 16 2.4Sum´ ario 18 3 an ´ alise e abordagem da plataforma landing pages 19 3.1Plataforma Landing Pages 19 3.1.1Arquitetura Plataforma Landing Pages 20 3.1.2Aplicac¸˜ ao Landing Pages 21 3.2Grupos de templates da plataforma Landing Pages 23 3.2.1Grupo 123 3.2.2Grupo 224 3.2.3Grupo 325 3.2.4Grupo 426 3.2.5Grupo 528 3.2.6Grupo 629 3.2.7S´ ıntese 31 3.3Plataforma de desenvolvimento 33 3.3.1Criac¸˜ ao de User Interface 33 3.3.2Navegac¸˜ ao entre screens 34 3.4Criac¸˜ ao do interpretador 34 3.5Sum´ ario 35 4 desenvolvimento 36 vi contents vii 4.1Problemas e Decis˜ oes 36 4.1.1Motor de animac¸˜ ao 37 4.1.2Motor de Escala 37 4.1.3Gest˜ ao dos elementos visuais 38 4.1.4Alterac¸ ˜ oes devido a atualizac¸˜ oes 38 4.1.5Falta de documentac¸˜ ao 38 4.1.6Navegac¸˜ ao entre screens 39 4.1.7Sum´ ario 39 4.2Implementac¸˜ ao 39 4.2.1Arquitetura do m´ odulo 40 4.2.2Comunicac¸˜ ao com a API 42 4.2.3Navegac¸˜ ao no router 43 4.2.4Screens e Views 43 4.2.5Navegac¸˜ ao nas screens 52 4.3Sum´ ario 52 5 casos de estudo e resultados 54 5.1Ambiente de execuc¸˜ ao 54 5.2Casos de estudo 54 5.2.1Primeira Aplicac¸˜ ao 55 5.2.2Segunda Aplicac¸˜ ao 59 5.3Discuss˜ ao dos resultados obtidos 62 5.3.1Divergˆ encias nas animac¸ ˜ oes 62 5.3.2Funcionalidades n˜ ao implementadas 63 5.4Sum´ ario 64 6 conclus ˜ ao e trabalho futuro 65 6.1Conclus˜ ao 65 6.2Trabalho futuro 66 a configurac¸˜ ao p ´ agina inicial da aplicac¸˜ ao 1 71 b configurac¸˜ ao p ´ agina inicial da aplicac¸˜ ao 2 73 VOD Video On Demand. X XML eXtensible Markup Language. 1 INTRODUC¸ ˜ A O Atelevis ˜ ao (TV) transformou-se nos ´ ultimos 20 anos numa plataforma interativa, onde o utilizador pode interagir com a TV de maneira a obter informa c¸ ˜ oes ou personalizar a sua experi ˆ encia, designando-se como Televis ˜ ao Interativa (iTV). Esta transforma c¸˜ ao ´ e mais aparente com o aparecimento de aplica c¸ ˜ oes dita interativas, como o Electronic Program Guide (EPG) eDigital Video Recording (DVR), que s ˜ ao usadas quotidianamente. Nesta evolu c¸˜ ao a TV tamb ´ em ganhou acesso ` a internet e a novas aplica c¸ ˜ oes que tiveram de ser redesenhadas de maneira a funcionar neste ambiente com inputs restritos. A integra c¸˜ ao da internet com a televis ˜ ao, permitiu a distribui c¸˜ ao de programas de televis ˜ ao atrav ´ es de redes Internet Protocol (IP), designado por Internet Protocol television (IPTV), o que permitiu a cria c¸˜ ao de novos servi c¸ os como network Time Shifting (nTS), que permite a um utilizador ver programas de televis˜ ao atrasados relativamente a sua programac¸˜ ao normal. Com esta evolu c¸˜ ao e com o aparecimento de dispositivos m ´ oveis, cada vez mais usados, os operadores de TV tiveram de mudar as suas ofertas para manter e atrair clientes, passando de transmissor de canais de televis ˜ ao para fornecedores de diversos servi c¸ os, como Video On Demand (VOD),streaming, grava c¸ ˜ oes na cloud,nTS, subscri c¸ ˜ oes e aplica c¸ ˜ oes interativas. Estes servi c¸ os s ˜ ao acess ´ ıveis a partir da TV atrav ´ es de aplica c¸ ˜ oes interativas, sendo essas geralmente acess ´ ıveis unicamente a partir da Set Top Box (STB) fornecida pelo operador. AAutoridade Nacional de Comunica c¸˜ oes (ANACOM) define a STB como ”um equipamento descodificador que se liga ao televisor e a uma fonte externa de sinal (cabo ethernet, cabo coaxial, linha telef ˆ onica ou antena tradicional) e transforma esse sinal de forma a que a emiss ˜ ao possa ser vista no televisor” [ 2 ]. Para al ´ em disto, estas tamb ´ em fornecem servi c¸ os como DVR e permitem aceder a uma gama de aplica c¸ ˜ oes interativas, disponibilizadas pelo operador. As principais funcionalidades duma STB s˜ ao [17]: •descodificar o sinal de entrada; •verificar os direitos de acesso e os n´ ıveis de seguranc¸a; •apresentar o conte´ udo na TV; •processar e apresentar servic¸os iTV e da Internet. 1 1.1. Contexto 2 ASTB ´ e, assim, um mini-computador, geralmente conectado ` a internet, que adiciona capacidades ao dispositivo a que est´ a ligado. As aplica c¸ ˜ oes interativas devem correr em diferentes STB, com diferente hardware esoftware, e possivelmente outros dispositivos como televis ˜ oes inteligentes. De maneira a facilitar a cria c¸˜ ao e o porte de aplica c¸ ˜ oes para diferentes plataformas ´ e estudado uma plataforma de cria c¸˜ ao de aplica c¸ ˜ oes baseadas em templates desenvolvida pela Altice Labs fazendo o porte dessa para uma nova plataforma. 1.1 contexto A Altice Labs, e mais precisamente a sua dire c¸˜ ao Digital, Internet e Televis ˜ ao (DIT), ´ e respons ´ avel pela conce c¸˜ ao, desenvolvimento e teste de aplica c¸ ˜ oes e plataformas para TV, web e dispositivos m ´ oveis, que s ˜ ao usadas dentro e fora do grupo Altice, tendo como exemplo as aplica c¸ ˜ oes interativas do servi c¸ o MEO IPTV e tamb ´ em as aplica c¸ ˜ oes MEO Go e MEO Remote. Dentro desta dire c¸˜ ao, o grupo da Televis ˜ ao Interativa (iTV) est ´ a focado na manuten c¸˜ ao da plataforma MEO IPTV, na cria c¸˜ ao de novas funcionalidades e no estudo de plataformas alternativas. Hoje em dia, o servi c¸ o de televis ˜ ao MEO IPTV est ´ a assente na plataforma propriedade da MediaKind 1 , chamada Mediaroom, para distribui c¸˜ ao do seu servi c¸ o, sendo o seu cliente instalado em mais de 40 milh ˜ oes de STB em todo o mundo [ 6 ]. Esta plataforma, por ser propriedade de outros, tem uma arquitetura definida e limita c¸ ˜ oes pr ´ oprias, que a Altice Labs n ˜ ao pode modificar. O grupo iTV da Altice Labs, durante v ´ arios anos, estudou a plataforma, usou-a e explorou-a at ´ e os seus limites, personalizando quase todas as funcionalidades base, mas, sendo uma plataforma fechada, ´ e cada vez mais dif ´ ıcil criar aplica c¸ ˜ oes inovadoras e distintivas, estando-se limitado ao que a plataforma oferece. Assim, o grupo Altice est ´ a a desenvolver uma plataforma que espera poder ser usada em todas as suas opera c¸ ˜ oes, que forneceria as mesmas funcionalidades hoje dispon ´ ıveis, e que seria assente em tecnologias standards e normas abertas que permitam uma maior evolu c¸˜ ao e resili ˆ encia. Esta nova plataforma de desenvolvimento, est ´ a a ser constru ´ ıda usando essencialmente JavaScript, CSS3e HTML5, que s ˜ ao normas da web e tecnologias com anos de uso e uma comunidade ativa, resultando numa evolu c¸˜ ao constante destas. Al ´ em disto, estas tecnologias s ˜ ao hoje usadas em outras plataformas IPTVs como Hybrid broadcast broadband TV (HbbTV), um standard da ind ´ ustria para a normaliza c¸˜ ao da transmiss ˜ ao de TV, servi c¸ os IPTV e acesso a internet para os consumidores atrav´ es de smart TVs eSTB. 1https://www.mediakind.com/pt/ 1.2. Problema 3 1.2 problema A Altice Labs, j ´ a possui uma vers ˜ ao inicial da nova plataforma, que segue uma estrutura modular que permite a adi c¸˜ ao de funcionalidades na forma de m ´ odulos, sendo necess ´ ario test ´ a-la, verificando se esta ´ e capaz de incorporar funcionalidades hoje disponibilizadas e se ´ e compat ´ ıvel com servi c¸ os de backend usados em produ c¸˜ ao. A empresa possui um backoffice designado por Landing Pages (LP) que permite escolher templates de aplica c¸ ˜ oes pr ´ edefinidas, configur ´ a-los e criar uma aplica c¸˜ ao interativa para TV pronta a ser distribu ´ ıda, sem necessidade de programar. As aplica c¸ ˜ oes criadas no backoffice s ˜ ao depois disponibilizadas atrav ´ es de uma Web Application programming interface (API) usado pelo m ´ odulo das LP respons ´ avel por, a partir da configura c¸˜ ao, recriar a UI e a l ´ ogica das aplica c¸ ˜ oes na STB. Assim, ´ e necess ´ ario criar e incorporar um m ´ odulo na nova plataforma que ir ´ a recriar as aplicac¸ ˜ oes LP, atrav´ es das suas configurac¸ ˜ oes. 1.3 desafios A nova plataforma da Altice dever ´ a correr numa STB mas a especifica c¸˜ ao desta ´ e desconhecida, sendo assim dif ´ ıcil testar e avaliar o desempenho real da plataforma e das aplica c¸ ˜ oes recreadas, por isso, ser ´ a usado um web browser e a plataforma NW.js como ambientes de testes. A cria c¸˜ ao e integra c¸˜ ao de um m ´ odulo numa plataforma privada em desenvolvimento e com documenta c¸˜ ao limitada ´ e o maior desafio desta disserta c¸˜ ao, uma vez que este m ´ odulo deve servir como interpretador de aplicac¸ ˜ oes interativas LP e ser escrito em JavaScript. 1.4 objetivos A dissertac¸˜ ao possui dois objetivos, que s˜ ao: • o desenvolvimento de um interpretador para as aplica c¸ ˜ oes LP incorporado na nova plataforma da Altice, na forma de um m ´ odulo da plataforma e desenvolvido usando JavaScript; • a avalia c¸˜ ao da capacidade da plataforma para incorporar servi c¸ os da empresa usados em produc¸˜ ao. O primeiro objetivo pode ser dividido em subobjetivos que refletem o n ´ umero de templates que dever ˜ ao ser interpretados. Antes de os listar, ´ e necess ´ ario definir o que ´ e um template e uma aplica c¸˜ ao LP, assim como os grupos de templates que ser ˜ ao implementados. Um template ´ e aqui definido como um plano constru ´ ıdo, onde s ˜ ao especificados os componentes visuais, as suas posi c¸ ˜ oes, a c¸ ˜ oes que podem realizar e fontes de dados usados por estes. Cada template possui um conjunto de componentes predefinidos, sendo agrupados segundo os 1.5. Estrutura da dissertac¸˜ ao 4 seus usos e as rela c¸ ˜ oes entre eles. Uma aplica c¸˜ ao LP ´ e uma aplica c¸˜ ao interativa constru ´ ıda usando um conjunto de templates relacionados, usados em conjunto para a apresenta c¸˜ ao de conte ´ udo. A aplica c¸˜ ao ´ e composta por uma p ´ agina de entrada, designada por home page, e um conjunto de outros templates relacionados com essa. Cada template oferece uma gama de configura c¸˜ ao e comportamento diferente. A partir da home page s ˜ ao definidos liga c¸ ˜ oes para outros templates usados na aplica c¸˜ ao. Atualmente existem dez templates diferentes na plataforma, agrupados em seis grupos, sendo os crit ´ erios de agrupamento a l ´ ogica presente e como podem ser usados na constru c¸˜ ao de uma aplica c¸˜ ao LP, isto ´ e, excluindo um grupo que contem templates que podem ser usados em mais do que um grupo, cada grupo permite a criac¸˜ ao de uma aplicac¸˜ ao LP. Os grupos s˜ ao apresentados na secc¸˜ ao 3.2. Assim, os subobjetivos s˜ ao: • O interpretador deve permitir a visualiza c¸˜ ao e o uso das aplica c¸ ˜ oes criadas usando os templates do grupo 1; • O interpretador deve permitir a visualiza c¸˜ ao e o uso das aplica c¸ ˜ oes criadas usando os templates do grupo 2; • O interpretador deve permitir a visualiza c¸˜ ao e o uso das aplica c¸ ˜ oes criadas usando os templates do grupo 3; • O interpretador deve permitir a visualiza c¸˜ ao e o uso das aplica c¸ ˜ oes criadas usando os templates do grupo 4; • O interpretador deve permitir a visualiza c¸˜ ao e o uso das aplica c¸ ˜ oes criadas usando os templates do grupo 5; • O interpretador deve permitir a visualiza c¸˜ ao e o uso das aplica c¸ ˜ oes criadas usando os templates do grupo 6. Uma apresenta c¸˜ ao mais detalhada de cada grupo de templates da plataforma LP ser ´ a feito mais adiante nesta disserta c¸˜ ao. Al ´ em disto, ser ´ a feito um estudo da plataforma LP e da sua Web API, de maneira a perceber quais os seus objetivos, a sua arquitetura, os diferentes templates e o formato das configurac¸ ˜ oes guardadas. 1.5 estrutura da dissertac¸˜ ao A dissertac¸˜ ao ´ e dividida em seis cap´ ıtulos. O primeiro apresenta o contexto, problema, desafios e objetivos da dissertac¸˜ ao. O segundo cap ´ ıtulo, Estado da arte foca-se nas tecnologias IPTV em uso, e apresenta uma defini c¸˜ ao para IPTV. S ˜ ao apresentadas nesse cap ´ ıtulo tr ˆ es solu c¸ ˜ oes IPTV que s ˜ ao o Open IPTV Forum IPTV Solution, o Nagra OpenTV e a plataforma MediaKind Mediaroom. Para al ´ em 1.5. Estrutura da dissertac¸˜ ao 5 disso, ´ e apresentado o m ´ etodo de desenvolvimento de aplica c¸ ˜ oes para televis ˜ ao aconselhado pela Samsung. O terceiro cap ´ ıtulo, faz a an ´ alise da plataforma LP e descreve a sua arquitetura e os seus templates para aplica c¸ ˜ oes. Nesse cap ´ ıtulo, tamb ´ em ´ e feito a an ´ alise da plataforma de desenvolvimento, explicando como s ˜ ao criadas aplica c¸ ˜ oes, sendo sugeridos passos para o desenvolvimento do interpretador a partir dessa an´ alise. O quarto cap ´ ıtulo, descreve como o desenvolvimento do interpretador foi feito. O cap ´ ıtulo ´ e dividido em duas partes. Na primeira parte ´ e feito a an ´ alise dos problemas encontrados e as decis ˜ oes tomadas para os resolver, enquanto na segunda parte foca-se a implementa c¸˜ ao realizada com a apresentac¸˜ ao da arquitetura do interpretador criado. O quinto cap ´ ıtulo, apresenta duas aplica c¸ ˜ oes (simples e complexa) que foram criadas e reproduzidas na nova plataforma, com a an ´ alise dos resultados obtidos comparando o aspeto e as funcionalidades das aplica c¸ ˜ oes na nova plataforma e na plataforma hoje em uso. No sexto cap ´ ıtulo, conclui-se a disserta c¸˜ ao apresentando as conclus ˜ oes tiradas do trabalho efetuado e os trabalhos futuros que dever ˜ ao ser efetuados quer no m ´ odulo criado quer na plataforma. 2 ESTADO DA ARTE Neste cap´ ıtulo ´ e apresentado uma vis˜ ao global sobre IPTV, onde ´ e explicado o que ´ eIPTV, os seus desafios e ´ e apresentado uma defini c¸˜ ao para IPTV. Depois, ´ e definido o que constitui uma solu c¸˜ ao IPTV, explicando os dom ´ ınios que engloba e, por consequ ˆ encia, os problemas que deve resolver. O cap ´ ıtulo foca-se em solu c¸ ˜ oes IPTVs em utiliza c¸˜ ao, os servi c¸ os que prop ˜ oem, a sua organiza c¸˜ ao e como as aplica c¸ ˜ oes interativas s ˜ ao criadas e distribu ´ ıdas, sendo depois analisado o desenvolvimento de aplicac¸ ˜ oes neste dom´ ınio. 2.1 uma vis ˜ ao global sobre iptv OIPTV ´ e uma forma de televis ˜ ao digital, ou Digital Television (DTV), onde, contrariamente ` a televis ˜ ao tradicional anal ´ ogica, a transmiss ˜ ao e recep c¸˜ ao de imagem e som ´ e feita atrav ´ es de sinais digitais, sinais codificados de forma bin ´ aria. Isto permitiu aumentar o n ´ umero de canais, a qualidade de recep c¸˜ ao e a resolu c¸˜ ao desses, para al ´ em de possibilitar o uso de um canal de comunica c¸˜ ao bidirecional entre o utilizador e o operador, possibilitando a cria c¸˜ ao de aplicac¸ ˜ oes interativas, teletexto, EPG, a transmiss˜ ao de canais de r´ adios, e mais. Em Portugal, a DTV mais conhecida ´ e a Televis ˜ ao digital terrestre (TDT) e usa uma largura de banda de 8MHz, sendo implementada usando a norma Digital Video Broadcasting — Terrestrial (DVB-T). Esta norma define como canais de televis ˜ ao e outros conte ´ udos multim ´ edias s ˜ ao codificados e transmitidos ao cliente. A codifica c¸˜ ao de imagens e ´ audio ´ e feito usando a norma MPEG norma 2(MPEG-2), uma norma de compress ˜ ao definida como uma ”codifica c¸˜ ao gen ´ erica para imagens em movimento e informa c¸˜ ao de ´ audio associado”, para canais Standard definition (SD), sendo substitu ´ ıda pela norma MPEG norma 4(MPEG-4)quando ´ e necess ´ ario um maior n´ ıvel de compress˜ ao, como acontece em canais High Definition (HD) [28]. Sendo uma forma de DTV,IPTV lida com abordagens, tecnologias e protocolos para a distribui c¸˜ ao de conte ´ udo SD eHD, em tempo real e on-demand, atrav ´ es de redes baseadas no protocolo IP.IPTV alcan c¸ a todos os pr ´ e-requisitos de Quality of Service (QoS),Quality of Experience (QoE), e Acesso conditional (CA) (seguran c¸ a). Da mesma maneira, preenche os requisitos para a gest ˜ ao de blackout, que permite limitar o acesso a conte ´ udos de um canal a certos utilizadores, e o Sistema de alerta de emerg ˆ encia (EAS). Tamb ´ em possibilita a 6 2.2. Soluc¸ ˜ oes IPTV 7 implementa c¸˜ ao de servi c¸ os de legenda, controlo parental, recolha de dados para o sistema de medi c¸˜ ao de audi ˆ encia, Second audio program ou Segundo programa de a ´ udio (SAP) para a transmiss ˜ ao e recep c¸˜ ao no cliente de diversos canais de ´ audios, permitindo a transmiss ˜ ao do ´ audio em diversas l ´ ınguas, e picture-in-picture (PiP) [ 19 ]. Para al ´ em disto, IPTV suporta todos os requisitos de neg ´ ocio, como a distribui c¸˜ ao de servi c¸ os, fatura c¸˜ ao, aprovisionamento, e requisitos de prote c¸˜ ao de conte ´ udo com, por exemplo, Sistema de acesso condicional (CAS) ou Digital Right Management (DRM), muitas vezes associados com a distribui c¸˜ ao de conte ´ udos comerciais [ 19 ]. O conte ´ udo transmitido atrav ´ es de IPTV pode ser entregue para qualquer dispositivo compat ´ ıvel com acesso ` a internet, permitindo atingir novos consumidores e disponibilizar mais servi c¸ os. Uma liga c¸˜ ao broadband ´ e usada como meio de transmiss ˜ ao, e a defini c¸˜ ao oficial para IPTV, aprovada pelo International Telecommunication Union focus group on IPTV (ITU FG IPTV),´ e : ” IPTV ´ e definido como sendo servi c¸ os multim ´ edias como televis ˜ ao / ´ audio /texto /graphics /dados transmitidos atrav ´ es duma rede baseada no protocolo IP, para fornecer os n ´ ıveis de QoS eQoE, seguranc¸a, interatividade e confiabilidade” [16]. 2.2 soluc¸˜ oes iptv Uma solu c¸˜ ao IPTV ´ e aqui considerada como uma plataforma desenvolvida por fabricantes de software ou hardware, que pode ser implementada por um fornecedor de servi c¸ o, como empresas de telecomunicac¸ ˜ oes ou de televis˜ ao por cabo, para oferecer servic¸os IPTV. Estas solu c¸ ˜ oes especificam como o conte ´ udo ´ e adquirido, tratado e apresentado ao cliente. Para facilitar a interoperabilidade das solu c¸ ˜ oes, a maioria deles especificam um middleware pr ´ oprio que permite a qualquer dispositivo com este middleware de aceder aos servi c¸ os da plataforma. Uma solu c¸˜ ao IPTV engloba diferentes dom ´ ınios, envolvendo diferentes entidades, apresentados na Figura 1. Estes dom´ ınios s˜ ao definidos como [9]: • o fornecedor de conte ´ udo, que possui ou est ´ a licenciado para vender conte ´ udo ou ativos e fornece os metadados descritivos; • o fornecedor de servi c¸ o, que fornece o servi c¸ oIPTV ao cliente, utilizando conte ´ udo adquirido ou licenciado dos fornecedores de conte´ udo; • o fornecedor de acesso a rede IP, que fornece ao cliente uma conex ˜ ao ao fornecedor de servi c¸ o. O sistema de entrega ´ e geralmente constitu ´ ıdo por uma rede de acesso e n ´ ucleo ou redes de backbone. A rede de entrega ´ e transparente para o tr ´ afego IP, podendo vir a ser relevante para real-time streaming. Esta rede ´ e controlada por um fornecedor de rede; 2.2. Soluc¸ ˜ oes IPTV 8 • aHome, que corresponde ao dom ´ ınio onde os servi c¸ os s ˜ ao consumidos. Neste dom ´ ınio podem existir um ou mais dispositivos IPTV, geralmente uma STB fornecida pelo fornecedor de servic¸o. Figura 1: Modelo em camada que mostra as rela c¸ ˜ oes entre os dominios e camadas do modelo OSI [ETSI TS 102 034][9] A Figura 1apresenta as conectividades existentes entre os dom ´ ınios segundo o modelo Open System Interconnection (OSI). Na figura ´ e poss ´ ıvel verificar que o fornecedor de conte ´ udo comunica com os aparelhos do dom ´ ınio Home ao n ´ ıvel das aplica c¸ ˜ oes e de sess ˜ ao, contudo ao n ´ ıvel f ´ ısico este s ´ o ´ e ligado ao seu fornecedor de acesso. A seguir s ˜ ao apresentadas algumas solu c¸ ˜ oes que os fornecedores de servi c¸ os podem implementar, especificando a sua arquitetura e os servic¸os que oferecem. 2.2.1Soluc¸˜ ao IPTV do Open IPTV Forum OOpen IPTV Forum (OIPF) ´ e um cons ´ orcio e uma organiza c¸˜ ao de normaliza c¸˜ ao cujo objetivo ´ e definir e publicar normas para a arquitetura de solu c¸ ˜ oes IPTV fim-a-fim. Em 2014, oOIPF integrou a associa c¸˜ ao Hybrid broadcast broadband TV (HbbTV). Em janeiro de 2014, oOIPF publicou a vers ˜ ao 2.3da sua solu c¸˜ ao IPTV. Esta solu c¸˜ ao fornece as especifica c¸ ˜ oes para uma plataforma fim-a-fim para a implementa c¸˜ ao de servi c¸ os IPTV, e permite a qualquer dispositivo, conforme com a especifica c¸˜ ao OIPF, aceder a servi c¸ os enriquecidos e personalizados seja numa rede controlada pelo fornecedor de servi c¸ o ou n ˜ ao. A Figura 2 mostra uma abstra c¸˜ ao da estrutura da solu c¸˜ ao, em termo de redes e entidades funcionais na rede residencial. Numa rede residencial podem estar um ou mais Open IPTV Terminal 2.2. Soluc¸ ˜ oes IPTV 9 Function (OITF) conetados a um ou mais gateways. Estes gateways n ˜ ao t ˆ em de ser dispositivos separados do OITF podendo todos residir neste, como ´ e o caso numa STB ou TV. A rede de acesso, access network, pode ser ou n ˜ ao gerido pelo fornecedor de servi c¸ o, mas quando acontece este pode usar mecanismos da rede para melhorar a qualidade dos seus servi c¸ os, como a diferencia c¸˜ ao do tr ´ afego para priorizar tr ´ afego IPTV, melhorando a qualidade do servi c¸ o e a experi ˆ encia do utilizador, ou multicast IP para diminuir a largura de banda usada na distribui c¸˜ ao de servi c¸ os TV ao vivo. Acess ´ ıvel a partir da rede de acesso, a plataforma de servi c¸ o, Service Platform, ´ e respons ´ avel pela autentica c¸˜ ao e gest ˜ ao de sess ˜ ao do OITF, e a gest ˜ ao dos servi c¸ os IPTV fornecidos. A plataforma oferece a possibilidade ao OITF de escolher fornecedores de servi c¸ os diferentes em fun c¸˜ ao dos servi c¸ os pretendidos, sendo a escolha feita usando o IPTV Service Provider Discovery, que devolve informa c¸˜ ao sobre os fornecedores dispon´ ıveis. Figura 2:ˆ Ambito da soluc¸˜ ao OIPF IPTV [11] A soluc¸˜ ao suporta os seguintes servic¸os[11]: •Televis˜ ao ao vivo; •gravac¸˜ ao de televis˜ ao em direto ou DVR; •EPG; •servic¸os h´ ıbridos, com a combinac¸˜ ao de canais de transmiss˜ aoeIPTV no OITF; •servic¸os de VOD; 2.3. Desenvolvimento de aplicac¸ ˜ oes para televis˜ ao 16 (PF) Applications [ 3 ]. No dom ´ ınio IPTV Content Distribuition ´ e feito a distribui c¸˜ ao dos conte ´ udos e servi c¸ os da plataforma, sendo usados servidores VOD e de TV ao vivo pr ´ oximos dos clientes para diminuir a lat ˆ encia. No dom ´ ınio Content Consumption os utilizadores usam uma STB instalada com o cliente Mediaroom para acederem a plataforma. O cliente Mediaroom comunica com a plataforma autenticando-se l ´ a, e serve de middleware para as aplicac¸ ˜ oes Presentation Framework (PF). 2.3 desenvolvimento de aplicac¸˜ oes para televis˜ ao O desenvolvimento de aplica c¸ ˜ oes para Smart TVssegue, geralmente, quatros etapas, aconselhadas pela Samsung[8] e especificadas por Arthur Varushyla[4], que s˜ ao : •Planificac¸˜ ao da aplicac¸˜ ao e da sua UI; •Implementac¸˜ ao da aplicac¸˜ ao; •Depurac¸˜ ao e teste da aplicac¸˜ ao; •Submiss˜ ao e publicac¸˜ ao. Todas essas etapas s ˜ ao comuns no desenvolvimento de software mas ´ e aqui dado uma grande import ˆ ancia a planifica c¸˜ ao da UI da aplica c¸˜ ao, pois existem requisitos de usabilidades diferentes daqueles presentes nos computadores que devem ser tomados em considera c¸ ˜ oes [5]. 2.3.1Desenvolvimento de UI para a Samsung ASamsung aconselha fazer a planifica c¸˜ ao tendo em considera c¸ ˜ oes quatro pontos[ 27 ] que s ˜ ao: •princ´ ıpios de design; • a maneira como se interage com a aplica c¸˜ ao, geralmente efetuado atrav ´ es do comando ( mas pode incluir outros m´ etodos, como o telem´ ovel ); • a sua apar ˆ encia em ecr ˜ as de diversos tamanhos e resolu c¸ ˜ oes, uma vez que as televis ˜ oes variam muito quanto ao seu tamanho e resolu c¸˜ ao devendo ser assegurada a apar ˆ encia e usabilidade da aplicac¸˜ ao nessas; • as especifica c¸ ˜ oes obrigat ´ orias definidas pela plataforma de distribui c¸˜ ao. A televis ˜ ao ´ e uma plataforma fragmentada [ 1 ] sendo que cada distribuidora especifica requisitos que as aplicac¸ ˜ oes devem cumprir. 2.3. Desenvolvimento de aplicac¸ ˜ oes para televis˜ ao 17 Os princ ´ ıpios de design englobam todos as regras e considera c¸ ˜ oes que devem ser tomadas durante o design da aplica c¸˜ ao. A Samsung divide esses pontos em tr ˆ es categorias que s ˜ ao as caracter ´ ısticas do ambiente de utiliza c¸˜ ao, princ ´ ıpios de design da aplica c¸˜ ao e regras para fornecer uma melhor experiˆ encia ao utilizador. O primeiro ponto especifica as caracter ´ ısticas pr ´ oprias ao uso da televis ˜ ao, um ambiente descontra ´ ıdo, efetuado a uma grande distancia, aproximadamente tr ˆ es metros mas varia enormemente [ 26 ], com um controlo reduzido atrav ´ es do comando e podendo ser utilizado por v´ arias pessoas. O segundo ponto especifica regras, ou boas pr ´ aticas, que devem ser seguidas pela aplica c¸˜ ao e suas interfaces sendo divididas em categorias que s˜ ao: • Simplicidade, aconselhando um aspeto simples e pr ´ atico que facilita a descoberta de conte´ udo, limitando o n´ umero de transic¸ ˜ oes e navegac¸ ˜ oes, com um uso intuitivo; • Clareza, a navega c¸˜ ao devendo ser simples, sem efeitos complexos e como esperado pelo utilizador, indicando inequivocamente a localizac¸ ˜ ao do utilizador na aplicac¸˜ ao; • Controlo pelo Utilizador, a aplica c¸˜ ao deve ter em considera c¸˜ ao o dispositivo de controlo usado pelo utilizador apresentando uma apar ˆ encia adequada, para al ´ em disso as a c¸ ˜ oes tomadas pela aplica c¸˜ ao devem corresponder ao esperado pelo utilizador, n ˜ ao devendo a aplicac¸˜ ao impor as suas regras de navegac¸˜ ao; • Consist ˆ encia, de maneira a facilitar o uso da aplica c¸˜ ao esta n ˜ ao se deve desviar das normas pr ´ e-estabelecidas na plataforma de uso. Al ´ em disso, a aplica c¸˜ ao deve manter-se consistente no seu todo de maneira a n ˜ ao confundir o utilizador. A Samsung especifica tr ˆ es tipos de consist ˆ encia que s ˜ ao a consist ˆ encia de controlo, do layout do ecr ˜ a e de navegac¸˜ ao; • Resposta, ´ e aconselhado que cada a c¸˜ ao efetuada pelo utilizador provoque uma resposta por parte da aplica c¸˜ ao, seja com uma mensagem de erro, seja com uma altera c¸˜ ao no aspeto visual dessa. Essas respostas n ˜ ao devem confundir o utilizador, devendo ajud ´ alo a compreender o que pode ou n ˜ ao fazer. Da mesma maneira, opera c¸ ˜ oes demoradas devem providenciar uma anima c¸˜ ao para confirmar que o ecr ˜ a ir ´ a mudar como pedido pelo utilizador; • Considera c¸ ˜ oes est ´ eticas, aplica c¸ ˜ oes para televis ˜ oes devem ter em aten c¸˜ ao as cores usadas, as resoluc¸ ˜ oes e as composic¸ ˜ oes dos ecr˜ as que s˜ ao diferentes, por exemplo, de computadores e telem ´ oveis. Televis ˜ oes t ˆ em diferentes resolu c¸ ˜ oes e, mesmo para a mesma resolu c¸˜ ao, o tamanho e tecnologia do ecr ˜ a varia muito. A Samsung recomenda criar a aplica c¸˜ ao para uma resolu c¸˜ ao fixa de 1080p, com o redimensionamento gerido pela framework. Para texto recomenda-se um tamanho de fonte m ´ ınimo de vinte pixeis, com fontes e cores leg´ ıveis em quaisquer ecr˜ as e a uma boa distˆ ancia. 2.4. Sum´ ario 18 No ´ ultimo ponto a Samsung especifica todos os requisitos obrigat ´ orios e aconselhados que as aplica c¸ ˜ oes devem possuir para poderem ser distribu ´ ıdas na sua plataforma. Esses requisitos especificam, por exemplo, a resolu c¸˜ ao m ´ ınima das imagens usadas, o comportamento da aplica c¸˜ ao face a inputs, como o player se deve comportar na aplica c¸˜ ao e, tamb ´ em, as respostas que esta deve fornecer ao utilizador. 2.4 sum ´ ario Como foi abordado existem diferentes plataformas IPTV e fornecedores de servi c¸ os IPTV. Essas plataformas dividem internamente o seu dom ´ ınio em quatro partes [ 9 ] que s ˜ ao os fornecedores de conte ´ udos, os fornecedores de servi c¸ os, a rede de acesso e o utilizador. As plataformas definem como interagem com os dom ´ ınios e o que fornecem para ter uma solu c¸˜ ao completa. Mesmo sendo diferentes, todas as plataformas suportam os seguintes servic¸os: •televis˜ ao ao vivo; •DVR; •EPG; •VOD; •servic¸os de notificac¸ ˜ oes. As aplica c¸ ˜ oes interativas usadas nessas plataformas s ˜ ao criadas usando diferente linguagens, por exemplo, aplica c¸ ˜ oes para a plataforma Mediaroom usam C# [ 18 ] enquanto que ´ e usado uma framework Javascript eHTML5na plataforma Nagra OpenTV[ 24 ][ 23 ]. O desenvolvimento de aplica c¸ ˜ oes para televis ˜ oes ou outras solu c¸ ˜ oes IPTV segue quatro etapas que s ˜ ao a planifica c¸˜ ao, implementa c¸˜ ao, teste e depura c¸˜ ao, e submiss ˜ ao e publica c¸˜ ao da aplica c¸˜ ao. Dentro de cada etapa ´ e dada muito import ˆ ancia ` a planifica c¸˜ ao, mais especificamente a planifica c¸˜ ao da UI devido ao contexto de utiliza c¸˜ ao. Assim, a Samsung aconselha fazer a planificac¸˜ ao tendo em conta quatro pontos[27]: •princ´ ıpios de design; •as maneiras do utilizador interagir com a aplicac¸˜ ao; •a aparˆ encia dessa em ecr˜ as de diversos tamanhos e resoluc¸ ˜ oes; •os requisitos mandat´ orios definidos pela plataforma de distribuic¸˜ ao. 3 A N ´ ALISE E ABORDAGEM DA PLATAFORMA LANDING PAGES Neste cap ´ ıtulo, ´ e apresentada a abordagem que ser ´ a usada para a cria c¸˜ ao de um interpretador da plataforma LP para a nova plataforma da Altice. ´ E inicialmente feito a apresenta c¸˜ ao da plataforma LP, sendo analisados os grupos de templates a recriar e os componentes que os comp ˜ oe. Depois ´ e apresentada a plataforma para onde o interpretador ser ´ a desenvolvido e integrado. Finalmente, ´ e apresentada uma proposta para a resolu c¸˜ ao do problema e uma poss´ ıvel arquitetura para a implementac¸˜ ao. 3.1 plataforma landing pages A plataforma LP ´ e uma plataforma para a cria c¸˜ ao de aplica c¸ ˜ oes interativas para TV baseadas em templates e foi criada para reduzir o tempo de desenvolvimento das aplica c¸ ˜ oes, enquadrando-se numa metodologia no code, pois esta permite a cria c¸˜ ao de aplica c¸ ˜ oes vocacionadas a promo c¸˜ ao de conte ´ udos e servi c¸ os multim ´ edias, atrav ´ es de templates predefinidos, sem ter que se proceder a desenvolvimento adicional. Desde a sua cria c¸˜ ao, esta plataforma foi utilizada para criar diversas aplica c¸ ˜ oes, tendo evolu ´ ıdo para integrar mais templates e reduziu o tempo de desenvolvimento destas aplica c¸ ˜ oes. Al ´ em disso, tamb ´ em permitiu que a equipa de produto de televis ˜ ao da empresa seja capaz de criar aplica c¸ ˜ oes rapidamente, envolvendo a equipa de desenvolvimento unicamente para a sua disponibiliza c¸˜ ao, dando maior independ ˆ encia a pessoas n ˜ ao especializadas e mais tempo ` a equipa de desenvolvimento. Esta plataforma, como muitas plataformas no code, funciona muito bem para a cria c¸˜ ao de aplica c¸ ˜ oes enquadradas pelos templates especificados e facilita a cria c¸˜ ao r ´ apida, por pessoas n ˜ ao especializadas, de aplica c¸ ˜ oes interativas para TV, sendo que ´ e previsto a continua c¸˜ ao da evolu c¸˜ ao da plataforma com a introdu c¸˜ ao de um template gen ´ erico. A seguir ´ e apresentada a sua arquitetura e uma an ´ alise dos seus componentes. 19 3.1. Plataforma Landing Pages 20 3.1.1Arquitetura Plataforma Landing Pages A plataforma ´ e composta por quatro componentes principais, apresentados na Figura 5. Figura 5: Arquitetura simplificada da plataforma Landing Pages Obackoffice permite a cria c¸˜ ao de uma aplica c¸˜ ao interativa, dita aplica c¸˜ ao LP, usando um dos cinco grupos de templates hoje dispon ´ ıveis, por exemplo, o template do grupo 4, apresentado na Figura 6, pode ser uma aplica c¸˜ ao LP v ´ alida. Uma vez selecionado o template, ´ e poss ´ ıvel configur ´ a-lo, escolhendo o background, a estrutura dos menus, parte da l ´ ogica, as imagens a apresentar, as cores e fontes de letras, entre outras op c¸ ˜ oes. Ap ´ os configura c¸˜ ao, a aplica c¸˜ ao ´ e guardada numa base de dados na forma de um conjunto de par ˆ ametros, podendo ser depois modificados. 3.1. Plataforma Landing Pages 21 Figura 6: Exemplo de um template com um background e um menu As aplica c¸ ˜ oes s ˜ ao depois expostas atrav ´ es de uma Web API que recupera da base de dados as configura c¸ ˜ oes, usando tamb ´ em servi c¸ os externos caso necess ´ ario. O resultado de um pedido ` aAPI pode ser JavaScript Object Notation (JSON) ou eXtensible Markup Language (XML). O interpretador ´ e o adaptador para a plataforma onde as aplica c¸ ˜ oes devem correr. Ele acede ` aAPI, recuperando a informa c¸˜ ao sobre a aplica c¸˜ ao e interpreta-a, criando a aplica c¸˜ ao configurada. ´ E uma parte essencial da plataforma e ´ e uma grande fonte de flexibilidade, pois permite o uso das aplica c¸ ˜ oes em qualquer plataforma que implemente o interpretador. 3.1.2Aplicac¸˜ ao Landing Pages Como definido na sec c¸˜ ao 1.4, uma aplica c¸˜ ao LP ´ e uma aplica c¸˜ ao interativa constru ´ ıda usando um conjunto de templates relacionados, usados em conjunto para a apresenta c¸˜ ao e o acesso a multim ´ edia. Na plataforma, uma aplica c¸˜ ao LP ´ e guardada como um conjunto de ficheiros de configurac¸ ˜ oes relacionados, como vis´ ıvel na Figura 7. 3.1. Plataforma Landing Pages 22 Figura 7:´ Arvore de configurac¸˜ ao de uma app Pela Figura 7, uma aplica c¸˜ ao ´ e constitu ´ ıda por pelo menos um template, que ´ e a sua home page, v ´ arias ´ areas, que correspondem a subp ´ aginas da aplica c¸˜ ao e a quem ´ e associado um template, itens, que s ˜ ao conte ´ udos associados a uma ´ area e que podem ser associados atemplates da aplica c¸˜ ao, e subitens que s ˜ ao conte ´ udos dos itens. ´ Areas e itens possuem um tipo, que especifica o comportamento e a origem dos dados que representam, por exemplo, se uma ´ area ´ e associada a uma feed Rich Site Summary (RSS), ent ˜ ao os seus itens s ˜ ao os elementos da feed. ´ Areas, itens e subitens possuem entradas diferentes na API, o tipo influenciando tamb´ em a entrada da API usada para os recuperar. O primeiro ficheiro de configura c¸˜ ao recuperado ´ e a configura c¸˜ ao geral da aplica c¸˜ ao, tendo informa c¸ ˜ oes gerais sobre esta, como os templates que usa, a sua identifica c¸˜ ao, restri c¸ ˜ oes de acesso, entre outras informa c¸ ˜ oes. A partir desta configura c¸˜ ao todos os templates da aplica c¸˜ ao s ˜ ao especificados. A primeira p ´ agina da aplica c¸˜ ao ´ e a sua home page e corresponde ao home template especificado. A partir da home page o utilizador navega na aplica c¸˜ ao, acedendo as p´ aginas e conte´ udos dessa. 3.2. Grupos de templates da plataforma Landing Pages 23 3.2 grupos de templates da plataforma landing pages Os templates da plataforma LP s ˜ ao p ´ aginas compostas por componentes e especificam como esses s ˜ ao organizados e se comportam . Para facilitar a configura c¸˜ ao, os templates s ˜ ao otimizados para uma resolu c¸˜ ao de 1280x720 pixeis, sendo deixado ao interpretador o redimensionamento destes. Todos os templates permitem a modifica c¸˜ ao do background. A seguir s ˜ ao apresentados e explicados os grupos de templates listados nos objetivos da sec c¸˜ ao 1.4, sendo apresentado um resumo dos componentes usados nos templates. 3.2.1Grupo 1 O grupo 1s´ o possui um template, apresentado na Figura 8. Figura 8: Template do grupo 1 Este template ´ e constitu ´ ıdo por uma seta, um carrossel, dois labels, uma borda, uma textbox, um contador e um slider. O carrossel ´ e usado para a navega c¸˜ ao numa lista de elementos sendo, por omiss ˜ ao, n ˜ ao circular. A posi c¸˜ ao no carrossel ´ e assinalada pelo contador. A seta assinala o in ´ ıcio do carrossel e que se o utilizador continuar a navegar para a esquerda, esse sair ´ a da aplica c¸˜ ao. Uma borda ´ e associada ao elemento selecionado, sendo informa c¸ ˜ oes sobre esse apresentado na textbox. Os labels s ˜ ao usados para apresentar informa c¸ ˜ oes sobre o elemento como o seu nome. O slider est ´ a associado a textbox, representando a navega c¸˜ ao nele caso necess ´ ario. O carrossel usa como fonte de dados os itens da ´ area associada. A 3.2. Grupos de templates da plataforma Landing Pages 24 posi c¸˜ ao e tamanho dos componentes podem ser modificados, sendo que, para al ´ em disso, ´ e poss ´ ıvel modificar a fonte e o tamanho de letra a usar para os labels, o contador e a textbox e a apar ˆ encia do slider ´ e modific ´ avel. Para os elementos do carrossel ´ e poss ´ ıvel configurar o tamanho desses e o espa c¸ amento entre elementos. A apar ˆ encia do elemento ´ e a imagem de background definido no item que o representa. 3.2.2Grupo 2 O grupo 2possui um ´ unico template, apresentado na Figura 9, sendo este a home page das aplica c¸ ˜ oes deste grupo. Essas aplica c¸ ˜ oes usam templates do grupo 6para complementar a aplicac¸˜ ao. Figura 9: Template do grupo 2 Otemplate possui tr ˆ es componentes, um carrossel, que por omiss ˜ ao ´ e circular, um indicador de posi c¸˜ ao e uma borda. O carrossel ´ e preenchido usando as ´ areas associadas ` a aplica c¸˜ ao. Os elementos do carrossel possuem um placeholder para o nome ou descri c¸˜ ao do elemento. O elemento selecionado ´ e assinalado com uma borda e ´ e ampliado, sendo a posi c¸˜ ao do elemento no carrossel assinalada pelo indicador de posi c¸˜ ao. A posi c¸˜ ao, tamanho e apar ˆ encia do indicador de posi c¸˜ ao s ˜ ao configur ´ aveis. Para o carrossel ´ e poss ´ ıvel modificar a sua posi c¸˜ ao, se ´ e ou n ˜ ao circular e o tamanho dos seus elementos. Al ´ em disso, o espa c¸ amento entre elementos, a posi c¸˜ ao do placeholder e o estilo do texto, ou seja fonte, tamanho de letra e cor, presente nesse, s˜ ao configur´ aveis. 3.2. Grupos de templates da plataforma Landing Pages 25 3.2.3Grupo 3 Este grupo possui dois templates mas o segundo ´ e um caso particular do primeiro, sendo usados juntos e considerados como um ´ unico template na plataforma e s ˜ ao, assim, a home page das aplica c¸ ˜ oes desse grupo. O primeiro template, apresentado na Figura 10, possui um carrossel, duas setas, quatro labels e um contador. Figura 10: Primeiro template do grupo 3 As setas e os labels ao lado delas indicam o nome do pr ´ oximo ou anterior item que ser ´ a apresentado se o utilizador navegar para l ´ a, sendo semelhante a um menu vertical. O label 1 ´ e o nome da ´ area agora apresentada sendo os itens da ´ area usados para preencher o carrossel. Olabel 4 ´ e o nome do elemento selecionado. O carrossel pode ou n ˜ ao ser circular, n ˜ ao o sendo por omiss ˜ ao. Como no template 1do grupo 1, o elemento selecionado ´ e assinalado por uma borda configur ´ avel, e o contador especifica em que elemento do carrossel o utilizador se situa. Quando a ´ area possui um ´ unico item ´ e usado o segundo template, apresentado na Figura 11, ficando o carrossel com um ´ unico elemento e sendo adicionados dois labels e uma textbox. 3.2. Grupos de templates da plataforma Landing Pages 32 Nome Configurac¸ ˜ oes Label posic¸˜ ao tamanho, cor e fontes de letra Carrossel (sem placeholder) posic¸˜ ao tamanho dos elementos espac¸o entre elementos se ´ e ou n˜ ao circular Carrossel (com placeholder) posic¸˜ ao tamanho dos elementos espac¸o entre elementos se ´ e ou n˜ ao circular fonte, cor e tamanho do placeholder posic¸˜ ao do placeholder background do placeholder Menu Vertical posic¸˜ ao n´ umero de itens vis´ ıveis tamanho dos itens espac¸o entre itens background do item Seta posic¸˜ ao tamanho imagem Contador posic¸˜ ao tamanho, cor e fontes de letra Borda posic¸˜ ao tamanho aspecto Icon tamanho posic¸˜ ao imagem Textbox tamanho posic¸˜ ao Slider posic¸˜ ao tamanho aparˆ encia Indicador de navegac¸˜ ao posic¸˜ ao tamanho aparˆ encia Asset posic¸˜ ao tamanho imagem Tabela 1: Lista dos elementos e das suas configurac¸ ˜ oes 3.3. Plataforma de desenvolvimento 33 3.3 plataforma de desenvolvimento A nova plataforma da Altice ´ e uma aplica c¸˜ ao maioritariamente escrita em JavaScript que usa as capacidades do browser, como a API History[ 20 ], para a cria c¸˜ ao duma UI responsiva e para fornecer servi c¸ os IPTV. Novas funcionalidades s ˜ ao adicionadas ` a plataforma atrav ´ es de m ´ odulos escritos em JavaScript que s ˜ ao registados e descarregados localmente antes de serem carregados, como apresentado na Figura 18 . A gest ˜ ao dos m ´ odulos ´ e feita, no momento, por um ficheiro de configura c¸˜ ao e a classe ModuleManager. A cada m ´ odulo ´ e associado um caminho ´ unico na plataforma, permitindo navegar para eles. Figura 18: Os m´ odulos s˜ ao baixados e carregados localmente 3.3.1Criac¸˜ ao de User Interface Uma ´ unica p ´ agina HTML ´ e usada pela plataforma, sendo a UI criada por manipula c¸˜ ao do Document Object Model (DOM) e´ e constitu´ ıda por screens eviews. Uma view ´ e um objeto constitu ´ ıdo por outras views e elementos primitivos da plataforma. Os elementos primitivos s ˜ ao classes da plataforma que abstraem funcionalidades HTML como a apresenta c¸˜ ao de texto e imagens. Uma view e os seus filhos s ˜ ao depois traduzidos numa ´ arvore DOM de elementos HTML, sendo usado a tag div para representar a view e os seus filhos. Cada view ´ e respons ´ avel pelos seus filhos, definindo o estilo desses como o tamanho, a posic¸˜ ao e visibilidade, tendo a capacidade de modific´ a-los. Uma screen ´ e um objeto constitu ´ ıdo por uma cole c¸˜ ao de views e define a UI da p ´ agina onde o utilizador se encontra. Esta ´ e respons ´ avel por responder aos inputs do utilizador, propagando esses aos seus filhos, se necess ´ ario. A screen define os seus filhos, o estilo desses e passa para esses dados e eventos. Quando uma screen ´ e carregada essa ´ e traduzida 3.4. Criac¸˜ ao do interpretador 34 num elemento div, sendo-lhe acrescentado os seus filhos. Algumas views definidas pela plataforma n ˜ ao s ˜ ao acrescentados como filhos, sendo adicionados diretamente a p ´ agina, como, por exemplo, o video player. N ˜ ao podem ser usados elementos primitivos como filhos de uma screen. As views escreens s ˜ ao objetos com estados, o estado deles variando em fun c¸˜ ao das intera c¸ ˜ oes com o utilizador. Uma screen possui dois estados, vis ´ ıvel e escondido. Quando vis ´ ıvel a screen tem o foco, sendo os eventos direcionados para ele, e os seus filhos passam a ser vis ´ ıveis. Quando escondido a screen e os seus filhos s ˜ ao escondidos, n ˜ ao recebendo eventos. As views possuem os mesmos estados mas ´ e poss ´ ıvel definir novos estados para esses, como o estado selecionado, e transi c¸ ˜ oes entre estados, algo n ˜ ao poss ´ ıvel para as screens. Todos os componentes s ˜ ao posicionados de maneira absoluta, isto ´ e, a propriedade CSS positioning ´ e posta a absoluto e s ˜ ao posicionados de acordo com os valores em pixeis atribu ´ ıdos as propriedades top eleft. De maneira a n ˜ ao bloquear o fluxo de v ´ ıdeo e as outras opera c¸ ˜ oes da STB, todas as opera c¸ ˜ oes bloqueantes ou que podem vir a ser canceladas, como as anima c¸ ˜ oes, devem ser ass ´ ıncronas, sendo usado a API Promise [ 21 ] e ferramentas fornecidas pela plataforma. 3.3.2Navegac¸˜ ao entre screens A navega c¸˜ ao na plataforma ´ e feita atrav ´ es de um router que usa a API History[ 20 ] para recriar a navega c¸˜ ao do browser sem o refrescar, guardando a ´ ultima screen apresentada. Para navegar para outra screen, uma screen usa a API do router, passando-lhe o nome do m ´ odulo e dados. Esta navega c¸˜ ao ´ e feita entre screens sendo de dois tipos, entre m ´ odulos ou dentro do m´ odulo. Quando a navega c¸˜ ao ´ e feita entre m ´ odulos, o router geral da plataforma determina se o caminho pedido existe e, caso existir, muda a localiza c¸˜ ao do browser e entrega os dados passados ao router do m´ odulo que ir´ a determinar que screen quer carregar. Quando a navega c¸˜ ao ´ e feita dentro do m ´ odulo a localiza c¸˜ ao do browser n ˜ ao ´ e alterada, ficando a cargo do router do m´ odulo determinar a screen a apresentar. Em ambos os casos, se a screen escolhida j ´ a tinha sido carregada ent ˜ ao ´ e atualizada e apresentada pelo router, sen ˜ ao a nova screen ´ e carregada e a screen at ´ e agora vis ´ ıvel passa a ficar escondida. 3.4 criac¸˜ ao do interpretador Como visto anteriormente, a UI da plataforma ´ e representada por screens carregadas atrav ´ es de um router. Pela estrutura duma aplica c¸˜ ao LP e da plataforma, ´ e poss ´ ıvel adotar o modelo Model View Controller (MVC) para o interpretador, onde o modelo ser ´ a representado pelas 3.5. Sum´ ario 35 ´ areas, itens e subitens da aplica c¸˜ ao, as vistas pelos templates e as correspondentes screens,eo controlador geral constitu ´ ıdo, no m ´ ınimo, pelo router do m ´ odulo. Assim, para cada template ser ´ a criada uma screen, sendo implementados os componentes dos templates, como imagens e menus, atrav´ es de views, reutilizando-se os componentes j´ a definidos na plataforma. A plataforma permite o registo de v ´ arias rotas para cada m ´ odulo, podendo cada uma delas corresponder a um dos templates ou, pode-se registar uma ´ unica rota onde se decida que template deve ser apresentado, em todos os casos, o controlador, a partir de informa c¸ ˜ oes que recebe e recolhe da API, ir ´ a decidir que template e com que configura c¸˜ ao deve ser carregado. As screens recebem eventos da plataforma respondendo a esses alterando as suas views, assim essas tamb ´ em poderiam ser implementadas seguindo o modelo MVC onde seriam os controladores, recuperando e processando informa c¸ ˜ oes da API que passariam depois as suas views para apresentac¸˜ ao. O controlador geral ´ e o ´ unico componente que comunica com a web API, devendo tentar minimizar os pedidos efetuados. 3.5 sum ´ ario Como foi apresentado, a plataforma LP ´ e dividida em diversos componentes sendo de salientar um backoffice para a cria c¸˜ ao de aplica c¸ ˜ oes, uma API para obter as aplica c¸ ˜ oes e o interpretador que reproduz as aplica c¸ ˜ oes no destino. As aplica c¸ ˜ oes s ˜ ao constitu ´ ıdas por templates divididos em seis grupos sendo que cada template tem as suas propriedades e componentes. Na framework aUI ´ e constitu ´ ıda de elementos designados por views que, em conjuntos, constituam uma screen. Para a cria c¸˜ ao do interpretador ´ e assim proposto seguir um modelo MVC onde cada template ser ´ a implementado como screen, ligados atrav ´ es de um controlador para recriar as aplicac¸˜ oes. 4 DESENVOLVIMENTO Ap ˆ os a an ´ alise dos templates efetuado na sec c¸˜ ao 3.2uma parte do trabalho a ser efetuado j ´ a tinha sido identificado. A partir da ´ ı foi necess ´ ario compreender como um template seria implementado na plataforma, compreendendo como interage com a API e os outros templates. Para tal criou-se uma prova de conceito, um esbo c¸ o inicial, onde ´ e implementado um ´ unico template que recupera e trata dados da API. Este ´ e muito simples consistindo duma ´ unica screen com diversas views, que realiza todo o trabalho, comunicando com a API e guardando todas as configura c¸ ˜ oes e dados recuperados. O esbo c¸ o s ´ o foi criado para melhor compreender a plataforma de desenvolvimento e as intera c¸ ˜ oes entre as aplica c¸ ˜ oes e aAPI mas permitiu, para al ´ em disto, identificar diferentes problemas e ajudou a desenhar uma arquitetura b´ asica para o m´ odulo. Neste cap ´ ıtulo ´ e detalhado como o desenvolvimento do m ´ odulo foi efetuado, descrevendo a arquitetura adotado para este, os elementos desenvolvidos, os problemas encontrados e as decis˜ oes tomadas. 4.1 problemas e decis ˜ oes Nesta sec c¸˜ ao s ˜ ao apresentadas dificuldades e problemas identificados durante a cria c¸˜ ao do prot ´ otipo inicial e do m ´ odulo, assim como as respetivas solu c¸ ˜ oes adotadas durante o desenvolvimento para as ultrapassar. A maioria desses problemas devem-se a uma falta de conhecimento e experi ˆ encia sobre a plataforma. Os problemas identificados mais impactantes foram: • Um motor de anima c¸˜ ao reduzido, limitado a propriedades espec ´ ıficas que dependem do elemento que se quer animar; • Um motor de escala inexistente, n ˜ ao permitindo um ajuste autom ´ atico dos elementos visuais; • A manuten c¸˜ ao dos elementos visuais criados, estes permanecendo na p ´ agina at ´ e ao seu pr´ oximo uso o que dificulta a configurac¸˜ ao desses; 36 4.1. Problemas e Decis˜ oes 37 •As mudanc¸as na plataforma devido a atualizac¸˜ oes; • A falta de uma documenta c¸˜ ao extensa que explique os diversos elementos da plataforma de desenvolvimento; •A navegac¸˜ ao entre screens tem as suas dificuldades. Esses problemas s ˜ ao a seguir discutidos com mais detalhe e apresentados as solu c¸ ˜ oes adotadas. 4.1.1Motor de animac¸˜ ao As anima c¸ ˜ oes s ˜ ao uma parte essencial de uma interface interativa, permitindo mostrar ao utilizador que algo mudou devido ` as suas a c¸ ˜ oes, sendo muito utilizado nos diversos grupos de templates. A plataforma permite a criac¸˜ ao de animac¸ ˜ oes de duas maneiras: • estaticamente, com a defini c¸˜ ao de estados e transi c¸ ˜ oes nos elementos com valores fixos; •dinamicamente, com a criac¸˜ ao e execuc¸˜ ao em runtime de animac¸ ˜ oes. Estas duas maneiras complementam-se mas s ˜ ao prejudicadas pela falta de maturidade do motor, pois este s ´ o permite a anima c¸˜ ao de um n ´ umero reduzido de propriedades que dependem muito do elemento que se quer animar. Al ´ em disto, s ´ o ´ e poss ´ ıvel animar uma propriedade de cada vez aumentando o n ´ umero de anima c¸ ˜ oes a criar para a realiza c¸˜ ao de anima c¸ ˜ oes complexas. Estas tamb ´ em n ˜ ao implementam eventos, impedindo a realiza c¸˜ ao de a c¸ ˜ oes no fim das anima c¸ ˜ oes. Para resolver esses problemas foi necess ´ ario substituir as anima c¸ ˜ oes indispon ´ ıveis por outras anima c¸ ˜ oes, por exemplo, em vez de animar a passagem de uma cor para outra num elemento, s ˜ ao criados dois elementos, um com a cor original e outro com a cor pretendida, e ´ e feito a transi c¸˜ ao de um para outro atrav ´ es da opacidade desses. Estas substitui c¸ ˜ oes n ˜ ao s ˜ ao realizadas para todas as propriedades que se quer animar. Como a plataforma n ˜ ao implementa um mecanismo de execu c¸˜ ao no fim da anima c¸˜ ao de uma a c¸˜ ao, foi decidido criar uma classe que estende as anima c¸ ˜ oes criadas pela plataforma para implementar tal mecanismo. Esta classe adiciona uma propriedade que representa uma fun c¸˜ ao, geralmente chamada por callback, que ´ e executada, se existir, sempre que a anima c¸˜ ao acabar, sendo-lhe passado como argumento a pr´ opria animac¸˜ ao. 4.1.2Motor de Escala A plataforma foi desenvolvida para a apresenta c¸˜ ao de conte ´ udo HD de uma resolu c¸˜ ao de 1080p, n ˜ ao disponibilizando, neste momento, de mecanismos para o redimensionamento autom ´ atica das UIs criadas. Como os templates s ˜ ao especificados para um resolu c¸˜ ao de 720p 4.1. Problemas e Decis˜ oes 38 ´ e necess ´ ario fazer o scaling destes, n ˜ ao para 1080pmas para a resolu c¸˜ ao do ecr ˜ a onde s ˜ ao apresentados. Para isto, foi decidido calcular o r ´ acio entre a resolu c¸˜ ao de refer ˆ encia e a do ecr ˜ a, sendo depois aplicado um factor de escala (scale), atrav ´ es da propriedade transform, diretamente ` aUI usando o r ´ acio calculado. Para ter um dimensionamento uniforme o ratio ´ e calculado relativamente a largura do ecr˜ a. 4.1.3Gest˜ ao dos elementos visuais Os elementos visuais, como as screens e as views, s ˜ ao geridos pela plataforma, sendo preservados depois de serem escondidos. Este comportamento leva a que as screens s ´ o s ˜ ao criadas uma vez, preservando o seu estado mesmo depois deste ser escondido. Se isto permite evitar a cria c¸˜ ao e disposi c¸˜ ao sucessiva de objetos tamb ´ em leva a um problema quando a mesma screen ´ e utilizada por diversas aplica c¸ ˜ oes com configura c¸ ˜ oes distintas, pois quando a screen volta a ser apresentada, esta ´ e apresentada com uma configura c¸˜ ao antiga, at ´ e que a nova configura c¸˜ ao e os novos dados chegam. Para contornar este problema ´ e usado um overlay que esconde a screen at ´ e ` a nova configura c¸˜ ao ser aplicada, sendo as altera c¸ ˜ oes for c¸ adas onde necess ´ ario. Al ´ em disto, os elementos mais din ˆ amicos das screens, como os carross ´ eis e menus, s ˜ ao limpos quando escondidos. Se tal permite evitar dados desatualizados na p ´ agina, tamb ´ em leva a que esses elementos podem voltar a ser preenchidos com os elementos limpos, podendo provocar a criac¸˜ ao desnecess´ ario de objetos. 4.1.4Alterac¸˜ oes devido a atualizac¸˜ oes A plataforma ainda se encontra em desenvolvimento n ˜ ao possuindo uma vers ˜ ao est ´ avel, sofrendo periodicamente altera c¸ ˜ oes que modificam a maneira como os elementos s ˜ ao apresentados e utilizados, para al ´ em de remover alguns componentes. Estas atualiza c¸ ˜ oes, se esperadas, causam muitas vezes problemas na UI. Tais altera c¸ ˜ oes s ˜ ao inevit ´ aveis, devendo ser tratadas ` a medida que a plataforma ´ e atualizada. Mesmo assim ´ e poss ´ ıvel limitar os problemas causados e a extens ˜ ao das modifica c¸ ˜ oes a efetuar usando abstra c¸ ˜ oes e dividindo corretamente as funcionalidades e os elementos visuais. 4.1.5Falta de documentac¸˜ ao Por ser uma plataforma propriet ´ aria em desenvolvimento a documenta c¸˜ ao, se existente, ´ e limitada, n ˜ ao explicando os diversos componentes da plataforma, como interagem e como podem ou devem ser usados. Tal falta foi muito sentido ao longo da prototipagem, o que levou a cria c¸˜ ao de uma mini documenta c¸˜ ao com apontamentos sobre os componentes mais importantes, os seus m ´ etodos, as suas vari ´ aveis, como eles se comportam, o que 4.2. Implementac¸˜ ao 39 conseguam ou n ˜ ao fazer e como podem ser usados. Tais apontamentos foram essenciais na implementa c¸˜ ao, durante a qual foram complementados, mas n ˜ ao s ˜ ao suficientes para compreender toda a plataforma, n˜ ao substituindo uma documentac¸˜ ao oficial. 4.1.6Navegac¸˜ ao entre screens Devido a falta de documenta c¸˜ ao foi dif ´ ıcil perceber como se podia passar de uma screen para outra preservando, no hist ´ orico, a screen anterior. Para al ´ em disto, as aplica c¸ ˜ oes LP navegam usando dados provenientes da API, devendo possivelmente passar informa c¸˜ ao a screen que lhe segue e preservar o estado de alguns dos seus elementos visuais, sendo essa ´ ultima informa c¸˜ ao usada quando o utilizador voltar para a screen. Sem documenta c¸˜ ao a m ˜ ao decidiu-se inspecionar o c ´ odigo para encontrar as classes e m ´ etodos a usar, verificar o que as vari ´ aveis definidas representam e modific ´ a-las no m ´ odulo para obter o comportamento esperado. Depois de compreender como o hist ´ orico era usado e como a navega c¸˜ ao ´ e feita internamente foi necess ´ ario definir como o router iria escolher a screen a mostrar. Como um router pode possuir v´ arias rotas seria poss´ ıvel definir uma rota para cada template existente mas isto implica a cria c¸˜ ao e registo de novas rotas, para al ´ em da l ´ ogica necess ´ aria para aceder a esta, cada vez que um novo template ´ e criado. Decidiu-se, por isso, criar uma ´ unica rota no router deixando a escolha ao controlador atrav´ es das informac¸ ˜ oes recebidas. 4.1.7Sum´ ario Como visto, muito dos problemas derivaram da plataforma n ˜ ao estar est ´ avel e s ´ o foram superados atrav ´ es de um estudo cont ´ ınuo do c ´ odigo fonte, a cria c¸˜ ao de uma documenta c¸˜ ao pr ´ opria e a organiza c¸˜ ao do m ´ odulo de maneira a evitar o uso direto dos elementos da plataforma. Outros problemas sugiram relativamente ` a organiza c¸˜ ao dos componentes, relativamente ` a l ´ ogica a implementar e a representa c¸˜ ao dos dados, que ser ˜ ao explorados na pr´ oxima secc¸˜ ao. 4.2 implementac¸˜ ao A implementa c¸˜ ao come c¸ ou com a cria c¸˜ ao dum esbo c¸ o onde foi implementado um ´ unico template para familiarizar-se com a plataforma. Para tal, foi criado um router que regista uma ´ unica route que devolve sempre a mesma screen, implementando o m ´ ınimo necess ´ ario para o bom funcionamento do template. Este primeiro esbo c¸ o permitiu identificar os m ´ etodos necess ´ arios para recuperar dados da API, como podem ser recuperados pela screen assim como podem ser localmente conservados para evitar pedidos desnecess ´ arios. A partir deste, a implementa c¸˜ ao do m ´ odulo foi feito iterativamente e incrementalmente, come c¸ ando pela 4.2. Implementac¸˜ ao 40 cria c¸˜ ao de um controlador que faz a liga c¸˜ ao entre o router e as screens do m ´ odulo. A l ´ ogica que era implementada na screen passou a ser feita no controlador, sendo que a screen interage com este para recuperar dados. O controlador foi criado para poder manter o contexto da aplicac¸˜ ao entre screens e abstrair a l´ ogica de recuperac¸˜ ao dos dados das mesmas. Com a cria c¸˜ ao do controlador e a implementa c¸˜ ao do esbo c¸ o foram identificados diferentes elementos e partes l´ ogicas que constituem o m´ odulo, sendo esses: •A l´ ogica de comunicac¸˜ ao com a API atrav´ es do controlador e classes auxiliares; • A l ´ ogica de navega c¸˜ ao do lado do router, para escolher a screen a apresentar e recuperar os dados que lhe ser˜ ao necess´ arios atrav´ es do controlador; •Os elementos visuais, como as screens e as views,eal´ ogica pr´ opria a cada um deles; • A l ´ ogica de navega c¸˜ ao do lado das screens de maneira a determinar a a c¸˜ ao a realizar para poder navegar dentro da aplica c¸˜ ao preservando o estado atual, permitindo voltar para esses. Cada itera c¸˜ ao da implementa c¸˜ ao foi efetuada relativamente aos templates a implementar, isto ´ e, cada itera c¸˜ ao come c¸ a pela implementa c¸˜ ao de um novo template, s ´ o se concluindo depois de ser testado, corrigido e visualmente aceite pelos respons ´ aveis na empresa. Em cada itera c¸˜ ao as diferentes partes l ´ ogicas sofrem altera c¸ ˜ oes tendo sido sempre necess ´ ario garantir a validade dos templates anteriormente implementados, voltando a test ´ a-los em cada iterac¸˜ ao. A seguir ´ e apresentado a arquitetura implementada no m ´ odulo sendo depois discutido a implementac¸˜ ao das partes identificadas. 4.2.1Arquitetura do m´ odulo O m ´ odulo segue a arquitetura MVC, tendo sido dividido em elementos visuais, modelos de dados, controladores e utilidades, sendo apresentado um diagrama do m ´ odulo na Figura 19. 4.2. Implementac¸˜ ao 41 Figura 19: Diagrama de classes do modulo 4.2. Implementac¸˜ ao 48 existir um url para uma feed de ´ audio que deve ser reproduzida quando carregado, por isso, ´ e usado um leitor de ´ audio a quem ´ e passado o url recuperado da configurac¸˜ ao. Figura 21: Elementos do Grupo 2 Esta screen usa as suas ´ areas como fonte de dados para preencher o carrossel, sendo que este pode ou n˜ ao ser circular dependendo da configurac¸˜ ao. grupo 3 O grupo 3foi implementado com uma ´ unica screen, apresentada na Figura 22. Figura 22: Elementos do Grupo 3 4.2. Implementac¸˜ ao 49 AUI da screen ´ e controlada por uma view prim ´ aria que atualiza os elementos. De maneira a poder implementar o segundo template identificado no Cap ´ ıtulo 3.2.3, foi criado uma view que esconde e apresenta os elementos do caso particular quando pedido. Assim, se a view prim ´ aria verifica que ´ e pedido a apresenta c¸˜ ao do caso particular, ele altera a sua configura c¸˜ ao de maneira a sua apar ˆ encia corresponder ao segundo template. Isto s ´ o ´ e poss ´ ıvel porque este s ´ o difere do template normal em elementos precisos, facilmente escondidos, e porque a sua configura c¸˜ ao est ´ a especificada num ´ unico template, isto ´ e, s ´ o existe um ´ unico ficheiro de configura c¸˜ ao para ambos os casos. Este template representa a home screen das aplica c¸ ˜ oes deste grupo usando as suas ´ areas como sec c¸ ˜ oes, sendo que os itens da sec c¸˜ ao selecionada s ˜ ao usados para preencher o carrossel. O template funciona como um agregador de conte ´ udo onde o utilizador navega entre secc¸ ˜ oes sendo-lhe apresentado elementos dessa. grupo 4 O grupo 4 ´ e constitu ´ ıdo por dois templates identificados na sec c¸˜ ao 3.2.4. Esses templates foram implementados por duas screens, apresentadas na Figura 23. Figura 23: Elementos do Grupo 4 O primeiro template, a home screen das aplica c¸ ˜ oes deste grupo, foi implementado com a screen MCSHomeScreen e o segundo pela screen MCSContentScreen. Ambas as screens possuem uma view prim´ aria respons´ avel pela gest˜ ao da sua UI. 4.2. Implementac¸˜ ao 50 grupo 5 O grupo 5 ´ e constitu ´ ıdo por dois templates identificados na sec c¸˜ ao 3.2.5, tendo sido implementados por duas screens, como apresentado na Figura 24. Figura 24: Elementos do Grupo 5 O primeiro template ´ e implementado com a screen RadiosHomeScreen, sendo a sua UI representada pela sua view prim ´ aria RadioHomeContainer. Neste template ascreen recupera e processa as suas ´ areas para preencher o menu vertical. Depois, usando o elemento selecionado, a screen recupera e processa os itens associados ao elemento e passa-os a sua view que preenche o carrossel e os labels. O segundo template foi implementado pela screen RadiosContentScreen, sendo a sua UI implementada atrav ´ es da view RadioContentContainer. Quando carregada, a screen recupera elementos da api, atrav ´ es do controlador, que processa para preencher o seu carrossel e preencher o menu. A seguir, a screen verifica se a informa c¸˜ ao do elemento selecionado tem que ser atualizada recorrentemente, indicado por uma propriedade de atraso de busca, se sim ent ˜ ao ´ e criado um timer que pede periodicamente informa c¸ ˜ oes ao controlador atualizando a view caso houver modificac¸ ˜ oes. grupo 6 4.2. Implementac¸˜ ao 51 O grupo 6possui dois templates, identificados na sec c¸˜ ao 3.2.6, usados pelas aplica c¸ ˜ oes dos outros grupos. A Figura 25 apresenta o diagrama de classe da implementa c¸˜ ao desse grupo. Figura 25: Elementos do Grupo 6 O primeiro template foi implementado na screen HungerContentScreen que efetua a gest ˜ ao da sua UI atrav ´ es da view HungerContentContainer. A UI ´ e composta por um carrossel preenchido por dados recuperados pelo controlador e processados pela screen. Neste template um dos labels ´ eot ´ ıtulo da screen e o outro ´ e o nome do elemento selecionado, o contador seguindo a navegac¸˜ ao do utilizador. Como definido, o carrossel ´ e n˜ ao circular sendo a seta escondida quando o primeiro elemento do carrossel n˜ ao ´ e selecionado. O segundo template ´ e mais simples e foi implementado na screen HungerSlideshowScreen e sua view prim ´ aria HungerContentContainer. O indicador de navega c¸˜ ao ´ e um slider numerado tendo sido usado a view Slider e o slideshow foi implementado pela view Slideshow que, dado uma lista de urls, permite a apresenta c¸˜ ao sequencial de imagens. A view prim ´ aria faz a gest˜ ao dos elementos da UI mantendo o slideshow e o slider sincronizados. 4.3. Sum´ ario 52 4.2.5Navegac¸˜ ao nas screens As screens devem ser capazes de navegar n ˜ ao s ´ o para outras screens da aplica c¸˜ ao como para outras aplica c¸ ˜ oes e elementos da plataforma. De momento a implementa c¸˜ ao foca-se na navega c¸˜ ao para outras aplica c¸ ˜ oes e dentro dessas. Eventos de navega c¸˜ ao acontecem unicamente quando o utilizador seleciona um elemento da UI ou quando decide voltar para ascreen anterior. O ´ ultimo ´ e facilmente processado atrav ´ es das ferramentas disponibilizadas pela plataforma, a implementac¸˜ ao focando-se no primeiro. Os elementos selecionados podem ser itens ou ´ areas, sendo que possuem diferentes tipos que implicam a realiza c¸˜ ao de diferentes a c¸ ˜ oes quando selecionados, como por exemplo sair da aplica c¸˜ ao ou apresentar um v ´ ıdeo, mas as a c¸ ˜ oes poss ´ ıveis e a l ´ ogica necess ´ aria varia se o elemento ´ e uma ´ area ou um item. Como a fonte de decis ˜ ao ´ e sempre o elemento decidi criar na screen pai, LPGeralScreen, um ´ unico m ´ etodo que, dado as informa c¸ ˜ oes do elemento, ir ´ a decidir que a c¸˜ ao deve ser efetuada. Foram consideradas outras implementa c¸ ˜ oes, como, por exemplo, a cria c¸˜ ao de callbacks associadas a cada tipo de elemento que corresponderiam a a c¸ ˜ oes a realizar, ou deixar o controlador, ou outra classe, decidir que a c¸˜ ao deve ser realizada mas, no primeiro caso, o elemento ´ e que sabe como deve ser usado, ora se isto permite facilmente modificar a implementa c¸˜ ao da a c¸˜ ao, implica que ele conhece demasiada informa c¸˜ ao sobre o contexto onde ´ e usado. O segundo caso ´ e uma poss ´ ıvel evolu c¸˜ ao do sistema implementado caso se verifica a necessidade de separar a decis ˜ ao da a c¸˜ ao a realizar da screen em si. Assim, o m ´ etodo recebe o elemento selecionado e determina se ´ e uma ´ area, item ou subitem, pois possuem diferentes tipos, identificados por diferentes propriedades. A seguir ´ e determinado, em fun c¸˜ ao do tipo associado ao elemento, que a c¸˜ ao deve ser realizado. O tipo d ´ a informa c¸˜ ao sobre o que o elemento representa como um v ´ ıdeo, uma aplica c¸˜ ao, elementos da loja de v ´ ıdeo, entro outros. Quando se move para outra screen dentro da plataforma, sem usar o back, ´ e necess ´ ario preservar o contexto da screen para poder voltar a este. Para tal esta l ´ ogica foi centralizada num ´ unico m ´ etodo que preserva o contexto e lan c¸ a o routing para a nova screen. O m ´ etodo foi implementado na screen LPGeralScreen podendo os filhos reescrever este m´ etodo caso necess´ ario. 4.3 sum ´ ario Como visto o desenvolvimento do interpretador foi feito iterativamente e incrementalmente, tendo-se come c¸ ado com um esbo c¸ o para familiarizar-se com a plataforma. Com este foi poss ´ ıvel identificar diferentes problemas, que foram tomados em considera c¸˜ ao durante a implementa c¸˜ ao, e elementos que seriam reusados na implementa c¸˜ ao. Depois passouse a implementar o m ´ odulo iterando-se sob os diferentes templates definidos, testando e 4.3. Sum´ ario 53 corrigindo-os antes de passar a pr ´ oxima itera c¸˜ ao. Cada template foi representado por uma screen com os seus elementos visuais implementados com views. O contexto da aplica c¸˜ ao e a comunica c¸˜ ao ´ e feito pelo controlador do m ´ odulo sendo abstra ´ ıdo das screens limitando a l ´ ogica presente nessas. Assim, conseguiu-se implementar todos os grupos de templates identificados tendo sido testados e validados. 5 CASOS DE ESTUDO E RESULTADOS Neste cap ´ ıtulo s ˜ ao analisadas duas aplica c¸ ˜ oes, uma simples e outra mais complexa, criadas na plataforma LP e que s ˜ ao apresentadas no browser usando o interpretador criado. Essas aplica c¸ ˜ oes s ˜ ao usadas como casos de estudo para verificar a flexibilidade e robustez da plataforma de desenvolvimento. Assim, s ˜ ao um exemplo de aplica c¸ ˜ oes que podem ser criadas na plataforma. Sendo a UI din ˆ amica, algumas diferen c¸ as n ˜ ao s ˜ ao vis ´ ıveis nas imagens apresentadas, mas ´ e feita uma descri c¸˜ ao onde essas diferen c¸ as s ˜ ao mais not ´ orias. Um teste de performance n ˜ ao foi efetuado por n ˜ ao ter sido poss ´ ıvel testar a implementa c¸˜ ao no mesmo ambiente que a implementac¸˜ ao original. 5.1 ambiente de execuc¸˜ ao Aframework foi executado no Google Chrome Web Browser e na plataforma Nw.JS, sendo que as duas aplica c¸ ˜ oes foram criadas atrav ´ es da plataforma LP e conservadas num servidor de teste donde s˜ ao recuperadas. 5.2 casos de estudo Para cada grupo de templates, excluindo o grupo seis, foram criadas aplica c¸ ˜ oes no servidor LP. Usando essas aplica c¸ ˜ oes, e outras j ´ a presentes, o interpretador criado foi testado, verificando que este ´ e capaz de recuperar dados e modificar a interface para respeitar as configura c¸ ˜ oes dos templates. Neste cap ´ ıtulo s ˜ ao apresentadas duas aplica c¸ ˜ oes usadas para teste. A primeira aplica c¸˜ ao ´ e uma das aplica c¸ ˜ oes mais simples que pode ser criada, pelo seu aspeto e suas funcionalidades, enquanto que a segunda aplica c¸˜ ao ´ e mais complexa tendo mais elementos visuais. Para mostrar que as configura c¸ ˜ oes n ˜ ao s ˜ ao fixas, s ˜ ao apresentadas varia c¸ ˜ oes de certas p´ aginas das aplicac¸ ˜ oes. 54 5.2. Casos de estudo 55 5.2.1Primeira Aplicac¸˜ ao A primeira aplica c¸˜ ao foi criada com os templates do grupo quatro e ´ e constitu ´ ıda por dois templates que s ˜ ao a p ´ agina inicial e a p ´ agina de conte ´ udos. Para tal acedeu-se ao backend da plataforma LP e criou-se uma nova aplica c¸˜ ao. Depois, escolheu-se o template da p ´ agina inicial, que aqui corresponde ao primeiro template do grupo, e fez-se a configura c¸˜ ao dessa. Esta configura c¸˜ ao implica configurar o t ´ ıtulo, o contador, o ´ ıcone, as setas e o menu vertical, sendo a configura c¸˜ ao desta p ´ agina apresentada no Anexo A. Uma vez a configura c¸˜ ao acabada foi necess ´ ario criar ´ areas atrav ´ es do backend, sendo que essas ir ˜ ao ser usadas para preencher o menu vertical da p ´ agina. A cada ´ area ´ e dado um nome e a identifica c¸˜ ao de um ´ ıcone a usar no menu. Nessa aplica c¸˜ ao foram criadas seis ´ areas cada uma delas com um tipo. Quatro delas s ˜ ao associadas a feeds RSS externas, uma delas ´ e uma categoria de VOD e a ´ ultima possui itens pr ´ oprios, sendo o tipo mais simples. Com esses dados a p ´ agina inicial da aplicac¸˜ ao ´ e completa e vis´ ıvel na Figura 26. Figura 26: P´ agina inicial da aplicac¸˜ ao na nova plataforma Esta p ´ agina foi configurada de maneira a que o ´ ıcone, o t ´ ıtulo e contador sejam posicionados um pouco acima a esquerda do menu vertical, sendo que este foi configurado para ocupar a parte central da p ´ agina em todo a sua largura. Para al ´ em disso, o menu foi configurado para s ´ o apresentar tr ˆ es elementos de cada vez, os outros ficando escondidos, e as setas foram posicionadas por cima e por baixo do menu, como vis´ ıvel na Figura 26. No menu a barra vertical indica o elemento selecionado, subindo e descendo segundo os inputs do utilizador, e possui um efeito de brilho, passando de uma cor para outra. Nesta aplica c¸˜ ao essa barra passa de azul para branco, mas pode ser configurada para mostrar outras cores. 5.2. Casos de estudo 56 A apar ˆ encia da p ´ agina na plataforma em uso ´ e semelhante a apar ˆ encia da p ´ agina na nova framework, apresentado na Figura 26, como vis´ ıvel na Figura 27. Figura 27: P´ agina inicial da aplicac¸˜ ao na plataforma hoje em uso e na nova plataforma A p ´ agina de conte ´ udo foi criada com o segundo template do grupo quatro. Para aceder a essa p ´ agina o utilizador tem que selecionar um elemento do menu associado a essa. Nesta aplica c¸˜ ao, todas as ´ areas foram associadas ao template da p ´ agina de conte ´ udos sendo irrelevante o elemento selecionado. Como apresentado no Cap ´ ıtulo 3.2.4, esta p ´ agina ´ e composta por um t ´ ıtulo, um ´ ıcone, um contador, uma seta, uma borda e um carrossel, sendo a p´ agina apresentada na Figura 28 5.2. Casos de estudo 57 Figura 28: P´ agina de conte´ udo da aplicac¸˜ ao O t ´ ıtulo e o ´ ıcone foram configurados para ficarem um ao lado do outro um pouco acima do carrossel, este ficando na parte baixa da p ´ agina. O t ´ ıtulo, como na p ´ agina de conte ´ udo, ´ e um label tendo sido configurado com uma cor e fam ´ ılia de fontes de texto. A borda ´ e configurada para n ˜ ao aparecer sendo que a seta s ´ o aparece quando o primeiro elemento ´ e focado. O carrossel n ˜ ao ´ e circular sendo preenchido com os itens da ´ area selecionada. Nessa aplica c¸˜ ao, os itens podem ser os elementos recuperados de uma das feeds RSS, itens VOD da categoria associada a ´ area ou ent ˜ ao itens criados no backend que foram associados a ´ area. Em todos os casos a apar ˆ encia dos elementos do carrossel ´ e din ˆ amica, variando quando s ˜ ao selecionados. Aqui a configura c¸˜ ao espec ´ ıfica que, quando selecionado, o texto deve ter uma cor branca com fundo azul escuro, enquanto que quando n ˜ ao selecionados este deve ter uma cor azul claro sem fundo, como vis´ ıvel na Figura 28. A apar ˆ encia da p ´ agina na plataforma original ´ e semelhante mas divergem quanto ao espac¸o que ocupa o texto e as imagens, como vis´ ıvel na Figura 29. 5.4. Sum´ ario 64 5.4 sum ´ ario As duas aplica c¸ ˜ oes analisadas permitem perceber que o interpretador criado consegue reproduzir aplica c¸ ˜ oes LP e apresentar os seus conte ´ udos, como especificado pelas suas configura c¸ ˜ oes. Mesmo assim, o interpretador criado n ˜ ao disponibiliza todas as funcionalidades do interpretador original, pois difere em certas anima c¸ ˜ oes nos templates e n ˜ ao permite a filtragem do conte ´ udo de acordo com o perfil do utilizador devido a uma falta de integra c¸˜ ao com servi c¸ os internos da empresa. Mesmo assim, o interpretador ´ e suficientemente completo para permitir testar todas as aplicac¸ ˜ oes LP na framework. 6 CONCLUS ˜ AO E TRABALHO FUTURO Neste cap ´ ıtulo ´ e feita a conclus ˜ ao do trabalho efetuado, refletindo sobre os objetivos que foram atingidos, os desafios ultrapassados, a abordagem usada e o que se conseguiu demonstrar. 6.1 conclus ˜ ao Neste trabalho conseguiu-se criar um m ´ odulo, para um servi c¸ o da Altice Labs, numa plataforma privada em desenvolvimento e com documenta c¸˜ ao limitada. O m ´ odulo serve de interpretador para aplicac¸ ˜ oes interativas LP na nova plataforma e foi escrito em JavaScript. A cria c¸˜ ao do interpretador e a implementa c¸˜ ao dos templates, permitiu demonstrar que servi c¸ os e aplica c¸ ˜ oes semelhantes e usados em produ c¸˜ ao na empresa, podem ser implementados na nova framework, mas tamb ´ em permitiu identificar lacunas nesta que limitam, em parte, a implementa c¸˜ ao desses servi c¸ os. Essas lacunas, podem ser corrigidas pois a framework pertence ` a empresa, n ˜ ao sendo limitado por um terceiro como acontece na plataforma Mediaroom. A divis ˜ ao dos templates em grupos ajudou no processo iterativo feito na implementa c¸˜ ao. Pois, como os templates partilham muitos elementos visuais semelhantes, acabar um grupo de templates reduzia o trabalho a efetuar na itera c¸˜ ao seguinte. Mesmo assim, tiveram que ser implementados muitas views pois a framework n ˜ ao disponibilizava componentes que respondiam as necessidades dos templates. Se a abordagem escolhida ajudou no desenvolvimento, a falta de documenta c¸˜ ao da framework e uma falta de conhecimento sob as funcionalidades das aplica c¸ ˜ oes LP foram problemas que me acompanharam durante todo o trabalho. Com o primeiro caso, perdeu-se tempo em pesquisar no c ´ odigo fonte, exemplos de funcionalidades ou componentes que poderiam ter ajudado na realiza c¸˜ ao deste trabalho mas acabou-se por verificar que n ˜ ao existiam. No segundo caso, a implementa c¸˜ ao dos templates foi feita, usando como fonte de informa c¸˜ ao documentos fornecidos pela empresa, mas esses documentos s ´ o especificavam os elementos visuais e n ˜ ao explicavam as funcionalidades dos templates, que dados recuperariam, como 65 6.2. Trabalho futuro 66 eram tratados nem como seriam afetados por par ˆ ametros configurados na aplica c¸˜ ao e nos dados. Muitos desses assuntos foram resolvidos durante a implementa c¸˜ ao, mas outros s ´ o foram percebidos no fim do trabalho n˜ ao tendo sido implementados. Nesta fase de teste, a empresa decidiu que essas funcionalidades n ˜ ao s ˜ ao necess ´ arias, sendo que, ser ˜ ao adicionadas ao interpretador e ` aframework mais tarde. Mesmo assim, poder trabalhar numa plataforma privada em desenvolvimento foi um desafio ´ unico que permitiu compreender a necessidade de planear e organizar o trabalho a efetuar, de maneira a esse n ˜ ao ser desperdi c¸ ado em caso de mudan c¸ as. Este trabalho permitiu realizar a import ˆ ancia de ferramentas que apoiam a cria c¸˜ ao r ´ apida de aplica c¸ ˜ oes como ´ e o caso da plataforma LP, porque reduzem o trabalho a efetuar e o tempo de desenvolvimento. Por exemplo, as duas aplica c¸ ˜ oes apresentadas no Cap ´ ıtulo 5foram criadas num ´ unico dia, enquanto que o desenvolvimento normal dessas aplica c¸ ˜ oes diretamente na framework e seguindo as etapas apresentadas na sec c¸˜ ao 2.3teria demorado semanas. Assim, os objetivos do trabalho foram atingidos com a implementa c¸˜ ao de todos os grupos de templates e a possibilidade de usar as aplica c¸ ˜ oes LP na framework, havendo a possibilidade da sua evolu c¸˜ ao futura, implementando outras funcionalidades ainda n ˜ ao dispon ´ ıveis que tornar˜ ao toda a soluc¸˜ ao mais completa e robusta. 6.2 trabalho futuro O interpretador deve ser mantido de maneira a acompanhar as evolu c¸ ˜ oes tanto da framework como da plataforma LP com a implementa c¸˜ ao de novos templates. Para al ´ em desta manuten c¸˜ ao, e como visto anteriormente na sec c¸˜ ao 5.3, existem funcionalidades das aplicac¸ ˜ oes LP que n˜ ao foram implementadas neste trabalho sendo assim necess´ ario fazer a implementa c¸˜ ao dessas, continuando o desenvolvimento do interpretador. No futuro, seria tamb ´ em necess ´ ario rever a arquitetura do m ´ odulo, fazendo o refactoring desse, de maneira a melhorar o seu desempenho e reduzir a sua complexidade, pois esse foi criado com conhecimentos reduzidos da framework podendo vir a ser melhorado. Um foco principal desse processo dever ´ a estar no controlador e router devido a l ´ ogica l ´ a presente, pois muito do trabalho ´ e feito no controlador devendo ser poss ´ ıvel dividi-lo em partes mais especializadas. Por exemplo, na implementa c¸˜ ao atual o controlador faz o mapeamento entre template e a sua correspondente screen mas este processo poderia ser passado para outro componente, independente do controlador. Assim, o controlador usaria este componente para fazer o mapeamento ou esse poderia ser deixado ao router. A framework permite importar ficheiros de configura c¸ ˜ oes, mas sem documenta c¸˜ ao n ˜ ao se-conseguiu usar tal ferramenta, assim recomenda-se usar essa funcionalidade para criar ficheiros de configura c¸ ˜ oes para o interpretador. Esses ficheiros poderiam conter o mapeamento dos templates para screens,urls para a API e outras opc¸ ˜ oes necess´ arias. 6.2. Trabalho futuro 67 Para facilitar futuros desenvolvimentos e a manuten c¸˜ ao do m ´ odulo, ´ e necess ´ ario ciar uma documenta c¸˜ ao extensa da framework e de todos os seus componentes, com exemplos e detalhes, devendo ser revista a documenta c¸˜ ao dos servi c¸ os existentes para facilitar a aprendizagem e poss´ ıveis portes para outras plataformas desses servic¸os. BIBLIOGRAPHY [1] Smart tv market segmentation analysis report 2015. URL https://www.marketwatch. com/press-release/smart-tv-market-segmentation-application-technology-market-analysis-research-report-2025-2019-02-28 . Accessed on 2019-12-12. [2] ANACOM. O que ´ e uma set-top box? https://www.anacom.pt/render.jsp?contentId= 928091. Accessed on 2018-12-18. [3] T. M. A. Antunes. Aplica c¸˜ ao iOS para partilha, edi c¸˜ ao e controlo de UGC na TV. PhD thesis, Faculdade de ci ˆ encias e tecnologia, Universidade de Coimbra, 2de Setembro de 2015. section 6.3.2. [4] C. . F. a. A. C. Arthur Varushyla, 2018. URL https://www.quora.com/ How-do-I-develop-apps-for-smart-TV. Acessed on 2019-07-05. [5] K. Chorianopoulos. User interface design principles for interactive television applications. International Journal of Human-Computer Interaction, volume 24, pages 3-9. [6] J. Clover. Mediakind puts mediafirst on legacy set-tops. https://www.broadbandtvnews. com/2018/09/06/mediafirst-puts-mediaroom-on-legacy-set-tops/ , Setembro 2018. Accessed on 2018-12-18. [7] E. Commission. Explanatory note commission recommendation on relevant product and service markets within the electronic communications sector. URL https://www.pts.se/globalassets/startpage/dokument/legala-dokument/eu-regler/ explanatorynote-201410091.pdf. Accessed on 2019-10-17. [8] S. Developers. Application development process, 2014. URL https://developer.samsung. com/tv/develop/legacy-platform-library/art00008/index. Accessed on 2019-07-05. [9] D. DVB, ETSI. Digital video broadcasting (dvb); transport of mpeg-2ts based dvb services over ip based networks. Accessed on 2019-01-06. [10] ETSI. Digital video broadcasting (dvb); globally executable mhp (gem) specification 1.3 (including ott and hybrid broadcast/broadband). URL https://www.etsi.org/deliver/ etsi ts/102700 102799/102728/01.02.01 60/ts 102728v010201p.pdf . Accessed on 201910-17. 68 bibliography 69 [11] O. I. Forum. Open iptv forum release 2specification volume 1overview. http: //www.oipf.tv/web-spec/volume1.html, . Accessed on 2019-10-17. [12] O. I. Forum. Release 2specification volume 5declarative application environment, . URL http://www.oipf.tv/web-spec/volume5.html. Accessed on 2019-10-17. [13] O. I. Forum. Open iptv forum release 2specification volume 2media formats, . URL http://www.oipf.tv/web-spec/volume2.html. Accessed on 2019-10-17. [14] O. I. Forum. Open iptv forum release 2specification volume 6procedural application environment, . URL http://www.oipf.tv/web-spec/volume6.html . Accessed on 2019-1017. [15] M. P. Inc. Video assurance and analytics best practices for ericsson mediaroom platform operators adding new on-demand and ott services. URL http://www.marinerxvu.com/wp-content/uploads/2015/03/ Mariner-xVu-Mediaroom-plus-OTT-streaming-White-Paper-Q3-2016.pdf . Accessed on 2019-01-06. [16] ITU. https://web.archive.org/web/20110916031736/http://www.itu.int/ITU-T/ newslog/IPTV+Standardization+On+Track+Say+Industry+Experts.aspx . Accessed on 2018-12-22. [17] R. J. Lopes. The design of a digital satelitte set-top box. https://web.njit.edu/∼rlopes/ example-2.pdf. Accessed on 2018-12-18. [18] Luiz F.G. Soares, Marcio F. Moreno, Carlos de Salles S. Neto, and Marcelo F. Moreno. Ginga-ncl: Declarative middleware for multimedia iptv services. In IEEE Communications Magazine ( Volume: 48 , Issue: 6, June 2010 ). [19] D. Minoli. IP Multicast with Applications to IPTV and Mobile DVB-H. [20] Mozilla Developpers Web Docs. History interface, . URL https://developer.mozilla.org/ en-US/docs/Web/API/History. Accessed on 2019-04-10. [21] Mozilla Developpers Web Docs, . URL https://developer.mozilla.org/en-US/docs/Web/ JavaScript/Reference/Global Objects/Promise. Accessed on 2019-09-20. [22] N. OpenTV. Opentv os experience features. https://opentv.nagra.com/ux/features , . Accessed on 2018-12-11. [23] N. OpenTV. Opentv os. https://opentv.nagra.com/os/overview-0 , . Accessed on 201812-11. bibliography 70 [24] N. OpenTV. Opentv platform architecture. https://opentv.nagra.com/platform/ architecture, . Accessed on 2018-12-11. [25] N. OpenTV. Opentv os player. https://opentv.nagra.com/player , . Accessed on 2018-1211. [26] D. Proteste. Televisor: qual a diagonal de ecr ˜ a certa para a minha sala?, 2016. URL https://www.deco.proteste.pt/tecnologia/televisores/dicas/ televisor-qual-a-diagonal-de-ecra-certa-para-a-minha-sala. Acessed on 2019-07-09. [27] Samsung. Design. URL https://developer.samsung.com/tv/design . Accessed on 201910-07. [28] T. C. Suzana Benge. Televis ˜ ao digital terrestre. URL http://www.img.lx.it.pt/∼fp/cav/ ano2012 2013/Trabalhos MEEC 2012 2013/Artigo9/html/content/TDT.pdf . Accessed on 2019-01-06. [29] J. E. D. Valle and H. Perez. Module: About microsoft and digital lifestyle. URL http://download.microsoft.com/download/3/4/E/ 34ED7E22-516B-41F0-BD49-92CFC037B29D/msdn About Microsoft Digital Lifestyle. pdf. page 21, Accessed on 2019-01-07. A CONFIGURAC¸ ˜ A O P ´ AGINA INICIAL DA APLICAC¸ ˜ A O 1 – AnimationImageId: null BackgroundColor: ”rgba(255, 255, 255, 1)” BackgroundImageId: ”3cc79355-4531-e911-8396-005056a8e1a9” CounterLeft: 375 CounterPlaceholderFormat: ”–0˝ –of˝ –1˝” CounterTextColor: ”rgba(134, 176, 206, 1)” CounterTextFontStyle: ”CoText28” CounterTop: 300 CursorGlowImageId: null CursorImageId: null DownArrowImageHeight: 64 DownArrowImageId: ”3fc79355-4531-e911-8396-005056a8e1a9” DownArrowImageWidth: 70 DownArrowLeft: 640 DownArrowTop: 580 GridLeft: 0 GridTop: 370 IconHeight: 57 IconImageId: ”3dc79355-4531-e911-8396-005056a8e1a9” IconLeft: 110 IconTop: 280 IconWidth: 57 Id: 329 IsHomePage: true ItemBackgroundColor: ”rgba(255, 255, 255, 0)” ItemBackgroundColorGlow: ”rgba(134, 176, 206, 0.85)” ItemBackgroundColorSelected: ”rgba(134, 176, 206, 1)” ItemHeight: 62 71 72 ItemIconHeight: 50 ItemIconLeft: 400 ItemIconTop: 3 ItemIconWidth: 50 ItemTextColor: ”rgba(134, 176, 206, 1)” ItemTextColorSelected: ”rgba(255, 255, 255, 1)” ItemTextFontStyle: ”CoText26” ItemTextFontStyleSelected: ”CoText26” ItemTextLeft: 480 ItemTextTop: 20 ItemTextWidth: 700 ItemTypeVideoOverlayImageId: null ItemWidth: 1280 LeftArrowImageId: null NumberOfVisibleElements: 3 SelectorSelectedImageId: null SelectorUnselectedImageId: null SliderBarImageId: null SliderSelectorImageId: null SplashScreenImageId: null Title: ”CATEGORIAS” TitleLeft: 180 TitleTextColor: ”rgba(134, 176, 206, 1)” TitleTextFontStyle: ”CoText28” TitleTop: 300 Type: ”MCSHOME” UpArrowImageHeight: 64 UpArrowImageId: ”3ec79355-4531-e911-8396-005056a8e1a9” UpArrowImageWidth: 70 UpArrowLeft: 640 UpArrowTop: 290 ˝ B CONFIGURAC¸ ˜ A O P ´ AGINA INICIAL DA APLICAC¸ ˜ A O 2 – AnimationImageId: null, BackgroundColor: ”rgba(0, 0, 0, 1)”, BackgroundImageId: ”3b80ba87-35d4-e611-8ff4-005056a8e1a9”, CursorGlowImageId: null, CursorHeight: 180, CursorImageId: ”9fee27ba-e1ac-e611-95ec-005056a8e1a9”, CursorLeft: -15, CursorTop: -10, CursorWidth: 240, DownArrowImageHeight: 21, DownArrowImageId: ”5c2773ce-e1ac-e611-95ec-005056a8e1a9”, DownArrowImageWidth: 26, DownArrowLeft: 117, DownArrowTop: 308, GridAreaItemHeight: 30, GridAreaItemSpacing: 10, GridAreaItemTextColor: ”rgba(200, 200, 200, 1)”, GridAreaItemTextFontStyle: ”CoText20”, GridAreaItemWidth: 300, GridAreaLeft: 156, GridAreaTop: 125, GridLeft: 150, GridTop: 355, IconImageId: null, Id: 44, IsHomePage: true, ItemBorderColor: ”rgba(0, 255, 0, 1)”, ItemBorderSize: 2, 73