}w!"#$%&'()+,-./012345<ya

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Textový klient pro JVoiceXML na platformě Google Android BAKALÁŘSKÁ PRÁCE Martin Nekula Brno, podzim 2013

2 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Martin Nekula Vedoucí práce: Mgr. Luděk Bártek, Ph.D. ii

3 Poděkování Děkuji vedoucímu této bakalářské práce Mgr. Lud kovi Bártkovi, Ph.D., za vstřícnost a pomoc při psaní této práce. Dále děkuji vedoucímu projektu JVoiceXML, Dr. Dirk Schnelle-Walka, za rady a pomoc při realizaci textového klienta. iii

4 Shrnutí Tato práce se zabývá platformou JVoiceXML, která je schopna interpretovat dokumenty VoiceXML. Cílem je analyzovat aktuální stav této technologie a způsoby jakými lze JVoiceXML interpret zpřístupnit na platformě Google Android. V praktické části je jeden ze způsobů vybrán a zrealizován v podobě textového klienta. iv

5 Klíčová slova VoiceXML, JVoiceXML, textový klient, Google Android, dialogové systémy, Java v

6 Obsah 1 VoiceXML Architektura Dokumentový server a VoiceXML interpret Implementační platforma Struktura dokumentů Příklad VoiceXML Souvisící technologie a normy Form Interpretation Algorithm (FIA) Speech Recognition Grammar Specification (SRGS) Speech Synthesis Markup Language (SSML) ECMAScript JVoiceXML Architektura Komunikace klienta s JVoiceXML Používané technologie Log4J JNDI Apache Commons Real-time Transport Protocol Stav vývoje Google Android Hlavní vlastnoti systému Android Grafické rozhraní Aplikace Správa paměti Architektura Linuxové jádro Knihovny + běhové prostředí Aplikační rámec Aplikace Základní části aplikací Aktivity Služby Content provider

7 3.3.4 Broadcast receiver Soubor manifest Historie verzí Možnosti implementace JVXML na platformu Android Stav vývoje klienta před touto prací Možnosti implementace Připojení k JVoiceXML interpretu Získávání VoiceXML dokumentů Zvolený způsob implementace Realizace textového klienta Hlavní využívané JVoiceXML knihovny JVoiceXMLMain Session TextServer ConnectionInformation Postup tvorby klienta Vytvoření Aktivit AndroidTextConfiguration JVoiceXML funkcionalita Metody rozhraní TextListener Kompatibilita s OS Android

8 Úvod Dnešní doba s sebou přináší možnost hlasově komunikovat už i s elektronickými automatickými systémy. Toho je využíváno například při dotazech na stav objednaného zboží, navigaci při řízení dopravního prostředku nebo i pro hlasový přístup k elektronické poště. Ve všech těchto případech stačí, když stroj po rozpoznání řeči volajícího zjistí požadavek, vyhledá jej v databázi či jinak zpracuje a formou textu nebo syntetizované řeči předá volajícímu výsledek. V této oblasti se používá také technologie VoiceXML[31]. Je to značkovací jazyk, který byl vyvinut za spolupráce firem AT&T, IBM, Lucent a Motorola. Účelem bylo vytvořit standardizovaný jazyk pro tvorbu konverzačních aplikací. Jako standard byl uznán organizací W3C v roce 2000[33]. Je schopen vytvářet audio dialogy za pomoci syntetizované řeči, digitalizovaného zvuku a také zvládá rozpoznávání mluvené řeči. Tato technologie dnes běžně usnadňuje uživatelům komunikaci se systémy, protože odpadá povinnost studovat mnohdy složité manuály. Domluvit se s aplikací vlastními slovy je také nejpřirozenější způsob ovládání, který má své výhody i pro nevidomé a jinak postižené osoby. Vzhledem k tomu, že VoiceXML je jen jazyk, bylo potřeba vyvinout i programy (interprety), které dokáží dokumenty psané v tomto jazyce zpracovávat a provádět syntézu řeči. Jedním z nich je například OptimTalk[17] vyvíjen společností OptimSys s.r.o. V této práci byl ovšem použit interpret JVoiceXML[25], jenž je postaven na platformě Java. Využívá všechny soudobé technologie v telefonních i sít ových systémech. Narozdíl od OptimTalku je vyvíjen jako open source software pod licencí GNU Library General Public Licence. Jeho projektovým manažerem je Dirk Schnelle-Walka. Ne vždy je ovšem možné s dialogovými systémy zacházet pouze hlasově, at už z provozních důvodů nebo z rozhodnutí uživatele. Cílem této práce je právě vytvoření klienta k interpretu JVoiceXML umožňující textový přístup k VoiceXML dokumentům. V prvních třech kapitolách práce nejprve popisuje technologie, které souvisejí s klientem nebo s používanými platformami. Čtvrtá kapitola shrnuje co bylo dosud podniknuto pro tvorbu klienta na 3

9 platformu Android a popisuje možnosti jak by se implementace mohla provést. Nakonec je určitá metoda vybrána a zdůvodněna. Poslední pátá kapitola se věnuje samotné realizaci klienta a popisuje chování a funkce jednotlivých tříd. Jako provozní platforma byl zvolen operační systém Google Android pro mobilní zařízení ve verzi Aplikace k tomuto systému jsou povětšinou vyvíjeny v jazyce Java, a jelikož má Android stále rostoucí procentuální zastoupení na trhu, slibuje to možné praktické využití tohoto klienta i v budoucnu. Jako vývojové prostředí byl použit program Eclipse[29] ve verzi Do něj byl přidán plugin Android Development Tools usnadňující vývoj aplikací pro tuto platformu a také obsahuje konfigurovatelný emulátor Android Virtual Device, simulující prostředí tohoto operačního systému, pro jednoduché testování textového klienta. Klient také zaručuje nezbytnou funkčnost v rámci platformy Android, jako přerušení běhu aplikace v případě příchozího telefonního hovoru. Aktuální funkční verze interpretu byla získána z projektového úložiště Subversion 1 z webové adresy projektu jvoicexml.svn. sourceforge.net. 1. Centralizovaný nástroj pro správu verzí softwaru 4

10 1 VoiceXML VoiceXML 1 [31] je značkovací jazyk na bázi XML, využívaný pro tvorbu zvukových uživatelských rozhraní k dialogovým systémům[14]. Je určen pro zpřístupnění informací a obsahu z Internetu přes hlasová a telefonní zařízení. Umožňuje vytvářet audio dialogy pomocí syntézy řeči, digitalizovaného zvuku, rozpoznávání řeči a DTMF 2 vstupu, záznamu řeči, telefonie a střídání počítače s uživatelem ve vedení dialogu (tzv. mixed initiative). Jazyk začal vznikat od roku 1995, kdy společnost AT&T založila projekt zvaný Phone Markup Language (PML)[34]. To byl jazyk už na bázi XML, pro usnadnění procesu vývoje aplikací v rámci této společnosti. Cílem tohoto jazyka bylo zjednodušit rozpoznávání řeči v programech AT&T. Podobné projekty vznikaly v tu dobu v několika dalších velkých společnostech. Proto bylo v roce 1998 založeno VoiceXML Forum (dále jen Forum), tehdy tvořeno firmami AT&T, IBM, Lucent a Motorola. Cílem Fóra bylo definovat standardizovaný jazyk, který by mohli vývojáři používat pro tvorbu dialogových systémů. V roce 2000 vydalo Forum jazyk VoiceXML 1.0 a krátce na to téhož roku byl přijat organizací W3C jako mezinárodní standard. Aktuální verze tohoto jazyka je nyní 2.1[38] a verze 3.0[39] je zatím ve stadiu pracovního návrhu od roku Architektura Architektura VoiceXML obsahuje následující komponenty: Dokumentový server VoiceXML interpret + kontext interpretu Implementační platforma 1. Voice extensible Markup Language. 2. Dual Tone Multi-Frequency neboli tónová volba. 5

11 1. VOICEXML Obrázek 1.1: Architekturální model[37] Dokumentový server a VoiceXML interpret Dokumentový (nebo také webový) server zpracovává požadavky od klientské aplikace, zvané VoiceXML interpret, skrze kontext VoiceXML interpretu. Kontext slouží jako rozhraní mezi okolním světem a interpretem. Typicky se zabývá mechanismy, kterými začíná spouštění skriptů a které získávají dokumenty pro interpret. Server poskytuje kontextu jako odpověd na požadavky VoiceXML dokumenty, které jsou poté interpretem zpracovány. Kontext interpretu může také monitorovat uživatelské vstupy paralelně s interpretem. V praxi to znamená, že například kontext interpretu může vždy naslouchat speciální únikové frázi (escape phrase), která přesměruje uživatele k vysokoúrovňovému osobnímu asistentu. Jiný kontext zase může naslouchat frázím, které mění uživatelská nastavení jako je hlasitost nebo vlastnosti TTS text-to-speech syntetizátor, produkující lidskou řeč z textu. 6

12 1. VOICEXML Implementační platforma Implementační platforma je ovládána kontextem interpretu i interpretem samotným. Například v interaktivní hlasové aplikaci by kontext VoiceXML interpretu měl být odpovědný za detekci příchozího hovoru, získání počátečního VoiceXML dokumentu a odpovědi na příchozí hovor. Interpret potom vede samotný dialog, po přijetí hovoru kontextem. Implementační platforma generuje události jako reakci na činnost uživatele (např. hlasový nebo textový vstup, odpojení) a systémové události (např. vypršení časového limitu). Na některé z těchto událostí reaguje interpret samotný, jak je specifikováno ve VoiceXML dokumentu, zatímco na ostatní reaguje kontext VoiceXML interpretu. 1.2 Struktura dokumentů VoiceXML dokument sestává primárně z prvků vysoké úrovně zvaných dialogy. Ty musí být uvedeny mezi značkami[32] (elementy) <vxml> a </vxml>, které ohraničují celý dokument. Dialogy jsou dvojího typu: Form (formulář) Dialog pro prezentaci informací a sběr dat. Je klíčovou komponentou VoiceXML dokumentů. Zpravidla obsahuje sadu položek formuláře (form items), které jsou postupně zpracovány v hlavní smyčce algoritmu pro interpretaci formuláře. Menu (nabídka) Dialog umožňující uživateli vybrat jednu z nabízených možností (např. jazyk dokumentů) a podle jeho volby přenese zpracování dialogu na určité místo v rámci stejného dokumentu nebo vyžádá od dokumentového serveru jiný Příklad VoiceXML Interpretace dokumentu začíná standardně u prvního dialogu a při jeho provádění se určuje, který dialog bude následovat po něm. Pokud už není žádný další dialog stanoven, interpretace dokumentu skončí. Následuje ukázka jednoduchého VoiceXML dokumentu, který přehraje uživateli, pomocí syntézy hlasu, frázi Hello World! nebo 7

13 1. VOICEXML v případě textového klienta ji uživateli vypíše a poté skončí, protože není specifikován žádný další dialog: <?xml version = " 1. 0 " encoding ="UTF 8"?> <vxml xmlns =" http ://www. w3. org /2001/vxml " version ="2.1" > <form> <block >Hello World! </ block > </form> </vxml> Další element, který byl v tomto příkladu použit je block. Požívá se jako kontejner pro neinteraktivní spustitelný kód, např. nějakou formu uvítání nebo informaci pro uživatele. Na jeho místě by se také mohl použít element prompt, který ovládá výstup syntézy řeči a přednahraného zvuku. Koncepčně jsou výstupy okamžitě zařazeny pro přehrání uživateli, takže interpretace pokračuje dokud není potřeba zažádat o vstup od uživatele. 1.3 Souvisící technologie a normy Form Interpretation Algorithm (FIA) Implicitní algoritmus, který je předepsán pro interpretaci formulářů a platformy jej musí implementovat. Sestává z hlavní smyčky, která opakovaně vybírá položky formuláře a navštevuje je. Pokud položka ještě nemá přidělenu žádnou hodnotu, tak vyzve uživatele k jejímu vyplnění Speech Recognition Grammar Specification (SRGS) SRGS je W3C standard pro gramatiky[35], který VoiceXML používá k rozpoznávání hlasu uživatele. Specifikuje dvě rozdílné, ale ekvivalentní syntaxe. Jedna je založena na XML prvcích. Druhá využívá ABNF 4 syntaxi, tedy nesestává z XML, ale z prostého textu a je podobna tradiční BNF 5 [40] gramatice. Obě mají vyjadřovací schopnost bezkontextové gramatiky. 4. Augmented BNF for Syntax Specifications 5. Backusova-Naurova forma 8

14 1. VOICEXML Speech Synthesis Markup Language (SSML) SSML je W3C standard[36] pro jazyk založený na XML, využíván aplikacemi pro syntézu řeči. Hlavní rolí jazyka je poskytnout vývojářům standardizovaný způsob pro ovládání některých aspektů syntetické řeči. Může jít o výslovnost, hlasitost, intenzitu, tempo řeči a další. Často je součástí VoiceXML skriptů ECMAScript ECMAScript[10] je standard od asociace evropských výrobců Ecma International. Ten je implementován jazykem JavaScript, využívaným právě ve VoiceXML dokumentech. JavaScript je široce používán ve webových aplikacích pro skriptování na straně klienta. Jazyk je dynamický a slabě typovaný. 9

15 2 JVoiceXML Jelikož je VoiceXML jen značkovací jazyk, i se všemi technologiemi s ním spjatými, je potřeba nějaká platorma, která bude dokumenty s tímto jazykem uživateli interpretovat. Aplikace neboli interpret využívaný pro tento účel v této práci je projekt JVoiceXML[25]. JVoiceXML je volně dostupný interpret VoiceXML 2.1 naprogramován v jazyce Java a udržuje si otevřenou architekturu pro jednoduché přidávání nových rozšíření. Podporuje i tvorbu vlastních VoiceXML dokumentů. Jako demonstrační implementační platformy podporuje mimo jiné i standardní Java API jako JSAPI[20] 1.0 a 2.0 nebo JTAPI[21]. Projekt je vyvíjen jako open source pod licencí GNU Library General Public License[12] a hostován na serveru SourceForge.net. Cílem je poskytnout volně použitelnou aplikaci, která je nezávislá na operačním systému. Projektovým manažerem je Dr. Dirk Schnelle-Walka, působící na Technické univerzitě v Darmstadtu v Německu. 2.1 Architektura Základní přehled architektury JVoiceXML je zaznamenán v diagramu komponent na obrázku 2.1. Interpret je, podobně jako architektura VoiceXML, rozdělen do tří částí. VoiceXML dokumenty jsou obvykle uloženy na webovém serveru nebo servlet kontejneru, což je komponenta webového serveru, která může komunikovat s Java servlety 1. Ty jsou zpřístupňovány většinou pomocí HTTP protokolu, JVoiceXML ovšem podporuje i jiné protokoly, jako např. file. JVoiceXML beží jako samostatný server a získává dokumenty ze servlet kontejneru nebo z jiného dokumentového úložiště Komunikace klienta s JVoiceXML Jsou dva hlavní způsoby, jakými klienti mohou komunikovat s JVoiceXML. Pomocí JNDI[19] nebo Java rozhraní CallManager. 1. Třída Javy, používaná k rozšíření schopností serveru nebo aplikace na serveru. 10

16 2. JVOICEXML Obrázek 2.1: Model architektury[24] JVoiceXML Většina demonstračních klientů používá Java Naming and Directory Interface (JNDI)[19] pro přístup k JVoiceXML. Momentálně je tímto podporována jen základní telefonie, ale uživatelé mohou volat aplikace z vlastních Java programů. Způsob jakým lze tohoto docílit je popsáno v Userguide 0.7.5[24]. Koncepčně JNDI umožňuje připojení k centralizovanému spuštěnému JVoiceXML serveru. JVoiceXML také dovoluje mít samotný interpret na straně serveru, se kterým by klient musel vytvořit spojení vzdáleně za pomoci rozhraní CallManager. V tomto případě by JVoiceXML interpret čekal na příchozí hovory a jakmile by CallManager detekoval příchozí hovor, tak by zavolal přednastavenou aplikaci pro jeho zpracování. 2.2 Používané technologie Log4J Jelikož je projekt JVoiceXML psán v jazyce Java, používá také knihovnu Log4J[7], od neziskové organizace Apache Software Foundation, k zaznamenávání důležitých událostí při běhu programu 11

17 2. JVOICEXML (tzv. logging). Jeho hlavní výhoda je v nízké výpočetní náročnosti i při běhu na starším hardwaru a možnost jednoduché úpravy způsobu vypisování událostí programu, aniž by bylo nutno upravovat kód aplikace samotný. K přizpůsobení záznamů stačí upravit jen konfigurační soubor log4j.xml. Logger umožňuje programátorovi třídit záznamy do několika úrovní, uvedených ve třídě org.apache.log4j.level. Například úroveň INFO by měla obsahovat informace o důležitých běhových událostech. Úroveň ERROR už určuje chybové události, které ovšem mohou dovolit aplikaci dále běžet, ale záznamy úrovně FA- TAL již obvykle informují o závažných chybách, které pravděpodobně přeruší běh aplikace. Pomocí všech úrovní a možnosti jejich filtrace a zobrazování například jen jedné úrovně naráz je většinou jednoduché najít příčinu chyby v programu. Tohoto bylo využíváno i v praktické části této práce JNDI Java API poskytující jmennou a adresářovou funkcionalitu aplikacím napsaným v jazyce Java. Bylo vytvořeno speciálně pro platformu Java pomocí javového objektového modelu. Pomocí JNDI[19] mohou aplikace založené na Javě ukládat a objekty jakéhokoliv typu. JNDI poskytuje i metody pro standardní adresářové operace, jako asociaci atributů s objekty a hledání objektů pomocí těchto atributů. API ovšem není definováno závisle na žádné specifické implementaci jmenné nebo adresářové služby. Umožňuje aplikacím přistupovat i k několika rozdílným službám, jako LDAP 2, RMI 3 nebo DNS, pomocí běžných API. Tohoto je využíváno i při přístupu k JVoiceXML interpretu, který se tak může nacházet na nějakém stroji v počítačové síti a klient k němu může centralizovaně vzdáleně přistupovat. 2. Lightweight Directory Access Protocol 3. Remote Method Invocation 12

18 2. JVOICEXML Apache Commons Projekt JVoiceXML využívá také knihovny Commons[8] od Apache Software Foundation. Jejich cílem je poskytovat opakovaně použitelný open source Java software, který může být velmi často programátory používán, ale ve standardní verzi Javy stále chybí. Knihovny poskytují i rozšíření Java balíku java.lang. To obsahuje například balík lang3.builder, který poskytuje pomocné třídy pro tvorbu efektivních hashovacích funkcí[13], či metod compareto nebo tostring podle knihy Effective Java[9]. Projekt se snaží udržet kód stabilní a nezávislý na jiných než standardních Java knihovnách, aby budoucí změny knihoven negativně neovlivňovaly stávající programy, které je využívají Real-time Transport Protocol Protokol aplikační vrstvy, který JVoiceXML využívá pro přenos telefonie. Protokol standardizuje paketové doručování zvukových dat po internetu a je veden jako standard v RFC 3550[26]. Je používán ve spojení s RTP Control protokolem, který slouží k řízení RTP relace na základě sledování kvality toku. RTP data jsou obvykle přenášena UDP protokolem. 2.3 Stav vývoje V této době ještě není interpret zcela dokončen, momentálně se nachází ve verzi Zejména chybí podpora některých VoiceXML elementů z verze 2.0, takže zatím není doporučována integrace JVoiceXML do žádných velkých projektů. Dále také po instalaci JVoiceXML není dostupné žádné uživatelské rozhraní k použití interpretu. V uživatelských průvodcích je sice postup jak nějaké jednoduché vytvořit, ale uživatelé bez znalostí jazyka Java, případně vývojového prostředí pro něj, nemohou interpret vyzkoušet, pouze jej spustit pomocí přiložených dávkových souborů. Na projektu momentálně pracuje pětičlenný tým s občasnými příspěvky dalších uživatelů. 13

19 3 Google Android V současné době je Google Android nejrychleji rostoucí mobilní operační systém. Je založen na linuxovém jádru a navržen hlavně pro mobilní zařízení s dotykovou obrazovkou jako jsou chytré telefony nebo tablety. Vývoj systému začal původně ve společnosti Android, Inc v roce Jejím cílem bylo vytvořit mobilní operační systém, který by byl schopen konkurovat systémům Symbian nebo Windows Mobile. V roce 2005 byla ovšem kvůli finančním problémům odkoupena společností Google, čímž se stala její dceřinnou společností a vývoj systému pokračoval. První verze platformy Android byla potom vydána v listopadu roku 2007 a postavena na linuxovém jádru verze 2.6. Android ovšem není upravený Linux, vestavěný do mobilního zařízení. Linuxové jádro využívá jen pro hlavní systémové služby, takže standardní linuxové utility jako X-windows nebo knihovny GNU C nejsou podporovány. Podobně je to také u aplikací pro Android, které se píší pomocí jazyka Java, ale není to čistá Java. Standardní Java knihovny, jako je Swing, nejsou podporovány. Jiné zase nemusí být preferovány a jsou nahrazeny knihovnami napsanými specificky pro Android. Ty jsou pak lépe přizpůsobeny vestavěnému (embedded) prostředí s omezenými výpočetními možnostmi. Celkově je Android veden jako open source platforma, což znamená, že vývojáři mohou prohlížet a používat jakoukoliv část zdrojového kódu. Existují ovšem výjimky a některé části zdrojového kódu jsou vedeny jako proprietární software 1, například GPS navigace. 1. Software s uzavřeným kódem, ke kterému obvykle nejsou volně k dispozici zdrojové kódy. 14

20 3.1 Hlavní vlastnoti systému Android 3. GOOGLE ANDROID Po vstupu na trh si zařízení s operačním systémem Android získala rychle oblibu, hlavně díky inovativnímu grafickému rozhraní, nárůstu použitelných aplikací a s tím spojené správě paměti Grafické rozhraní Uživatelské rozhraní Androidu je založeno na přímé manipulaci pomocí dotyků. Odezva uživateli by měla být okamžitá a plynulá, což je jeden z principů[1] tohoto rozhraní, občas může být také doplňována vibrací zařízení. Rozhraní a aplikace jsou doplňovány i dalšími hardwarovými přídavky, jako je akcelerometr, gyroskop nebo senzory přiblížení. S jejich pomocí se může rozhraní přízpůsobovat uživatelským činnostem například změnou orientace displeje nebo simulací celého zařízení jako volantu ve hrách. Základní obrazovka po startu zařízení je tzv. homescreen. Je to základní navigační a informační bod, podobně jako plocha na osobních počítačích. Zde se obvykle nachází ikony nainstalovaných aplikací, které příslušnou aplikaci spouští a tzv. widgety. Ty zobrazují obsah, který se může pravidelně měnit, například stav ové schránky nebo předpověd počasí. Homescreen může být uživatelem rozsáhle upravován, nejen aplikacemi a widgety, které zobrazuje, ale kze upravit i grafiku a polohu funkčních částí rozhraní. V nejvyší části displeje je vždy zobrazován stavový řádek, jenž ukazuje důležité informace o zařízení a síle signálu. Řádek může být uživatelem roztažen směrem dolů a potom je možno vidět obrazovku s upozorněními, kde aplikace zobrazují důležité informace nebo aktualizace tak, aby zbytečně nevyrušovaly uživatele Aplikace Aplikace pro Android jsou psány v jazyce Java. Kód je kompilován nástroji Android SDK 2 [3] společně s jakýmikoliv daty nebo zdrojovými soubory do balíku platformy Android s koncovkou.apk. Všechen kód v tomto balíku je považován za jednu aplikaci a je to vše 2. Source Development Kit. 15

21 3. GOOGLE ANDROID co je potřeba k nainstalování daného programu na zařízení s Androidem. SDK obsahuje rozsáhlou sadu vývojářských nástrojů jako je debugger 3, softwarové knihovny, emulátor handsetu (zařízení s OS Android) pro testování aplikací, dokumentaci, ukázkové kódy a návody pro tvorbu. Oficiálně podporované vývojářské prostředí (IDE 4 ) je program Eclipse[29] s pluginem Android Development Tools (ADT). Dostupná jsou i další rozšíření, např. pro tvorbu aplikací nebo rozšíření v jazyce C nebo C++. Většinu aplikací, at už zdarma nebo placených, je možno získat na internetových obchodech Google Play nebo Amazon Appstore. Při vývoji vlastní aplikace stačí stáhnout a nainstalovat samotný APK soubor Správa paměti Protože jsou zařízení s Androidem většinou napájena z baterie, systém se snaží udržet spotřebu elektrické energie na minimu pomocí správy paměti (na těchto zařízeních je používána RAM 5 ). Když už se aplikace nepoužívá, systém ji automaticky v paměti pozastaví. Aplikace je pořád technicky otevřena, ale spotřebovává mnohem méně energie z baterie nebo výpočetního výkonu. Tak zůstává, dokud není znovu zavolána uživatelem. Toto umožňuje rychlejší přecházení mezi pozastavenými aplikacemi, protože jsou pořád načteny v paměti. Pokud je stav volné paměti již nízký, systém začne ukončovat pozastavené aplikace na pozadí, začínajíc nejdéle pozastavenou aplikací. Tento proces je také automatický a uživateli skrytý. Toto je také příčinou kontroverzí, protože na jednu stranu má uživatel o starost méně, ale proces může ukončit ještě žádoucí aplikace. 3. Softwarový nástroj, který se používá pro hledání chyb při vývoji softwaru. 4. Integrated Development Environment. 5. Random Access Memory 16

22 3. GOOGLE ANDROID Obrázek 3.1: Model architektury systému Android 3.2 Architektura Google často označuje OS 6 Android za softwarový zásobník[28] (software stack). Každá vrstva tohoto zásobníku sdružuje několik programů, které podporují určité funkce tohoto operačního systému. Existují 4 vrstvy: Linuxové jádro Knihovny + běhové prostředí Aplikační rámec (framework) Aplikace 6. Operační systém 17

23 3. GOOGLE ANDROID Linuxové jádro Jádro (kernel) operačního systému je nejniží vrstva architektury. Tvoří abstraktní vrstvu mezi hardwarem a zbytkem softwaru v ostatních vrstvách. Je postaveno na systému Linux, v současné době je verze [30]. Jádro se stará o programy pro správu paměti, bezpečnostního nastavení, napájení a několik dalších hardwarových driverů (ovladačů). Drivery jsou právě programy, které zajišt ují ovládání hardwarových zařízení. Dále se stará o ovládání bezdrátového internetu (WiFi), fyzické klávesnice (pokud je přítomna), audio výstupů, atd. Důvodem použití jádra Linux byla také vlastnost poměrně snadné integrace na různá zařízení a tím zaručená přenositelnost Knihovny + běhové prostředí Další softwarovou úrovní jsou nativní softwarové knihovny. Ty fungují jako sada instrukcí, které umožňují systému zpracovávat různé typy dat. Například knihovna media framework podporuje přehrávání a nahrávání různých formátů audia, videa a obrázků. pro 2D a 3D grafiku je tu zase knihovna Open GL[2]. Knihovny jsou napsány v jazyce C nebo C++. Na stejné úrovni se také nacházejí důležité Java knihovny, protože se aplikace píší pomocí tohoto jazyka. Je tu také virtuální stroj Dalvik[5] (Dalvik Virtual Machine), který byl vyvinut speciálně pro Android. DVM je software, který spouští a zpracovává aplikace platformy Android. Aplikace, napsané v Javě pro Android, jsou zkompilovány nejprve do bytekódu, na soubor.class, kompatibilní s virtuálním strojem Java[22]. Teprve potom jsou převedeny do formátu.dex (Dalvik Executable), který DVM může zkompilovat a spustit. Formát Dalvik má být ideální pro prostředí s dosti omezenou pamětí nebo rychlostí procesoru Aplikační rámec Tato úroveň obsahuje programy, které spravují funkce a služby zařízení, jako je alokace zdrojů (řetězců, grafiky), telefonní aplikace, 18

24 3. GOOGLE ANDROID přepínání mezi procesy a programy nebo zjišt ování fyzické polohy zařízení. Vývojáři aplikací mají k této vrstvě úplnýpřístup, což jim dovoluje využít každou ze schopností zařízení ve své apliakci Aplikace Na nejvyšší úrovni se nachází samotné Aplikace. Ty sestávají ze základních funkcí, důležitých pro uživatele. Jedná se například o přijímání hovorů, přístup k internetovému prohlížeči, seznam kontaktů nebo jakákoliv další, i stažená, aplikace. Se vším na této vrstvě se manipuluje pomocí uživatelského rozhraní. Niží vrstvy jsou tedy používány jen vývojáři z Googlu nebo vývojáři aplikací. 3.3 Základní části aplikací Jakmile je nějaká aplikace nainstalována, tak setrvává ve svém vlastním tzv. bezpečnostním pískovišti[4] (security sandbox). Tak má každá aplikace přístup jen k těm částem systému, které potřebuje pro svůj provoz a nic víc. To zajišt uje velmi bezpečné prostředí a aplikace nemají přístup k částem systému ke kterým nemají povolení. Sandbox funguje následovně: Android je víceuživatelský operační systém a každá aplikace je vedena jako jiný uživatel. Systém přidělí každé aplikaci unikátní linuxové uživatelské ID, které je známo jen systému a aplikace sama jej nezná. Systém dále nastaví právo přístupu k souborům aplikace tak, že jen uživatelské ID přiděleno k aplikaci k nim může přistupovat. Každý proces má svůj vlastní virtuální stroj, takže kód aplikace je spouštěn izolován od ostatních aplikací. Každá aplikace má tedy svůj vlastní linuxový proces. Android tento proces zapíná, když je potřeba nějakou z komponent aplikace spustit. Potom jej vypíná až když není aplikace potřeba nebo je nutné uvolnit místo v paměti pro jiné aplikace. Základní stavební prvky aplikace jsou aplikační komponenty. Každá komponenta je rozdílný bod, skrz který může systém vstoupit do 19

25 3. GOOGLE ANDROID aplikace. Některé komponenty mohou být na sobě vzájemně závislé, ale každá představuje stavební prvek, definující celkové chování aplikace. Existují 4 rozdílné typy komponent, každá s jiným významem a životním cyklem. Jsou to aktivity, služby (services), content providery (poskytovatelé obsahu) a broadcast receivery (přijímače vysílání). Každá z komponent musí být také deklarována v souboru zvaném Manifest Aktivity Aktivita[15] představuje jednu obrazovku v uživatelském rozhraní. Například ová aplikace může mít jednu aktivitu, která zobrazuje seznam nových ů, jiná může sloužit k napsání nové zprávy a další zase ke čtení ů. Přestože tu aktivity spolupracují, aby vytvořily pro uživatele jednolitou aplikaci, každá je stále nezávislá na ostatních. Jiná aplikace tedy může spustit jakoukoliv z výše zmíněných aktivit (pokud to ová aplikace dovoluje). Například aplikace prohlížeče internetu může zavolat aktivitu z ové aplikace přímo pro napsání nové zprávy Služby Služba je komponenta, která se spouští a běží na pozadí. Vetšinou provádí dlouhotrvající operace nebo práci pro vzdálené procesy. Služba tedy neposkytuje uživatelské rozhraní. Může tedy například přehrávat hudbu na pozadí, zatímco je uživatel v nějaké aplikaci nebo může stahovat data ze sítě, aniž by blokovala uživatelskou interakci s rozhraním. Službu může spustit i jiná komponenta, jako třeba aktivita, a může ji nechat běžet nebo ji k sobě připoutat aby s ní mohla i nadále komunikovat. Služba ovšem není samostatný proces. Většinou běží ve stejném procesu jako aplikace, které je součástí. Také to není programové vlákno, takže neulehčuje práci vláknu, ze kterého byla spuštěna. 20

26 3. GOOGLE ANDROID Content provider Content provider spravuje sdílenou sadu aplikačních dat. Tyto data je možno uložit v souborovém systému zařízení, SQLite databázi, na webu nebo jakémkoliv trvalém úložišti, ke kterému má aplikace přístup. Skrze content provider mohou tedy i ostatní aplikace přistupovat nebo i měnit takováto data (pokud to content provider povoluje). Systém Androidu například poskytuje content provider spravující uživatelský seznam kontaktů. Jakákoliv aplikace s potřebnými právy tak může zažádat o přístup k tomuto seznamu a číst nebo zapisovat informace určitého kontaktu. Je ale možno také číst a zapisovat data, která jsou pro nějakou aplikaci soukromé a nesdílené. Takto lze využívat i aplikaci Note Pad k psaní poznámek, která obsahuje content provider pro ostatní aplikace Broadcast receiver Broadcast receiver je komponenta, která odpovídá na vysílání oznámení v celém systému. Mnoho vysílání také ze systému pochází, například vysílání oznamující, že byl vypnut displej, dochází baterie nebo byla pořízena fotografie. Aplikace mohou také začít vysílání, typicky aby oznámily ostatním aplikacím, že nějaká činnost byla dokončena, jako že bylo dokončeno stažení dat, která jsou nyní k dospozici. Přestože broadcast receivery také nemají uživatelské rozhraní, mohou vytvářet upozornění ve stavovém řádku. Tak je možno upozornit uživatele, že proběhla událost vysílání Soubor manifest Než může systém Android zapnout nějakou aplikační komponentu, musí nejprve vědět, že taková komponenta existuje. To zjišt uje ze souboru AndroidManifest.xml (soubor manifest). Aplikace musí deklarovat všechny své komponenty v tomto souboru, který musí být v kořenovém adresáři aplikace. Mimo deklaraci komponent určuje manifest i několik dalších věcí: 21

27 3. GOOGLE ANDROID Jakákoliv uživatelská oprávnění, která by aplikace mohla potřebovat. Často je to přístup k internetu nebo povolení ke čtení uživatelských kontaktů. Jakou minimální úroveň[6] API aplikace vyžaduje, podle toho jaká API používá. Hardwarové a softwarové požadavky nezbytné pro správný běh aplikace. Například kamera, fotoaparát, bluetooth, atd. API knihovny se kterými musí být aplikace propojena, ale které nejsou součástí standardních knihoven platformy Android. Například Google Maps knihovna. Seznam java tříd ze kterých aplikace sestává, atd. Aktivity, služby a content providery, které jsou součástí zdrojového kódu aplikace, ale nejsou deklarovány v manifestu, nejsou pro systém viditelné a nemohou být tedy použity. Broadcast receiver tvoří ovšem výjimku a může být uveden v manifestu nebo vytvořen dynamicky ve zdrojovém kódu a až následně registrován v systému. 3.4 Historie verzí V době psaní této práce má Android již svou devatenáctou aktualizaci, čili systém Android verze 4.4 s API verze 19. Od verze 1.5 má každá důležitá aktualizace má také svou přezdívku. Každá přezdívka začíná abecedně o písmeno výše než předchozí aktualizace a vztahuje se k nějakému dezertu nebo cukrovince. Historie verzí a některé jejich nové funkce: 1.0 První oficiální vydání systému Android. Podporoval již kameru, fotoaparát, Google aplikace jako Maps, Gmail, Talk; přehrávač médií, vytáčení hlasem, Wi-Fi i Bluetooth. 1.5 Cupcake Začala podpora widgetů, předvídání textu při psaní, animované přechody mezi obrazovkami aplikací, nahrávání videí. 1.6 Donut Quick Search Box neboli řádka k rychlému prohledávání systému nebo internetu, Text-To-Speech engine, vícejazyková syntéza řeči. 2.0 Éclair Podpora více účtů na jednom zařízení, Bluetooth 2.1, podpora HTML 5. 22

28 3. GOOGLE ANDROID 2.2 Froyo Android Cloud to Device Messaging (C2DM), služba usnadňující vývojářům posílání dat ze serverů do aplikací. Funkce Wi-Fi hotspot, umožňující zařízení fungovat jako bezdrátový přístupový bod k internetu. 2.3 Gingerbread Near Field Communication (NFC), sada bezdrátových technologií krátkého dosahu, pro výměnu dat mezi dalšími zařízeními platformy Android, typicky do vzdálenosti 4cm. 3.0 Honeycomb Nové virtuální a holografické uživatelské rozhraní, přizpůsobitelný homescreen, upravená klávesnice. 4.0 Ice Cream Sandwich Vertikální seznam nedávno využívaných aplikací, zobrazen při dvojím klepnutí na tlačítko Home. Aplikace pro monitorování množství dat využívaných systémem či přímo aplikacemi. 4.1 Jelly Bean Google Cloud Messaging (GCM), nová verze C2DM, umožňující přijímat i zprávy od přístrojů na stejném připojení. 4.4 KitKat Optimalizace výkonu na zařízeních s nižšími hardwarovými specifikacemi. Bezdrátový tisk. Zabudované nahrávání obrazovky. Nový experimentální virtuální stroj ART. 23

29 4 Možnosti implementace JVXML na platformu Android V praktické části této práce bude tedy realizována klientská aplikace JVoiceXML pro platformu Android. Díky mobilnosti této platformy plynou pro klienta výhody v podobě neustálé dostupnosti pro uživatele a nezávislost na osobních počítačích. Mnohá zařízení s Androidem jsou dnes již neustále připojena k internetu pomocí mobilního připojení a v ČR je pokrytí technologií EDGE[11] u všech mobilních operátorů skoro 100%. To umožňuje textovému klientu připojení k VoiceXML úložištím z jakéhokoliv místa s mobilním signálem. Vzhledem k malé velikosti VoiceXML dokumentů i příslušných souborů s gramatikami (řádově stovky bajtů až desítky kilobajtů) by i sít s EDGE technologií dovolila rychlé získávání VoiceXML dokumentů a tak plynulý provoz klienta. Zařízení s Androidem jsou většinou schopná vést i telefonní hovory, takže už disponují mikrofonem a reproduktorem. To by byly nezbytné součásti pro hlasovou komunikaci s VoiceXML dokumentem. Pro textovou verzi klienta je dostupná virtuální klávesnice s QWERTY rozložením, pokud interpret bude požadovat vstup od uživatele. Vzhledem k tomu, že většina zařízení s platformou Android umožňuje ovládání dotykovým displejem, je velikost displeje samotného mnohem větší než u dřívějších mobilních telefonů s fyzickou klávesnicí. Textovému klientovi to tak umožňuje vypisovat informace uživateli s velikostí písma, která bude dobře čitelná i při větším množství textu. 4.1 Stav vývoje klienta před touto prací Před touto prací ještě nebyl vytvořen žádný hlasový ani textový klient pro Android. Na oficiálním fóru 1 JVoiceXML se už ovšem několik uživatelů zajímalo o možnost zpřístupnění interpretu na této platformě

30 4. MOŽNOSTI IMPLEMENTACE JVXML NA PLATFORMU ANDROID Jeden z těchto uživatelů se pokusil o tvorbu klienta sám. Na oficiálním úložišti zdrojového kódu pro projekt JVoiceXML mu byl vytvořen oddíl pro klient na platformu Android. Do tohoto oddílu zkopíroval nezbytné JVoiceXML knihovny, potřebné pro zprovoznění klienta. Dále už jen vytvořil balík pro klientskou aplikaci samotnou, ovšem bez jakýchkoliv funkcí JVoiceXML interpretu. Tento klient tedy zatím obsahuje jen základní uživatelské rozhraní s tlačítky bez funkčnosti. Aktuálně není známo, zda uživatel chtěl v práci pokračovat. Kromě tohoto pokusu byla před touto prací ještě vytvořena internetová stránka JVoiceXML Android Port na oficiálním portálu s dokumentací k interpretu. Tady měl být průběžně aktualizován průběh vývoje klienta pro Android, ovšem stránka je stále prázdná. 4.2 Možnosti implementace Před realizací klienta bylo potřeba vybrat způsob, jakým se bude přistupovat k interpretu JVoiceXML a dokumentům VoiceXML Připojení k JVoiceXML interpretu Standardně se klient připojuje k interpretu pomocí JNDI rozhraní, které používá RMI[18] registr pro nalezení služby jvoicexml. Poté je s interpretem v klientské aplikaci nakládáno jako s obvyklým Java objektem. Dalvik VM ovšem nedovoluje použití některých standardních Java balíků, včetně javax.naming, který obsahuje právě JNDI/RMI knihovny. Aplikace, která obsahuje kód z těchto balíků potom není zkompilována a nemůže být použita v systému Android. Existují ovšem způsoby jak tyto knihovny přesunout do jiného balíku, čímž Dalvik VM nepozná, že jde o nedovolenou knihovnu a kód zkompiluje. Další možnost je místo JNDI použít komunikaci přímo pomocí internetových socketů. Aplikace by tak komunikovala s intepretem zasíláním paketů a využívala by podporovaný balík java.net. Tato metoda je vhodná zejména pro vzdálený přístup k interpretu přes 25

31 4. MOŽNOSTI IMPLEMENTACE JVXML NA PLATFORMU ANDROID Internet. Klient by potřeboval vědět IP adresu stroje kde běží interpret a jeho port. Interpret může být také součástí klienta, kde by byl přímo vytvořen jako Java objekt a před startem by musel načíst konfiguraci pro aktuální prostředí a účel. V tomto případě by to byla konfigurace pro běh v prostředí systému Android a textovou komunikaci Získávání VoiceXML dokumentů K dokumentům se přistupuje přes HTTP protokol na internetové úložiště nebo pokud jsou uloženy na pamět ové kartě zařízení, je možno je otevírat odtud. Klient může k VoiceXML dokumentu přistupovat po dobu interpretace vzdáleně a vytvořit tak objekt File s URL adresou dokumentu. Druhou možností je dokument stáhnout na zařízení. Po zadání adresy by byl dokument nejprve stažen na pamět ovou kartu a odtud čten interpretem. Při uložení dokumentu na pamět ovou kartu by ovšem mohl vzniknout problém, pokud by dokument potřeboval pro správnou funkčnost další VoiceXML dokumenty nebo gramatiky z původního úložiště. Tuto možnost lze tedy použít jen tehdy, pokud má dokument v elementu <vxml> stanoven parametr xml:base s adresou původního úložiště s dalšími nezbytnými dokumenty. Ty by byly v případě potřeby klientem dodatečně přečteny a interpretovány. 4.3 Zvolený způsob implementace Do praktické části bylo zvoleno zavedení interpretu jako součást klienta v podobě Java objektu a nepřistupovat k němu vzdáleně. Jelikož Dalvik VM nepovoluje JNDI, chtěli tvůrci Androidu nejspíše odradit vývojáře aplikací od používání tohoto rozhraní. Tato možnost tedy nebyla zvolena. Vzdálený přístup pomocí socketů nebyl brán v úvahu, protože by mohly vzniknout neočekávané problémy. Tento způsob přístupu totiž zatím nebyl vyzkoušen vývojáři interpretu a vyžadoval by vytvoření nového potomka třídy TextCallManager z balíku org. 26

32 4. MOŽNOSTI IMPLEMENTACE JVXML NA PLATFORMU ANDROID Obrázek 4.1: Diagram komponent klienta jvoicexml.callmanager.text, jehož pomocí by aplikace k interpretu přistupovala. VoiceXML dokumenty budou stahovány na zařízení, jejich velikost je velmi malá a jsou rychle staženy. Nebude tedy potřeba udržovat k nim internetové připojení po dobu interpretace. Podmínkou tedy ovšem je, aby dokument obsahoval správně vyplněný parametr xml:base. Pro uživatele by mělo být ovládání klienta vcelku jednoduché. Po spuštění se uživatel dostane na hlavní obrazovku klienta, kde se bude nacházet textové pole pro výpisy klienta a informací z interpretace VoiceXML dokumentu. Dále textové pole pro vstup od uživatele a tlačítka pro odeslání vstupu, otevření VoiceXML dokumentu a pro start interpretace. Nejprve tedy uživatel musí vybrat VoiceXML dokument, tlačítko pro tento výběr otevře uživateli aktivitu, ve které zadá URL daného dokumentu. Ten je následně stažen a je možno začít jeho interpretaci. V případě potřeby uživatelského vstupu jej uživatel bude moci zadat do textového pole k tomu určeného a odeslat tlačítkem send. Interpretace pak pokračuje, dokud není potřeba dalšího uživatelského vstupu nebo se nedosáhne konce dokumentu. Po skončení interpretace je možno vybrat další dokument a spustit jej nebo aplikaci zavřít. 27

33 4. MOŽNOSTI IMPLEMENTACE JVXML NA PLATFORMU ANDROID Obrázek 4.2: UseCase diagram klienta 28

34 5 Realizace textového klienta Pro tvorbu klienta byly využity vývojová prostředí Eclipse IDE, Android SDK a Android Virtual Device, jako virtuální zařízení s OS Andoid pro testování klienta. Zdrojový kód klienta byl psán v jazyce Java verze 6, Dalvik VM zatím nepodporuje aplikace psány ve verzi Javy 7. Nezbytné JVoiceXML knihovny byly staženy z oficiálního projektového repozitáře 1 Subversion. Tyto knihovny byly připraveny při předchozím pokusu o tvorbu klienta. Musely ovšem projít několika úpravami, protože obsahovaly některé v Javě 6 nepodporované funkce, jako například funkce Switch pro proměnné typu String. Jméno textového klienta v prostředí Eclipse a jmenná hierarchie balíků pro zdrojový kód byly zvoleny jako org.jvoicexml. client.android. Byl tak dodržen způsob pojmenovávání knihoven a balíků v JVoiceXML projektu. 5.1 Hlavní využívané JVoiceXML knihovny JVoiceXMLMain Hlavní třída JVoiceXML interpretu. Spravuje všechny centrální zdroje potřebné pro interpretaci VoiceXML dokumentů a zahajuje sezení pro interakci uživatele s VoiceXML dokumenty. Třída je implementována jako singleton 2 a při startu jejího vlákna si načte všechny potřebné zdroje, jako je DocumentServer a ImplementationPlatform. Zároveň si udržuje také reference k těmto zdrojům. V případě tohoto textového klienta není DocumentServer potřeba, protože se přistupuje přímo k VoiceXML dokumentům. Implementační platforma je textová. 1. Speciální server na internetu, který provozují tvůrci projektu či programu (nebo jiní) a odkud je možno stahovat balíčky s aktualizacemi programů a knihoven. 2. Může vytvořit jen jednu instanci. 29

35 5. REALIZACE TEXTOVÉHO KLIENTA Session Sezení (session) se spustí, když uživatel začne komunikovat s kontextem VoiceXML interpretu. To pak pokračuje při načítání a zpracovávání VoiceXML dokumentů. Ukončí se pokud si to vyžádá uživatel, dokument nebo kontext interpretu. Sezení se začíná metodou Session.call(), jako parametr se přidává URI odkaz na místo, kde je umístěn VoiceXML dokument pro interpretaci. Každé sezení je možné použít jen pro jedno volání (call), pro další hovor (interpretaci nového dokumentu) je potřeba vytvořit nové sezení. Po konci sezení je třeba zavolat metodu Session.hangup(), aby došlo k uvolnění zdrojů používaných interpretem během sezení. Jde např. o textový server nebo procesor gramatik TextServer Třída, která slouží jako socketový[23] server. Umožňuje streamování 3 textu mezi interpretem a textovým rozhraním uživatele. Třída, která TextServer používá, musí implementovat rozhraní TextListener. Pomocí tohoto rozhraní je možno naslouchat příchozímu textu a odesílat uživatelský vstup. Před startem serveru se nejprve vybere port na který bude interpret a uživatel odesílat vstupy. Dále se také se serverem musí registrovat třída (implementující Text- Listener) pomocí metody TextServer.addTextListener(TextListener), které se bude odesílat textový výstup. Jedna instance TextServeru může zpracovat jen jedno sezení a je potřeba nová instance pro další interpretaci ConnectionInformation V případě textového klienta získává tato třída informace o připojení k TextServeru. Tyto informace získá přímo od instance TextServeru, pomocí metody TextServer.getConnectionInformation(). Následně jsou načteny interpretem před začátkem sezení. 3. Pojem streamování v tomto případě znamená, že tok dat přijímaný TextServerem z interpretu není nikam ukládán, ale rovnou vypisován uživateli na obrazovku a opačně. 30

36 5.2 Postup tvorby klienta Vytvoření Aktivit 5. REALIZACE TEXTOVÉHO KLIENTA Klient sestává ze dvou obrazovek s uživatelským rozhraním, umožňující uživateli otevírat VoiceXML dokumenty a interpretovat je. MainJVXMLActivity Je to hlavní třída textového klienta. Obsahuje většinu jeho funkcionality a zároveň tvoří hlavní obrazovkou aplikace. Je tedy potomkem třídy Activity a dědí dvě její metody, bez kterých by se nemohlo zobrazit uživatelské rozhraní. Metoda oncreateoptionsmenu() zobrazí nabídku s možnostmi aplikace. Jelikož textový klient zatím žádné pokročilé nastavení neposkytuje, je zobrazena jen prázdná řádka a možnosti k opuštění aplikace. Metoda oncreate() je volána jako první po spuštění aplikace, protože MainJVXMLActivity je uvedena jako spouštěcí třída v souboru manifest textového klienta. V těle metody se inicializují zdroje nezbytné pro spuštění a zobrazení aplikace a jeho grafického rozhraní. OpenVXMLActivity Tato aktivita je spuštěna při zmáčknutí tlačítka Open VXML. Ukáže uživateli řádek pro adresu dokumentu k interpretaci a tlačítko pro otevření adresy. Při otevírání adresy nejprve aktivita ověří, zda dokument na dané adrese existuje a poté začne jeho stahování. Jelikož se při stahování dokumentu využívají Java knihovny z balíku java.io, musí být stažení samotné provedeno v novém výpočetním vlákně. Dalvik VM totiž jinak neodvolí spuštění aplikace. K tomu účelu byla využita třída AsyncTask[27], která je součástí balíku android.os. Je určena právě pro aplikace platformy Android a příkazy v jejím těle jsou prováděny v novém vlákně. Stažený dokument je poté předán zpět aktivitě MainJVXMLActivity. 31

37 5. REALIZACE TEXTOVÉHO KLIENTA Obrázek 5.1: Dvě aktivity, ze kterých je tvořeno uživatelské rozhraní klienta. 32

38 5.2.2 AndroidTextConfiguration 5. REALIZACE TEXTOVÉHO KLIENTA Třída pro nastavení všech nezbytných komponent pro interpretaci VoiceXML dokumentu. Je využívána při vytváření instance JVoiceXMLMain, kde pomáhá nastavit potřebnou implementační platformu, dokumentový server, procesor gramatik, atd. Pro tento konkrétní textový klient jsou inicializovány jen nezbytné části pro zpracování textu a běh na OS Android JVoiceXML funkcionalita Pro napsání hlavní části aplikace, tedy možnost interpretace dokumentu JVoiceXML platformou, byly využity postupy uvedeny v Userguide a demonstračním příkladu org.jvoicexml. demo.embedded, který je umístěn v JVoiceXML depozitáři. Po získání VoiceXML dokumentu může uživatel začít jeho interpretaci tlačítkem Start. K tomu se vytvoří instance třídy JVoiceXML- Main s konfigurací AndroidTextConfiguration. Tím se získá hlavní vlákno interpretu, čekající na začátek sezení. Dále je vytvořeno vlákno pro TextServer, který je spouštěn na standardním 4 portu Z tohoto TextServeru jsou získány informace o připojení ConnectionInformation, které jsou poté předloženy běžící instanci JVoiceXMLMain. Ta pomocí tohoto připojení odesílá TextServeru informace během interpretace dokumentu. Vlastní sezení začne při zavolání metody call() s odkazem na VoiceXML dokument jako parametr. Třída (aktivita) MainJVXMLActivity musí také dostávat výstupy z TextServeru a posílat do něj vstupy. Proto implementuje rozhraní TextListener a po vytvoření TextServeru je aktuální instance MainJ- VXMLActivity u tohoto serveru registrována pomocí metody add- TextListener() Metody rozhraní TextListener TextListener umožňuje třídě MainJVXMLActivity naslouchat důležitým událostem při interpretaci dokumentu. TextServer tak poskytuje 4. Podle Userguide

39 5. REALIZACE TEXTOVÉHO KLIENTA informace, zda sezení už začalo nebo skončilo pomocí metod started(), connected() a disconnected(). Metody také o těchto událostech informují uživatele pomocí zpráv v grafickém rozhraní. Textový obsah VoiceXML dokumentu je přijat od TextServeru v podobě SSML dokumentu metodou outputssml(ssmldocument). Samotný text na výstup pro uživatele je z tohoto dokumentu získán metodou gettextcontent(). Pokud si interpretace vyžádá vstup od uživatele, může jej napsat do příslušného řádku v grafickém rozhraní a odeslat tlačítkem Send. Metoda inputtext() jej pak předá TextServeru a ten pak běžící instanci JVoiceXMLMain pro zpracování Kompatibilita s OS Android Aby byl textový klient celkově kompatibilní a použitelný na platformě Android, musely kromě JNDI projít úpravami ještě některé další části JVoiceXML knihoven i aplikace třetích stran. V balíku org.jvoicexml byla například používána třída AudioInputStream, která se nachází ve standardním Java balíku javax.sound. Proto Dalvik VM neprovede kompilaci, přestože se v klientu nepoužívá zvuk. K tomuto účelu jsou totiž na Androidu používány třídy z balíku android.media. Třída tedy byla změněna a kód přizpůsoben pro jednoduchý InputStream což pro textový klient stačí. V případě rozšíření na zvukového klienta, může být kód přepsán tak, aby používal android.media. ECMAScript používaný standardně v JVoiceXML interpretu také nebyl podporován virtuálním strojem Dalvik. Jako náhrada se musela použít implementace ECMAScriptu Rhino[16], ve verzi 1.7. Rhino může být spuštěn v takzvaném interpretovaném módu, díky kterému může běžet i na Dalvik VM. Klient je kompatibilní se systémy Android verze 2.2 (API úrovně 8) a výše. Podle nástroje Android SDK by tak měl být schopen provozu na 95 % zařízení s platformou Android. 34

40 5. REALIZACE TEXTOVÉHO KLIENTA Obrázek 5.2: Diagram tříd textového klienta. 35