Schrijven van een graf ische gebruikersomgeving voor het MIA-raamwerk

Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout

Schrijven van een graf ische gebruikersomgeving voor het MIA-raamwerk door Barbara Van De Keer

Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. D. De Schrijver

Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica

Academiejaar 2004–2005

Dankwoord Graag wil ik Davy De Schrijver bedanken voor het lezen en corrigeren van de tekst en de hulp bij de presentaties, een betere begeleider had ik me niet kunnen wensen. Sven Rousseaux, mijn promotor bij de VRT, wens ik te bedanken voor deze interessante opdracht en de vele tips en verduidelijkingen. De opdracht was zwaar maar lag volkomen binnen mijn interessesfeer. Ik heb er dan ook (meestal) met plezier aan gewerkt. Jeroen Aert bedank ik voor de hulpvolle gesprekken en de vele verduidelijkingen van het MIA-raamwerk. Mijn promotor, Rik Van De Walle, wens ik te bedanken voor het beoordelen van de proefpresentaties en de feedback erop. Deze was van ontelbaar belang tijdens de eindpresentatie. Steun tijdens de moeilijke momenten kreeg ik van Christophe De Moor en mijn ouders, Gaston Van De Keer en Claudine De Kerpel. Christophe wens ik ook te bedanken voor de hulp met de afbeeldingen.

i

Schrijven van een graf ische gebruikersomgeving voor het MIA-raamwerk door Barbara Van De Keer Afstudeerwerk ingediend tot het behalen van de graad van Licentiaat in de Informatica Academiejaar 2004–2005 Universiteit Gent Faculteit Toegepaste Wetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. J. Van Campenhout Promotor: prof. dr. ir. R. Van de Walle Thesisbegeleider: lic. D. De Schrijver Samenvatting Deze tekst is het naslagwerk bij het programma dat in het kader van deze thesis geschreven werd. De opdracht voor de thesis omvatte het schrijven van een grafische gebruikersomgeving voor het ‘MHP Interactive Application’-raamwerk (MIA-raamwerk). Het MIA-raamwerk is een raamwerk ontwikkeld door de VRT voor het ontwikkelen van applicaties voor interactieve Digitale Televisie (iDTV). Dit raamwerk vertaalt MIAapplicaties in eXtensible Markup Language (XML) naar ‘Multimedia Home Platforms’applicaties (MHP-applicaties). De grafische gebruikersomgeving die geschreven werd in het kader van deze thesis, biedt de mogelijkheid om deze MIA-applicaties op een grafische manier op te bouwen. Het heeft als doel de ontwikkelaar van MIA-applicaties los te koppelen van de onderliggende technologie. Dit naslagwerk heeft ten eerste als doel het situeren van MIA in het domein van (interactieve) digitale televisie. Ten tweede worden de ontwerpsbeslissingen verduidelijkt. Tenslotte biedt het een gebruikersgids bij het programma. Trefwoorden: VRT, iDTV, MIA

ii

Inhoudsopgave 1 Inleiding 1.1 Probleemstelling . . . . . . . . 1.2 Overzicht . . . . . . . . . . . . 1.2.1 Het beoogde doel . . . . 1.2.2 Structuur . . . . . . . . 1.2.3 Gebruikte methodologie

. . . . .

2 Inleiding tot digitale televisie 2.1 Huidige situatie: analoge televisie 2.2 Digitale televisie . . . . . . . . . 2.3 Hoge Definitie Digitale Televisie . 2.4 Interactieve digitale televisie . . . 3 Multimedia Home Platform 3.1 Inleiding . . . . . . . . . . 3.2 De MHP-specificatie . . . 3.2.1 Wat biedt MHP? . 3.2.2 Profielen . . . . . . 3.2.3 MHP-applicatie . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

1 1 2 2 3 3

. . . .

4 4 5 5 6

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7 7 8 8 8 9

4 MHP Interactive Application 4.1 Inleiding . . . . . . . . . . . . . 4.2 Opbouw van een MIA-applicatie 4.2.1 Layout XML . . . . . . 4.2.2 Content XML . . . . . . 4.2.3 Applicatie XML . . . . . 4.3 Beschikbare componenten . . . 4.3.1 Logische componenten . 4.3.2 Visuele componenten . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

11 11 12 13 20 22 22 22 23

. . . . .

. . . . .

5 Ontwerpbespreking 24 5.1 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2 Specificatie-XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 iii

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

25 25 30 31 31 32 34 35

6 Gebruikersgids 6.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . 6.2 Vereisten . . . . . . . . . . . . . . . . . . . . . . 6.3 Statisch versus dynamisch . . . . . . . . . . . . 6.4 Basic page . . . . . . . . . . . . . . . . . . . . . 6.5 Aanmaken van een pagina . . . . . . . . . . . . 6.6 Component aanmaken . . . . . . . . . . . . . . 6.7 Component aanpassen . . . . . . . . . . . . . . 6.7.1 Container . . . . . . . . . . . . . . . . . 6.8 Gedrag . . . . . . . . . . . . . . . . . . . . . . . 6.8.1 Gebeurtenis toevoegen aan een toestand 6.8.2 Actie toevoegen aan een toestand . . . . 6.8.3 Post acties toevoegen aan een toestand . 6.9 Selectie . . . . . . . . . . . . . . . . . . . . . . . 6.10 Viewmode veranderen . . . . . . . . . . . . . . 6.11 Export . . . . . . . . . . . . . . . . . . . . . . . 6.12 Import . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

37 37 37 38 38 38 39 40 41 42 42 43 44 44 44 45 45

5.3

5.2.1 ‘comment’-tag . . . . . . . . . 5.2.2 Eigenschappen . . . . . . . . 5.2.3 Acties . . . . . . . . . . . . . Structuur . . . . . . . . . . . . . . . 5.3.1 Parsen van specificatie-XML . 5.3.2 Applicatie . . . . . . . . . . . 5.3.3 Applicatielezer . . . . . . . . 5.3.4 Grafische gebruikersomgeving

Bibliografie

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

52

iv

Lijst van figuren 3.1 3.2 3.3

Generieke interface tussen applicaties en terminals . . . . . . . . . . . . . . 8 MHP-applicatiemanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Levenscyclus van een Xlet . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1 4.2

Het MIA-raamwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Gebruik van templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.1 5.2 5.3

Structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17

Nieuwe pagina . . . . . . . . . . . . . . . . . . . . . . Nieuwe pagina - dialoogvenster . . . . . . . . . . . . Programma na toevoegen van pagina . . . . . . . . . Aanmaken van component . . . . . . . . . . . . . . . Component is toegevoegd . . . . . . . . . . . . . . . Wijzigen van de achtergrondkleur van de component Kleurkiezer . . . . . . . . . . . . . . . . . . . . . . . Bewerken component . . . . . . . . . . . . . . . . . . Component popup . . . . . . . . . . . . . . . . . . . Gedrag . . . . . . . . . . . . . . . . . . . . . . . . . . Een gebeurtenis aan een toestand hangen . . . . . . . Linkerpaneel voor een toestand . . . . . . . . . . . . Actie toevoegen aan een toestand . . . . . . . . . . . Linkerpaneel na toevoegen van een actie . . . . . . . Selecteren . . . . . . . . . . . . . . . . . . . . . . . . Verander de viewmode . . . . . . . . . . . . . . . . . Dynamische eigenschappen . . . . . . . . . . . . . . .

v

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

39 40 41 42 43 44 45 46 47 47 48 48 49 49 50 50 51

Hoofdstuk 1 Inleiding 1.1

Probleemstelling

Televisienetten, kabelmaatschappijen en zelfs telefoonmaatschappijen zijn momenteel volop bezig met hun eigen invulling te geven aan het begrip ’interactive Digitale TeleVisie’, of kortweg iDTV. Deze maatschappijen hopen dat dit binnenkort niet meer uit de huiskamer zal weg te denken zijn. Zo is ook de Vlaamse Radio en Televisie maatschappij (VRT) hier actief mee bezig. Een veelgebruikte standaard voor iDTV is het Multimedia Home Platform (MHP). De MHP-specificatie werd ontwikkeld door het Digital Video Broadcasting consortium (DVB). Dit is een samenwerkingsverbond van broadcasters, ontwikkelaars, netwerkoperatoren en software-ontwikkelaars, opgestart om wereldwijde standaarden te ontwikkelen voor digitale televisie en data services [1]. Interactieve digitale televisie kenmerkt twee communicatiekanalen, ´e´en van de broadcaster naar de terminal van de ontvanger (de kijker thuis dus), dit is het traditionele broadcastkanaal, en ´e´en interactief kanaal dat typisch communiceert met het Internet Protocol (IP). Via het eerste kanaal kan de broadcaster typisch video, audio en applicaties versturen naar de terminals. Een dergelijke applicatie bestaat uit verschillende pagina’s (te vergelijken met een teletekstpagina of een html-pagina) en beschrijft het gedrag van de applicatie. Met het gedrag bedoelen we bijvoorbeeld de actie die gebeurt wanneer de kijker op de rode knop van de afstandsbediening duwt. Het interactief kanaal (of terugkeerkanaal) wordt door de kijker gebruikt om bijvoorbeeld tijdens een kwis zijn antwoord terug te sturen. In sommige gevallen wordt dit kanaal ook voor het ontvangen van applicaties gebruikt [5]. 1

MHP draait op een Java Virtuele Machine (JVM). De specificatie beschrijft de bibliotheken die voorhanden zijn om applicaties voor iDTV mee te ontwikkelen. Ze zorgt ervoor dat terminals die MHP implementeren applicaties kunnen begrijpen van verschillende broadcasters, zolang de broadcasters de MHP-specificatie volgen. De terminal is dan bijvoorbeeld een settopbox of PC. Er draait een implementatie van het MHP-raamwerk op de terminal die de MHP-applicaties, afkomstig van de broadcaster, verwerkt en dan analoog of digitaal naar het televisietoestel stuurt. De ontwikkelaar van de settopbox moet het MHP-raamwerk implementeren naar eigen goeddunken. De VRT is hierin een stap verder gegaan door een extra laag van abstractie toe te voegen. Zij hebben een raamwerk ontwikkeld, genaamd MHP Interactive Application (MIA) dat, net zoals een MHP-applicatie, de MHP-API volgt. Dit raamwerk wordt dan eenmalig naar de settopbox van de ontvanger verstuurd. Het maakt het mogelijk om een applicatie te defini¨eren in eXtensible Markup Language (XML) in plaats van in Java. Het MIA-raamwerk vertaalt de XML-bestanden in een MHP-applicatie. De voordelen hiervan zijn een grotere personalisatie van de applicaties en de effici¨entie waarmee applicaties geschreven worden. Het probleem met deze nieuwe laag is echter dat, desondanks we nu XML kunnen schrijven in plaats van Java, applicaties nog steeds niet kunnen opgebouwd worden door mensen met een beperkte kennis van het MIA-raamwerk. Dit is waar deze thesis met behulp van een grafische gebruikersomgeving hulp komt bieden. Deze thesis wil bouwers van MIA-applicaties voor digitale televisie binnen de VRT ontlasten van de XML waar ze nu mee moeten omgaan. Er wordt daartoe een programma geschreven waarmee een applicatie voor digitale televisie kan opgebouwd worden zonder de gebruiker te moeten confronteren met XML. Dit wordt mogelijk gemaakt door de applicatie reeds visueel weer te geven zoals dit op het televisiescherm zou gebeuren. De gebruiker kan dan visueel componenten op het scherm toevoegen en eigenschappen voor deze componenten instellen. Ook het gedrag van de applicatie kan volledig visueel gedefinieerd worden.

1.2 1.2.1

Overzicht Het beoogde doel

Het doel van dit boek is in eerste instantie om de lezer inzicht te verschaffen in de wens van de VRT voor dit programma en de redenen van hun stap naar digitale televisie. In 2

tweede instantie wil ik de lezer een zicht werpen op hoe het probleem werd aangepakt. In derde instantie biedt dit boek een gebruikersgids voor het programma.

1.2.2

Structuur

Dit boek zal beginnen met in hoofdstuk 2 een inleiding te geven op interactieve digitale televisie. Daarin zal de sprong van analoge naar (interactieve) digitale televisie worden uitgelegd en de mogelijkheden die deze sprong teweeg brengt worden opgesomd. Hoofdstuk 3 zal de MHP-specificatie belichten. In hoofdstuk 4 wordt uitgelegd waarom de VRT het MIA-raamwerk ontwikkeld heeft en zal dit raamwerk verder worden toegelicht. Vervolgens zal in hoofdstuk 5 het doel van het ontwikkelde programma uitgelegd worden en wordt de manier waarop dit probleem werd aangepakt uit de doeken gedaan. Ook de beperkingen van het programma zullen aan bod komen. Tenslotte wordt in hoofdstuk 6 het resultaat voorgesteld in de vorm van een een gids die de lezer inleidt in het gebruik van het programma en de mogelijkheden ervan.

1.2.3

Gebruikte methodologie

Voor de theoretische hoofdstukken werden het internet, de MIA-documentatie en de communicatie met de VRT tijdens de implementatie van het programma als bron van informatie gebruikt. In het praktische hoofdstuk dat de implementatie van het ontwikkelde programma behandelt, worden Unified Modeling Language-schema’s (UML) gebruikt om het klassenontwerp te verduidelijken. In het laatste hoofdstuk dat dienst doet als gebruikersgids wordt ondermeer gebruikgemaakt van screenshots om de mogelijkheden en het gebruik van het programma weer te geven.

3

Hoofdstuk 2 Inleiding tot digitale televisie 2.1

Huidige situatie: analoge televisie

Voorlopig wordt in de meeste huiskamers nog naar analoge televisie gekeken. Deze komt binnen als een golf via de kabel of de antenne. Elk net heeft dan zijn eigen frequentie. Het probleem met deze techniek is dat er storingen kunnen optreden. Dit kan de kijker waarnemen onder ruis of sneeuw. Daarom moeten de frequenties voldoende ver van elkaar liggen om niet te interfereren. Dit heeft als gevolg dat veel plaats op de kabel verloren gaat, zo kunnen er slechts een 30-tal analoge kanalen op de kabel geplaatst worden. De belangrijkste nadelen van analoge televisie zijn ondermeer dat de communicatie slechts in ´e´en richting verloopt. Om interactiviteit te cre¨eren is het daardoor nodig om bijvoorbeeld telefoon of sms in te schakelen. Ook moeten de kijkers altijd op het juiste uur voor de buis zitten voor een bepaalde film of om hun lievelingsfeuilleton te zien. Er is dus geen mogelijkheid om het programma op te vragen wanneer je het zelf wil, tenzij door het op te nemen op Video Home System (VHS) of Digital Versatile Disc (DVD). Nog een nadeel zijn de teletekstpagina’s die vaak voor frustratie zorgen door de vaak lange wachttijden. Ook is de beeldresolutie behoorlijk laag, in onze streken wordt de ’Phase Alternating Line’-standaard (PAL) gebruikt die een resolutie heeft van 720x576 pixels. De stap naar digitale televisie zal veel van deze problemen oplossen.

4

2.2

Digitale televisie

Digitale televisie kan verstuurd worden over de kabel (DVB-Cable of DVB-C), langs de ether (DVB-Terrestrial of DVB-T) of via de satelliet (DVB-Satellite of DVB-S). Sinds 31 mei 2004 zendt de VRT reeds TV1 (nu ´e´en) en ketnet/canvas gratis digitaal uit langs de ether. Ook de radiostations van VRT kunnen langs deze weg ontvangen worden. Je hebt echter wel een settopbox nodig die het digitale signaal opvangt en vertaalt naar een analoog signaal dat naar huidige toestellen kan gestuurd worden. De basisstructuur van DVB-T is de transportstroom. Deze bestaat uit verschillende substromen. Een dergelijke substroom bevat informatie van ´e´en bepaald type, bijvoorbeeld video, audio of teletekst. Een radio- of tv-net komt dan overeen met een combinatie van zulke substromen. De benodigdheden zijn een antenne en een DVB-T set top box. Door compressie wordt bandbreedte bespaard waardoor we nu een mogelijkheid krijgen tot het ontvangen van 200 zenders. Dit vergeleken met de dertig bij analoge televisie is dit uiteraard een grote vooruitgang. Voor de beeldcompressie wordt de MPEG-2-standaard gebruikt. Dit is dezelfde compressie als deze van een DVD (met dit verschil dat DVD gebruikmaakt van programmastromen in plaats van transportstromen). Voor het geluid wordt MPEG-1 layer 2 (Musicam) gebruikt. Deze compressie maakt gebruik van de tekortkomingen van het oor door frequenties weg te laten die voor de mens toch niet hoorbaar zijn.

2.3

Hoge Definitie Digitale Televisie

Deze standaard gaat nog een stap verder dan gewone digitale televisie. Het beeld van Hoge Definitie Digitale Televisie (HDTV) bevat vijf maal meer detail dan een DVD. Er zijn twee resoluties mogelijk, namelijk 720p = 1280x720 (progressive genoemd) en 1080i = 1920x1080 (interlaced genoemd). De geluidskwaliteit is dezelfde als in de bioscoop: 5.1 Dolby Digital. Voor HDTV moeten programma’s opgenomen worden met speciale camera’s. Deze camera’s worden intussen reeds gebruikt, maar het zal nog minstens tot 2010 duren vooraleer VRT in HDTV zal uitzenden.

5

2.4

Interactieve digitale televisie

Interactieve digitale televisie, of kortweg iDTV is een extentie op digitale televisie. Het heeft dus alle mogelijkheden van digitale televisie, maar voegt er nog de factor interactiviteit aan toe. De Europese standaard hiervoor is MHP (Multimedia Home Platform). Bij iDTV hebben we een terugkeerkanaal, namelijk van de kijker naar de broadcaster. Het voegt mogelijkheden toe aan digitale televisie zoals stemmen, meespelen met spelletjes, programma’s op aanvraag, email, sms, snelle teletekst, tv-bankieren, winkelen,... [5]

6

Hoofdstuk 3 Multimedia Home Platform 3.1

Inleiding

Het Multimedia Home Platform (MHP) is een open standaard voor interactieve tvmiddleware. Het werd ontwikkeld door het Digital Video Broadcasting consortium. Dit consortium werd opgericht in 1993 voor het ontwikkelen van standaarden voor digitale televisie. Deze standaard wordt vooral in Europa gebruikt. MHP is niet de enige standaard voor interactieve tv-middleware, andere zijn bijvoorbeeld OpenTV, Liberate en OCAP (de Amerikaanse standaard). MHP kan door iedereen vrij ge¨ımplementeerd worden en MHP-applicaties worden in Java of HyperText Markup Language (HTML) geschreven. Dus platformonafhankelijk. Een settopbox die MHP ondersteunt zal een implementatie van MHP draaien. DVB biedt enkel de volledige specificatie en geen implementatie. Ontwikkelaars van settopboxen moeten die specificatie zelf implementeren. Een settopbox die MHP ondersteunt kan dan applicaties begrijpen die ze ontvangen van de broadcaster, zolang deze applicaties de MHP-specificatie volgen. Dit zorgt er dus voor dat broadcasters en ontwikkelaars van settopboxen onafhankelijk worden van elkaar, het enige waar ze rekening moeten mee moeten houden is de MHP-specificatie die ze volgen. Figuur 3.1 geeft dit grafisch weer. Broadcasters zijn dus niet verantwoordelijk voor de terminal die bij de kijker thuis staat, en de kijker kan met deze enkele terminal aangesloten zijn bij verschillende broadcasters. Dit voorkomt een monopoliepositie van ´e´en enkele broadcaster. Enkele voorbeelden van MHP-applicaties zijn de Elektronische ProgrammaGids (EPG), informatieservices (superteletekst), e-commerce en applicaties die gesynchroniseerd zijn 7

Figuur 3.1: Generieke interface tussen applicaties en terminals

met het tv-beeld, zoals bijvoorbeeld scoreborden tijdens sportwedstrijden.

3.2 3.2.1

De MHP-specificatie Wat biedt MHP?

De MHP-specificatie biedt een model voor applicaties. Ze beschrijft hoe applicaties zich gedragen, hoe een broadcaster kan laten weten dat een applicatie beschikbaar is en hoe een ontvanger de bestanden kan ophalen die nodig zijn om de applicatie te draaien. De bestanden die beschikbaar zijn, worden in een carousel geplaatst (dit is een DSM-CC object carousel). De terminal moet dus telkens wachten tot het juiste bestand op de carousel voorbijkomt om het binnen te kunnen halen.

3.2.2

Profielen

De MHP-specificatie biedt verschillende profielen. Er is het ‘enhanced broadcast’-profiel, het ‘interactive TV’-profiel en het ‘internet access’-profiel. De applicatie ontwikkelaar kan kiezen voor welk profiel hij een applicatie schrijft. Het enhanced broadcast-profiel biedt digitale broadcast van audio en video en maakt het mogelijk om applicaties te downloaden via het broadcastkanaal. Dit biedt enkel een lokale interactiviteit (zoals spelletjes en digitale teletekst), er is geen terugkeerkanaal. Het interaction broadcast-profiel biedt interactieve services en heeft dus een terugkeerkanaal. Dit is een standaard IP-kanaal. Applicaties kunnen nu niet alleen gedownload 8

worden via het broadcastkanaal maar ook via het terugkeerkanaal. Het internet access-profiel biedt internet services. Hiervoor is een settopbox nodig met meer processorkracht en geheugen dan voor de eerste twee profielen. De eerste twee profielen zitten vervat in de MHP 1.0 specificatie, het laatste in de MHP 1.1 specificatie. De ontwikkelaars van settopboxen moeten zelf kiezen welk profiel ze zullen ondersteunen.

3.2.3

MHP-applicatie

Er zijn twee types van applicaties. Enerzijds zijn er de DVB-J-applicaties. Deze zijn volledig geschreven in Java en worden Xlets genoemd. Anderzijds zijn er de DVB-HTMLapplicaties. Dit zijn HTML-pagina’s met Javascript voor de interactiviteit. DVB-HTML is enkel gedefinieerd in de MHP 1.1 specificatie. Dit is echter buiten de grenzen van deze thesis en zal dus verder niet behandeld worden. Een Xlet is vergelijkbaar met een Java-applet. De levenscyclus van zowel Xlets als Javaapplets wordt gecontroleerd door een applicatiemanager. Figuur 3.2 kan hierbij verduidelijking brengen. Een Xlet moet altijd de Xlet-interface uit het @I javax.tv.xlet package implementeren. Volgende methodes moeten hierbij ge¨ımplementeerd worden:

Figuur 3.2: MHP-applicatiemanager

• initXlet(XletContext); • startXlet(); • pauseXlet(); • destroyXlet(); Deze methodes worden gebruikt door de applicatiemanager om de levenscyclus te regelen van de Xlets. De manager werkt als een toestandsautomaat. De levenscyclus van een Xlet wordt weergegeven in Figuur 3.3. 9

Figuur 3.3: Levenscyclus van een Xlet

Een applicatiemanager kan pas een Xlet starten als volgende voorwaarden voldaan zijn: de terminal moet van het bestaan van de applicatie weten, de gebruiker moet permissie hebben om de applicatie te starten op dat moment en alle bestanden die de applicatie nodig heeft moeten beschikbaar zijn. Een Xlet komt in de ‘loaded’-staat wanneer zijn constructor wordt aangeroepen en deze geen fout teruggeeft. In het andere geval komt de Xlet direct in de ‘destroyed’-staat. Eens de Xlet in de ’loaded’-staat is, kan de applicatie manager hem in de ‘paused’-staat brengen door initXlet() aan te roepen. De initXlet()-methode kan echter een XletStateChangeException veroorzaken. Dan blijft de Xlet in de ‘loaded’-staat en is de enige staat waar hij nog in terecht kan, de ‘destroyed’-staat. Een Xlet kan in de ‘paused’-staat komen zoals eerder gezegd door er initXlet() op aan te roepen. Vanin de ‘active’-staat kan het in ‘paused’ komen door zelf XletContext.notifyPaused() aan te roepen of doordat de applicatie manager er pauseXlet() op aanroept. De ‘active’-staat wordt bereikt door in de ‘paused’-staat startXlet() op te roepen. De ‘destroyed’-staat kan vanuit alle staten bereikt worden door destroyXlet() op de Xlet aan te roepen of door zelf XletContext.notifyDestroyed() aan te roepen. De staat van een Xlet in zijn levenscyclus kan dus veranderd worden door de applicatie manager en door zichzelf. Wanneer het de applicatie manager is die de staatverandering veroorzaakt, zal dit gebeuren bij signalering door de broadcaster of wanneer de gebruiker zelf een andere applicatie kiest. [2] [4].

10

Hoofdstuk 4 MHP Interactive Application 4.1

Inleiding

VRT maakt deel uit van het consortium Vlaanderen Interactief dat de belangrijkste spelers op de Vlaamse mediamarkt samenbrengt. De gezamenlijke doelstelling is de realisatie van een digitaal MHP gebaseerd televisieplatform. In het kader van dit project ontwikkelt de VRT het MHP Interactive Application-raamwerk (MIA) dat ons toelaat om op een vereenvoudigde manier MHP-applicaties te bouwen. [3] MIA is een extra abstractielaag bovenop MHP. Het zorgt er voor dat applicaties niet in Java moeten geschreven worden, zoals gewone MHP-applicaties, maar in XML. Het voordeel hiervan is enerzijds effici¨entie in het schrijven en anderzijds zorgt deze aanpak voor een gepersonaliseerd uitzicht. Het MIA-raamwerk omvat: • een metaformaat (XML) die het mogelijk maakt om applicaties declaratief te defini¨eren. • de MHP-applicatie (MIA Framework engine) die nodig is om dit metaformaat te vertalen naar een werkende applicatie. • Een reeks MIA-componenten (visuele/niet-visuele componenten) die ieder voorzien in een welbepaalde functionaliteit (bv. knop, tekst, afbeelding, ...). Het MIA-raamwerk is een MHP-applicatie op zichzelf en implementeert dus de Xletinterface. Zoals reeds gezegd wordt een MHP-applicatie in Java geschreven, dus ook het MIA-raamwerk. Wanneer de initXlet()-methode uit de Xlet-implementatieklasse van 11

MIA wordt opgeroepen, zal de framework.xml geladen worden. Dit XML-bestand bevat een link naar de ‘basisapplicatie’. De basisapplicatie is doorgaans een menu waaruit dan kan gekozen worden voor de verschillende MIA-applicaties die voorhanden zijn. De MIA Framework Engine zal deze applicatie, geschreven in XML, parsen en omzetten naar een werkende MHP-applicatie in Java. Het MIA-raamwerk wordt eenmalig naar de settopbox verzonden. De beschikbare MIAapplicaties worden op de carousel geplaatst. Zie figuur 4.1

Figuur 4.1: Het MIA-raamwerk

4.2

Opbouw van een MIA-applicatie

Een MIA-applicatie is opgebouwd uit ´e´en applicatie-XML-bestand en verschillende contenten layout-XML-bestanden. Het applicatie-XML-bestand is de wortel van de applicatie. Een content- en layout-XML-bestand beschrijven samen een pagina, vergelijkbaar met een HTML-pagina. De belangrijkste functie van de applicatie-XML is het systeem vertellen welke pagina als eerste op het scherm moet geplaatst worden. In het layout-XML-bestand wordt beschreven welke componenten op het scherm zichtbaar moeten zijn. Dit zijn MIA-componenten uit het raamwerk zoals een tekstcomponent, een

12

knop, ... Aan deze componenten worden eigenschappen meegegeven zoals de co¨ordinaten of de kleur. De layout-XML beschrijft de layout van de pagina. Een pagina bevat ook een gedrag. Dit wordt om het aantal bestanden te beperken ook beschreven in het layout-XML-bestand. Het gedrag beschrijft welke acties moeten ondernomen worden bij externe gebeurtenissen, zoals het indrukken van een knop op de afstandsbediening. Er moet bijvoorbeeld bij het drukken op de gele knop een nieuwe pagina op het scherm getoond worden. Het content-XML-bestand is een uitbreiding van het layout-XML-bestand. Het kan voor elke component die aangemaakt werd in de layout-XML extra eigenschappen instellen bovenop deze die reeds ingesteld werden in de layout-XML. In de layout-XML kunnen bijvoorbeeld alle coordinaten en kleuren ingesteld worden voor de componenten. In de content-XML kan dan de tekst en afbeeldingen die op de componenten komen worden ingesteld. We kunnen de eigenschappen in de content-XML eigenlijk zien als dynamische eigenschappen en de eigenschappen in de layout-XML als statische eigenschappen. Er is echter niets dat de ontwikkelaar van de applicatie verbiedt om alle eigenschappen in de layout-XML of in de content-XML te schrijven. Er is enkel een logisch verschil dat niet noodzakelijk gerespecteerd moet worden. Het layout-XML-bestand kan hergebruikt worden door verschillende content-XML-bestanden. De layout-XML is dan een soort van template dat kan opgevuld worden door de content-XML.

4.2.1

Layout XML

De layout is opgebouwd uit drie lagen: • achtergrondaag: een afbeelding (een MPEG-2-I-frame) of een kleur. • videolaag: het videovenster. • grafische laag: de laag die de visuele componenten bevat. De volgorde van de lagen is respectievelijk zoals hierboven weergegeven met de backgroundlaag als onderste. De layout-XML is als volgt samengesteld: < layout / > < background / >

13

< video / > < logic / > < graphics / > < behavior / >

De video-, background en graphics-tag komen overeen met de lagen die hierboven genoemd werden. De logics-tag bevat logische componenten. Deze zijn niet zichtbaar op het scherm maar vervullen een bepaalde functie, zoals bijvoorbeeld het verzenden van informatie. In de behavior-tag wordt het gedrag beschreven van de pagina, zoals de acties die ondernomen moeten worden bij het drukken op een knop van de afstandsbediening. We zullen nu elk van deze tags uitgebreider bespreken. Background < background > < color > < image / >

In de colorsectie komen de rood-, groen-, blauw- en alpha-waarden die samen de kleur beschrijven die als achtergrond wordt gebruikt. De alpha-waarde komt overeen met de transparantie. In de imagesectie kan een URL naar een MPEG-bestand op de carousel worden ingevuld. Dit is MPEG-video bestaande ´e´en I-frame. De beide deelsecties zijn optioneel, maar ze kunnen niet samen ingesteld worden. Video < video > < use / > <x / > < width / >

14

< height / > < videosource / > < audiosource / >

In de use-tag moet de waarde ’true’ of ’false’ komen. Dit beschrijft of er een videovenster moet getoond worden of niet. De x-, y-, width- en height-tags beschrijven de locatie en de grootte van het videovenster. In de videosource- en audiosource-tags komen de video- en audio-stream die zichtbaar en hoorbaar zijn. Indien ze niet worden ingevuld wordt de video en audio gebruikt die op dat moment gebroadcast wordt. De use-tag is verplicht, de rest van de tags zijn optioneel. Indien ze niet worden ingevuld wordt standaard het volledige scherm gebruikt voor het huidige gebroadcaste signaal. Logics < logic > < objects > < object > < name / > < type / > < properties / >

De logic-tag bevat logische componenten. Deze componenten zullen niet zichtbaar zijn op het scherm, maar vervullen een functie, bijvoorbeeld het doorsturen van het antwoord van de kijker tijdens een kwis. De beschrijving van een logische component bevindt zich in de object-tag. In de name-tag komt de naam die de ontwikkelaar kiest voor de component. De type-tag bevat het type van de component. Dit type komt overeen met het bronbestand van de component binnen het MIA-raamwerk. In de properties-tag komen de eigenschappen voor de component. Graphics < graphics > < objects / > < looks / >

15

In de objects-tag komen de visuele componenten zoals tekst of een knop. < objects > < object > < name / > < type / > < properties / >

De name-, type-, en properties-tags hebben dezelfde functie als bij de logische componenten. De z-tag bevat de z-orde van de component. Dit bepaalt de diepte van de component en wordt gebruikt wanneer twee componenten elkaar overlappen. De component met de hoogste z-waarde wordt dan bovenop de andere getekend. Een visuele component kan ook een container zijn. Dit betekent dat hij andere visuele componenten kan bevatten. In dat geval komt er onder de properties-tag nogmaals een objects-tag met daarin de beschrijvingen van de componenten die in de container vervat zitten. Componenten kunnen aan een container toegevoegd worden op basis van een template, of zonder template. Zonder template ziet de objects-sectie er net uit zoals deze hierboven. Wat volgt is een voorbeeld van een container met template-gebaseerde componenten:

16

17

In de template-tag wordt een component beschreven dat werkt als template voor alle objecten in de container die als type de naam van het template hebben. Dit geeft het resultaat weergegeven in Figuur 4.2

Figuur 4.2: Gebruik van templates

Hetzelfde resultaat kan bekomen worden zonder het gebruik van templates door gewoon tweemaal een VRTButton-component te defini¨eren met dezelfde look. Het templatemechanisme wordt dus in principe enkel gebruikt voor tekstbesparing. Elke visuele component moet geassocieerd worden aan een look uit de looks-tag. Een look beschrijft het uitzicht van de component, zoals de achtergrondkleur, de tekstalignering en dergelijke meer. < looks > < look > < name / > < type / > < properties / >

18

Opnieuw vervullen de name-, type- en properties-tag dezelfde functies. De waarde in de name-tag van de lookbeschrijving wordt gebruikt in de beschrijving van de visuele component als verwijzing naar de look die met deze component geassocieerd is. Dit wordt ingesteld als een eigenschap in de properties-tag: < setLook > < look > naam van de look

Behavior < behavior > < default / > < global / > < states / >

Deze sectie beschrijft het gedrag van de pagina. Dit gedrag wordt beschreven als een ‘toestandsautomaat’. Een toestandsautomaat bevat een aantal toestanden die in elkaar kunnen overgaan bij bepaalde gebeurtenissen. De toestandsautomaat heeft dus altijd een ‘huidige toestand’. Deze is bij de start altijd de ‘default’ toestand. De ‘global’ toestand is een toestand die altijd van toepassing is, onafhankelijk van de huidige toestand. Een toestand wordt beschreven door zijn naam, een lijst van acties, een lijst van postacties en een lijst van gebeurtenissen: < states > < state > < name / > < actions / > < postactions / > < events / >

Acties worden uitgevoerd wanneer de toestandsautomaat de toestand als huidige instelt. Post-acties worden uitgevoerd bij het verlaten van de toestand. Een actie, zowel in de actions- als de postactions-tag, heeft het volgende schema:

19

< actions > < action > < object / > < method / > < params / >

In de object-tag komt het object waarop de actie gebeurt. Dit kan de naam van een logische component, visuele component of look bevatten, maar kan ook inwerken op het systeem, bijvoorbeeld om een nieuwe pagina op het scherm te brengen. In dat geval wordt in de object-tag ‘system’ ingevuld. In de method-tag komt de methode die uitgevoerd moet worden op het object. Dit kan een eigenschap zijn, of bijvoorbeeld ’setPage’ als het object ‘system’ is. De params-tag bevat dan de parameters die doorgegeven worden aan de methode. Events beschrijven de gebeurtenissen waarop de state zal reageren. De reactie bestaat uit het overgaan naar een andere state. < events > < event > < type / > < value / > < state / >

In de type-tag komt het type van de event. Een voorbeeld hiervan is ‘key’. Dit beschrijft het drukken op een knop van de afstandsbediening. De value-tag bevat dan bijvoorbeeld ‘VK COLORED KEY 2’ bevatten, wat de gele knop voorstelt. In de state-tag komt de naam van de state waar de pagina in terecht komt bij deze event.

4.2.2

Content XML

Zoals reeds gezegd vormt de content-XML een extentie op de layout-XML. De contentXML heeft ongeveer dezelfde hoofd-tags als de layout-XML en verwijst naar een component uit de layout-XML met de naam die daarin werd meegegeven met de component. Wanneer een pagina wordt aangeroepen op het systeem, gebeurt dit altijd door te verwijzen naar het content-XML-bestand. De content-XML verwijst op zijn beurt naar de layout-XML. 20

De opbouw is als volgt: < content > < layouturl / > < video / > < logic / > < graphics / >

In de layouturl-tag komt de verwijzing naar het layout-XML-bestand. In de video-tag kunnen eigenschappen ingesteld worden voor het videovenster. Wanneer hier ingesteld wordt dat het videovenster niet gebruikt mag worden (<use>false), maar het videovenster wel werd ingesteld in de layout, dan worden de eigenschappen uit de layout gebruikt. Indien in zowel content- als layout-XML het videovenster de tag <use>use heeft, dan worden de eigenschappen uit de content gebruikt. De logic-tag bevat verwijzingen naar logische componenten uit de layout-XML: < objects > < object > < name / > < properties / >

De graphics-tag bevat verwijzingen naar visuele componenten uit de content-XML: < object > < name / > < properties / >

Dit is dus hetzelfde als bij de logic-tag, met dit verschil dat hier geen ’objects’-tag gebruikt wordt. Er kan niet verwezen worden naar looks, daarvoor moeten alle eigenschappen ingesteld worden in de layout-XML.

21

4.2.3

Applicatie XML

Het formaat voor het applicatie-XML-bestand is hetzelfde als dat voor het layout-XMLbestand. Het verschil is echter dat componenten die aangemaakt worden in het applicatieXML-bestand zullen zichtbaar zijn op elke pagina die deel uitmaakt van de applicatie. De componenten zichtbaar op een pagina zijn de verzameling van de componenten uit de layout-XML voor die pagina en de componenten uit de applicatie-XML. In het contentXML-bestand kan verwezen worden naar zowel componenten uit de layout-XML als componenten uit de content-XML. Wanneer in de applicatie-XML ingesteld wordt dat het videovenster gebruikt moet worden, maar in de layout-XML staat het omgekeerde, dan worden de eigenschappen van de applicatie-XML gebruikt. Indien in beide ingesteld staat dat het videovenster gebruikt moet worden, dan worden de eigenschappen uit de layout-XML gebruikt. Indien het enkel in de layout-XML ingesteld staat, dan worden de eigenschappen uit de layout-XML uiteraard gebruikt. In de applicatie-XML kan wel nog een prefix ingesteld worden voor de verwijzing naar content-XML-bestanden. Dit kunnen we instellen als volgt: < settings > < prefix / >

Het raamwerk zal de prefix toevoegen aan elke verwijzing naar een pagina. Bijvoorbeeld als alle contentbestanden in de map ./data/content/ zitten, kunnen we ./data/content/ als prefix instellen en hoeven we enkel nog naar de bestandsnaam te verwijzen.

4.3

Beschikbare componenten

In wat volgt wordt opsomming van de voorlopig beschikbare componenten gegeven. Voor de beschrijving van deze componenten verwijs ik naar [3]

4.3.1

Logische componenten

• VRTAudioPlayer • VRTDataSender 22

• VRTDataSource • VRTDripFeedPlayer • VRTTimer • VRTSelectDispatcher • VRTEmailValidator • VRTSelectedValidator • VRTTextValidator

4.3.2

Visuele componenten

• VRTText met look: VRTTextLook • VRTButton met look: VRTButtonLook • VRTImage met look: VRTImageLook • VRTScrollableText met look: VRTSCrollableTextLook • VRTScrollableList met look: VRTScrollableListLook • VRTGrid met look: VRTGridLook • VRTAnimatedIcon met look: VRTAnimatedIconLook • VRTEntryField met look: VRTEntryFieldLook • VRTStatusBar met look: VRTStatusBarLook

23

Hoofdstuk 5 Ontwerpbespreking 5.1

Doelstellingen

Het doel is een programma te ontwerpen waarmee visueel een MIA-applicatie kan opgebouwd worden. Dit omvat: • de voorstelling van de applicatie door het programma, • de voorstelling van het gedrag van de applicatie door het programma, • ‘drag & drop’ van componenten, • inlezen van een MIA-applicatie, • exporteren van de MIA-applicatie, • de mogelijkheid tot uitbreiding van de beschikbare componenten. Dit hoofdstuk beschrijft de ontwerpsbeslissingen die genomen werden om deze doelstellingen te bereiken.

5.2

Specificatie-XML

Zoals hierboven reeds vermeld, moet de mogelijkheid bestaan om dynamisch componenten toe te voegen. Dit omdat de verzameling van beschikbare componenten (componenten worden hier gezien als logische componenten, visuele componenten en hun looks) uitbreidbaar moet zijn.

24

Om deze eis in te willigen werd een specificatie-XML ontworpen waarmee een component moet beschreven worden om hem in het programma te kunnen gebruiken. Deze specificatie-XML beschrijft de eigenschappen en de acties die mogelijk zijn voor de component. Componenten worden geregistreerd bij het programma door een verwijzing te schrijven in het juiste lijst-XML-bestand naar hun specificatie-XML-bestand. Er bestaat een lijstXML-bestand voor: • logische componenten: logicComponentList.xml • gewone visuele componenten: visualComponentList.xml • containers (visuele componenten die andere visuele componenten kunnen bevatten): containerList.xml • looks: lookList.xml Al deze bestanden zijn opgeslaan in de ‘files’-directory onder de directory van waaruit het programma uitgevoerd wordt. De specificatie-XML is als volgt opgebouwd: < visualComponent > < comment / > < properties / > < actions / >

5.2.1

‘comment’-tag

In de comment-tag wordt uitleg gegeven over de component. Deze uitleg wordt in het programma gebruikt om de gebruiker meer informatie te kunnen verschaffen over de component.

5.2.2

Eigenschappen

De properties-tag bevat de mogelijke eigenschappen voor de component. De inhoud van de tag ziet er als volgt uit:

25

< properties > < obligatedProps / > < no nOblig atedPr ops / >

In de obligatedProps-tag komen alle eigenschappen die verplicht ingesteld moeten worden voor de component. Bijvoorbeeld ‘setLook voor een visuele component. De nonObligatedProps-tag bevat eigenschappen die niet verplicht zijn in te stellen. Een eigenschap wordt als volgt beschreven: < property > < name / > < alias / > < comment / > < obligatedParams / > < n on Ob li ga te dP ar am s / > < forAll / >

De name-tag bevat de naam van de eigenschap. Dit is de naam van de methode uit de javaklasse van deze component. De alias is een gebruiksvriendelijke naam voor de eigenschap . Deze naam wordt in het programma gebruikt voor de weergave aan de gebruiker. In de comment-tag komt uitleg over de eigenschap. De tekst die de tag bevat wordt in het programma gebruikt als een verklaring voor de eigenschap. De obligatedParams-tag bevat verplichte parameters voor de methode, de nonObligatedParams-tag bevat parameters die niet verplicht zijn. De forAll-tag bevat de naam van een parameter die als sleutel gebruikt wordt. Als deze tag ingevuld is, betekent dit, dat voor alle mogelijke waarden van de parameter waarvan de naam in de forAll-tag staat, de eigenschap kan ingesteld worden voor de component. Een voorbeeld hiervan is de eigenschap ‘setDisplayData’. Deze eigenschap vraagt twee parameters: de mode waarvoor de data geldt en de tekst die op de component moet komen. De forAll-tag zal voor deze eigenschap de waarde ‘mode’ bevatten, naar de naam van de parameter die de mode bevat. We kunnen nu voor alle mogelijke waarden van mode een andere tekst instellen. Deze eigenschap kan dus meerdere keren herhaald worden voor telkens een andere waarde voor mode.

26

Parameters Een parameter wordt als volgt beschreven: < parameter > < name / > < type / > < comment / > < number / > < values / > < defaultValue / >

In de name-tag komt de naam van de parameter, in de type-tag het type en in de commenttag komt uitleg voor de gebruiker van het programma. Het type wordt gebruikt door het programma om te weten op welke manier het deze parameter aan de gebruiker moet voorstellen. De type-tag kan ´e´en van de volgende waarden bevatten: • url: voorgesteld door een bestandskiezer • string: voorgesteld door een tekstveld • integer: voorgesteld door een ‘spinner’ • look: voorgesteld door een ‘combobox’ • boolean: voorgesteld door een vinkje • state: voorgesteld door een ‘combobox’ • page: voorgesteld door een ‘combobox’ In de number-tag wordt beschreven of deze parameter enkelvoudig of meervoudig is. Indien hij meervoudig is kan hij verschillende keren na elkaar voorkomen in de eigenschap. Wanneer de gebruiker kan kiezen uit verschillende beschikbare waarden, in plaats van zelf een waarde in te vullen, wordt de values-tag ingevuld. Voor het type ‘integer’ kan de values-tag een interval beschrijven: < interval > < start / > < stop / >

27

Dit beschrijft de grenzen van de waarde voor de parameter. De values-tag kan ook volledig vooropgestelde waarden bevatten. In dat geval kan er gekozen worden tussen twee opties, nl ‘distinction’ en ‘combination’. Dit wordt ingesteld in de tag ‘composition’. Met de optie ‘distinction’ wordt er aangegeven dat er slechts ´e´en waarde kan gekozen worden. De optie ‘combination’ geeft aan dat er een combinatie van waarden kan meegegeven worden. Dit kan enkel gebruikt worden indien het type ‘integer’ is. In dat geval is de uiteindelijke waarde voor de parameter de som van de gekozen waarden. De tag ‘values’ heeft dan de volgende inhoud: < values > < composition / > < possibleValue > < value / > < alias / > ...

De value-tag van een mogelijke waarde bevat de eigenlijke waarde, de alias-tag bevat een gebruiksvriendelijke benaming voor de waarde. Wanneer de waarde ‘0’ bijvoorbeeld staat voor verticale alignering in het midden, dan bevat de value-tag ‘0’ en de alias-tag bijvoorbeeld ‘Center’. Parameters kunnen ook beschreven worden in een apart XML-bestand. Dit kan tekstbesparend werken. In dat geval wordt in het gewone specificatie-XML-bestand in de type-tag van de parameter een verwijzing ingevuld naar het bestand waarin de parameter beschreven staat. Er is bijvoorbeeld reeds een bestand TMode.xml aangemaakt. De verwijzing bevat de naam van het bestand zonder het .xml -gedeelte. Enkel de name-tag en de type-tag wordt dan nog opgevuld, de rest van de beschrijving voor de parameter wordt uit het aparte XML-bestand gehaald. In het specificatie-XML-bestand hebben we dan bijvoorbeeld een parameter: < parameter > < name > mode < type > TMode

Het bestand waarin de parameter beschreven staat heeft het volgende schema: 28

< parameterType > < type / > < comment / > < number / > < values / > < defaultValue / >

We zien dezelfde tags als voor de beschrijving van een gewone parameter, met uitzondering van het ontbreken van de name-tag (deze wordt nog in de specificatie-XML geschreven). Een parameter dat een kleur voorstelt is een speciaal geval. Een kleur wordt in de XMLbestanden van een MIA-applicatie samengesteld door 4 verschillende parameters, dit is voor de rood-, groen-, blauw- en alphawaarde van het kleur. Het is echter gewenst dat in het programma een kleur kan gekozen worden met behulp van bijvoorbeeld een ‘JColorChooser’. Het programma moet dus weten dat het niet om vier aparte parameters gaat, maar dat de vier parameters samen een kleur zijn. Om dit mogelijk te maken is het nodig om parameters in parameters te kunnen plaatsen. Er is reeds een XML-bestand aangemaakt, genaamd TColor.xml, dat een kleur beschrijft: < parameterType > < comment > Color < number > single < subsequent > < parameter > < name >r < type > integer < comment > De rood - waarde van het kleur < values > < interval > < start >0 < stop >255 < defaultValue >255 < parameter > < name >g < type > integer < comment > De groen - waarde van het kleur < values > < interval >

29

< start >0 < stop >255 < defaultValue >255 < parameter > < name >b < type > integer < comment > De blauw - waarde van het kleur < values > < interval > < start >0 < stop >255 < defaultValue >255 < parameter > < name >a < type > integer < comment > De alpha - waarde / transparency van het kleur . < values > < interval > < start >0 < stop >255 < defaultValue >255

Het type TColor kan door het bestaan van dit bestand vrij gebruikt worden bij het schrijven van specificatie-XML-bestanden. Intern wordt dit voorgesteld als ´e´en parameter met type ‘COLOR’ en verschillende subparameters.

5.2.3

Acties

Een actie heeft dezelfde opbouw als een eigenschap (property-tag), met uitzondering van de forAll-tag. 30

< actions > < action > < name / > < alias / > < comment / > < obligatedParams / > < n on Ob li ga te dP ar ams / > < actions >

5.3

Structuur

Figuur 5.1: Structuur

De programmacode is verdeeld in vier packages, elk met een welbepaalde functie: • Parsen van specificatie-XML • Applicatie • Applicatielezer • Grafische gebruikersomgeving

5.3.1

Parsen van specificatie-XML

Dit codegedeelte zorgt voor het parsen van de specificatie-XML die eerder beschreven werd. Het bevat een manager voor elk lijst-XML-bestand: • VisualComponentManager 31

• ContainerManager • LogicComponentManager • LookManager Deze managers halen hun informatie bij hun lijst-XML-bestand. Dat bestand beschrijft welke ‘componenten’ er van dat type beschikbaar zijt en bevat een link naar hun specificatieXML-bestand. De manager gaat dit lijst-XML-bestand inlezen en gaat een lijst bijhouden van componenten waarnaar gerefereerd wordt in het bestand. De componenten halen op hun beurt hun informatie uit hun specificatie-XML-bestand. Wanneer de methode parse() wordt aangeroepen op zo’n component gaat hij zijn specificatie-XML-bestand parsen en zijn lijsten met eigenschappen en acties opvullen aan de hand van de informatie in het bestand. LookManager is een speciale manager, met speciale componenten. Dit is nodig omdat in het lijst-XML-bestand voor looks ook wordt ingesteld voor welke componenten de looks kunnen ingesteld worden. De speciale componenten zijn dan anders van de gewone componenten doordat ze een verzameling bijhouden van componenten waarvoor ze kunnen gelden. Dit alles wordt visueel voorgesteld in Figuur 5.2

Figuur 5.2: Managers

5.3.2

Applicatie

De code in dit package stelt de MIA-applicatie voor in het geheugen die de gebruiker bouwt. Het bevat ook de exporteerfunctie die het uitschrijven van de MIA-applicatie 32

naar XML verzorgt. Een applicatie bestaat uit LayoutPages en ContentPages. Elke ContentPage houdt een referentie bij van zijn LayoutPage. Een LayoutPage bevat LayoutComponents, een ContentPage bevat ContentComponents. Op hun beurt bevat elke ContentComponent een referentie naar zijn LayoutComponent. Een component bevat een verzameling van eigenschappen met hun parameters. Een ContentPage moet zich registreren bij een LayoutPage. Dit impliceert dat een LayoutPage bijhoudt door welke ContentPages het gebruikt wordt. Ook een ContentComponent registreert zich bij zijn LayoutComponent. Wanneer een component (LayoutComponent) wordt toegevoegd aan de LayoutPage, zal de LayoutPage dit laten weten aan alle ContentPages die geregistreerd staan. De ContentPage zal als reactie daarop een ContentComponent aanmaken met als LayoutComponent deze die werd toegevoegd aan de LayoutPage. De verzameling van eigenschappen in de LayoutComponent en ContentComponent is dezelfde met uitzondering van de eigenschappen die ‘dynamisch’ gemaakt worden. Een eigenschap die dynamisch is, wordt uitgeschreven in de content-XML. Wanneer een eigenschap wordt toegevoegd aan de LayoutComponent, wordt dit meegedeeld aan de ContentPages die geregistreerd zijn. De eigenschappen die in de layout-XML geschreven worden, zijn al deze die verplicht zijn, of waarvan de parameters niet meer de standaard waarden bevatten. De eigenschappen uit de ContentComponent worden pas uitgeschreven wanneer ze niet dezelfde zijn als deze in de LayoutComponent en dus dynamisch. De opbouw van dit codedeel wordt weergegeven in Figuur 5.3 Er is ´e´en speciale LayoutPage, namelijk de ‘Basic page’. Deze komt overeen met de applicatie-XML. Elke ContentPage registreert zichzelf bij de Basic page. Hierdoor zal elke ContentPage ContentComponents bevatten die refereren naar LayoutComponents uit de Basic page. Dit komt overeen met de MIA-specificatie waarin gesteld wordt dat een component in de applicatie-XML geldt voor elke pagina binnen de applicatie. Een LayoutPage bewaart ook zijn gedrag. Dit is een ‘Behavior’-object uit het subpackage ‘behavior’. Daarin wordt de toestandsautomaat beschreven voor de pagina. Elke ContentComponent en LayoutComponent bevat een ‘Performer’-object. Dit object bevat de eigenlijke MIA-component. Het ‘Performer’-object past met behulp van reflexion 33

Figuur 5.3: Applicatie

alle eigenschappen toe op de MIA-component die ingesteld werden. Het ‘Performer’-object van de LayoutComponent bevat een MIA-component waarop enkel de eigenschappen werden ingesteld die statisch zijn, dit zijn deze eigenschappen die in de layout-XML worden uitgeschreven. Deze eigenschappen zijn opgeslaan in de LayoutComponent. Op de MIA-component in het ‘Performer’-object van de ContenComponent worden zowel de eigenschappen uit de LayoutComponent als deze voor de ContentComponent uitgevoerd. Dit is de component die we ook zouden zien op het televisiescherm. Op een performer kan de methode perform() aangeroepen worden. Deze methode zorgt ervoor dat er een nieuwe MIA-component wordt aangemaakt en voert daarop alle eigenschappen uit. Het aanmaken van een nieuwe MIA-component in plaats van voort te werken op de bestaande is nodig omdat we eigenschappen niet terug kunnen verwijderen van een MIA-component. Als we bijvoorbeeld de tekst voor de mode ‘focused’ zouden instellen als eigenschap en dan deze eigenschap terug zouden verwijderen, dan zou die eigenschap nog steeds ingesteld zijn op de MIA-component.

5.3.3

Applicatielezer

De applicatielezer biedt de mogelijkheid om reeds bestaande MIA-applicaties in XMLformaat in te lezen. Zo kan de gebruiker voortwerken op een reeds bestaande MIAapplicatie. De gebruiker moet hiertoe de Unified Resource Locator (URL) geven naar het applicatieXML-bestand. Dit bestand wordt ingelezen en doorgegeven aan het applicatiegedeelte. 34

Tijdens het inlezen van het gedrag (de tag ‘behavior’) wordt voor elke actie gecontroleerd of ze in de ‘object’-tag de waarde ‘system’ bevat en in de ‘method’-tag de waarde ‘setPage’. Indien dit het geval is, staat er in de ‘params’-tag een referentie naar een content-XMLbestand. De gerefereerde content-XML-bestanden worden ingelezen. Ze verwijzen naar een layoutXML-bestand in hun ‘layouturl’-tag. Dit layout-XML-bestand wordt dan op zijn beurt ook ingelezen (indien dit nog niet gebeurt is). De layout-XML kan opnieuw in zijn gedrag refereren naar een content-XML-bestand. De kans is groot dat MIA-applicaties die niet ontwikkeld werden met het programma, niet zullen kunnen ingelezen worden. De oorzaak daarvan is, dat de parameternamen moeten gebruikt worden die in de specificatie-XML staan. Deze parameternamen zijn immers niet bepaald door het MIA-raamwerk. Daarin wordt de naam van de tag van een parameter genegeerd. Parameternamen zijn echter van essentieel belang voor de goede werking van de grafische gebruikersomgeving.

5.3.4

Grafische gebruikersomgeving

Dit codedeel verzorgt de grafische gebruikersomgeving van het programma. Voor elk blok in Figuur 5.3, bestaat een ‘Grafical User Interface’-representatie in dit codedeel: • Application: ApplicationGUI • LayoutPage: LayoutPageGUI • ContentPage: ContentPageGUI • LayoutComponent: LayoutComponentGUI • ContentComponent: ContentComponenGUI • Behavior: BehaviorGUI (niet op Figuur 5.3 weergegeven) Elk *GUI-object bevat een referentie naar een *-object. Bijvoorbeeld: een LayoutPageGUI bevat een referentie naar een LayoutPage-object. Wanneer in de ApplicationGUI een nieuwe ContentPageGUI wordt aangemaakt, zal ApplicationGUI aan zijn Application-object de ContentPage doorgeven van ContentPageGUI. Hetzelfde gebeurt voor het aanmaken van een LayoutPageGUI.

35

Wanneer aan een LayoutPageGUI een LayoutComponentGUI wordt toegevoegd, geeft deze dat door aan zijn LayoutPage en aan de ContentPageGUIs die geregistreerd staan bij de LayoutPageGUI.

36

Hoofdstuk 6 Gebruikersgids 6.1

Inleiding

Dit hoofdstuk heeft tot doel de potenti¨ele gebruiker van het programma uit te leggen hoe met het programma een MIA-applicatie kan gebouwd worden.

6.2

Vereisten

Het programma is geschreven voor de Java Runtime Environment versie 5.0. Er moet dus een JRE op de computer aanwezig zijn. De directory waarin het programma wordt uitgevoerd, moet de ‘files’- en de ‘images’directory bevatten. De ‘files’-directory bevat de specificatie-XML-bestanden. Ook de bestanden video.xml, background.xml en system.xml kunnen daarin teruggevonden worden. Deze lijken op specificatie-XML-bestanden maar beschrijven de eigenschappen en parameters die ingesteld kunnen worden voor background en video en de acties die kunnen gebeuren op het systeem (zoals ‘setPage’). De ‘images’-directory bevat afbeeldingen die in het programma gebruikt worden op bijvoorbeeld de ‘behavior toolbar’. Het programma wordt opgeslaan in de directory dat de carouselbestanden bevat. Dit is nodig omdat het MIA-raamwerk bestanden zoals afbeeldingen voor componenten zou terugvinden. 37

6.3

Statisch versus dynamisch

In het programma kan gekozen worden tussen twee ‘viewmodes’, namelijk de statische en de dynamische viewmode. In de statische viewmode werken we op de layout-zijde van de applicatie. In de dynamische viewmode werken we op de content-zijde van de applicatie. Een applicatie kan volledig opgebouwd worden in de statische viewmode. Wanneer we echter een pagina uit de statische viewmode willen gebruiken als template voor verschillende pagina’s, dan moeten we overgaan naar de dynamische viewmode om de eigenschappen in te stellen van de componenten aan de content-zijde. Enkel in de statische viewmode kunnen componenten aangemaakt en verwijderd worden. Deze beslissing werd genomen omdat het niet legitiem is om aan de dynamische kant componenten toe te voegen. De component moet immers gedefinieerd worden in de layoutXML. Een component toevoegen in de dynamische viewmode zou als effect hebben dat de layout-XML veranderd wordt. Wanneer deze echter gebruikt wordt door verschillende pagina’s worden al deze pagina’s hierdoor be¨ınvloed.

6.4

Basic page

Bij het opstarten van het programma is reeds een pagina geselecteerd, namelijk de ‘Basic page’. Deze pagina komt overeen met de applicatie-XML. Elke component dat op deze pagina wordt geschreven, is zichtbaar in elke pagina binnen de applicatie. De eigenschappen voor de ‘Basic page’ zien we in het linkerpaneel. Als eigenschappen kunnen we de achtergrond en de video instellen. De instellingen voor achtergrond en video gelden voor elke pagina in de applicatie als ze deze niet zelf instellen.

6.5

Aanmaken van een pagina

Een pagina wordt aangemaakt door in de ‘Compose’-menu op de menubar te kiezen voor ‘New page’. Dit is weergegeven in Figuur 6.1 Nu wordt er een dialoogvenster weergegeven (Figuur 6.2 In het dialoogvenster kan de naam van de pagina ingesteld worden en kan gekozen worden of deze pagina gebaseerd moet zijn op een reeds bestaande pagina. In dat geval wordt de 38

Figuur 6.1: Nieuwe pagina

LayoutPage van de bestaande pagina gebruikt als LayoutPage van de nieuwe pagina. Na het aanmaken van de pagina ziet ons programma eruit zoals in Figuur 6.3 In het linkerpaneel zien we de eigenschappen van de pagina. We kunnen in dit paneel de naam van de pagina veranderen en, net zoals voor de Basic page, de achtergrond en video instellen. Deze eigenschappen hebben altijd voorrang op deze uit de Basic page.

6.6

Component aanmaken

Om een component op de pagina te plaatsen, moet er in de menubar, in de menu ‘Compose’, gekozen worden voor ‘New component’. Als gevolg daarvan komt het dialoogvenster tevoorschijn weergegeven in Figuur 6.4 In het dialoogvenster kunnen we kiezen of we een gewone visuele component, een container, of een logische component willen toevoegen. Bij het selecteren van een component, wordt gebruikersinformatie zichtbaar. De naam van de component moet worden ingesteld alvorens op ‘Add’ te klikken. De pagina mag nog geen component bevatten met dezelfde naam, anders zal de ‘Add’-knop 39

Figuur 6.2: Nieuwe pagina - dialoogvenster

niets doen. Het programma ziet er uit zoals in Figuur 6.5 na het toevoegen van een ‘Button component’. Links staan nu de eigenschappen van de component.

6.7

Component aanpassen

Alle eigenschappen van de component kunnen worden aangepast in het linkerpaneel. We kunnen bijvoorbeeld de achtergrondkleur van de component veranderen. Deze eigenschap bevindt zich in de look van de component. Zie hiervoor Figuur 6.6. Het wijzigen van de kleur gebeurt door te klikken op de knop naast het tekstveld met de tekst ‘color’. Dit zorgt ervoor dat een kleurkiezer getoond wordt (Figuur 6.7). Na instellen van tekst, verslepen en vergroten van de component, ziet het effect er uit zoals in Figuur 6.8. Een component heeft een popupmenu. Dit wordt weergegeven wanneer op de component geklikt wordt met de rechtermuisknop. De mogelijkheden van de popupmenu zijn het naar voor of naar achter brengen van de component (z-order), het verwijderen van de component en het ‘locken’ van de component. Wanneer een component gelockt wordt, kan hij niet meer versleept worden. Dit is handig wanneer er veel componenten op het scherm zijn om te vermijden dat de component per ongeluk verplaatst wordt. (Figuur 6.9). 40

Figuur 6.3: Programma na toevoegen van pagina

Bij het aanmaken van een nieuwe component wordt altijd een standaard look op de component ingesteld. Er wordt echter eerst gekeken of er nog geen look bestaat in de pagina die kan gelden voor de component. Als er bijvoorbeeld reeds een ‘Button look’ bestaat en je voegt een ‘Button component’ toe, dan zal hij de bestaande look instellen op de nieuwe component. Je kan echter eenvoudig een nieuwe look aanmaken voor de component door in het linkerpaneel bij zijn eigenschappen in de eigenschap ‘Look’ in de combobox een nieuwe naam te typen. Dan wordt er een nieuwe look aangemaakt met deze naam.

6.7.1

Container

Wanneer we een container toevoegen als component op een pagina, kunnen componenten daaraan toevoegen met behulp van het linkerpaneel. Om een onduidelijke reden worden de componenten in de container echter maar getekend binnen de linkerbovenhoek. Alles punten die buiten het vierkant met dimensie van 100 pixels vallen, wordt niet getekend.

41

Figuur 6.4: Aanmaken van component

6.8

Gedrag

Als linkerpaneel kan ‘Behavior’ gekozen worden in plaats van het ‘Screen’. Het programma ziet er dan uit zoals in Figuur 6.10. Het rechterpaneel beschrijft grafisch de toestandsautomaat. Daarop staan initieel twee toestanden. Dit is de starttoestand en de globale toestand. De toestandsautomaat wordt gestart in de starttoestand. De globale toestand is een toestand die altijd geldig is. Dit betekent dat de gebeurtenissen in die toestand altijd kunnen plaatsvinden, ongeacht de toestand waar de toestandsmachine op dat moment in staat. Onderaan staat een toolbar waarmee we toestanden kunnen toevoegen, hun naam veranderen, verwijderen, er gebeurtenissen, acties en post acties aan toevoegen.

6.8.1

Gebeurtenis toevoegen aan een toestand

Figuur 6.11 geeft het dialoogvenster weer dat wordt getoond wanneer op de knop wordt gedrukt om een nieuwe gebeurtenis toe te voegen. Deze gebeurtenis wordt toegevoegd aan de toestand die op dat moment geselecteerd is (rode kleur). Bij ‘destination’ kunnen we een toestand kiezen waar de toestandsautomaat in terecht moet komen wanneer de gebeurtenis heeft plaatsgevonden. In ‘type’ kunnen we het type gebeurtenis kiezen en in ‘value’ de waarde. Bijvoorbeeld kan het type ‘key’ zijn en de waarde VK COLORED KEY 0. Dit komt overeen met het drukken op de rode knop van de afstandsbediening.

42

Figuur 6.5: Component is toegevoegd

We kunnen in het linkerpaneel de eigenschappen van een toestand zichtbaar maken door dubbel te klikken op de toestand. De eigenschappen zijn dan de acties, de post acties, de events en de naam van de toestand. Als we de ‘Events’-knop in het linkerpaneel nu selecteren, zien we de gebeurtenissen die we toegevoegd hebben voor deze toestand. (Figuur 6.12).

6.8.2

Actie toevoegen aan een toestand

Wanneer we kiezen om een actie toe te voegen op de toolbar, krijgen we het dialoogvenster in Figuur 6.13. In de combobox naast het tekstveld met de tekst ‘Object’ kunnen we het object kiezen waarop we een actie willen doen. Dit object kan het ‘system’-object zijn of een component of look uit de pagina. Naast het tekstveld met de tekst ‘Method’ kan je kiezen welke methode je wil toepassen op die component. Bij het kiezen van een methode wordt er een parameterpaneel weergegeven (indien er parameters moeten ingesteld worden voor de methode).

43

Figuur 6.6: Wijzigen van de achtergrondkleur van de component

Op de figuur 6.13 wordt een actie ingesteld op de knop-component. De actie bestaat eruit de tekst van de knop te veranderen naar ‘nieuwe tekst’. De aangemaakte actie kunnen we nu zien in het linkerpaneel. (Figuur 6.14).

6.8.3

Post acties toevoegen aan een toestand

Dit gebeurt op dezelfde manier als het toevoegen van acties.

6.9

Selectie

Pagina’s, componenten of toestanden kunnen geselecteerd worden met behulp van de menu ‘Select’ in de menubar. Zie daarvoor Figuur 6.15

6.10

Viewmode veranderen

De viewmode kan veranderd worden door in de menubar in de menu ‘View’ te kiezen voor ‘Static view’ of ‘Dynamic view’. (Figuur 6.16). 44

Figuur 6.7: Kleurkiezer

In de dynamic view kunnen we voor eigenschappen kiezen of ze statisch of dynamisch moeten zijn. Als we ze in dynamic view aanpassen, worden ze zowiezo dynamisch. Dit wordt weergegeven in Figuur 6.17 In de figuur zien we onder het parameterpaneel van de eigenschap ‘Display Data’ een knop met de tekst ‘Dynamic’. Dit betekent dat deze eigenschap nu dynamisch is. Dit betekent niet dat de eigenschap ‘Display Data’ met de oude tekst verdwenen is, deze zit gewoon in de statische view en wordt in de dynamische view overschreven. Als we nu op de knop ‘Dynamic’ zouden klikken, dan komt daar terug de tekst ‘Static’ op en bevat de eigenschap terug de waarden ingesteld in de static view.

6.11

Export

De opgebouwde pagina kunnen we nu exporteren door in de menubar in de menu ‘File’ export te kiezen en een directory te kiezen uit de bestandskiezer waar de applicatiebestanden in moeten geschreven worden.

6.12

Import

Een bestaande MIA-applicatie kan ingelezen worden met de functie ‘Import’. Dit bekom je door in de menu ‘File’, ‘Import’ aan te klikken. Let wel op, de kans is groot dat

45

Figuur 6.8: Bewerken component

applicaties die niet opgebouwd werden met de grafische gebruikersomgeving, niet zullen kunnen ingelezen worden. Dit omwille van verkeerde of ontbrekende parameternamen.

46

Figuur 6.9: Component popup

Figuur 6.10: Gedrag

47

Figuur 6.11: Een gebeurtenis aan een toestand hangen

Figuur 6.12: Linkerpaneel voor een toestand

48

Figuur 6.13: Actie toevoegen aan een toestand

Figuur 6.14: Linkerpaneel na toevoegen van een actie

49

Figuur 6.15: Selecteren

Figuur 6.16: Verander de viewmode

50

Figuur 6.17: Dynamische eigenschappen

51

Bibliografie [1] The dvb project. www.dvb.org, 2003. [2] Mhp. www.mhp.org, 2003. [3] B. Janssens. Vlaanderen Interactief - MIA framework developer guide, 2004. Draft status. [4] S. Morris. An introduction to mhp. www.interactivetvweb.org/tutorial/mhp/, 2004. [5] K. Vetters. Digitale tv website. www.digitaletelevisie.be, 2005.

52