Systemy syntezy mowy z tekstu na urządzeniach mobilnych

Transkrypt

1 UNIWERSYTET IM. ADAMA MICKIEWICZA WYDZIAŁ MATEMATYKI I INFORMATYKI Tomasz Konieczny nr albumu: Systemy syntezy mowy z tekstu na urządzeniach mobilnych Praca magisterska na kierunku: INFORMATYKA Promotor: dr hab. Krzysztof Jassem Poznań 2013

2 Spis treści Wprowadzenie Systemy syntezy mowy z tekstu Historia systemów syntezy mowy Podział systemów syntezy mowy Pierwsze koncepcje systemów syntezy mowy Konkatenacyjne systemy syntezy mowy Korpusowe systemy syntezy mowy Systemy syntezy mowy oparte na ukrytych modelach Markowa Cechy systemu Android Specyfika działania systemu Wstępne informacje na temat systemu Cykl życia aplikacji i zarządzanie procesami Zarządzenie uprawnieniami Specyfika działania aplikacji Budowa i sposób działania aplikacji Struktura i sposób działania interfejsu użytkownika Zależności pomiędzy elementami aplikacji Wprowadzenie do tematyki dotyczącej środowiska programistycznego Android Informacje na temat pakietu programistycznego Cechy środowiska programistycznego Analiza wybranych interfejsów udostępnionych programistom Wykorzystanie systemów syntezy mowy na urządzeniach mobilnych Historia systemów syntezy mowy na platformie Android Obsługa systemów syntezy mowy przez system operacyjny Android Analiza istniejących systemów mowy z tekstu na urządzenia mobilne Analiza istniejących aplikacji wykorzystujących systemy syntezy mowy Możliwe sposoby rozwoju aplikacji i systemów TTS na platformie Android Analiza projektu magisterskiego Założenia i cele projektu Analiza budowy aplikacji Analiza głównego menu aplikacji

3 Analiza aktywności prezentujących możliwości wykorzystania systemów TTS Analiza aktywności ustawień systemu syntezy mowy Analiza API dotyczącego systemów syntezy mowy na platformie Android Konfiguracja systemu syntezy mowy Interfejsy umożliwiające korzystanie z systemu syntezy mowy Metody dodatkowe i pomocnicze Zakres zastosowania API Android dotyczący systemów syntezy mowy Możliwości Ograniczenia Zakończenie A. Dokumentacja projektu A.1. Tytuł projektu A.2. Założenia projektu A.2.1. Wizja projektu A.2.2. Uzasadnienie istnienia projektu A.2.3. Główne cele projektu A.2.4. Kluczowe rezultaty dla projektu A.2.5. Członkowie zespołu i interesariusze A.2.6. Wymagane zasoby projektu A.2.7. Wymagania funkcjonalne i opis zakresu projektu A.2.8. Zagrożenia dla powodzenia projektu oraz sposoby ich zminimalizowania 69 A.2.9. Plan prac wykonywanych na osi czasu A.3. Wykonanie A.3.1. Przegląd 1: A.3.2. Przegląd 2: A.3.3. Przegląd 3: A.4. Zamykanie A.4.1. Satysfakcja użytkowników i promotora A.4.2. Nauka wyniesiona z projektu A.4.3. Czy zostało już wszystko ukończone? Bibliografia Spis tabel Spis rysunków

4 Wprowadzenie Patrząc retrospektywnie na rozwój wielu dziedzin nauki, nie trudno jest wysnuć wniosek, że motywacją do ich rozwoju była chęć ludzi do poznania mechanizmów ich otaczających. Wśród tych mechanizmów jednym z najbardziej dręczących ludzkość jest sposób funkcjonowania ludzkiego organizmu. Od wieków badacze skupiają swoje pracę nad rozwiązaniem zagadki działania układu krwionośnego, budowy i funkcjonowania ludzkiego mózgu czy sposobu przetwarzania przez niego informacji. Przez tę ciekawość wykształciły się takie dziedziny nauki jak biologia, medycyna, fizjologia, psychologia czy socjologia. Chęć zrozumienia funkcjonowania ludzkiego organizmu nie jest obca także informatykom. Nie budzi wątpliwości, że chęć odwzorowania (co można tłumaczyć jako chęć zrozumienia) ludzkich zdolności za pomocą technologii i komputerów jest podyktowana ciekawością tego jak zbudowany jest ludzki organizm. Narzucającym się przykładem takich badań są badania nad sztuczną inteligencją, konstruowaniem robotów czy tworzeniem syntetycznej mowy. Rozwój tych nauk wynika z chęci poznania i odwzorowania cech charakterystycznych dla gatunku ludzkiego sposobu myślenia, poruszania się czy komunikacji za pomocą mowy. Porozumiewanie się ludzi za pomocą słów fascynuje informatyków od wielu wieków. Jednym z kierunków badań jest analiza umiejętności człowieka do budowania zdań z zastosowaniem gramatyki. Drugim popularnym nurtem badań w informatyce jest analiza tego, w jaki sposób dźwięki generowane przez ludzki aparat mowy są zamieniane w słowa. Nadrzędnym celem tego typu badań jest stworzenie syntetycznej mowy, która będzie jak najdokładniej naśladowała mowę ludzką. Wraz z rozwojem technologii, w dziedzinie syntezy mowy pojawiały się nowe możliwości. Dotyczyły one efektywności mechanizmów syntezy mowy oraz jakości generowanych przez nie wypowiedzi, wynikające z możliwości wykorzystania nowych rozwiązań technologicznych. Każdy etap rozwoju technologii informatycznych, takich jak możliwość nagrywania dźwięków czy zwiększenie mocy obliczeniowej komputerów, wpływał w sposób istotny na rozwój systemów syntezy mowy. Nie inaczej było w przypadku kiedy świat informatyki opanowała moda na urządzenia mobilne małe, przenośne komputery, które udostępniają wiele funkcjonalności, posiadając jednocześnie bardzo ograniczone zasoby sprzętowe. Wraz z nimi zaistniała potrzeba minimalizacji wymagań sprzętowych oprogramowania. Opisywanej tendencji podległy również systemy syntezy mowy. Wersje mobilne, które dostępne są, między innymi, wraz z systemem operacyjnym Android charakteryzują się jakością porównywalną z wersjami, które zdobyły popularność na urządzeniach stacjonarnych. 3

5 ROZDZIAŁ 1 Systemy syntezy mowy z tekstu 1.1. Historia systemów syntezy mowy Pierwsze prace nad systemami syntezy mowy nie łączą się dziedziną informatyki i komputerami. Zainteresowania dotyczące symulacji ludzkiej mowy były tak samo popularne, jak rozwijanie innych technologi i rozwijane były równolegle. Ich rozwój nie jest wpisany w dziedzinę, jaką są nauki informatyczne. Rozwój informatyki przyczynił się do rozwoju systemów TTS 1, jednak te dwie dziedziny nauki przez długi czas rozwijały się niezależnie. Pierwsze wzmianki na temat systemów TTS pochodzą w końca XVIII wieku, kiedy to badania nad stworzeniem sztucznej mowy prowadził Wolfgang von Kempelen, ówczesny niemiecki wynalazca[4]. Realizowany przez niego projekt polegał na stworzeniu urządzenia, które za pomocą mechanizmów przypominających w budowie instrumenty dęte imitowały dźwięki podobne do głosek. Maszyna miała bardzo ograniczone możliwości funkcjonalnie, niemniej pozwalała na stworzenie prawdziwej, syntetycznej mowy. Urządzenia tego typu, korzystające z dorobku twórców instrumentów muzycznych, tworzone były również w kolejnych wiekach. Ich budowa była analogiczna do maszyny autorstwa von Kempelena i ulegała ciągłemu usprawnianiu. Prawdziwy rozwój mowy syntetycznej przyniósł jednak rozwój elektryczności[4]. Przełom nastąpił w roku 1970 i łączy się już z połączeniem dziedziny tworzenia mowy syntetycznej i informatyki. Od tego czasu systemy TTS są nierozerwalnie i bezpośrednio połączone z technologiami komputerowymi. Efektem asymilacji TTS z dziedziną informatyki było powstanie wielu technologii tworzenia systemów przetwarzających tekst na mowę. Próby dotyczące stworzenia syntetycznej mowy rozpoczęły się od wielu różnych metodologii, wśród których główną została synteza formantowa, która łączy się z tematyką przetwarzania sygnałów dźwiękowych do postaci podobnej do formantów głosek[5]. 1 Text To Speech (TTS) angielska i ogólnie przyjęta nazwa dla określania systemów syntezy mowy z tekstu 4

6 1.2. Podział systemów syntezy mowy Pierwsze koncepcje systemów syntezy mowy Kategoryzacja systemów syntezy mowy łączy się z ciągłym poszukiwaniem satysfakcjonujących rozwiązań. Każda technologia jest w jakiś sposób od siebie zależna. Należy przez to rozumieć, że każda kolejna technika tworzenia systemów TTS łączy się wnioskami wyciągniętymi z niepowodzeń poprzednich rozwiązań. Każdy rodzaj systemu TTS to tak naprawdę inna droga prowadząca do osiągnięcia tego samego rozwiązania: wygenerowania syntetycznej mowy. Od samego początku głównym problemem, nad jakimi zmagali się twórcy systemów TTS była jakość wypowiedzi. Pierwszą popularną metodologią tworzenia systemów TTS była, wymieniona wcześniej, metoda formantowa. Jakość mowy generowana tą metodą jest najgorszą pod względem jakości metodą komputerową. Generowanie mowy tą metodą polega na tworzeniu filtrów, za pomocą których generowane są dźwięki o częstotliwościach odpowiadającym konkretnym głoskom (tzw. fonemów 2 ). Generowanie wypowiedzi polega zatem na wygenerowaniu głosek w odpowiedniej kolejności i połączeniu ich. Metoda nie uwzględnia tzw. alofonów 3, stąd też dźwięki często zlewają się ze sobą. Bardzo szybko okazało się, że metoda formantowa nie pozwoli wygenerować mowy, która będzie podobna do mowy ludzkiej. Stąd też rozwijały się nowe koncepcje. Jedną z teoretycznych koncepcji, która przez długi czas była rozpatrywana jest metoda artykulacyjna. Jej założeniem było utworzenie mowy, bazując na budowie ludzkiego aparatu mowy. Twórcy metody określili, że do stworzenia syntetycznej mowy ludzkiej konieczne jest użycie około sześćdziesięciu zależnych parametrów. Założenie to okazało się zaporą w rozwoju tej koncepcji. Efektem tego było przeistoczenie się metody artykulacyjnej w koncepcję czysto teoretyczną, w praktyce nigdy nierozpowszechnioną Konkatenacyjne systemy syntezy mowy Metoda konkatenacyjna, która spopularyzowała systemy TTS była rozwijana od początku lat 90. dwudziestego wieku. Metoda ta okazała się na tyle efektywna, że była rozwijana i implementowana przez blisko czterdzieści lat. Jej forma ulegała zmianie, była oparta o te same, niezmienne reguły. Atutem tej metody jest nie tylko możliwość generowania mowy dobrej jakości, ale także łatwość jej generowania. Syntezatory opierające swoje działanie na tej metodzie nazywane są syntezatorami drugiej generacji[9]. 2 fonem najmniejsza jednostka mowy, która można rozróżnić w danym języku 3 alofon realizacja fonemu, jego inna reprezentacja dźwiękowa, która zależy od pozycji fonemu w wyrazie 5

7 Istotą metody konkatenacyjnej jest łączenie ze sobą difonów 4 i trifonów 5, które zostały wcześniej nagrane[5]. O jakości generowanej mowy decyduje jakość nagrań i wielkość bazy difonów/trifonów. W tej metodzie istnieją zależności pomiędzy bazą dźwięków a działaniem syntezatora: im baza jest większa tym wypowiedzi generowane są dłużej, ale wzrasta ich jakość im baza jest mniejsza tym wygenerowane wypowiedzi zawierają więcej błędów, ale generowanie wypowiedzi jest szybsze. Wnioskiem z zastosowań metody konkatenacyjnej jest fakt, że tylko urządzenia posiadające odpowiednio duże zasoby sprzętowe mogą korzystać z systemów TTS o zadowalającej jakości. Prace koncepcyjne nad tą metodą w głównej mierze dotyczyły optymalizacji mechanizmu i baz. Początkowo do budowania syntezatora używano baz sylab, która pozwala na uzyskanie dobrych rezultatów. Problemem okazała się wielkość korpusu. Baza zawierająca wystarczająco wiele kombinacji sylab zawierałaby setki tysięcy wpisów. Stąd też narodził się pomysł wykorzystania difonów, których składanie daje zadowalające efekty już przy korpusie posiadającym 1500 elementów. Koncepcja dotycząca wykorzystania trifonów podyktowana była zwiększaniem jakości mowy, ponieważ łączenie trzech sąsiadujących głosek pozwala na dokładniejsze oddanie ich kontekstu. Mimo tego samo brzmienie mowy syntezowanej metodą konkatenacyjną nie jest idealne. Wynika to przede wszystkim z tego, że nagrania difonów i trifonów nie są w stanie przechowywać kontekstu wypowiedzi i zawsze brzmią tak samo. Łączenia wyrazów brzmią różnie w zależności od kontekstu zdania. Tych różnic metoda konkatenacyjna nie przewiduje, dlatego też wypowiedzi generowane tą metodą są zrozumiałe i przy odpowiednio dużej bazie dokładne[5], jednak zazwyczaj brzmią sztucznie Korpusowe systemy syntezy mowy Metoda korpusowa, znana również pod nazwą Unit Selection, jest rozwinięciem metody konkatenacyjnej. Metoda powstała jako odpowiedź na problem braku różnych kontekstów dla tych samych difonów[9] (główny problem metody konkatenacyjnej, opisany w punkcie 1.2.2). Metoda korpusowa zakłada istnienie bazy difonów wraz z wariantami. Oznacza to możliwość wystąpienia danego difonu w bazie kilka lub nawet kilkaset razy. Dla rozwiązania problemu generowania wymowy i wyboru odpowiednich difonów lub trifonów liczona jest 4 difon pojęcie z dziedziny fonetyki, oznacza przejście pomiędzy dwoma sąsiadującymi głoskami; pojęcie zwykle używane do określenia nagrania przejść pomiędzy głoskami 5 trifon pojęcie z dziedziny fonetyki, zbieżne z pojęciem difon, z tą różnicą, że określa przejście pomiędzy trzema sąsiadującymi ze sobą głoskami 6

8 tzw. funkcja kosztu szacująca, która kombinacja rekordów z bazy pozwoli osiągnąć najlepszy efekt[9]. Działanie tej funkcji polega w praktyce na oszacowaniu kilku możliwych wariantów połączeń difonów (lub trifonów) występujących w korpusie i porównaniu ich efektywności. Efektem działania funkcji jest wybór odpowiednich jednostek akustycznych z korpusu[5]. System syntezy mowy łączy je ze sobą, tworząc w tej sposób możliwie najlepszą jakościowo wypowiedź Systemy syntezy mowy oparte na ukrytych modelach Markowa Najnowocześniejsza i jednocześnie najbardziej obiecująca metoda tworzenia systemów syntezy opiera się na ukrytych modelach Markowa (Hidden Markov Model (HMM)). Wraz z przednio opisaną metodą Unit Selection, metoda HMM wchodzi w skład tzw. technik trzeciej generacji w tworzeniu systemów TTS[9]. HMM jest koncepcją w pełni matematyczną, należy do metod statystycznych[5]. Wiele prac nad mechanizmami TTS sprowadzało się do prób wykorzystania metod statystycznych do udoskonalania jakości generowanych wypowiedzi. Praktyka jednak pokazała, że najefektywniejszym sposobem jest wykorzystanie ukrytych modeli Markowa[9]. W metodzie tej system syntezy mowy opiera się na modelu, który nie jest znany od samego początku, lecz tworzony jest wraz z działaniem syntezatora mowy. Działanie, które ma na celu tworzenie odpowiedniego modelu, zwane jest treningiem syntezatora mowy. Do treningu wykorzystywane są ukryte modele Markowa, które są statystyczną metodą klasyfikowania sekwencji zdarzeń, w tym przypadku łączenia się jednostek akustycznych[5]. Trening polega na podawaniu syntezatorowi mowy kolejnych wypowiedzi uczących z bazy, która ma nauczyć mechanizm TTS jak prawidłowo konstruować wypowiedzi. Do przeprowadzenia treningu niezbędne są odpowiednio skonstruowane słowniki oraz ukryte modele Markowa, które w efektywny sposób pozwolą na kategoryzowanie jednostek akustycznej z bazy treningowej. W późniejszym etapie opracowywane są teksty, które mają na celu weryfikację tego czy trening przeprowadzony na mechanizmie był efektywny. W efekcie, syntezatory stworzone z wykorzystaniem HMM charakteryzują się bardzo wysoką jakością. Wypowiedzi generowane przez te mechanizmy często przypominają głos ludzki. Najważniejszym etapem tworzenia tych systemów jest odpowiednie przygotowanie modeli i przeprowadzenie treningów, za pomocą odpowiednich algorytmów, które pozwolą na stworzenie efektywnego modelu służącego do budowania wypowiedzi. 7

9 ROZDZIAŁ 2 Cechy systemu Android 2.1. Specyfika działania systemu Wstępne informacje na temat systemu System Android jest systemem operacyjnym, który przeznaczony jest na urządzenia mobilne, takie jak telefony komórkowe, tablety czy tak zwane smartfony, czyli urządzenia, które swoją funkcjonalnością przekraczają możliwości zwykłych telefonów komórkowych (posiadają wbudowane urządzenia takie jak odbiorniki GPS, aparaty fotograficzne itp.). Bazą systemu Android jest system operacyjny Linux[3]. Android jest rozpowszechniany na publicznej licencji GNU GPL 1. System ten rozwijany jest przez sojusz Open Handset Alliance (w skład którego wchodzi m.in. firma Google)[3]. System operacyjny Android wydany został w wielu różnych wersjach, zależnych od przeznaczenia. Jedną z pierwszych, popularnych wersji była wersja oznaczona jako 1.5, która charakteryzowała się niską wydajnością i dużą ilością błędów. Z biegiem czasu powstawały kolejne wydania, których przeznaczenie było ściśle określone. I tak przykładowo wersje 2.0, 2.1 czy 2.3 kierowane były do użytkowników smartfonów niższej klasy (tzn. o gorszych parametrach technicznych), choć początkowo były to najpopularniejsze wersje instalowane na większości urządzeń. W wersje od 3.0 wyposażane są głównie tablety, natomiast od 4.0 kierowane są do użytkowników nowszych tabletów i smartfonów. Aktualnie w przygotowaniu jest wersja 5.0. Co ważne przeznaczenie systemu Android ma tylko znaczenie teoretyczne, ponieważ każdy użytkownik może zainstalować na swoim urządzeniu system w dowolnej wersji. Instalując wybraną edycję systemu użytkownik musi jednak zwrócić uwagę, czy wszystkie urządzenia peryferyjne tabletu/smartfona są wspierane przez tę wersję Cykl życia aplikacji i zarządzanie procesami Specyfika działania aplikacji i procesów systemu Android jest związana zarówno z jego pochodzeniem, jak i przeznaczeniem. W związku z tym że Android wywodzi się z systemu Linux, sposób działania procesów oraz zarządzanie nimi od strony technicznej jest podobne do tego, który występuje na innych systemach operacyjnych z tej rodziny. Zarządzanie procesami 1 GNU General Public Licence licencja wolnego i otwartego oprogramowania, której założeniami jest wolność uruchamiania programu w dowolnym celu, dowolność dostosowywania go do potrzeb użytkownika oraz wolność udoskonalania i publicznego rozpowszechniania własnych usprawnień 8

10 i cykl życia aplikacji związany jest również ze specyfiką działania, wymaganiami i ograniczeniami urządzeń przenośnych, które znacząco różnią się tymi elementami od standardowych komputerów stacjonarnych i laptopów. Urządzenia mobilne stworzone są do obsługi określonych urządzeń peryferyjnych i do spełniania określonych zadań, takich jak robienie zdjęć, nawiązywanie połączeń telefonicznych i internetowych. W związku z tym system Android musiał zostać przygotowany do rozwiązywania innych problemów i zależności natury technicznej w stosunku do standardowych komputerów. Twórcy systemu Android, jak i programiści tworzący aplikacje na tę platformę muszą radzić sobie z następującymi aspektami: Optymalizacją zużycia energii (wiążącą się z krótkim czasem działania urządzenia od czasu naładowania baterii do całkowitego jej rozładowania) Ograniczonością zasobów i niską wydajności urządzeń mobilnych, w tym m. in.: Małą ilość pamięci RAM (od 128 MB) Małą ilością miejsca na dysku systemowym (od 80 MB) Słabą wydajnością procesora (od 400 MHz) Słabą wydajnością procesorów graficznych Ustalaniem priorytetu funkcjonalności systemu (zarządzanie podstawowymi procesami jak tryb czuwania telefonu czy odbieranie wiadomości SMS) Podczas programowania aplikacji na platformę Android programista nie ma do czynienia bezpośrednio z w/w problemami, ale aby tworzyć wydajne aplikacje musi mieć świadomość ich występowania. Problemy te rozwiązane są systemowo, tzn. poprzez elementy systemu, którymi można na różne sposoby sterować. Programista może optymalizować działanie swoich aplikacji. Możliwe jest to dzięki istnieniu kilku podstawowych składowych interfejsu programistycznego Android, którymi programista może się posługiwać. Każdy z tych elementów cechuje się własnym sposobem działania, możliwościami i ograniczeniami. Każda aplikacja działająca na systemie Android jest osobnym procesem[1]. Jej podstawową składową jest tzw. aktywność (ang. activity), która jest rodzajem kontrolera połączonego z klasą zarządzającą widokiem[6]. System Android stworzony jest tak, że sam zarządza działającymi na nim procesami. Mechanizm zarządzania procesami polega na układaniu aktywności na stosie. Każda nowo uruchomiona aktywność odkładana jest jego szczycie. Na podstawie pozycji na stosie ustalana jest hierarchia ważności aktywności. Im aktywność jest niższej na stosie, tym jej priorytet podtrzymywania działania przez system jest niższy. Priorytety te wykorzystywane są w procesie odzyskiwania zasobów, co jest niczym innym jak rodzajem radzenia sobie systemu z ograniczonością zasobów. Gdy na urządzeniu zaczyna brakować 9

11 zasobów (np. pamięci RAM) system może automatycznie podjąć decyzję o ich uwolnieniu poprzez usunięcie ze stosu aktywności o najniższym priorytecie[7]. Wyżej wymienione rozwiązanie jest typowo systemowe i niezależne od programisty, co niesie ze sobą zarówno pozytywne, jak i negatywne skutki. Z jednej strony nie ma obaw, że zasoby urządzenia niespodziewanie wyczerpią się i urządzenie zacznie się np. zawieszać. Z drugiej strony jednak taki sposób zarządzania aktywnościami mógłby prowadzić do niekontrolowanego usuwania ze stosu aktywności, które mimo niskiego priorytetu pełną ważną rolę i powinny ciągle działać. Z tego powodu twórcy systemu wprowadzili mechanizm pozwalający bezpośrednio kontrolować cykl życia każdej aktywności, którym można zarządzać za pomocą odpowiednich metod programistycznych. Każda aktywność składa się z metod, które implementuje programista, jednak konieczne jest też przestrzeganie pewnych z góry określonych zasad programistycznych odnoszących się do aktywności. Programiści mogą tworzyć i implementować dowolne metody, jednak do sterowania aktywnościami konieczne jest używanie wielu, z góry określonych metod. Jest to związane z koniecznością zarządzania jej cyklem życia. Do sterowania nim służą z góry określone metody, których implementacja bezpośrednio informuje system, jakie działanie dotyczące aktywności ma podjąć w określonym momencie. Metody te są bardzo opisowe i w pełni wyczerpują temat zarządzania działaniem aktywności. Przedstawia je rysunek 2.1, który obrazuje również cykl życia aplikacji oraz metody programistyczne, które pozwalają na kontrolowanie aktywności. 10

12 Rysunek 2.1. Cykl życia aktywności (opracowanie własne na podstawie [1]) Po włączeniu aplikacji aktywność jest budowana poprzez kolejne wywołanie metod: oncreate(), onstart() i onresume(). Jeśli aplikacja przejdzie w tryb działania, automatycznie zostaną wywołane metody onpause() oraz onstop(). Po wznowieniu aktywności ponownie wykonane zostaną metody onstart() i onresume(), jednak nie zostanie już wywołana metoda oncreate(). Zamiast niej wykonany będzie kod z metody onresume(). W ten sposób (za pomocą wszystkich wyżej opisanych metod) programista może w prosty sposób zarządzać każdym etapem działania aktywności od jej startu aż do zamknięcia[8]. Aktywności budowane są jako podstawa każdej aplikacji działającej w systemie Android. Mimo tego, że aktywności pełnią funkcję kontrolerów aplikacji to funkcjonalności programu, które odpowiadają za jego logikę (i powinny działać asynchronicznie do widoku) muszą być implementowane w inny sposób. Do tego służą między innym serwisy (ang. service), które posiadają swój własny cykl życia, odmienny od cyklu życia aktywności[7]. W odróżnieniu od aktywności, serwis nie jest osobnym procesem. Serwisy są częścią aplikacji i działają w jej obrębie. Co równie ważne serwisy nie są również wątkami, są częścią aplikacji, która działa w tle i która odpowiada na działania użytkownika, lecz nie 11

13 ma związku z wyświetlaniem treści. Serwisy przykładowo mogą odpowiadać za odtwarzanie muzyki, pobieranie treści z Internetu czy przetwarzanie tekstu do postaci mowy (za pomocą syntezatora mowy)[8]. Serwisy mogą być sterowane za pomocą mechanizmów, które podobne są do mechanizmów sterowania aktywnościami, jednak są od nich niezależne i nie działają w wątku głównym aplikacji. Serwisy mogą działać niezależnie od aktywności, jednak mogą zostać do niej przypinane (tzn. łączyć się z nią i świadczyć dla niej usługi). Taka niezależność oznacza również możliwość utrzymania w działaniu wielu elementów logiki aplikacji bez uzależniania się od cyklu życia i priorytetu aktywności. Jest to podyktowane tym, że system Android utrzymuje w działaniu każdy serwis, który jest w jakikolwiek sposób wykorzystywany lub podpięty do dowolnej aktywności. Oprócz wyżej wymienionych elementów systemu istnieje wiele standardowych mechanizmów, takich jak wątki czy zadania (ang. tasks). Główna część aplikacji, która sterowana jest za pomocą aktywności, nazywana jest wątkiem głównym. Możliwie jest tworzenie logiki poza nim poprzez tworzenie osobnych wątków i zadań[3]. Mogą być one tworzone standardowo za pomocą interfejsów dostępnych w języku Java, jak i z wykorzystaniem narzędzi udostępnionych ze środowiskiem programistycznym dla systemu Android. Bez względu jednak na technikę implementacji elementy te nie są w żaden sposób specyficzne dla systemu i działają w sposób znany z innych platform. Mechanizmy przedstawione powyżej są jedynie poglądowe, ponieważ złożoność problemu zarządzania procesami w systemie Android jest większa. Powyższy opis pozwala jednak na zrozumienie tego, w jaki sposób działa sam system i jakie mechanizmy decydują o wydajności i efektywności działania aplikacji. Istnieje wiele innych podziałów dotyczących procesów działających w systemie Android o różnym stopniu skomplikowania i złożoności. Podziały te systematyzują procesy (w tym aktywności, serwisy, wątki i zadania) ze względu na ich dostępność i widoczność Zarządzenie uprawnieniami Oprócz zarządzania procesami system Android zawiera także mechanizmy służące do ustalania uprawnień aplikacji dotyczących dostępu do zasobów i urządzeń wbudowanych w urządzenie mobilne. Mechanizm uprawnień został wprowadzony do systemu przede wszystkim w celu usprawnienia kontroli nad zakresem działania aplikacji[6]. Za pomocą uprawnień programista ustala, z jakich zasobów może korzystać program. Dzięki temu użytkownik korzystający z aplikacji dokładnie wie, z jakich zasobów urządzenia mobilnego korzysta dana aplikacja, a programista ją tworzący ma większą kontrolę nad zakresem jej działania. Dostęp do zasobów urządzenia rozumiany jest w tym przypadku dwojako[8]: Jako dostęp do danych zawartych w pamięci urządzenia, tj. listy kontaktów, listy wiadomości tekstowych, historii połączeń itp. 12

14 Jako możliwość wykorzystania funkcji urządzeń wbudowanych: dostępu do Internetu poprzez WiFi, korzystanie z odbiornika GPS czy dostępu do urządzenia bluetooth Ogólnym założeniem architektury systemu Android jest to, że domyślnie stworzona aplikacja nie ma nadanych żadnych uprawnień. Oznacza to, że programista chcąc skorzystać z jakichkolwiek zasobów urządzenia musi w odpowiednim pliku (nazywanym plikiem manifestu) dodać uprawnienia dla tworzonej aplikacji. Efektem wykorzystywania przez aplikacje zasobów systemu Android, jest posiadanie przez nie konkretnych uprawnień. Fakt ten łączony jest często z błędnym założeniem, że uprawnienia służą do ochrony danych użytkownika. Uprawnienia pełnią przede wszystkim rolę w udostępnianiu zasobów oraz służą do informowania użytkownika, z jakich zasobów korzysta aplikacja. Obecność uprawnień jest oczywistym elementem funkcjonalnego programu. Bez nich aplikacje byłyby bezużyteczne, ponieważ oczywistym jest fakt, że większość aplikacji tworzona jest po to, aby w sposób odpowiedni korzystać i przetwarzać zasoby systemu i urządzenia mobilnego Specyfika działania aplikacji Budowa i sposób działania aplikacji Głównymi elementami aplikacji od strony programistycznej są aktywności. Obecność aktywności jest cechą charakterystyczną środowiska programistycznego systemu Android. Pozostałe elementy aplikacji, takie jak schematy widoków, modele czy zasoby (zarówno tekstowe, jak i graficzne) są zawarte w określonych katalogach, ujętych w specyfikacji technicznej systemu. Nie wyróżniają się one jednak na tle innych środowisk programistycznych. Dodatkowym, charakterystycznym elementem systemu jest plik manifestu, który zawiera informacje o strukturze aplikacji. Plik manifestu jest plikiem o rozszerzeniu XML (Extensible Markup Language) i zawsze posiada tę samą nazwę: AndroidManifest.xml. W pliku tym programista musi zawrzeć wszystkie niezbędne informacje na temat własności aplikacji, takie jak: Minimalna wersja systemu Android, na której będzie działała aplikacja Docelowa wersja systemu, na którą jest przeznaczona aplikacja Uprawnienia (ang. permissions), które posiada aplikacja Informacje na temat aktywności i ich cech (np. określenie, która aktywność jest startową, czy aktywność powinna reagować na zmianę przechyłu telefonu itp.) Bez względu na wersje systemu, każda aplikacja działa w oparciu o te same zasady i struktury. Każda aplikacja to nic innego jak zbiór aktywności. Precyzując do wersji 4.1 (o nazwie 13

15 Jelly Bean) systemu, każda aplikacja była zbiorem aktywności, bez żadnego, z góry określonego stosu wywołań (ang. workflow). Oznacza to, że programista tworząc aplikację, tworzy tak naprawdę każdą aktywność osobno, nie zastanawiając się nad zależnościami pomiędzy nimi. Otwarcie nowej aktywności jest realizowane poprzez stworzenie i wywołanie odpowiedniego obiektu, zwanego Intent. Intent to rodzaj obiektu, który zawiera informacje na temat aktualnej aktywności oraz aktywności, która ma zostać otwarta. W ten sposób programista może poinformować system, jaką aktywność chce zainicjalizować oraz jaka aktywność jest bazową. Przykładowo: gdy włączona jest aktywność o nazwie MainActivity i z jej poziomu programista chce zaprogramować możliwość otworzenia nowej aktywności (o przykładowej nazwie OtherActivity), może to zrobić za pomocą szeregu poleceń (patrz: kod źródłowy 2.1). 1 I n t e n t mintent = new I n t e n t ( MainActivity. this, OtherActivity. class ) ; 2 MainActivity. this. s t a r t A c t i v i t y ( mintent ) ; Kod źródłowy 2.1. Przykład wywołania nowej aktywności Naturalną konsekwencją takiego stanu rzeczy jest to, że każda aktywność może zostać utworzona przez inną aktywość w ramach danej aplikacji. Oznacza to również, że wszystkie aktywności danej aplikacji działają w ramach jednego procesu. Po zamknięciu wywołanej aktywności przywracana jest poprzednia i w jej ramach wykonuje się metoda onresume(). Wszystko odbywa się zgodnie z cyklem życia aktywności. Gdy zostanie zamknięta ostatnia aktywność aplikacji, zakończony zostaje cały jej proces, co równoważne jest z zakończeniem działania całego programu. Opisany sposób zarządzania aktywnościami został usprawniony w wersji 4.1. Zmiany wprowadzone w tej wersji nie wpłynęły na sam sposób zarządzania aktywnościami. Dodano natomiast dodatkową opcję, którą można dodać jako atrybut aktywności w pliku manifestu. Atrybut android:parentactivityname można dodać do tagu dowolnej aktywności, czyli w ramach tagu activity. Przykładowy kod źródłowy widoczny jest na przykładzie <a c t i v i t y android : name= C h i l d A c t i v i t y 2 android : parentactivityname = P a r e n t A c t i v i t y > Kod źródłowy 2.2. Przykład ustawienia zależności pomiędzy aktywnościami Za pomocą tej dodatkowej funkcjonalności, architekci systemu Android chcieli usprawnić sposób nawigowania pomiędzy aktywnościami. Sednem usprawnienia jest umożliwienie określenia aktywności nadrzędnej. Poprzez przypisanie wartości dla opisywanego tagu programista gwarantuje użytkownikom przewidywalną kolejność wywołań aktywności. Dzięki 14

16 temu twórca programu zwolniony jest z obowiązku (a raczej dobrej maniery) programowania metod, które operują na stosie aktywności. Takimi metodami są np. funkcje nasłuchujące (ang. listeners) naciśnięcie systemowego przycisku cofania, który zazwyczaj oznaczany jest jako strzałka skierowana w lewo i domyślnie zaprogramowanego na cofanie poprzednich akcji użytkownika Struktura i sposób działania interfejsu użytkownika Aktywności mają bardzo szeroki zakres zastosowań. Odpowiadają zarówno za sterowanie logiką aplikacji, jak i warstwą interfejsu użytkownika. Jednak jeśli chodzi elementy funkcjonowania interfejsu użytkownika, system Android przewiduje inne sposoby jego budowy aniżeli poprzez same aktywności. Szablony widoków każdej aplikacji tworzone są w osobnych plikach w formacie XML, zwanych layout ami (ang. layout plan, układ). Pliki te, ze wzgląd na swój format i strukturę są statyczne, w związku z czym muszą być zarządzane z poziomu aktywności. W pliku layoutu programista określa wszystkie elementy widoku, które będą potrzebne do działania interfejsu użytkownika odpowiadającej mu aktywności. Oznacza to, że szablon widoku tworzony jest z przeznaczeniem dla konkretnej funkcjonalności w obszarze aktywności, która będzie wykorzystywać widok. Elementy interfejsu użytkownika, które można opisać za pomocą odpowiednich tagów w plikach szablonów to: szablony rozkładu elementów na ekranie (np. liniowe horyzontalne i wertykalne, tabelaryczne, rozkłady listujące) elementy funkcjonalne, które obsługiwane są przez aktywności (np. przyciski, elementy formularzy, paski postępu) inne elementy tj. zdjęcia, obrazki i inne elementy uatrakcyjniające wygląd aplikacji. Wszystkie tagi i atrybuty tagów muszą być określone w specyfikacji systemu Android. Oznacza to, że każda wersja systemu posiada zakres atrybutów szablonów widoku, którymi można się posłużyć do budowania interfejsu użytkownika. Wraz z kolejnymi wersjami systemu Android pojawiały się nowe elementy i tagi. Wszystkie interfejsy programistyczne systemu są wstecznie kompatybilne. Oznacza to, że jeśli działały na starszych wersjach systemu, to będą działać również na wersjach nowszych. Dotyczy to również elementów interfejsu graficznego. 15

17 Rysunek 2.2. Przykład działania szablonu widoku (opracowanie własne) Przykład ukazany na rys. 2.2 obrazuje zastosowanie bardzo prostego widoku liniowego o ułożeniu wertykalnym, który zawiera trzy programowalne przyciski. Przedstawiony efekt zastosowania schematu wygląda bardzo podobnie na każdej wersji systemu Android, jednak może różnić się szczegółami stylistycznymi zależnymi od motywu, stylu i oprogramowania systemu (które są zależne od wersji i producenta urządzenia mobilnego). Szablony graficzne tworzone za pomocą schematów XML są bardzo rozbudowanym narzędziem do tworzenia statycznych elementów interfejsu użytkownika. Jednak najważniejszym czynnikiem budującym użyteczność całej aplikacji jest to, że elementy interfejsu użytkownika mogą być interaktywne i odpowiadać na działania użytkownika. Elementy te służą do wizualizowania działań, informowania o postępie, przebiegu działania aplikacji czy też do nawigowania pomiędzy aktywnościami. Zarządzanie elementami interfejsu graficznego zostało rozwiązanie poprzez utworzenie połączenia pomiędzy aktywnościami a plikami szablonów. Połączenie to jest możliwe poprzez utworzenie odniesienia w aktywności do nazwy szablonu, która jest generowana w pliku R.java. Możliwe jest również pobieranie elementów zawartych w szablonie pod warunkiem nadania tym elementom identyfikatorów za pomocą atrybutu android:id. Sterowanie interfejsem odbywa się z poziomu aktywności. Jest to jedyny sposób pozwalający na modyfikowanie i dynamiczne sterowanie zawartością widoku ekranu, choć niesie ze sobą konsekwencje od strony programistycznej. Aktywności, oprócz korzystania i zmienia- 16

18 nia gotowych schematów widoków, mogą także implementować własne elementy wizualne. Charakterystyczną cechą aktywności jest również to, że twórca aplikacji nie ma do czynienia ze wzorcem model widok kontroler, który staje się bardzo popularny wraz z rozwojem technik programowania obiektowego. Powoduje to komplikacje, ponieważ aktywność w ten sposób staje się komponentem, który odpowiada pośrednio za każdy element działania programu i nieumiejętne zaprojektowanie jego struktury może być przyczyną problemów na poziomie działania aplikacji Zależności pomiędzy elementami aplikacji Każda aplikacji działająca na systemie Android posiada wiele elementów składowych. Jest tak w przypadku nawet małych aplikacji, które posiadają niewiele funkcjonalności. Podstawową składową jest aktywność każda aplikacja musi składać się choć z jednej. Tak samo jest z szablonem widoków. Jeśli istnieje aktywność, to musi ona korzystać przynajmniej z jednego szablonu interfejsu użytkownika. Ponadto każdy program zawiera również szereg dodatkowych zasobów, zarówno tekstowych, jak i graficznych przetrzymywanych w osobnych katalogach i zarządzanych w sposób podobny do tego, jak to ma miejsce w przypadku szablonów graficznych w formacie XML. Wszystkie te elementy są od siebie zależne. 17

19 Rysunek 2.3. Uogólniony schemat zależności pomiędzy elementami aplikacji (opracowanie własne na podstawie [6]) Schemat 2.3 obrazuje, że istnieje pośrednia zależność między wszystkimi elementami aplikacji. Istnieje również wiele zależności pomiędzy składowymi aplikacjami a elementami systemu operacyjnego oraz zasobami urządzenia mobilnego. Dla uproszczenia i lepszego wyjaśnienia zależności, na schemacie pominięto zależności dotyczące zasobów tekstowych, graficznych i serwisów. W ramach aplikacji istnieją dwa ważne połączenia. Pierwszym jest zależność pomiędzy widokami a aktywnościami. Aktywności są dla programisty zawsze elementem najistotniejszym, który zarządza wszystkimi innymi elementami aplikacji w ramach danego ekranu. Z poziomu aktywności zarządza się również interfejsem użytkownika. Po pierwsze, przy inicjalizacji aktywności zawsze określany jest szablon graficzny, z którego będzie korzystała aktywność. Jest to obowiązkowy element startowy, pokazujący jak ścisła jest zależność między interfejsem użytkownika a aktywnością. Powiązanie widoku i aktywności realizuje metoda setcontentview(nazwaszablonu). Po drugie, aktywność może pobierać elementy zawarte w szablonie i obsługiwać je. Pobranie odpowiedniego elementu szablonu można wykonać poprzez wykonanie metody findviewbyid(r.id.identyfikatorelementu). Wszystkie elementy zawarte w szablonach XML mają swoje odpowiedniki jako gotowe klasy w bibliotece 18

20 Androida. W związku z tym, możliwe jest dynamiczne tworzenie elementów interfejsu użytkownika, bez konieczności używania schematów XML. Ważną rolę pełni także plik manifestu AndroidManifest.xml. Informacje w nim zawarte (opisane w punkcie 2.2.1) pełnią nie tylko rolę informacyjną, ale mają znaczenie zarówno dla programisty, jak i użytkownika. Przede wszystkim plik manifestu jest informacją dla systemu, z czego składa się aplikacja, ponieważ zawiera on informacje na temat wszystkich aktywności zawartych w aplikacji. Aplikacja zadziała tylko i wyłącznie na wersji systemu tożsamej lub wyższej niż ta, która została określona w pliku manifestu. Z tym wiąże się oczywiście zależność dotycząca aktywności, ponieważ te będą musiały implementować metody dostępne w interfejsach programistycznych dla wersji tożsamej lub niższej, niż określona w pliku AndroidManifest.xml. Podobne zależności dotyczą wszystkich składowych aplikacji i systemu, co pokazuje złożoność problemów, z którymi borykają się twórcy programów na system operacyjny Android. Duża ilość składowych z jednej strony czyni strukturę programów bardziej skomplikowaną. Z drugiej strony programiści mają dzięki temu większe możliwości w tworzeniu oprogramowania, a system może wspierać zaawansowane narzędzia, takie jak systemy syntezy mowy, mimo ograniczoności zasobów urządzeń mobilnych Wprowadzenie do tematyki dotyczącej środowiska programistycznego Android Informacje na temat pakietu programistycznego Wzrastająca popularność systemu Android wśród użytkowników powoduje, że wzrasta również ilość programistów, którzy tworzą oprogramowanie na tę platformę. Jest jednak dodatkowy czynnik, który stymuluje wzrost popularności tego systemu wśród programistów. Jest to bardzo rozbudowany i dopracowany SDK 2, który jest stale rozwijany przez firmę Google. Pakiet programistyczny dla systemu Android jest rozbudowany, a w jego skład wchodzą zarówno biblioteki programistyczne, jak i narzędzia niezbędne do poprawnego tworzenia oprogramowania. Dodatkowo twórcy systemu wyposażyli programistów w pakiet ADT 3, który zawiera m.in.: menadżer SDK, pozwalający na pobranie interfejsów programistycznych dla dowolnej wersji systemu Android 2 Software Development Kit (SDK) zbiór narzędzi przeznaczonych dla sprecyzowanej grupy programistów, który dostarcza rozwiązania umożliwiające tworzenie aplikacji na konkretnej platformie programistycznej 3 Android Development Tools (ADT) zbiór narzędzi ułatwiających tworzenie aplikacji na platformę Android oraz umożliwiający łatwiejsze utrzymanie stworzonego oprogramowania 19

21 dodatek do programu Eclipse 4, który zawiera zestaw narzędzi rozszerzający możliwości programu o funkcjonalności do łatwego tworzenia szablonów, projektów i aplikacji na platformę Android. narzędzie ADB (Android Debug Bridge), umożliwiające połączenie pomiędzy komputerem a urządzeniem mobilnym, dzięki czemu programista może testować tworzone aplikacje bezpośrednio na urządzeniu mobilnym najnowszą wersję platformy Android narzędzie umożliwiające emulowanie systemu Android na komputerze z systemem Linux lub Windows najnowszą wersję systemu Android, którą można użyć na emulatorze. Dodatkową zaletą środowiska programistycznego tej platformy oraz jej API 5 jest bardzo czytelna i rozbudowana dokumentacja projektu. Biorąc pod uwagę mnogość wersji systemu oraz różnice pomiędzy interfejsami programistycznymi kolejnych wersji, istnienie takiej dokumentacji jest dla wielu programistów zbawienne. Dokumentacja API zawarta jest w bibliotece programistycznej, dzięki czemu programista może korzystać z niej z poziomu środowiska programistycznego Eclipse. Jednak najczytelniejsza i najbardziej rozbudowana wersja dokumentacji, która jest zawsze wersją najbardziej aktualną, znajduje się stronie twórców systemu pod adresem Dodatkowym atutem wersji internetowej, jest to, że zawiera ona nie tylko szczegółową dokumentację, ale także pełen zbiór porad, przykładów i komentarzy dotyczących zawiłości programistycznych dotyczących klas programistycznych. Pakiet programistyczny ADT (zawierający SDK) działa zarówno na systemach Linux, jak i Windows. Dzięki zastosowaniu tego pakietu programista może łatwiej kontrolować zmiany w interfejsach programistycznych, które następują w kolejnych wersjach systemu Android. Przykładem może być API dla systemów syntezy mowy, które zostało rozbudowane w wersji Jelly Bean. Dzięki zastosowaniu ADT programista posiada dostęp do najnowszych źródeł programistycznych. Dzięki temu może on tworzyć oprogramowanie, wykorzystując zawsze najnowsze biblioteki programistyczne. Mimo tego, że narzędzia i biblioteki programistyczne są stale rozwijane i aktualizowane, programiści muszą się zmagać z wieloma problemami natury technicznej, które wynikają z cech środowiska programistycznego. 4 Eclipse zintegrowane środowisko programistycznego, przeznaczone głównie do tworzenia oprogramowania w języku Java; rozpowszechniane na zasadach wolnego oprogramowania 5 Application Programming Interface ściśle określony zestaw reguł i ich opisów, który służy do tworzenia oprogramowania; API jest podzbiorem języka programowania, na bazie którego zostało stworzone 20

22 Cechy środowiska programistycznego Podstawowe problemy techniczne podczas tworzenia aplikacji wynikają z tego, że nowe wersje systemu Android pojawiają się stosunkowo często jak na tego typu oprogramowanie (patrz: rys. 2.4). Rysunek 2.4. Harmonogram wydań kolejnych wersji systemu Android Mimo tego że programiści moją dostęp do najnowszych interfejsów programistycznych często bywa tak, że nie mogą z nich skorzystać. Jest tak, ponieważ muszą liczyć się z tym, że użytkownicy nie posiadają najnowszych wersji systemu operacyjnego na swoich urządzeniach mobilnych, w związku z czym metody z nowszych wersji nie są na nich wspierane. Istnienie takiego problemu jest niestety mankamentem i ujemną cechą środowiska programistycznego, którego prawdopodobnie twórcy systemu Android nie przewidzieli. Problem ten jest cechą nabytą, która pojawiła się w momencie, gdy nowe wersje systemu pojawiały się szybciej, niż rynek był na to przygotowany. Obrazują to oficjalne raporty zamieszczane przez firmę Google (patrz: rys. 2.5). 21

23 Rysunek 2.5. Popularność wersji systemu Android (opracowanie własne na podstawie: raport Google z dnia [1]) Raporty zamieszczane na oficjalnej stronie deweloperskiej projektu Android tworzone są okresowo. Zamieszczenie raportu poprzedza czternastodniowy okres badania aktywności urządzeń, z których pobierane są dane na temat wersji systemu, na jakim działają. Z powyższego raportu wynika, że społeczność użytkowników systemu Android jest bardzo niejednolita. Taka tendencja utrzymuje się od dłuższego czasu, a wraz z pojawianiem się kolejnych wersji podział wśród użytkowników jest coraz większy. Konsekwencje opisywanego stanu rzeczy są bardzo widoczne na poziomie programistycznym. Programista tworząc aplikację, już na samym początku określa docelową oraz minimalną wersję systemu operacyjnego, na którym ma działać jego aplikacja. Oznacza to konieczność oznaczenia wersji dedykowanej, co akurat nie jest dużym ograniczeniem. Oznaczenie wersji dedykowanej oznacza, że programista zapewnia najlepsze działanie aplikacji właśnie na tej wersji. Oznaczenie tzw. target SDK gwarantuje takie działanie, ponieważ określenie tego parametru powoduje, że aplikacja podczas tworzenia będzie budowana z wykorzystaniem pliku JAR, który przeznaczony jest właśnie dla tej konkretnej wersji. Większe konsekwencje niesie ze sobą konieczność oznaczenia wersji minimalnej. Dla przykładu: programista oznacza w pliku manifestu atrybut wersji minimalnej numerem 11 (co oznacza bibliotekę programistyczną dla systemu w wersji 3.0). Oznacza to, że tworząc aplikację, programista będzie mógł użyć tych metod programistycznych, które zostały przeznaczone dla bibliotek programistycznych dla wersji 3.0 systemu oraz wcześniejszych. Konsekwencje takiego postępowania są znamienne: aplikacja nie będzie działała na starszych wersjach systemu operacyjnego aplikacja, jeśli będzie dostępna w markecie, nie będzie widoczna dla urządzeń działających na wersji systemu niższej niż

24 programista nie będzie mógł wykorzystać metod nowszych, przeznaczonych dla nowszych wersji systemu. Pierwsze dwa argumenty są na tyle silne, że większość tworzonych aplikacji jako wersję minimalną posiada bibliotekę dla wersji Mimo tego że wersje systemu o numerach 3.x i 4.x są o wiele bardziej nowoczesne i oferują programiście multum lepszych rozwiązań programistycznych i technicznych, są rzadko określane jako wersje minimalne. Jest tak, ponieważ według raportów Google ciągle główną rzeszę użytkowników systemu Android stanowią użytkownicy wersji Argument dotyczący braku nowszych metod podczas projektowania aplikacji programiście co prawda mogą obejść, stosując tzw. refleksje 6. Jest to jednak metoda niepolecana ze względu na to, że wymaga bardzo dużego nakładu pracy w stosunku do korzyści ze sobą niosących. Dodatkowo stosowanie refleksji w kodzie Java powoduje, że kod staje się nieczytelny. Wniosek końcowy jest taki, że zazwyczaj programiści nie decydują się na korzystanie z bibliotek programistycznych dla nowszych wersji systemu. Nie chcą oni pozbawiać się dużej szerzy potencjalnych klientów, którzy używają starszych wersji systemu Android. Pozostaje jedynie o wiele bardziej pracochłonna alternatywa, czyli stworzenie dwóch wersji aplikacji przeznaczonych dla nowszych i starszych wersji systemu. Na szczęście wszystkie wersje środowiska programistycznego Android cechują się kompatybilnością wsteczną. Oznacza to, że biblioteki dostarczane do nowej wersji systemu obsługują także metody, które zawarte były w poprzednich wersjach. W przypadku rozszerzania lub zmiany funkcjonalności istnieje także możliwość, że metody poprzednich bibliotek zostaną oznaczone jako przestarzałe. Oznacza to, że nowa biblioteka zawiera nowe interfejsy, które obsługują daną funkcjonalność, a używanie poprzednich metod jest niezalecane. Przypadki takie zdarzają się, gdy twórcy znajdują nowsze, lepsze rozwiązania problemów, które istniały w poprzednich wersjach. Jednak większość mechanizmów programistycznych, które stanowią podwaliny biblioteki Androida, nie zmieniła się od początku istnienia systemu Analiza wybranych interfejsów udostępnionych programistom Zmiany interfejsów w bibliotekach programistycznych Android ewoluowały zgodnie z rozwojem technologicznym. Oznaczanie metod jako przestarzałych oraz powstawanie nowych mechanizmów jest charakterystyczne przede wszystkim dla klas i interfejsów służących do obsługi kamery, aparatu fotograficznego czy systemów syntezy mowy. Twórcy systemu reagowali na rosnące możliwości sprzętu peryferyjnego oraz dostosowywali biblioteki do ich potrzeb. Jednak pisząc o standardowych mechanizmach systemu, które nie ulegały zmianom, zaznacza się przede wszystkim klasy, które sterują samymi aplikacjami, interfejsem użytkow- 6 mechanizm refleksji proces, podczas którego program może być modyfikowany w trakcie działania w sposób zależny od własnego kodu oraz od zachowania w trakcie wykonania 23

25 nika czy sposobami zarządzania danymi w ramach aplikacji. Takimi klasami są między innymi klasy tzw. preferencji. Preferencje programuje się korzystając z klasy SharedPreferences oraz klas w pakietach jej podległych. Preferencje są rodzajem ustawień aplikacji. Za pomocą preferencji można przechowywać dane w obrębie całego programu. Jest to zatem rodzaj zmiennych globalnych w ramach programu. Do preferencji można przekazywać dowolne obiekty Java, które potem można pobrać z preferencji w dowolnym momencie. Co ważne, nie służą one do przekazywania danych pomiędzy aktywnościami, do tego służą inne mechanizmy. Jak sama nazwa wskazuje, preferencje służą do zapisywania stałych opcji aplikacji. Weźmy za przykład aplikację korzystającą z systemu syntezy mowy: biblioteki obsługujące TTS na systemie Android posiada metody umożliwiające modyfikacje szybkości oraz wysokości tonu czytanego tekstu. Metody te są standardowymi setterami 7, które przekazują mechanizmowi TTS informacje w formacie liczb dziesiętnych. Zatem ustawienie wartości dla szybkości czytania dźwięku spowoduje ustawienie tej właściwości syntezatora mowy dla danej jego instancji. Jednak zazwyczaj jest tak, że użytkownik ustawiając tego typu własności, dla różnego rodzaju mechanizmów oczekuje, że po jednorazowym ustawieniu wartość ta będzie zapamiętywana na stałe. Szybkość i ton czytania tekstu nie powinny być czasowe, a powinny być stanem syntezatora mowy. Co więcej, użytkownicy oczekują, że własności te będą zapamiętywane nie tylko w czasie działania aplikacji, ale również po jej wyłączeniu i po ponownym uruchomieniu w innym czasie. Do rozwiązania tego teoretycznie skomplikowanego od strony technicznej problemu służą wymienione wyżej klasy preferencji. Co ciekawe, obiekt preferencji używany przez programistów nie jest instancją, którą należy tworzyć. Jest on zawarty w tzw. kontekście aplikacji. Kontekstem nazywa się obiekt, który tworzony jest na samym początku wraz z aktywnością. Jest on bazą każdej aktywności, elementem nadrzędnym. Kontekst przechowuje wszystkie potrzebne informacje na temat programu, m.in. preferencje i informacje o pozwoleniach. Kontekst posiada zestaw metod do pobierania opisywanych stanów, np. do pobrania istniejących preferencji służy metoda getsharedpreferences(string, int), która zwraca obiekt SharedPreferences. Cały opisany proces wynika ze specyfiki budowy aplikacji działających na systemie Android. Dzięki takiemu działaniu możliwe jest zapisywanie stanu obiektów bez obaw, że zostaną one utracone wraz z zakończeniem procesu, w którego obrębie działa aplikacja. Charakterystyczne dla systemu i spójne dla wszystkich wersji systemu są sposoby implementowania i używania interfejsów służących do obsługi elementów interfejsu użytkownika. Istnieje spójność i połączenie pomiędzy szablonami interfejsów graficznych tworzonych za 7 setter (od ang. set ustawiać) metoda ustawiająca wartość określonego pola obiektu, na którym jest wywoływana 24

26 pomocą plików XML oraz częścią kodową aplikacji, która programowana jest w języku Java. Połączenie elementów interfejsu graficznego, opisywane za pomocą XML, odbywa się poprzez oznaczanie elementów szablonów określonymi atrybutami tagów. Zasadą jest, że każdy atom szablonu powinien mieć określony identyfikator (opisywany za pomocą atrybutu XML: android:id= identyfikator ). Na podstawie danych zgromadzonych we wszystkich źródłach zasobów, prawidłowo skonfigurowane środowisko programistyczne przy każdym budowaniu projektu, generuje również plik R.java. Plik ten jest zbiorem finalnych, statycznych pól, które zawierają informacje o wszystkich elementach projektu, tj.: plikach graficznych szablonach interfejsów graficznych tekstach, napisach (tworzonych, tak samo, jak szablony graficzne, w odpowiednich plikach XML) zdefiniowanych stylach identyfikatorach (np. elementów interfejsu graficznego) Wszystkie pola generowane są razem z plikiem. Dla wszystkich grup zasobów generowane są pola, pogrupowane w statycznych klasach. Wszystko tworzone jest według wzoru ukazanego w kodzie źródłowym public s t a t i c f i n a l class l ayout { 2 public s t a t i c f i n a l int a c t i v i t y b r o w s e r=0x7f ; 3 public s t a t i c f i n a l int a c t i v i t y s e t t i n g s =0x7f ; 4 public s t a t i c f i n a l int a c t i v i t y t t s m e n u=0x7f ; 5 public s t a t i c f i n a l int a c t i v i t y t t s r e v i e w =0x7f ; 6 public s t a t i c f i n a l int browse menu=0x7f ; 7 public s t a t i c f i n a l int s e t t e x t d i a l o g =0x7f ; 8 } Kod źródłowy 2.3. Przykład kodu wygenerowanego dla potrzeb zarządzania szablonami graficznymi Jak widać na przykładzie kodu źródłowego 2.3, wszystkie wartości są unikalne, przetrzymywane w formacie liczb całkowitych. Ani dla programisty, ani dla użytkownika nie ma to najmniejszego znaczenia, ponieważ podczas programowania programista korzysta z pól klasy R, jako elementów identyfikacyjnych. Metody pozwalające na korzystanie z tych identyfikatorów zawarte są bezpośrednio w aktywnościach. W zależności od typu zasobu programista musi wykorzystać odpowiednią metodę do jego pobrania. I tak, dla przykładu, dla szablonów graficznych oraz elementów interfejsu użytkownika jest to metoda findviewbyid(r.id.identyfikator). 25

27 Aby korzystać z elementu, który został wcześniej zdefiniowany w szablonie XML, należy go rzutować na odpowiedni typ, odpowiadający typowi danego elementu. Najlepiej ilustruje to przykładowe zastosowanie tego schematu (patrz: kod źródłowy 2.4). 1 <Button 2 android : i d / testbutton 3 android : l a y o u t w idth= wrap content 4 android : l a y o u t h e i g h t= wrap content 5 android : t e x / t e s t /> Kod źródłowy 2.4. Przykład schematu XML dla elementu szablonu graficznego Oprogramowanie takiego elementu (którego identyfikator to testbutton) odbywa się poprzez wywołanie kodu źródłowego przedstawionego w przykładzie Button testbutton = ( Button ) findviewbyid (R. i d. testbutton ) ; Kod źródłowy 2.5. Przykład definiowania przycisku funkcyjnego za pomocą API Android Ważnym elementem takiego wywołania jest odpowiednie rzutowanie obiektu. Obiekty elementów interfejsu użytkownika są definiowane w bardzo prosty sposób. Wszystkie tagi szablonów graficznych i elementów UI 8 mają swój bezpośredni odpowiednik w klasach bibliotek programistycznych, tak jak widoczne jest to na przykładzie przycisku, gdzie odpowiednią klasą jest klasa Button. Mając taką wiedzę na temat budowy i sposobu działania aplikacji, zasobów i bibliotek programistycznych systemu Android, programista może rozpocząć pracę nad bardziej szczegółowymi elementami SDK Android. 8 UI User Interface, interfejs użytkownika 26

28 ROZDZIAŁ 3 Wykorzystanie systemów syntezy mowy na urządzeniach mobilnych 3.1. Historia systemów syntezy mowy na platformie Android Systemy syntezy mowy dostępne są na urządzeniach działających na systemie operacyjnym Android od września 2009 r., kiedy to oficjalnie wydany został Android Donut. Było to wydanie, które było przełomem wśród systemów operacyjnych przeznaczonych na urządzenia mobilne. Android dzięki tej wersji zyskał ogromną popularność, dzięki temu, że udostępniał wiele nowych rozwiązań technologicznych. Wśród nich pojawiły się systemy syntezy mowy, choć tej funkcjonalności nie można było uznać w tamtym czasie za popularną. Było tak przede wszystkim ze względu na to, że system syntezy mowy jest narzędziem zewnętrznym. Oznacza to, że samo udostępnienie możliwości zainstalowania TTS w systemie to nie wszystko. Potrzebny jest jeszcze systemowy mechanizm syntezy mowy. Jest to rodzaj komponentu systemu, który służy do generowania mowy z tekstu. A tego niestety w początkowym okresie systemu nie było. Skutkiem tego był brak rozwoju klas w API dla opisywanego modułu. Od czwartej rewizji API (czyli od wersji 1.6 systemu) istniała tylko jedna klasa programistyczna. Nie pomagała ona w żadnej sposób w tworzeniu systemów syntezy mowy. Była ona zwyczajnym kontrolerem akcji dla TTS, dzięki czemu gotowe systemy mógłby być łatwo wykorzystywane w aplikacjach. W API dostępny jest co prawda cały pakiet android.speech.tts, który zawierał dwie klasy: opisywany kontroler, czyli TexToSpeech oraz klasę Engine, który była jedynie zbiorem stałych parametrów, które wykorzystywane są podczas programowania funkcji z wykorzystaniem TTS. Z biegiem czasu powstawały systemy syntezy mowy przeznaczone na platformę Android, które można było pobrać bezpośrednio z Internetu, bądź pobrać przez autoryzowany serwis Google o nazwie Google Play. Są one tworzone przede wszystkim przez grupy programistów, ponieważ nie istniały metody API, które pozwalałyby na tworzenie nowych systemów TTS, które byłyby stuprocentowe zgodne z API Android. Sytuacja zmieniła się dopiero po wydaniu systemu Android 4.0. Co prawda nic nie zmieniło się w kwestiach działania i używania systemów syntezy mowy, ale firma Google wraz z wydaniem czternastej wersji API, dodała do niej nowe metody. Do pakietu programistycznej android.speech.tts dodano nowe klasy, które nie łączyły się z samym wykorzystaniem TTS. 27

29 Klasy te umożliwiają implementację własnych systemów syntezy mowy. Wraz z wydaniem tej wersji biblioteki programistycznej programiści otrzymali pełen zestaw klas i interfejsów, które pozwalają na utworzenie syntezatora mowy od podstaw. Nowe klasy pakietu tts umożliwiają również implementację głosów dla syntezatorów mowy. Tak późne udostępnienie wyżej opisanych bibliotek API skutkuje ich bardzo niską popularnością. Na fakt składają się dwa główne czynników: 1. Systemy TTS stworzone przy wykorzystaniu tych bibliotek będą działać jedynie na systemach Android 4.0 oraz nowszych. 2. Do czasu wydania API z nowymi metodami TTS zdążyło powstać bardzo dużo profesjonalnych systemów syntezy mowy, charakteryzujących się wysoką wydajnością działania i jakością czytanego tekstu. Skutki pierwszej z wymienionych przyczyn są o wiele poważniejsze, niż mogłoby się wydawać. Użytkownicy systemu, którzy korzystają z systemu Android w wersji 4.0 i nowszych stanowią około 55% wszystkich użytkowników tej platformy. Oznacza to, że system TTS stworzony zgodnie z metodami API trafiłby co najwyżej do nieco ponad połowy (55%) wszystkich użytkowników. Taka praktyka jest niepolecana i niepopularna, ponieważ na samym wstępie programista traci możliwość udostępnienia swojej aplikacji potencjalnym klientom. Należy pamiętać o tym, że istnienie interfejsów programistycznych dla TTS nie warunkuje ich dobrego działania. Podwaliną dobrze działającego systemu syntezy mowy są mechanizmy, które pozwalają na efektywne przetwarzanie tekstu do postaci mowy. Te algorytmy są mechanizmami złożonymi i działają tak samo niezależnie od platformy. Pozostaje więc tylko kwestia ich implementacji. API Android pozwala jedynie na zaimplementowanie systemu syntezy mowy, które będzie mógł zostać wgrany jako zasób systemu. Pozostaje kwestia opracowania możliwie optymalnych algorytmów TTS oraz przygotowanie głosów, które będą zestawem głosowym dla stworzonego systemu. Nie ulega wątpliwości, że na rynku od wielu lat istnieją firmy, które specjalizują się w tego rodzaju systemach. Z powodu swoistego monopolu na tego rodzaju systemu w praktyce nie powstają amatorskie projekty TTS dla systemu Android, które mogłyby przetrwać na rynku oprogramowania mobilnego. Zanim pojawiły się biblioteki do tworzenia systemów generujących mowę z tekstu powstały mobilne odpowiedniki znanych już systemów do syntezy mowy, takich jak chociażby najpopularniejszy, nie tylko w Polsce, ale i na świecie IVONA. 28

30 3.2. Obsługa systemów syntezy mowy przez system operacyjny Android Od strony użytkowej, od momentu, gdy Android zaczął wspierać systemy syntezy mowy, nie zmieniło się zbyt wiele. Opcja, która pozwala na zarządzanie TTS, jest wbudowanym elementem systemu, którym można zarządzać tak samo, jak innymi elementami ustawień systemu. Ustawienia TTS wchodzą w skład Ustawień funkcji głosowych, a w ich ramach, oprócz samej syntezy mowy, znajdują się ustawienia rozpoznawania mowy. Jest to drugi i jedyny poza TTS mechanizm łączący się z przetwarzaniem mowy, występujące w systemie operacyjnym tworzonym przez firmę Google. Podział tych ustawień zmienił się minimalnie w wersji 4.0. W dalszym ciągu systemem syntezy mowy można zarządzać przez ustawienia systemu, jednak ze względu na rozbudowane menu tej części systemu, przegrupowano opcje i przeniesiono niektóre składniki ustawień w inne miejsce. Systemy syntezy mowy są w pełni konfigurowalne, tzn.: Można wybrać dowolny z zainstalowanych w systemie systemów do przetwarzania mowy z tekstu Można instalować wiele systemów jednocześnie Można instalować wiele plików głosów dla każdego z systemów Można określać szybkość oraz wysokość tonu mowy syntezowanej przez system TTS. W związku z takimi własnościami, twórcy systemu przenieśli ustawienia systemu do działu ustawień osobistych. Wadą takiego rozwiązania jest to, że początkującemu użytkownikowi ciężko jest znaleźć opcje ustawień TTS. W systemie znajdują się one dopiero w podgrupie nazwanej Język, klawiatura, głos. Dopiero po takiej sekwencji wywołań użytkownik może zmienić ustawienia syntezatora. Opcja ustawień TTS jest nazwana przetwarzaniem tekstu na mowę i podobnie jak w poprzednich wersjach systemu stanowi ekran z pełnym wachlarzem opcji. 29

31 Rysunek 3.1. Wygląd ekranu ustawień systemu syntezy mowy na systemach Android i 4.0 Wartym zaznaczenia jest fakt, że początkowe wersje systemu były skierowane w dużej części do osób, które lubiły w znaczny sposób personalizować swój system. Wraz z rozwojem urządzeń aplikacji można zauważyć tendencję, że twórcy systemów operacyjnych zmniejszali liczbę szczegółowych opcji w swoich produktach. Widać to również po ustawieniach systemu syntezy mowy. Pierwszy z przedstawionych na rys. 3.1 ekranów przedstawia ustawienia TTS dostępne w systemie w wersji 2.3.x. Na jego przykładzie widać, że użytkownik miał do usług wiele możliwości personalizacji TTS nawet tak szczegółową, jak blokowanie ustawienia. Zablokowanie ustawień TTS, które można ustawić w tej wersji systemu, poprzez zaznaczenie opcji zawsze używaj moich ustawień, powodowało, że metody API TTS były ignorowane. Dotyczy to konkretnie metod, które modyfikowały szybkość i ton czytania tekstu przez syntezator. Gdy wymienione opcje zostały zaznaczone przez użytkownika, żadne ustawienia wewnątrz aplikacji, które wykorzystywały API nie były brane pod uwagę przy generowaniu mowy z tekstu. Dla odmiany, w systemie Android 4.0 głównymi opcjami jest jedynie wybór mechanizmu TTS oraz możliwość odtworzenia przykładowego, syntezowanego tekstu. Drugą opcją jest ustawienie szybkości czytania tekstu. Opcja ta, w przeciwieństwie do poprzednich wersji systemu, zawiera tylko predefiniowane szybkości. Określone są ogólnie, jako szybkie, średnie lub wolne czytanie tekstu. Bardziej szczegółowych opcji TTS w opisywanej wersji systemu należy szukać w dalszych ekranach, które można wywołać m.in. poprzez naciśnięcie na nazwę syntezatora mowy. 30

32 3.3. Analiza istniejących systemów mowy z tekstu na urządzenia mobilne Systemy syntezy mowy, które dostępne są na urządzenia mobilne, oparte na platformie Android udostępniane są głównie przez producentów specjalizujących się w tego rodzaju produktach. Ich rozwój następował przez wiele lat, również na urządzeniach stacjonarnych, a wersje mobilne są rodzajem konwersji sprawdzonych rozwiązań. Najbardziej popularnym systemem TTS w Polsce jest IVONA TTS, który tworzony jest przez należącą do koncernu Amazon, firmę IVONA Software. Powodów popularności tego systemu jest kilka. Przede wszystkim IVONA jest jedynym systemem TTS na system Android, który oferuje dobrej jakości głosy, syntezujące polską mowę. Niesprawiedliwością jednak byłoby stwierdzenie, że to główny powód popularności tego systemu. Pakiet plików głosowych dla opisywanego systemu, o nazwie Maja dostępny jest bez opłat poprzez serwis Google Play (tak samo, jak sam opisywany system TTS). Producent systemu udostępnia (również poprzez Google Play) także pliki głosowe dla języków: angielskiego (dla dialektów: brytyjskiego, walijskiego, amerykańskiego oraz australijskiego) francuskiego hiszpańskiego (w dwóch dialektach) islandzkiego niemieckiego rumuńskiego włoskiego Co ważne, system jest popularny również w innych krajach, co wynika z wysokiej jakości syntezowania mowy w różnych językach oraz dostępności dużej ilości głosów, które imitują płeć męską oraz żeńską w różnych dialektach danego języka. Ponadto system IVONA jest darmowy. Od roku 2012 prowadzone są otwarte testy beta. Na czas przeprowadzania testów wszystkie mechanizmy producenta IVONA Software są ogólnie dostępne, bez dodatkowych opłat. Okres beta-testów nie jest określony przez producenta. Od dnia wydania do maja 2013 roku, został on zainstalowany na ok. pół miliona urządzeń mobilnych. Średnia ocena systemu wyniosła w tym czasie 3,9 punktów (maksymalna nota: 5,0), co należy uznać za dobry wynik. System syntezy mowy IVONA charakteryzuje się bardzo naturalnym imitowaniem mowy. Zdania wypowiadane przez syntezator są wyjątkowo wyraźne i precyzyjne. Obiektywna ocena 31

33 jest niemożliwa, ze względu na to, że każdy użytkownik ocenia dźwięki syntezatora w sposób indywidualny. Jednak sądząc po statystykach i subiektywnych ocenach użytkowników, które dostępne są w niezależnych od producenta serwisach, jak Google Play, można stwierdzić, że IVONA TTS jest jednym z najefektywniejszych systemów syntezy mowy na rynku. Mechanizm TTS IVONA zdobywa popularność na rynku systemów mobilnych, jednak najpopularniejszym systemem tego typu jest system Pico TTS (oraz jego następca Classic TTS), którego producentem jest SVOX. Jego popularność nie pokrywa się z jakością. Popularność systemu to przede wszystkim efekt długiego stażu na rynku. Przez długi czas na platformie Android praktycznie istniał tylko ten system syntezy mowy. System firmy SVOX jest najstarszym silnikiem syntezy mowy dostępnym na platformę Android. System od samego początku istnienia tworzony był z myślą o rynku urządzeń mobilnych. Początkowo systemy syntezy mowy SVOX tworzone były z myślą o nawigacjach satelitarnych, starszych generacjach telefonów komórkowych oraz urządzeniach montowanych w samochodach. System SVOX tworzony jest nieprzerwanie od 2000 roku. Największy skok jakościowy systemu nastąpił po roku 2002, gdy w rozwój technologii zainwestowała firma Siemens. Stworzenie systemu syntezy mowy SVOX Pico na system Android było oczywistą konsekwencją działań firmy tworzącej ten mechanizm TTS. Doświadczenie na rynkach mobilnych bezpośrednio przekłada się na jakość mechanizmu. Głosy, które można wykorzystać w systemie SVOX cechują się przeciętną jakością w porównaniu z mechanizmem IVONA, ponieważ mowa generowana przez Pico TTS brzmi sztucznie i słychać, że jest generowana komputerowo. Pico TTS na większości wersji systemu Android jest preinstalowany (czyli jest dostarczany użytkownikowi wraz z systemem operacyjnym). W roku 2009, gdy Google udostępniło możliwość instalacji systemu syntezy mowy na systemie Android, SVOX Pico TTS został wybrany na domyślny system, który będzie rozpowszechniany razem z systemem operacyjnym. Z tego powodu jest też jednym z najpopularniejszych systemów. Nie wymaga od użytkownika żadnej instalacji. Do systemu domyślnie nie są dołączone pliki głosów, jednak ich instalacja jest bezproblemowa. Oba wymienione wyżej systemy syntezy mowy są w stanie syntezować teksty w języku polskim. Pico TTS pod tym względem przegrywa jednak z IVONA TTS, ponieważ język polski w mechanizmie SVOX jest gorszej jakości. W praktyce język polski wspierany jest dopiero przez system Classic TTS, który jest następcą Pico TTS. System Pico przestał być rozwijany przez firmę SVOX i został zastąpiony systemem Classic TTS. Jest on w pełni komercyjną, płatną wersją systemu Pico TTS, w która firmą SVOX ciągle inwestuje. Mechanizm SVOX Classic TTS zastąpił też Pico TTS w roli domyślnego syntezatora mowy na systemie Android 4.0. Teksty w języku polskim syntezowane przez Classic TTS są bardzo często niezrozumiałe 32

34 i często wypowiadane nieprawidłowo, choć ze względu na ciągły rozwój tej technologii, jakość głosów tego systemu systematycznie wzrasta. Oba opisywane systemy są dostępne za darmo, jednak zaletą IVONA TTS, jest to, że wszystkie głosy wspierane przez system, dostępne są za darmo. Pliki głosów kompatybilne z systemem SVOX dostępne są jedynie za dodatkową opłatą. Tabela poniżej przedstawia zbiór najbardziej popularnych systemów syntezy mowy z tekstu dostępnych na system operacyjny Android. Tabela zawiera również informacje na temat średniej oceny systemu (dane z maja 2013 r. na podstawie Google Play). Nazwa systemu syntezy mowy Ilość wspieranych języków Średnia ocena (maks. 5,0) w Google Play IVONA 7 (w różnych dialektach) 3,9 SVOX Pico TTS 5 SVOX Classic TTS 45 3,9 Google TTS 5 espeak 40 3,5 Tabela 3.1. Najpopularniejsze systemy syntezy mowy z tekstu na platformę Android (opracowanie na podstawie [2]) 3.4. Analiza istniejących aplikacji wykorzystujących systemy syntezy mowy Wraz ze wzrostem jakości, a co za tym idzie, popularności systemów syntezy mowy, na rynku aplikacji mobilnych zaczęło się pojawiać wiele programów wykorzystujących te mechanizmy. Produkty takie można podzielić na dwie kategorie: aplikacje, które opierają swoją funkcjonalność na syntezatorach mowy aplikacje, które oferują mechanizm TTS jako funkcjonalność rozszerzającą ich główne funkcje. Większość aplikacji mobilnych, wykorzystujących systemy TTS zalicza się do tej drugiej kategorii. Wynika to z samej specyfiki wykorzystywania systemów syntezy. Użytkownicy są przyzwyczajeni do czytania komunikatów i korzystania z ekranu systemy syntezy mowy pełnią w ten sposób rolę pomocniczą, pomagającą wykorzystać wszystkie możliwości programów. Głównym zastosowaniem, którym chwalą się i podają za przykład wszyscy producenci systemów syntezy mowy, są mobilne nawigacje GPS. Standardowym przykładem jest Nawi- 33

35 gacja Google, która jest integralną częścią aplikacji Google Maps. Aplikacja z mapami firmy Google jest bardzo często programem instalowanym domyślnie, wraz z systemem operacyjnym. Nawigacja Google pozwala na wybór punktu, którego użytkownik chce dotrzeć. Po jego zatwierdzeniu zostaje obliczona trasa przejazdu. Aplikacja korzystając z odbiornika GPS prowadzi użytkownika do wskazanej lokalizacji. Trasa oraz informacje o manewrach pokazywane są na jednym ekranie. Sam wygląd mapy jest oparty na standardowym wyglądzie map Google (patrz: rys. 3.2). Rysunek 3.2. Wygląd Nawigacji Google w trybie nawigowania do punktu (źródło: [2]) Aby aplikacja mogła współpracować z systemem syntezy mowy musi zostać spełniony jeden warunek: zainstalowany system syntezy mowy musi posiadać zainstalowany pakiet głosów, który odpowiada językowi aplikacji Nawigacja Google. Jeśli warunek jest spełniony, istnieje możliwość włączenia powiadomień głosowych, które wygłaszane są w czasie nawigowania podczas podróży. Powiadomienia polegają na wygłaszaniu przez system syntezy mowy informacji na temat najbliższych manewrów na drodze. Przykładowy komunikator może wystąpić np. w odległości dwustu metrów przed zakrętem. Oprócz informacji graficznej użytkownik usłyszy komunikat: Za dwieście metrów skręć w prawo. Przykład pokazuje, że wiele aplikacji wykorzystuje systemy syntezy mowy w miejscu, gdzie czytanie komunikatów graficznych i tekstowych przez użytkownika jest niepraktyczne. Podczas prowadzenia samochodu kierowca może się skupić na prowadzeniu pojazdu. Bez odrywania wzroku może jednocześnie korzystać z nawigacji GPS. 34

36 Większość aplikacji, które wykorzystują systemy syntezy mowy na systemie Android, wykorzystuje fakt, że użytkownik urządzenia mobilnego większość czasu posiada je przy sobie, jednak nie zawsze ma czas na skorzystanie z niego poprzez odczytywanie informacji z ekranu. Dlatego też powstało bardzo wiele aplikacji, które co prawda w głównej mierze polegają na wykorzystywaniu zasobów systemu i reagują na jego akcje, ale główną rolę odgrywają metody API dotyczące mechanizmu TTS. Przykładem takiej aplikacji jest SMS, my Car and Me. Aplikacja monitoruje i reaguje na takie akcje systemu jak: odbiór wiadomości SMS/MMS pojawienie się w skrzynce odbiorczej nowej wiadomości odbiór wiadomości z komunikatorów, np. komunikatora Google oraz Facebook Aplikacja w pełni wykorzystuje aktualne możliwości API systemu Android dotyczące mechanizmów syntezy mowy. Zawiera dużo możliwości personalizacji, ale przede wszystkim poprawnie korzysta z zainstalowanego mechanizmu TTS. Aplikacja, w momencie zauważenia, że w którejś z możliwych usług wywołała akcję polegającą na odbiorze wiadomości, wywołuje metody obsługujące system TTS. Gdy system Android zarejestruje nową wiadomość , zostanie ona automatycznie przeczytana przez syntezator mowy. Istnieją aplikacje, które w inny sposób wykorzystują możliwość reakcji na przychodzące wiadomości SMS oraz połączenia telefoniczne. Przykładem takiej aplikacji jest Talking SMS and Caller ID. Funkcje, które obsługiwane są przez program, reagują na odebraną wiadomość SMS poprzez odczytanie imienia i nazwiska nadawcy. Identycznie wygląda sytuacja podczas połączeń przychodzących. Aplikacja przerywa na chwilę sygnał informujący o połączeniu oraz, za pomocą systemu syntezy mowy, informuje użytkownika o tym, kto próbuje się z nim połączyć. Aplikacja wykorzystuje uniwersalność systemów TTS i jeśli okaże się, że osobą dzwoniąca nie znajduję się w liści kontaktów zapisanych w systemie, mechanizm TTS czyta numer telefonu osoby dzwoniącej. Opisane wyżej aplikacje są typowymi wykorzystaniami systemów syntezy mowy. Są to przykłady, które często same się narzucają i są oczywiste. Jednak praktyczność wykorzystania systemów TTS ukazuje inna aplikacja, która od długie czasu jest bardzo popularna wśród amatorów i profesjonalistów zajmujących się sportem. Aplikacja nosi nazwę Endomondo. Aplikacja należy do grupy tzw. mobilnych trenerów osobistych (tak samo, równie popularny RunKeeper). Aplikacje tego typu służą do zarządzania treningami i korzystają z niej przede wszystkim biegacze i kolarze. Endomondo służy sportowcom podczas treningów, rejestrując ich czas, dystans, tempo oraz wiele innych parametrów, które pozwalają dokładnie je zanalizować. Wygląd ekranu obrazującego przebieg 35

37 treningu widoczny jest na przykładzie pierwszym z rys Dodatkowo aplikacja, na podstawie danych GPS z treningów tworzy statystyki, przeglądy i analizy treningów (rys. 3.3, przykład 2). Jest zatem rodzajem elektronicznego trenera osobistego. Ważnym elementem tej aplikacji jest funkcjonalność dotycząca systemu syntezy mowy. Co ciekawe, aplikacja pokazuje jak praktycznie wykorzystać system TTS oraz jak go nie wykorzystywać od strony technicznej. Rysunek 3.3. Przykładowe zrzuty ekranów aplikacji Endomondo (opracowanie własne) Program Endomondo podczas treningów, za pomocą syntezatora mowy, przekazuje użytkownikowi informacje o: czasie treningu przebiegniętym dystansie tempie pobitych rekordach osobistych. Komunikaty są wywoływane w odpowiednich momentach, np. informując biegacza co każdy kilometr o czasie, w jakim go pokonał. Od samego początku wykorzystywania przez Endomondo systemu syntezy mowy, wykorzystanie API wydaje się niepoprawna od strony technicznej. API TTS systemu Android nie wymaga znajomości przez aplikację tego, z jakiego systemu syntezy mowy korzysta. API zawiera metody abstrakcyjne, uniwersalne ze względy na każdy mechanizm do syntezy mowy z tekstu. Jedynym warunkiem koniecznym do poprawnej konfiguracji TTS jest podanie 36

38 przez programistę języka, który będzie używany przez system TTS. Określenie języka jest równoważne z użyciem odpowiednich plików głosowych danego systemu syntezy mowy. Aplikacja Endomondo od strony funkcjonalnej realizuje metody API w poprawny sposób. Jednak ogranicza użytkownikowi możliwości dotyczące wyboru systemu syntezy mowy. W ustawieniach aplikacji istnieje możliwość konfiguracji audio, która dotyczy bezpośrednich ustawień systemu syntezy mowy. Wśród dostępnych opcji jest możliwość wyboru systemu syntezy mowy. Jest ona jednak z góry ograniczona do wyboru pomiędzy dwoma systemami firmy SVOX: przestarzałym Pico TTS oraz jego komercyjną wersją, Classic TTS (patrz: rys. 3.3, przykład 3). W praktyce aplikacja korzysta z serii powtarzalnych komunikatów, które uzupełniane są odpowiednimi wartościami liczbowymi. W związku z tym nie budzie wątpliwości fakt, że każdy system syntezy mowy, który dostępny jest na platformę Android, poradziłby sobie z ich syntezą bez problemu. Dlatego też dziwi fakt ograniczenia użytkownikom wyboru systemu syntezy mowy. Tym bardziej że polski system IVONA, charakteryzuje się lepszą jakością syntezowania mowy z liczb. Z punktu programistycznego, implementacja zastosowana przez programistów aplikacji Endomondo nie ma żadnego uzasadnienia, a działa na niekorzyść zarówno użytkowników, jak i twórców innych systemów TTS. Wartym nadmienienia jest również jedno z najpopularniejszych zastosowań mobilnych systemów syntezy mowy Siri, które jest dostępne jedynie na urządzenia mobilne firmy Apple. Siri jest wirtualnym doradcą użytkownika, a jej cała funkcjonalność opiera się na rozpoznawaniu mowy oraz generowaniu odpowiedzi za pomocą syntezatora mowy. Aplikacja potrafi imitować dialog, jaki prowadzą ze sobą ludzie, a wykorzystanie mechanizmu TTS nadaje aplikacji realizmu oraz podwyższa komfort korzystania z całego systemu operacyjnego. Aplikacja Siri jest popularna do tego stopnia, że jest słynna wśród dużej rzeczy ludzi, którzy nigdy nie korzystali z produktów firmy Apple. Stawia się ją za wzór wykorzystania sztucznej inteligencji, mechanizmów rozpoznawania oraz syntezy mowy. Funkcjonalności aplikacji nie umniejsza fakt, że wspiera jedynie język angielski, a syntezator mowy wykorzystywany przez system operacyjny ios nie jest najlepszym produktem w swojej kategorii Możliwe sposoby rozwoju aplikacji i systemów TTS na platformie Android Większość aktualnie dostępnych aplikacji bazuje na kilku podstawowych funkcjach, które dostępne są w API platformy Android. Wykorzystywane są przede wszystkim metody, które zostały udostępnione wraz z pierwszym wydaniem API. Są to metody, które pozwalają na połączenie się z serwisem systemu TTS oraz wykorzystywanie zainstalowanego systemu 37

39 do syntezowania tekstu. Co ciekawe niektóre metody API dotyczące modułu TTS są praktycznie niewykorzystywane przez programistów, co świadczy o ich małej użyteczności. Przez długi czas twórcy systemu Android nie pozwalali prorokować na temat rozwoju aplikacji wykorzystujących systemy syntezy mowy, ponieważ klasy API dotyczące TTS nie były zmieniane w jego wydaniach przez ponad dwa lata. Wydawać by się mogło, że twórcy tej platformy nie widzą przyszłości w mobilnych systemach przetwarzających tekst na mowę. Dopiero wraz z wydaniem systemu Ice Cream Sandwich (Android 4.0) można zauważyć postęp w rozwoju API TTS (patrz rys. 3.4), który pozwala z optymizmem patrzeć nie tylko na rozwój oprogramowania wykorzystujące systemy syntezy mowy, ale również na rozwój samych mechanizmów TTS. Rysunek 3.4. Oś czasu obrazująca wydania API dla systemów syntezy mowy na platformie Android (opracowanie własne na podstawie [1]) W związku z długim interwałem czasu, przez który klasy TTS w API Android nie zmieniały się, programiści wykorzystali wachlarz rozwiązań oferowanych przez interfejsy programistyczne. Z powodu ograniczoności metod w API, zastosowanie systemów mowy jest zazwyczaj uzupełnieniem głównym funkcjonalności aplikacji. Jednak wydanie nowych bibliotek TTS daje programistom wiele nowych możliwości. Nowe API pozwala twórcom aplikacji na tworzenie i implementacje swoich własnych systemów syntezy mowy oraz głosów do nich przeznaczonych. Co ważne, wszystkie nowe metody opierają się na takim samym schemacie budowy, jak inne elementy aplikacji na system Android. Jest to dużą zaletą, ponieważ nie wymaga to nauki implementacji nowych standardów. Programista posiadający algorytmy, które pozwolą stworzyć system syntezy mowy oraz znający zagadnienia związane z API Android nie ma przed sobą żadnych ograniczeń. Otworzenie środowiska programistycznego na tworzenie nowych implementacji systemów 38

40 do syntezy mowy z tekstu niesie ze sobą wiele korzyści. Łączą się one ze zwiększeniem się konkurencyjności na rynku mechanizmów TTS. Z powodów technicznych, we wcześniejszych wersjach API, początkujący twórcy, którzy nie są ekspertami w dziedzinie syntezy mowy, mieli zamkniętą drogę. Od momentu wydania API dla systemu Android 4.0 pojawiły się nowe możliwości, dzięki którym z pewnością pojawi się wiele nowych rozwiązań, które będą rozwijane przez zwolenników systemu. Tworzenie oprogramowania na system Android nie niesie ze sobą żadnych kosztów. Zarówno sam system, jak i narzędzia programistyczne są ogólnodostępne oraz darmowe. W związku z tym istnieje duże prawdopodobieństwo, że powstaną projekty, które będą udostępniane na zasadach standardu Open Source. Tego typu podejście spowoduje ciągłe udoskonalanie produktów pojawiających się na rynku. Efektem tego może być powstanie wielu systemów TTS, które będą konkurencyjne dla komercyjnych rozwiązań. Efektem zastosowania nowych interfejsów, może być też rozwój oprogramowania opartego na systemach syntezy mowy. Dzięki możliwości implementacji własnych systemów TTS programiści będą mogli tworzyć implementacje, które będą dostosowane do potrzeb konkretnych funkcjonalności aplikacji. Chodzi tutaj o dopracowywanie syntezy mowy w konkretnych kierunkach, najważniejszych dla używającej jej aplikacji. Można tutaj podać za przykład aplikację Endomondo (analizowaną w rozdziale 3.4). Najważniejszą rolą systemu syntezy w tej aplikacji jest syntezowanie liczb, które informują m.in. o czasie i spalonych podczas treningu kaloriach. Oznacza to, że ilość komunikatów jest ograniczona a ich rodzaj sprecyzowany. Zatem, zamiast popełniać błąd, polegający na nieudostępnianiu wszystkich systemów mowy, które mogłyby działać na tej aplikacji, jej twórcy mogą sami stworzyć system TTS. System taki mógłby być dopasowany do czytania kilku konkretnych komunikatów, a algorytmy syntezy mowy zostać dobrane tak, aby największym atutem systemu było syntezowania mowy z liczb. 39

41 ROZDZIAŁ 4 Analiza projektu magisterskiego 4.1. Założenia i cele projektu Stworzenie aplikacji projektowej miało na celu: ukazanie możliwości wykorzystania systemów syntezy mowy na urządzeniach mobilnych ukazanie zastosowania wszystkich możliwych metod API, które odnoszą się do systemów TTS (dotyczy pierwszej wersji bibliotek TTS, dostarczonych wraz z systemem Android 1.6) umożliwienie analizy rozwiązań technicznych, które twórcy systemu Android udostępnili programistom (również dotyczy czwartej rewizji API, czyli udostępnionej z systemem Android 1.6) umożliwienie oceny działania i możliwości wykorzystania istniejących systemów TTS. Dla osiągnięcia postawionych celów projekt został podzielony na trzy części, a każda z nich została zrealizowana jako osobna aktywność. Każda z aktywności realizuje inne zadania oraz wykorzystuje różne metody API Android, które pokrywają możliwości części biblioteki programistycznej tego systemu, która odnosi się do systemów syntezy mowy, a przede wszystkim do praktycznego ich wykorzystania syntezowania mowy z tekstu, zapisu wypowiedzi oraz personalizacji głosu syntezatora mowy. 40

42 Rysunek 4.1. Schemat realizacji metod API Android przez aplikację projektową Na schemacie 4.1 widać, że aktywności odgrywają rolę grupującą implementacje funkcji API, które operują na systemach syntezy mowy. Aplikacja została stworzona tak, aby funkcjonalności każdej z aktywności skupiały się na konkretnym zagadnieniu związanym z tematem implementacji funkcji mobilnych systemów TTS. Uzasadnieniem decyzji o wykorzystaniu metod z czwartej rewizji API były: chęć odzwierciedlenia realiów wykorzystania API dla mobilnych systemów syntezy mowy skupienie się na funkcjach pozwalających wykorzystywać systemy TTS umożliwienie zainstalowania aplikacji na najpopularniejszych urządzeniach z systemem Android. Każde z uzasadnień ma wspólne źródło. Zgodnie z analizą popularności systemu Android (patrz: rys. 2.5), większość użytkowników korzysta z systemu Android w wersji niższej niż 4.0. W związku z tym, metody z czternastej rewizji API (wydanej wraz z systemem Android 4.0) nie działałyby na większości urządzeń. Dodatkowym argumentem jest to, że większość metod dodanych w tej wersji biblioteki programistycznej nie odnosi się do wykorzystania systemów TTS, a do implementacji samych mechanizmów od podstaw Analiza budowy aplikacji Analiza głównego menu aplikacji Interfejs graficzny aplikacji składa się z czterech szablonów graficznych. Każdy z nich odpowiada konkretnej aktywności. Aplikacja nie zawiera dodatkowych plików XML, które opisy- 41

43 wałyby możliwe motywy graficzne czy szablony. Wszystkie możliwe rozszerzenia interfejsu użytkownika zostały ograniczone tak, aby zwrócić uwagę na funkcjonalności systemu syntezy mowy. Z drugiej strony, istniejące szablony graficzne zawierają możliwe najwięcej elementów interfejsu użytkownika, które są popularne w aplikacjach mobilnych. Zostały one użyte w taki sposób, aby ukazać możliwe korelacje między UI a mechanizmami syntezy mowy. Podstawową jednostką interfejsu graficznego, która służy do nawigacji pomiędzy aktywnościami są przyciski. Ten natywny element systemu Android jest dostępny z poziomu API (klasa anroid.widget.button). Oprócz nawigacji służą one do wywoływania i zatwierdzania funkcji. Są również jednym z głównych elementów składowych głównego menu aplikacji. Interfejs graficzny głównego menu aplikacji zawiera dwie składowe (widoczne na rys. 4.2). Pierwsza z nich to prosty szablon liniowy (tzw. LinearLayout), który zawiera w sobie natywny dla systemu Android komponent, który służy do wizualizacji postępu akcji ProgressBar. Ta część widoku nie jest interaktywna, oczekuje jedynie na wykonanie akcji działającej w tle. Rysunek 4.2. Szablon graficzny głównego ekranu aplikacji projektowej Druga składowa również opiera się na szablonie liniowym, który opiera się na tym, że elementy zawarte w szablonie układane są w jednej linii horyzontalnie obok siebie lub wertykalnie pod sobą, w zależności od parametru szablonu andriod:orientation. Obie składowe oparte na szablonie liniowym mają orientację wertykalną. Druga część widoku głównego menu jest interaktywna z użytkownikiem. Składa się ona z trzech przycisków o takich samych wymiarach, które przekierowują do konkretnych, zdefiniowanych dla aplikacji, aktywności. 42

44 Mimo prostoty budowy główne menu aplikacji zawiera istotne połączenie funkcjonalności systemu syntezy mowy z funkcjonalnością interfejsu graficznego. Interfejs graficzny dla tej aktywności posiada dwie składowe po to, aby ukazać proces inicjalizacji systemu syntezy mowy w aplikacji projektowej. System syntezy mowy jest elementem systemu Android. Jeśli zaistnieje potrzeba skorzystania z systemu syntezy mowy, wtedy konieczne jest połączenie się z silnikiem syntezy mowy. Oznacza to, że każda aktywność musi zażądać połączenia z systemem TTS, aby z niego skorzystać. Proces ten może zostać wykonany jednorazowo, np. bezpośrednio przed użyciem syntezatora mowy. W takim przypadku czas oczekiwania na wypowiedź wygenerowaną przez syntezator zwiększa się o czas łączenia aplikacji z systemem TTS. Z tego powodu regułą jest jednorazowe połączenie z silnikiem TTS w momencie inicjalizacji aktywności. Takie rozwiązanie ma dwie zalety: ewentualne błędy (np. brak zainstalowanego systemu TTS) wychwytywane są na samym początku działania programu generowanie wypowiedzi przez system TTS jest szybkie. Proces łączenia jest zazwyczaj krótki. Na nowszych modelach urządzeń mobilnych jest wręcz niezauważalny, lecz na popularnych telefonach działających na systemie Android 2.2 może trwać do kilku sekund. Dlatego możliwa jest implementacja tego procesu w dwojaki sposób: zablokowanie interfejsu użytkownika na czas inicjalizacji systemu TTS inicjalizacja systemu TTS w tle podczas działania programu (w osobnym wątku). W przypadku głównego menu aplikacji projektowej, ale również pozostałych aktywności jedynym słusznym było pierwsze rozwiązanie. Funkcjonalność aplikacji łączy się tylko i wyłącznie z API TTS, dlatego też ważne było uniemożliwienie użytkownikowi jakiejkolwiek interakcji z aplikacji do czasu połączenia się z systemem TTS. Powodem tego było zbyt duże ryzyko wywołania akcji, która wymaga działania systemu syntezy mowy, podczas gdy jest on niedostępny. Implementacja łączenia się z systemem TTS w głównym menu aplikacji przebiega jednak inaczej niż w pozostałych ekranach. Jest ona zobrazowana, podczas gdy pozostałe aktywności przeprowadzają ten proces w sposób niezauważalny przez użytkownika. Motywacją do tego sposobu implementacji była chęć zobrazowania procesu inicjalizacji aplikacji, interfejsu użytkownika i systemu syntezy mowy. W tym celu interfejs graficzny został stworzony z dwóch szablonów liniowych, które zawarte są kontenerze widoku, który API występuje pod nazwą ViewSwitcher. Standardowo 43

45 podczas tworzenia aplikacji na system Android, programista musi trzymać się ścisłej relacji pomiędzy konkretnym szablonem graficznym a aktywnością, na której jest używany. Oznacza to, że inicjalizując aktywność, definiowany jest tzw. widok zawartości (ang. content view). Akcje wykonywane w ramach aktywności mogą być prezentowane właśnie na tym szablonie. Czasami jednak istnieje potrzeba zawarcia dwóch szablonów graficznych w ramach jednej aktywności. Jest to możliwe dzięki zastosowaniu komponentu ViewSwitcher. Konieczność zastosowania tego komponentu wystąpiła również w przypadku menu głównego aplikacji projektowej. Komponent ViewSwitcher jest rodzajem kontenera, który umożliwia zawarcie w nim dwóch podrzędnych szablonów graficznych. 1 <ViewSwitcher xmlns : android= http : / / schemas. android. com/apk/ r e s / android 2 android : i d / menu swicher 3 android : l a y o u t w i d t h= match parent 4 android : l a y o u t h e i g h t= match parent > 5 6 <LinearLayout 7 android : l a y o u t w idth= match parent 8 android : l a y o u t h e i g h t= match parent 9 android : o r i e n t a t i o n= v e r t i c a l > <! 12 Miejsce na elementy pierwszego szablonu 13 > </LinearLayout> <LinearLayout 18 android : l a y o u t w idth= match parent 19 android : l a y o u t h e i g h t= match parent 20 android : o r i e n t a t i o n= v e r t i c a l > <! 23 M iejsce na elementy drugiego szablonu 24 > </LinearLayout> </ViewSwitcher> Kod źródłowy 4.1. Przykład zostosowania komponentu ViewSwitcher Kod źródłowy 4.1 przedstawia zarys szablonu menu głównego aplikacji projektowej, która oparta jest na komponencie ViewSwitcher. Sedno działania szablonu polega na tym, że 44

46 w momencie inicjalizacji aktywności na ekranie renderowana jest zawartość pierwszego szablonu liniowego. Po ustawieniu widoku wywoływane są metody służące do inicjalizacji systemu syntezy mowy. W projekcie zostały zaimplementowane dodatkowe klasy nasłuchujące (ang. listener), których metody wywoływane są jako reakcja na zakończenie procesu inicjalizacji systemu TTS. W wyniku wykonania tych metod przeprowadzane są operacje na szablonie graficznym. Oznacza to, że drugi szablon liniowy zawarty w tym pliku widoku jest zależny od pierwszego komponentu LinearLayout oraz metod, które są wywoływane, podczas gdy ten jest widoczny. Pierwszy szablon zawiera komponent ProgressBar, który w czytelny sposób informuje użytkownika o tym, że inicjalizowany jest system TTS. Po procesie inicjalizacji wywoływana jest metoda, która przełącza widok w ramach komponentu ViewSwitcher. W ten sposób aktywowany zostaje drugi szablon liniowy. Szablon zostaje zależnie od powodzenia inicjalizacji systemu syntezy mowy. Zależność ta jest pełnym uzasadnieniem połączenia inicjalizacji systemu syntezy mowy z komponentem ViewSwitcher. Drugi szablon jest kompozycją trzech przycisków odsyłających do pozostałych aktywności aplikacji. Jeśli inicjalizacja systemu TTS zakończy się sukcesem, wtedy użytkownik uzyska dostęp do przycisków. Za pomocą interakcji z interfejsem graficznym uzyska dostęp do pozostałych aktywności. W przeciwnym wypadku przyciski zostaną dezaktywowane oraz wyświetlona zostanie informacja o niepowodzeniu inicjalizacji silnika TTS. Informacja ta oznacza, że: w systemie operacyjnym nie został ustawiony domyślny mechanizm syntezy mowy ustawiony w systemie mechanizm syntezy mowy nie jest poprawnie skonfigurowany (nie zostały zainstalowane lub ustawione pliki głosów przeznaczone dla ustawionego mechanizmu). Po zatwierdzeniu informacji o błędzie (jednoznacznej z zapoznaniem się z komunikatem) aplikacja zostaje zamknięta. Przy ponownym uruchomieniu proces jest powtarzany. Opisywany sposób implementacji menu głównego jest uzasadniony tym, że menu główne jest jedyną aktywnością aplikacji, która pozwala na przejście do pozostałych aktywności, które wykorzystują TTS. W pozostałych aktywnościach inicjalizacja mechanizmu TTS wykonywana jest w tle, ponieważ ich uruchomienie musiało nastąpić z poziomu głównego menu. Oznacza to, że inicjalizacja systemu syntezy mowy musiała już wcześniej przebiec pomyślnie i ponowne wyświetlanie informacji o tym procesie w innych aktywnościach byłoby nieuzasadnione. Pozostałe szablony graficzne uruchamiane są dopiero po połączeniu się aktywności z systemem syntezy mowy, z pominięciem szablonu z komponentem ProgessBar. 45

47 Analiza aktywności prezentujących możliwości wykorzystania systemów TTS Jedynym elementem, który łączy główne menu aplikacji z API TTS jest łączeniem się z systemem syntezy mowy. Pozostałe aktywności nie pełnią już roli nawigacyjnej, ale swoją funkcjonalność skupiają na wykorzystaniu metod API Android dotyczącego systemów systemu mowy. Pierwsza z aktywności dostępna jest z poziomu menu, zostaje zainicjowana poprzez naciśnięcie przycisku Przegląd funkcji TTS. Inicjowanie połączenia aktywności z mechanizmem TTS przebiega tutaj poprzez te same interfejsy programistyczne, jednak zostały one obsłużone w inny sposób niż w głównym menu aplikacji. Po naciśnięciu przycisku aktywność zostaje uruchomiona, jednak interfejs graficzny nie jest widoczny do momentu, aż system syntezy mowy będzie gotowy. W praktyce czas oczekiwania na ukazanie się przycisków jest krótki. Rysunek 4.3. Szablony graficzne ekranów funkcyjnych aplikacji projektowej Podobnie jak w przypadku menu głównego, aktywność o nazwie Przegląd funkcji TTS (która zaimplementowana została w klasie TtsReviewActivity) opiera się na bardzo prostym szablonie graficznym. Składa się on z pięciu przycisków, których proporcję są identyczne (patrz: rys. 4.3, przykład 1). Zabieg ten jest umyślny, ponieważ celem aktywności jest ukazanie możliwości API, które dotyczące jedynie silnika TTS. W opisywanej aktywności wszystkie metody korzystające z mechanizmu TTS wywoływane są poprzez podstawowe składowe interfejsu użytkownika. Dzięki temu możliwe było ukazanie, w jaki sposób działają mobilne systemy syntezy mowy oraz w jaki sposób współpracują z elementami systemu Android. Każda z wykorzystywanych metod jest publiczną metodą klasy TextToSpeech dołączonej 46

48 do API Android, która jest zainicjalizowana w opisywanym wcześniej procesie. Efektem tej inicjalizacji jest gotowa do użycia instancja klasy. Odpowiedzią na skończenie procesu jest ustawienie odpowiednich wartości opisujących wysokość tonu głosu syntezatora mowy oraz szybkość czytania. Wartości te pobierane są z preferencji zapisanych w aplikacji. Jeśli wcześniej użytkownik nie określił tych wartości (patrz: punkt 4.2.4) do co tych wartości, wtedy ustawiane są wartość domyślne. Pierwsza funkcjonalność zaimplementowana w API TTS i wykorzystana w tej aktywności wywoływana jest tak samo, jak reszta funkcjonalności w prezentowanej aktywności, poprzez przycisk (komponent Button). Kliknięcie obsługiwane jest przez metodę API (patrz kod źródłowy 4.2). 1 Button reviewtestbutton = ( Button ) findviewbyid (R. i d. r e v i e w t e s t b u t t o n ) ; 2 3 reviewtestbutton. s e t O n C l i c k L i s t e n e r ( 4 new OnClickListener ( ) { 5 public void onclick ( View v ) { 6 t t s. speak ( g e t S t r i n g (R. s t r i n g. speak something ), 7 TextToSpeech. QUEUE FLUSH, null ) ; 8 } 9 } ) ; Kod źródłowy 4.2. Sposób podpinania akcji do komponentu Button Przykład kodu źródłowego 4.2 pokazuje, że inicjalizacja realizacji danej akcji, wykonywanej jako reakcja na naciśnięcie przycisku jest jednorazowa. Po inicjalizacji interfejsu graficznego wywoływany jest fragment kodu, który łączy akcję z przyciskiem poprzez implementację interfejsu dołączonego do API Android, będącego klasą typu listener. Pierwsza funkcjonalność to wywołanie metody tts.speak(), która wyzwala na syntezatorze mowy akcję czytania tekstu, który został podany jako argument. Inicjalizacja interfejsu graficznego jest reakcją na pomyślne zainicjalizowanie systemu syntezy mowy. W związku z tym, nie jest konieczne sprawdzanie czy obiekt TextToSpeech tts jest prawidłowym obiektem i czy nie jest pusty, bo to gwarantuje nam początkowy proces inicjalizacji. Funkcjonalność podpięta do pierwszego przycisku prezentuje najpopularniejszą metodę API TTS oraz też najprostsze zastosowanie mechanizmu syntezy mowy. Funkcjonalności wykonujące się jako reakcje na naciśnięcie drugie i trzeciego przycisku wymagają od użytkownika więcej interakcji. Funkcjonalności te prezentują współdziałanie systemu syntezy mowy z popularnymi komponentami systemu Android, jakimi są przyborniki daty i czasu. Są to predefiniowane komponenty, zwane dialogami. Komponent Dialog jest klasą rozszerzalną, za pomocą której użytkownik może definiować 47

49 swoje własne dialogi. Jest to rodzaj okna wywoływanego w ramach aktywności, który nie zaburza jej interfejsu graficznego. Jest rodzajem nakładki na działający interfejs graficzny. Rysunek 4.4. Domyślny wygląd dialogów do wyboru daty i godziny w systemie Android 4.0 W ramach API, oprócz szkieletu dialogów, które można rozbudować, istnieją również gotowe implementacje, które obsługują najpopularniejsze funkcjonalności. Takimi typami komponentów są DatePicker oraz TimePicker (patrz: rys. 4.4). Komponenty te umożliwiają w prosty sposób wybrać konkretną datę i godzinę oraz łatwo zarządzać danymi z nich otrzymanymi. Uproszczenia te odnoszą się zarówno do sfery użytkowej, jak i programistycznej, ponieważ minimalizują ilość kodu potrzebnego na implementację wielu elementów graficznych, które składają się na te komponenty. Użycie wyżej opisywanych komponentów miało dwa cele: ukazanie, w jaki sposób można połączyć funkcje zwracające dane z popularnych komponentów systemu Android z systemem syntezy mowy ocena, w jakim stopniu mobilne systemy syntezy mowy rodzą sobie z syntezowaniem teksty z formatów liczbowych, tj. dat i czasu. 48

50 Głównym wnioskiem jest to, że stosowanie API dotyczącego TTS wraz z dialogami jest bezproblemowe. Jest tak dzięki temu, że instancja klasy TextToSpeech jest łatwo dostępna, a jej metody przyjmują małą ilość argumentów o precyzyjnym przeznaczeniu. Dodatkowym wnioskiem wartym odnotowanie jest fakt, że system syntezy IVONA jest skonstruowany tak, że radzi sobie nie tylko z tekstem, ale również liczbami. Najpopularniejsze mobilne systemy syntezy mowy rozpoznają, z jakim formatem licz mają do czynienia i z łatwością zamieniają np. liczby na nazwy konkretnych miesięcy. Przedostatni komponent Button zawarty w interfejsie graficznym opisywanej aktywności służy do wywołania nieszablonowego dialogu. Jest to AlertDialog, który jest rozszerzeniem komponentu Dialog. Klasa AlertDialog zaimplementowana została z myślą o tworzeniu dialogów, które zawierają od jednego do trzech komponentów typu Button. Jest to zatem gotowy komponent, który można jednak znacznie konfigurować. Rysunek 4.5. Dialog w aplikacji projektowej umożliwiający ustawienie tekstu do wypowiedzenia przez syntezator W przypadku aplikacji projektowej do komponentu AlertDialog został wstrzyknięty szablon graficzny, stworzony na potrzeby prezentacji możliwości systemu syntezy mowy. Szablon zawiera m.in. komponent EditText umożliwiający użytkownikowi wprowadzanie tekstu (co widać na rys. 4.5). Dzięki takiej implementacji możliwe jest ukazanie szerokiej gamy zastosowania API TTS bez konieczności wdrażania wielu szablonów graficznych lub tworzenia jednego, rozbudowanego szablonu. Tak samo jak w poprzednich dwóch funkcjonalnościach, zaimplementowany dialog pozwala na testowanie systemu syntezy mowy. Różnica polega na braku ograniczeń, ponieważ użytkownik może wprowadzić do komponentu EditText dowolny tekst, który po zatwierdzeniu jest przekazywany jako parametr do systemu syntezy mowy. Ostatni przycisk, będący elementem aktywności, od strony funkcjonalnej jest prosty, ale 49

51 pokazuje dodatkowe możliwości API TextToSpeech. Po jego naciśnięciu następuje kolejkowanie tekstów zawartych w poprzednich dialogach oraz pierwszym wstępnym tekście. Jest to funkcjonalność API, która pozwala na składanie tekstów z wielu źródeł i dynamiczne budowanie wypowiedzi. Druga aktywność, dostępna z poziomu głównego menu po naciśnięciu przycisku Wyszukiwarka, jest rozwinięciem funkcjonalności zawartych w aktywności pierwszej. Jej stworzenie było motywowane chęcią ukazanie praktycznego zastosowania systemów syntezy mowy. W opisywanej aktywności funkcje systemu TTS mają rolę współgrać z resztą funkcjonalności, tworząc wraz z pozostałymi elementami programistycznymi spójną całość. W tym celu zastosowanych zostało wiele komponentów wchodzących w skład API Android, tj. komponent EditText, przyciski, widok listy oraz mechanizm AsyncTask, który pozwala łatwe przetwarzanie i zarządzanie informacjami w innym wątku. System syntezy mowy reaguje na akcje użytkownika oraz na zmiany przetwarzanych danych. Funkcjonalność aktywności opiera się na wyszukiwaniu informacji z serwisu Wikipedia, jednak w odróżnieniu od standardowych wyszukiwarek, treści nie są prezentowane w formie tekstowej, ale wyniki prezentowane są poprzez wypowiedź wygenerowaną przez mobilny mechanizm TTS. Po wpisywaniu tekstu do pola tekstowego i zatwierdzaniu go odpowiednim przyciskiem aplikacja rozpoczyna wyszukiwanie. Dzięki odpowiednim uprawnieniom aplikacja może korzystać z zasobów systemu. Pierwszym uprawnieniem jest możliwość korzystania z Internetu. Podczas wyszukiwania aplikacja, w osobnym wątku, za pomocą zdefiniowanych algorytmów wyszukuje w serwisie Wikipedia odpowiednich dla zapytania treści oraz parsuje je. Efektem zakończenia algorytmu jest wygenerowanie wypowiedzi przez syntezator mowy, która przedstawia efekt wyszukiwania. Gdy do wyszukiwanej frazy nie zostaje dopasowany żaden wynik, na ekranie pojawia się stosowna informacja. Dodatkową funkcjonalnością aktywności jest zapisywanie efektów wyszukiwania do pliku dźwiękowego w formacie wav. Jest to możliwe dzięki wykorzystaniu uprawnienia do zapisywania danych na karcie pamięci, komponentu Buton oraz odpowiednim metodom API TTS. Po wyszukaniu wynik dla frazy w interfejsie użytkownika zostaje odblokowany przycisk Eksportuj do pliku. Reakcją na jego wywołanie jest wygenerowanie wypowiedzi przez syntezator i zapisanie jej do pliku na karcie pamięci. Dzięki tej funkcjonalności możliwe jest odtwarzanie znalezionej wypowiedzi każdorazowo po otarciu aplikacji, bez konieczności posiadania dostępu do internetu i korzystania z syntezatora mowy. System jedynie odtwarza zapisany wcześniej plik dźwiękowy. Każda wypowiedź wygenerowana w dwóch opisanych aktywnościach respektuje ustawienia systemu syntezy mowy, które zapisywane są w preferencjach aplikacji. Użytkownik może je modyfikować przechodząc do aktywności odpowiadającej za ustawienia systemu TTS. 50

52 Analiza aktywności ustawień systemu syntezy mowy Aktywność o nazwie Ustawienia, dostępna z poziomu głównego menu, korzysta z metod API klasy TextToSpeech, które nie dotyczą generowania wypowiedzi z tekstu. Aktywność została stworzona z myślą o: umożliwieniu zmiany ustawień systemu syntezy mowy ukazaniu możliwości ingerowania w głos syntezatora mowy pobraniu i przedstawieniu informacji na temat zainstalowanego w systemie syntezatora mowy Aktywność została podzielona na dwie części interaktywną, umożliwiającą użytkownikowi zmianę ustawień oraz informacyjną, które prezentuje informacje na temat systemu syntezy mowy. Pierwsza część aktywności składa się z dwóch zgrupowanych komponentów SeekBar. Służą one do modyfikacji dwóch ustawień systemu syntezy mowy, które wpływają głos syntezatora. Pierwszą jest szybkość czytania tekstu, druga to wysokość tonu głosu syntezatora mowy. Nazwy tych opcji są deskryptywne i ich modyfikowanie domyślne. Co ważne, ustawienie tych opcji powoduje zapisanie wartości do preferencji aplikacji, a nie ustawienie ich dla syntezatora mowy. Wartości tych opcji pobierane są każdorazowo po inicjalizacji systemu TTS w aktywnościach funkcjonalnych i dopiero tam zapisywane dla danej instancji obiektu TextToSpeech. Uzasadnieniem zastosowania komponenty SeekBar do ustawienia opcji systemu TTS jest to, że parametry metod ustawień TTS muszą być przedstawione w postaci dziesiętnej, a ich wartości muszą zawierać się w przedziale obustronnie domkniętym, od 0 do 1. Przedstawienie wartości liczbowych użytkownikom niemającym pojęcia o tych parametrach nie miałoby uzasadnienia. Komponent SeekBar rozwiązuje ten problem, ponieważ pozwala on na płynne zmienianie wartości w danym przedziale. Druga część aktywności składa się z prostych komponentów umożliwiających wyświetlanie tekstu. Wykorzystywane są tutaj metody API związane z mechanizmem syntezy mowy oraz dotyczące pobierania informacji na temat komponentów środowiska i systemu operacyjnego. Dzięki połączeniu różnych metod API generowane są informacje na temat aktualnie dostępnego i aktywnego systemu syntezy mowy. W pierwszym polu tekstowym wyświetlane są przetworzone informacje na temat silnika syntezy mowy, który jest zainstalowany. W drugim polu wymieniony jest domyślny język, z jakiego korzysta wyżej wymieniony system syntezy mowy (patrz: rys. 4.3, przykład 3). 51

53 4.3. Analiza API dotyczącego systemów syntezy mowy na platformie Android Część API do systemu Android, która przeznaczona jest dla systemów syntezy mowy, jest stosunkowo niewielka oraz zawiera mało klas programistycznych. Od czwartej do czternastej rewizji API istniały jedynie cztery interfejsy programistyczne, które wspierały mechanizm TTS. W czternastej i piętnastej rewizji API (odpowiadającym systemowi Android 4.0) pojawiły się kolejne klasy programistyczne w pakcie android.speech.tts. Skalę API, wielkość API TTS oraz jej udział w całym API dla systemu Android ukazuje rys Rysunek 4.6. Wyszczególnienie interfejsów TextToSpeech w API Android (opracowanie własne na podstawie [1]) Wśród niewielkiej ilości klas API znajdujących się w pakiecie android.speech.tts część klas nie odnosi się do funkcjonalności, jakie oferują systemy syntezy mowy. Duża liczba klas programistycznych łączy się z pobieraniem informacji o mechanizmie TTS (Engine, EngineInfo), reakcjami na działanie mechanizmu TTS (OnUtteranceCompletedListener, UtternaceProgressListener) i zarządzaniem instancją obiektu TTS (OnInitListener) Konfiguracja systemu syntezy mowy Mechanizm służący do syntezy mowy jest rodzajem składowej systemu Android. Oznacza to, że to system operacyjny zarządza silnikiem syntezy mowy, a sam mechanizm TTS zapewnia wszelkie metody i implementacje (wraz z plikami głosów), które są konieczne do poprawnego korzystania z możliwości, jakie zapewnia system operacyjny. Aplikacja, która korzysta z systemu syntezy mowy musi podłączyć się do systemu TTS, który został wcześniej zainstalowany i ustawiony jako główny dla systemu Android. 52

54 Inicjalizacja systemu syntezy mowy odbywa się osobno dla każdej aktywności. Wynika to przede wszystkim z odgórnych założeń API systemu Android. Od strony programistycznej inicjalizacja to utworzenie instancji klasy android.speech.tts.texttospeech. Klasa ta, zgodnie z API, ma odgórnie narzucony konstruktor: TextToSpeech(Context context, TextToSpeech.OnInitListener listener). Istotę inicjalizacji można przedstawić charakteryzując parametry konstruktora dla systemu syntezy mowy. 1 public void i n i t T t s ( TextToSpeech t t s ) { 2 i f ( t t s!= null ) { 3 Locale p o l i s h L o c a l e = new Locale ( P l p l ) ; 4 int ttslanguagesetresult = t t s. setlanguage ( p o l i s h L o c a l e ) ; 5 switch ( ttslanguagesetresult ) { 6 case TextToSpeech. LANG MISSING DATA : 7 l i s t e n e r. onttsconfigurationend ( f a l s e ) ; 8 break ; 9 case TextToSpeech.LANG NOT SUPPORTED: 10 l i s t e n e r. onttsconfigurationend ( f a l s e ) ; 11 break ; 12 default : 13 l i s t e n e r. onttsconfigurationend ( true ) ; 14 } 15 } 16 } Kod źródłowy 4.3. Inicjalizacja systemu syntezy mowy Konstruktor klasy TextToSpeech jako pierwszy parametr przyjmuje tzw. kontekst aplikacji. Kontekst jest klasą abstrakcyjną, która przechowuje informacje na temat środowiska aplikacji. Klasa ta jest dostarczana jako natywny element systemu Android. Stworzona została po to, aby umożliwić programistom łatwe przechowywanie i przekazywanie informacji na temat wszystkich niezbędnych informacji na temat aplikacji (np. zasoby, grafiki, teksty, szablony, uprawnienia). Instancją kontekstu w aplikacji jest aktywność. Chcąc przekazać informacje na temat aktywności do innej klasy, programista powinien przekazać kontekst aplikacji, a nie całą aktywność. Sytuacja taka zachodzi w przypadku konstruktora TextToSpeech, gdzie jako kontekst należy podać aktywność, w której klasa ta jest inicjalizowana. Z tego faktu wynika konieczność inicjalizacji klasy TextToSpeech dla każdej aktywności osobno, bo tylko w ten sposób można zapewnić przekazanie odpowiedniego kontekstu dla instancji mechanizmu TTS. Drugi argument, który należy przekazać do konstruktora TextToSpeech to implementacja interfejsu TextToSpeech.OnInitListener. Ten element inicjalizacji, w przeciwieństwie do przekazywania kontekstu aplikacji, jest specyficzny dla API TextToSpeech. Klasa 53

55 OnInitListener jest interfejsem, co oznacza, że implementacja tej klasy zależy od programisty. Niesie to ze sobą dużą dowolność, lecz wadą tej metody jest konieczność znajomości schematu inicjalizacji systemu TTS (kod źródłowy specyficzny dla tego procesu został ukazany na listingu kodu 4.3). W związku z tym, że w aplikacji projektowej od inicjalizacji systemu TTS uzależniony jest proces budowania interfejsu użytkownika, implementacja interfejsu OnInitListener została rozszerzona o dodatkowe metody. Dodatnie tych metod miało na celu lepsze zobrazowanie inicjalizacji mechanizmu TTS oraz ukazanie, że samo wywołanie procesu inicjalizacji może oddziaływać na działanie całej aplikacji. Aplikacja projektowa zawiera i implementuje dwa dodatkowe interfejsy pomocnicze, które uzupełniają proces inicjalizacji systemu TTS. Interfejs API OnInitListener zawiera tylko jedną metodę: oninit(int status), która musi zostać zaimplementowana, a której argument zwraca status inicjalizacji systemu TTS w postaci liczby całkowitej. Liczby ta odpowiada konkretnej fladze API TextToSpeech: TextToSpeech.SUCCESS wartość oznacza poprawne zainicjalizowanie TTS TextToSpeech.ERROR wartość oznacza błąd przy inicjalizacji. Reakcją metody API oninit(int status) na przyjęcie parametru status odpowiadającemu TextToSpeech.SUCCESS, jest wywołanie dodatkowych metod, które w efekcie wywołują metodę inittts(texttospeech tts), która operuje już na zainicjalizowanym obiekcie TextToSpeech (patrz: kod źródłowy 4.3). W metodzie tej wywoływane są metody API Android, które ustawiają język dla syntezatora mowy (czyli pośrednio określane są plików głosów dla mechanizmu TTS). Metoda setlanguage(locale locale) jako efekt działania zwraca wartość w postaci liczby całkowitej, która odpowiada flagom API: TextToSpeech.LANG MISSING DATA wartość oznacza, że system TTS nie posiada danych do obsługi ustawianego języka TextToSpeech.LANG NOT SUPPORTED wartość oznacza, że system TTS nie obsługuje ustawianego języka. Język dla systemu TTS zostaje poprawnie ustawiony, jeśli metoda setlanguage(locale locale) nie zwróci żadnej z wyżej wymienionych wartości. W takim wypadku wywoływane są metody, które budują szablon graficzny aktywności i zakończony zostaje proces inicjalizacji systemu TTS oraz aktywności, w której będzie wykorzystywany. 54

56 Interfejsy umożliwiające korzystanie z systemu syntezy mowy Po inicjalizacji, gdy instancja klasy TextToSpeech jest gotowa do użycia, korzystanie z systemu syntezy mowy jest stosunkowo łatwe. Jak w przypadku inicjalizacji, programista korzystając z metod API musi korzystać z dodatkowych flag (czyli zbioru statycznych, finalnych pól z przypisanymi wartościami), które dostarczone są wraz z API. Wszystkie metody syntezatora mowy należą do klasy TextToSpeech i na jej instancji należy je wywoływać. Najpopularniejszą metodą tej klasy jest metoda speak(string text, int queuemode, HashMap<String, String> params). Za pomocą tej metody można wywołać wypowiedź syntezatora mowy. Jej pierwszym argumentem jest tekst, który będzie syntezowany. Drugi parametr to liczba całkowita, która określa sposób kolejkowania wypowiedzi. Wartość tego parametru musi odpowiadać wartości flag klasy TextToSpeech: TextToSpeech.QUEUE ADD ustawienie wartości powoduje, że podany tekst zostaje dodany do kolejki wypowiedzi i zostanie syntezowanym, dopiero gdy ukończona zostanie synteza wcześniej dodanych tekstów TextToSpeech.QUEUE FLUSH efektem ustawienia wartości jest natychmiastowe przekształcenie tekstu na mowę i usunięcie z kolejki wszystkich przedtem dodanych tekstów. Trzeci parametr jest mapą dodatkowych parametrów syntezatora mowy. Mapa posiada zbiór kluczy w formie tekstu, które posiadają wartości tego samego typu. Klucze tej mapy muszą być podzbiorem kluczy zawartych w klasie TextToSpeech.Engine, który jest zbiorem trójelementowym, a wartości danego klucza muszą odpowiadać rodzajowi strumienia opisanego w klasie AudioManager. Własności te są zagadnieniem zaawansowanym i dotyczą korzystania z ustawieniem strumieni audio, które zapisane są dla takich strumieni jak strumień muzyki, dzwonków czy notyfikacji, które są rozróżniane przez system Android. Kolejkowanie za pomocą parametru TextToSpeech.QUEUE ADD nie jest jedynym sposobem kontroli nad wypowiedziami syntezatora mowy. Istnieje również metoda isspeaking(), która w zależności od tego czy syntezator jest zajęty syntezowaniem tekstu, zwraca wartość prawda lub fałsz. Jeśli zwróconą wartością jest prawda, wtedy możliwe jest także przerwanie wypowiedzi za pomocą metody stop(). Możliwe jest także modyfikowanie samych wypowiedzi syntezatora mowy. Służą do tego cztery metody posiadające kilka dodatkowych wariantów. Zostały one opisane w tabeli

57 Nazwa metody Parametry Opis działania addearcon String earcon String filename Pozwala na dodanie dźwięku tzw. przerywnika, sygnału, który używany jest np. między informacjami. Pierwszy parametr określa nazwę przerywnika, a drugi jest referencją do pliku dźwiękowego. addearcon String earcon String packagename int resourceid Funkcjonalność taka sama j/w. Metoda różni się referencją do pliku dźwiękowego, który w tym przypadku odnosi się do konkretnego pakietu. addspeech String text String packagename int resourceid Metoda dodaje mapowanie tekstu podanego jako pierwszy argument na konkretne źródło dźwiękowe o identyfikatorze podanym w trzecim argumencie z pakietu podanego jako argument drugi. Po dokonaniu metody kolejne wyraz podany jako pierwszy argument nie będzie w metodzie speak(...) syntezowany, lecz zastępowany dźwiękiem ze źródła podanego wywołowaniu tej metody. addspeech String text String filename Funkcjonalność j/w. Różnica polega na tym, że tekst podany w pierwszym argument podczas syntezowania będzie zastępowany dźwiękiem, którego źródłem jest plik, do którego ścieżka została określona w drugim argumencie. playearcon String earcon int queuemode HashMap params Odtworzenie wcześniej określonego przerywnika, do którego odwołuje się po nazwie (wcześniej podanej w metodzie addearcon(...)) playsilence long durationinms int queuemode HashMap params Dodanie pauzy do wypowiedzi (o długości określonej w pierwszym argumencie). Tabela 4.1. Metody klasy TextToSpeech służące ingerowaniu w wypowiedź mechanizmu TTS (opracowanie własne na podstawie [1]) Poprzez zbiór wyżej opisanych metod oraz wielu możliwych kombinacji parametrów możliwe jest budowanie złożonych wypowiedzi. Za pomocą parametrów metod możliwe jest również 56

58 modyfikowanie samych wypowiedzi, co umożliwia zwiększanie jakości wypowiedzi i podkreślanie informacji zawartych w tekście. Możliwe jest też ingerowanie w samą wypowiedź syntezatora mowy poprzez tworzenie substytutów dla konkretnych słów czy zwrotów. Dodanie substytutów dla tekstu za pomocą metody addspeech(...) jest jednak nieefektywne, ponieważ głosy mapowane zdecydowanie różnią się tonem i jakością wypowiedzi od głosów syntezatora oraz są zawsze takie same niezależnie od kontekstu. Utworzenie zamiennika tekstu o lepszej jakości jest przez to praktycznie niemożliwe. Praktycznym zastosowaniem metod do zamieniania konkretnych fraz jest cenzurowanie wulgarnych wyrazów Metody dodatkowe i pomocnicze Oprócz metod służących do generowania mowy poprzez system TTS oraz modyfikowania wypowiedzi istnieją także metody API, które nie są związane bezpośrednio z tymi procesami. Są to przede wszystkim metody służące do: ustawiania wartości i modyfikacji ustawień mechanizmu TTS pobierania informacji na temat mechanizmu TTS Metody z pierwszej grupy służą do modyfikacji głosów syntezatora mowy, ale ich zmiana nie wpływa na sam sposób syntezowania mowy. Operacje wykonywane tymi metodami ingerują z charakterystykę tonu mechanizmu TTS. W skład tej grupy wchodzą dwie podstawowe metody, które przyjmują jako parametr liczby dziesiętne: setspeechrate(float speechrate) oraz setpitch(float pitch). Pierwsza metoda służy do określania szybkości wypowiedzi generowanych przez syntezator mowy (im większa wartość parametru, tym szybsza wypowiedź). Druga metoda określa wysokość tonu syntezatora mowy (im większa wartość tym ton wypowiedzi wyższy). W API dostępna jest również metoda pozwalająca na ustawienie systemu syntezy mowy. Jako parametr przyjmuje nazwę pakietu, w którym jest zainstalowany system syntezy mowy. Wadą tego rozwiązania jest brak możliwości wyboru domyślnego systemu z listy zainstalowanych systemów TTS. Istnieje więc duże ryzyko, że pakiet, który został podany w argumencie metody nie będzie w ogóle dostępny. Druga grupa metod to tzw. gettery (ang. get pobierać). Podstawową metodą tego rodzaju jest getdefaultengine(), która dostępna jest od samego początku istnienia API TTS. Pozwala ona na pobranie nazwy pakietu domyślnego silnika TTS. Nie pozwala ona jednak na pobranie informacji na temat samego mechanizmu. Jednak informacja o nazwie pakietu jest wystarczająca, ponieważ API Android przewiduje dodatkowe metody, które pozwalają pobierać informacje na temat zasobów systemu po nazwie pakietu. Równie przydatne są metody getlanguage() i islanguageavailable (Locale loc). Pierwsza zwraca informacje 57

59 na temat domyślnego języka używanego przez system TTS. Druga pozwala na sprawdzenie czy podany w argumencie język jest obsługiwany przez mechanizm syntezy mowy. Część metod do pobierania informacji, których brakowało we wcześniejszych wersjach API, pojawiła się wraz z API dla systemu Android 4.0. Są nimi metody getengines() i getfeatures(locale locale). Szczególnie przydatna jest pierwsza z nich, ponieważ zwraca ona, w postaci listy wyników, wszystkich mechanizmy TTS, które zainstalowany są na danym urządzeniu. W API systemu Android istnieje jeszcze jedna szczególna metoda, oferująca dodatkową funkcjonalność synthesizetofile(string txt, HashMap params, String file). Jest ona substytutem metody speak(...), ponieważ jej działanie polega również na przekształceniu tekstu na mowę. Różnica jest jednak taka, że efektem działania tej metody nie jest wygenerowanie dźwięku, emitowanego bezpośrednio po syntezie, ale zapisanie pliku dźwiękowego z wygenerowaną wypowiedzią. Pliki zapisywane są w formacie wav Zakres zastosowania API Android dotyczący systemów syntezy mowy Wyciągając wnioski z wykorzystania metod opisanych w poprzednich rozdziałach można stwierdzić, że API Android pozwala na efektywne korzystanie z mechanizmów TTS. Korzystając ze wszystkich metod pakietu android.speech.tts programista może nie tylko korzystać z systemu syntezy mowy, ale także ingerować w wypowiedzi systemu TTS zwiększając ich jakość. Niestety ze względu na długi przestój w rozwijaniu API dotyczącego TTS, zawiera ono wiele ograniczeń i brakuje w nim metod, które pozwalałyby na dostosowanie systemu syntezy mowy do potrzeb aplikacji mobilnych Możliwości Ważnym aspektem API TextToSpeech jest fakt, że zawiera ono kompleksowy zestaw metod do generowania wypowiedzi za pomocą systemu syntezy mowy. Pozwala na zarządzanie wypowiedziami i ich kolejnością wraz z zarządzeniem kolejką wypowiedzi. Pozwala to na przetwarzanie nie tylko krótkich informacji tekstowych, ale także na generowanie wypowiedzi, z bardzo długich tekstów, takich jak artykuły czy nawet książki fabularne. Jest to możliwe dzięki wywoływaniu szeregu metod z odpowiednimi parametrami, które współgrają ze sobą. Metody te łączą teksty, tworząc spójną wypowiedź. Dodatkowym atutem mobilnych systemów syntezy mowy jest możliwość eksportowania wypowiedzi do plików tekstowych, co pozwala na tworzenie wypowiedzi nie zależnych od zasobów systemu, w tym także od samych systemów syntezy mowy. Dzięki zastosowaniu eksportowania wypowiedzi możliwe jest późniejsze odtworzenie wygenerowanej wypowiedzi na 58

60 dowolnym urządzeniu (mobilnym czy też stacjonarnym), które nie ma możliwości skorzystania z mechanizmu TTS. Ważną cechą jest też możliwość modyfikacji szybkość czytania i tonu wypowiedzi oraz możliwość dodawania pauz lub przerywników. Dzięki tym funkcjom możliwe jest ingerowanie w wypowiedzi syntezatora mowy. Co prawda nie dotyczy to samej jakości przetworzenia tekstu, ale funkcje te umożliwiają dostosowanie wygenerowanej wypowiedzi do konkretnej funkcjonalności. Możliwe jest tworzenie wypowiedzi z odpowiednimi przerwami, przerywnikami dźwiękowymi. Możliwe jest również przyśpieszanie wypowiedzi w konkretnych momentach, dla konkretnych fraz, podnoszenia i obniżanie tonu syntezatora. Opcje te czynią mobilne systemy syntezy mowy bardziej funkcjonalnymi i praktycznymi. Rozwój API Android niesie ze sobą dodatkowe możliwości dotyczące mobilnych systemów TTS. Łączy się to przede wszystkim tendencją twórców systemu Android do dodawania nowych interfejsów umożliwiających implementacje nowych systemów syntezy mowy. Jest zagadnienie niezwiązane z funkcjonalnością istniejących systemów TTS i ich wykorzystaniem, ale pokazuje, że twórcy systemu operacyjnego widzą możliwości rozwoju technologii TTS i inwestują w nią swoją pracę. Widać to także po nowych interfejsach, dodawanych w najnowszych wydaniach API Android, które pozwalają na śledzenie wypowiedzi. Chodzi tutaj o klasy, które reagują na postęp wypowiedzi oraz jej zakończenie. W nowych wersjach systemu Android możliwe będzie śledzenie postępu generowania mowy oraz reagowania na np. zakończenie pierwszej części wypowiedzi syntezatora Ograniczenia Ograniczenia mobilnych systemów syntezy mowy są efektem dwóch czynników. Pierwszym z nich są ograniczenia samego API dla mechanizmów TTS. Drugi powód nie jest zależny od samych syntezatorów mowy. Wynika on z ograniczoności sprzętowej, zasobów i możliwości samego systemu operacyjnego Android. Co prawda ograniczenia nie dotyczą głównych i najważniejszych funkcjonalności systemów syntezy mowy, czyli generowania wypowiedzi. Wpływają one jednak na możliwości personalizacji aplikacji pod względem wykorzystania funkcji TTS. Ograniczenia, jakie niesie ze sobą API TTS to przede wszystkim ograniczenie opcji wyboru systemu syntezy mowy, pobrania informacji o nim, dostępności informacji na temat wspieranych dźwięków. Na szczęście twórcy systemu Android zdają sobie z tego sprawę, co widać w czternastym wydaniu API. W tym wydaniu interfejsów programistycznych zostały dodane metody takie jak getengines() i getfeatures(), które pozwalają na pobranie dokładnej listy informacji na temat wszystkich systemów syntezy mowy zainstalowanych w systemie operacyjnych. Pozostaje jednak zagadką, dlaczego tak podstawowe funkcje były 59

61 niedostępne przez ponad dwa lata, przez co wiele aplikacji korzystających z systemów TTS nie wykorzystuje w pełni ich możliwości. Innym, godnym wymienienia ograniczeniem API jest ograniczenie związane z eksportowaniem wypowiedzi syntezatora mowy do pliku dźwiękowego. Związane jest ono przede wszystkim z cechami systemu Android i brakiem dodatkowych narzędzi wspomagających tę funkcjonalność. Przy opisywaniu metod eksportujących wypowiedzi do pliku (patrz: punkt 4.3.3) zaznaczone zostało, że pliki zapisywane są w formacie wav. Właśnie ten format jest główny ograniczeniem funkcjonalności, co czyni ją jedynie ciekawostką i wyklucza jej praktyczne zastosowanie. System Android i jego API niosą ze sobą ograniczenia dotyczące kompresji plików dźwiękowych. W praktyce nie jest możliwe proste kompresowanie plików do postaci popularnych formatów jak np. mp3. Co prawda format wav gwarantuje zadowalającą jakość dźwięku, ale jednocześnie pliki w tym formacie zajmują dużo przestrzeni dyskowej. Urządzenia mobilne cechują się ograniczonością zasobów, a przede wszystkim ograniczonością powierzchni dyskowej. Przykładowa, wyeksportowana wypowiedź o długości jednej minuty może zajmować na karcie pamięci nawet ponad 1 MB danych. Zakładając, że twórcy aplikacji chcieliby generować pliki, które zawierają długi fragment artykułu (nie wspominając o całej powieści fabularnej) taki plik mógłby być o wiele większy niż pojemność całej karty pamięci. W praktyce oznacza to dyskwalifikację opisywanej funkcjonalności API. 60

62 ROZDZIAŁ 5 Zakończenie Kierunek rozwoju systemów syntezy mowy odzwierciedla tendencje, jakie panują w dziedzinie rozwoju oprogramowania. W związku ze wzrostem popularności urządzeń mobilnych, takich jak smartfony czy tablety, widoczne jest dążenie producentów do przenoszenia rozwiązań znanych z komputerów stacjonarnych na urządzenia mobilne. Co ważne, mimo ograniczonych zasobów sprzętowych urządzeń mobilnych, mobilne mechanizmy TTS charakteryzują się taką samą jakością jak ich odpowiedniki działające na wydajniejszych komputerach. Wynika to z faktu, że autorami opisywanych systemów na platformę Android są ci sami producenci, którzy od wielu lat znani są z rozwiązań technologicznych związanych z budową mechanizmów syntezy mowy. Wśród mobilnych syntezatorów mowy wyróżniają się Ivona TTS oraz SVOX Classic TTS, których produkty charakteryzują się wysoką jakością generowanych wypowiedzi i dużą ilością wspieranych języków. Mechanizmy syntezy mowy pojawiły się na platformie Android wraz z wydaniem wersji 1.6. Wtedy wraz z umożliwieniem korzystania z mechanizmów TTS udostępnione zostało otwarte API. Przez ponad dwa lata ono było dostępne w niemal niezmienionej formie. Klasy i metody w nim zawarte umożliwiają zaprogramowanie funkcjonalności, które wykorzystują zainstalowany w systemie operacyjnym silnik TTS. Opisywana wersja API nie umożliwia tworzenia nowych systemów mowy. Jego funkcjonalność ogranicza się do możliwości użycia gotowego silnika, który uprzednio musi być zainstalowany w systemie operacyjnym. API zestaw metod, które umożliwiają m. in.: generowanie rozbudowanych wypowiedzi z dowolnych tekstów kolejkowanie tekstów, z których generowane są wypowiedzi i efektywne zarządzanie nimi modyfikowanie wypowiedzi poprzez dodawanie pauz, przerywników dźwiękowych i podmienianie określonych fraz plikami dźwiękowymi modyfikowanie szybkości i wysokości tonu wypowiedzi eksportowanie wygenerowanych wypowiedzi do plików dźwiękowych pobieranie i modyfikowanie ustawień systemu TTS Z wykorzystaniem API wiążą się również ograniczenia, które wpływają negatywnie na efektywność wykorzystania systemów syntezy mowy: 61

63 konieczne jest zainicjalizowanie systemu mowy każdorazowo dla każdej aktywności aplikacji eksportowanie syntezowanej wypowiedzi jest nieefektywne z powodu wymuszonego formatu pliku dźwiękowego zapisane pliki zajmują dużo przestrzeni dyskowej wykorzystanie API wymaga od programisty dobrej znajomości elementów biblioteki programistycznej odnoszących się do inicjalizacji systemu TTS Pomimo ograniczeń, mobilne systemy mowy stały się popularne zarówno wśród twórców oprogramowania na platformę Android, jak i wśród użytkowników. Dowodem na to jest istnienie dużej ilości aplikacji, które wykorzystują API TextToSpeech. Ich przekrój funkcjonalności jest szeroki od programów czytających treści wiadomości SMS, poprzez aplikacje dla sportowców, na nawigacjach satelitarnych kończąc. Od momentu wydania systemu Android 4.0 twórcy tej platformy regularnie rozszerzają możliwości API TTS. W nowych wersjach pojawiły się m. in. klasy i metody umożliwiające tworzenie nowych implementacji systemów TextToSpeech i rozszerzające możliwości wykorzystania istniejących mechanizmów. Metody te nie stały się jeszcze popularne z powodu krótkiego czasu istnienia i dlatego, że przeznaczone są na nowe wersje systemu Android. Jednak zaangażowanie twórców w rozwój bibliotek programistycznych pozwala z optymizmem patrzeć na rozwój mobilnych systemów syntezy mowy. 62

64 DODATEK A Dokumentacja projektu A.1. Tytuł projektu Aplikacja mobilna wykorzystująca system syntezy mowy z tekstu. A.2. Założenia projektu A.2.1. Wizja projektu Istotą projektu jest stworzenie aplikacji na platformę Android w wersji min 2.2, która będzie wykorzystywała możliwie jak najwięcej metod SDK (Software Development Kit) platformy Android umożliwiających skorzystanie z systemu syntezy mowy z tekstu. Aplikacja działać będzie w oparciu dowolny zainstalowany system syntezy mowy na urządzeniu z systemem Android. Podstawowym językiem wykorzystywanym przez aplikację będzie język polski. Aplikacja końcowa powinna pokazywać przekrój zastosowania narzędzi do syntezy mowy z tekstu udostępnianych przez system Android wskazywać możliwe kierunki i możliwości wykorzystania mobilnych mechanizmów TTS (Text-To-Speech). A.2.2. Uzasadnienie istnienia projektu Projekt łączy się z dwoma szybko rozwijającymi się dziedzinami informatyki dziedziną aplikacji mobilnych oraz dziedziną syntezy mowy z tekstu. Mimo dużego rozwoju obu dziedzin wciąż mało popularne jest ich połączenie. Na rynku nie istnieje zbyt wiele aplikacji mobilnych, które wykorzystują w pełni możliwości dostarczane przez mobilne systemy syntezy mowy. Utworzenie aplikacji korzystającej z TTS ma ukazać, jakie możliwości drzemią w mobilnych systemach syntezy mowy. A.2.3. Główne cele projektu Głównym celem projektu jest stworzenie aplikacji, która będzie umożliwiała użytkownikowi: 1. Testowanie podstawowych funkcjonalności syntezatora mowy języka polskiego 2. Testowanie funkcjonalności syntezatora w połączeniu z dodatkowymi funkcjami systemu (np. poprzez pobranie z Internetu treści i przeczytanie jej). 3. Zmienianie ustawień syntezatora mowy 63

65 Aplikacja powinna również sprawdzać czy system dostarcza wszystkie niezbędne rozwiązania, które umożliwią skorzystanie z syntezatora mowy, tj. czy w systemie zainstalowany jest system syntezy mowy z tekstu oraz, czy zainstalowany jest przynajmniej jeden plik głosów odpowiedni dla zainstalowanego syntezatora. A.2.4. Kluczowe rezultaty dla projektu Aplikacja w wersji finalnej powinna implementować wszystkie możliwe funkcjonalności syntezatora mowy, które udostępnia API systemu Android. Dotyczy to zarówno funkcji czytania tekstu przez syntezator, jak i funkcji do ustawiania parametrów czytanego tekstu. A.2.5. Członkowie zespołu i interesariusze Zespół: Tomasz Konieczny Główni zainteresowani: programiści Java tworzący aplikacje na platformę Android A.2.6. Wymagane zasoby projektu Zasoby projektu dzielą się na dwie kategorie: 1. Zasoby do tworzenia aplikacji: (a) Komputer o parametrach umożliwiających tworzenia aplikacji mobilnych, jego wymagania minimalne to: i. Procesor dwurdzeniowy, 2.0 GHz ii. 4GB pamięci RAM iii. Płyta główna z portami USB 2.0 (b) Oprogramowanie dostosowane do tworzenia aplikacji mobilnych (c) Biblioteki do tworzenia aplikacji na platformę Android 2. Zasoby służące testowaniu aplikacji: (a) Urządzenie mobilne z systemem operacyjnym Android i dostępem do Internetu (b) Zainstalowany system syntezy mowy (c) Zainstalowany co najmniej jestem plik głosów, odpowiedni dla zainstalowanego syntezatora mowy. A.2.7. Wymagania funkcjonalne i opis zakresu projektu Zakres i wymagania projektu dzielą się na cztery podstawowe części, w których przestawiane są inne funkcjonalności. Podzielone są one na kolejne ekrany tak, aby każdy przedstawiał inny zbiór funkcjonalności systemu (poza menu aplikacji, które pełnić będzie funkcję nawigacyjną). 64

66 Pierwsze okno aplikacji (menu) Wymaganie Opis Dane wejściowe Oczekiwane działanie Aktywator Efekt Walidacja zasobów systemu pod kątem systemu syntezy mowy Aplikacja po włączeniu musi sprawdzić czy na urządzeniu zainstalowany jest odpowiedni system syntezy mowy oraz pliki głosów odpowiednie dla danego syntezatora. Brak W razie spełnienia wszystkich warunków co do systemu syntezy mowy, okno nie powinno zwracać żadnych danych. W razie błędnej walidacji aplikacja powinna wyświetlić okno dialogowe informujące o tym jakie warunki nie zostały spełnione i co należy zrobić, aby móc w pełni korzystać z programu. Włączenie aplikacji z odpowiedniego menu systemowego Wyświetlone menu aplikacji lub okno dialogowe z ostrzeżeniami Okno podstawowych zastosowań TTS Wymaganie Opis Dane wejściowe Aktywator Efekt Użycie syntezatora mowy do przeczytania z góry zdefiniowanego tekstu Funkcjonalność pozwala na szybkie sprawdzenie działania syntezatora mowy wymaga ona od użytkownika minimum aktywności, nie wymaga wprowadzania danych a jedynie sprawdza poprawność działania systemu TTS. Brak Kliknięcie w odpowiedni przycisk Wypowiedzenie tekstu przez syntezator Wymaganie Opis Dane wejściowe Aktywator Efekt Użycie syntezatora mowy do wymowy godziny Użytkownik może skorzystać z okna dialogowego, które w prosty sposób umożliwi wybór godziny. Po wybraniu odpowiednich danych syntezator mowy powinien je przeczytać. Tekst w postaci godziny i minuty Kliknięcie w odpowiedni przycisk i wybranie przez użytkownika godziny i minuty z przybornika Wypowiedzenie tekstu przez syntezator 65

67 Wymaganie Opis Dane wejściowe Aktywator Efekt Użycie syntezatora mowy do wymowy daty Użytkownik może skorzystać z okna dialogowego, które w prosty sposób umożliwi wybór daty z kalendarza. Po wybraniu odpowiednich danych syntezator mowy powinien je przeczytać. Tekst w postaci dnia, miesiąca i roku Kliknięcie w odpowiedni przycisk i wybranie przez użytkownika daty z kalendarza Wypowiedzenie tekstu przez syntezator Wymaganie Opis Dane wejściowe Aktywator Efekt Użycie syntezatora mowy do wymowy wprowadzonego tekstu Użytkownik wprowadza do pola tekstowego dowolny tekst i zatwierdza go odpowiednim przyciskiem. Tekst w dowolnej postaci, o długości do 255 znaków Wprowadzenie tekstu przez użytkownika i zatwierdzenie go Wypowiedzenie tekstu przez syntezator Wymaganie Opis Dane wejściowe Aktywator Efekt Użycie syntezatora mowy do wymowy wszystkich tekstów zatwierdzonych wcześniej przez użytkownika Użytkownik wprowadza dane do wszystkich pól na danym ekranie, syntezator przetwarza teksty i wypowiada je. Teksty w różnych formach Wprowadzenie tekstów przez użytkownika i zatwierdzenie go Wypowiedzenie tekstu przez syntezator 66

68 Okno przykładowych zastosowań TTS Wymaganie Opis Dane wejściowe Aktywator Efekt Użycie syntezatora mowy do przeczytania treści znalezionej w Internecie Użytkownik może skorzystać z ekranu aplikacji jak z wyszukiwarki internetowej. Wynikiem wyszukiwania jest wypowiedzenie treści znalezionej w Internecie przez syntezator mowy Tekst Użytkownik wprowadza frazę do pola tekstowego i zatwierdza ją odpowiednim przyciskiem Wypowiedziany przez syntezator mowy tekst znaleziony w Internecie. Ewentualne okno dialogowe informujące o błędach w połączeniu z Internetem. Wymaganie Opis Dane wejściowe Aktywator Efekt Zapisane syntezowanej nowy do postaci pliku dźwiękowego Po wyszukaniu treści, użytkownik może zapisać syntezowany tekst do postaci pliku dźwiękowego. Test (wyszukana wcześniej fraza) Użytkownik naciska przycisk Plik zapisuje się na nośniku urządzenia mobilnego. Zapisany element pojawia się na liście zapisanych elementów. Okno ustawień TTS Wymaganie Opis Dane wejściowe Dane wyjściowe Aktywator Stan końcowy Ustawienie szybkości wypowiadanego tekstu i wysokości tonu głosu syntezatora mowy Użytkownik wprowadza dane na temat szybkości wypowiedzi i wysokości tonu syntezatora mowy za pomocą odpowiednich kontrolek interfejsu użytkownika. Dane w formacie odpowiadającym formatowi parametrów dla syntezatora mowy Ustawienia tzw. shared preferences, czyli dane wprowadzone przez użytkownika, które są zapisywane do ustawień aplikacji Użytkownik zmienia wartości ustawień za pomocą interfejsu użytkownika Ustawienia są zapisywane przez aplikację i odtwarzane przy każdym jej uruchomieniu 67

69 Wymaganie Opis Dane wejściowe Dane wyjściowe Sprawdzenie danych na temat syntezatora mowy Użytkownik sprawdza w polu tekstowym dane na temat tego jakie są zainstalowane języki dla danego syntezatora mowy. Brak Tekst 68

70 A.2.8. Zagrożenia dla powodzenia projektu oraz sposoby ich zminimalizowania Zagrożenie dla Sposób zminima- Ryzyko wystąpie- Wpływ na powo- powodzenia pro- lizowania nia dzenie projektu jektu Niewystarczająca Optymalizacja kodu wysokie wysoki szybkość działania aplikacji programu, możliwość zawieszania wypowiedzi Nieukończenie pro- Dobry plan projektu średnie wysoki jektu w terminie i kontrola nad jego realizacją Trudność w wyko- Wykorzystanie średnie wysoki rzystaniu wszystkich specyfikacji, doku- funkcjonalności TTS mentacji i artykułów na systemie Android dotyczących budowy w wersji 2.2 systemu Android Słabe efekty działa- Wykorzystanie kilku średnie średnie nia syntezatora mo- istniejących syn- wy tezatorów mowy i wybranie najefektywniejszego w działaniu Problemy z odna- Przegląd aktualnych średnie średnie lezieniem odpowied- rozwiązań na ryku nich systemów mo- mobilnych systemów wy syntezujących ję- syntezy mowy zyk polski Problemy z konfi- Szczegółowa analiza średnie wysoki guracją syntezatora bibliotek systemu mowy na potrzeby Android pod kątem aplikacji działania TTS 69

71 Problemy z zasto- Wykorzystanie lite- niskie wysoki sowaniem bibliotek ratury, zrozumienie systemu Android działania syntezy mowy na systemie Android A.2.9. Plan prac wykonywanych na osi czasu A.3. Wykonanie A.3.1. Przegląd 1: Wszystkie elementy projektu wykonane zostały zgodnie z planem, bez nieprzewidzianych problemów i komplikacji. A.3.2. Przegląd 2: Pierwsze dwa ekrany zostały zaimplementowane i działają zgodnie z założeniami, brak komplikacji i opóźnień. A.3.3. Przegląd 3: Aplikacja została ukończona zgodnie z planem i zawiera wszystkie zaplanowane na początku funkcjonalności. Aplikacja działa stabilnie i pokazuje przekrój działania systemów syntezy mowy na platformie Android. A.4. Zamykanie A.4.1. Satysfakcja użytkowników i promotora Aplikacja została ukończona na czas. Wszystkie funkcjonalności zostały zaimplementowane zgodnie z założeniami i w odpowiednim czasie. Aplikacja w sposób praktyczny pokazuje zastosowania systemów syntezy mowy w związku z czym użytkownicy, jak i promotor mogą być usatysfakcjonowani z wyników pracy. 70