Na tomto míst bude ociální zadání va²í práce

Na tomto míst¥ bude ociální zadání va²í práce • Toto zadání je podepsané d¥kanem a vedoucím katedry, • musíte si ho vyzvednout na studiijním odd¥lení Katedry po£íta£· na Karlov¥ nám¥stí, • v jedné odevzdané práci bude originál tohoto zadání (originál z·stává po obhajob¥ na kated°e), • ve druhé bude na stejném míst¥ neov¥°ená kopie tohoto dokumentu (tato se vám vrátí po obhajob¥).

i

ii

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·

Diplomová práce

Dvoufázová navigace pro zrakov¥ postiºené Bc. Jan Pe²ka

Vedoucí práce:

Bc. t¥pán Kop°iva, MSc.

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský

Obor: Výpo£etní technika

8. kv¥tna 2011

iv

v

Pod¥kování Na tomto míst¥ bych cht¥l pod¥kovat Bc. t¥pánu Kop°ivovi, MSc., za vedení této diplomové práce, cenné rady b¥hem vývoje a také za p°átelský p°ístup. Dále bych cht¥l pod¥kovat panu Ing. Zde¬ku Míkovci, Ph.D a p°edstavitel·m sdruºení SONS za poskytnuté informace a ochotu p°i konzultacích. V neposlední °ad¥ také d¥kuji svým p°átel·m a rodin¥ za jejich podporu p°i realizaci tohoto projektu.

vi

vii

Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

Ve Slaném dne 9. 5. 2011

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

viii

Abstract This diploma thesis deals with navigation of visually impaired people in outdoor using Google Android mobile phone. At the beginning of the thesis possibilities of Google Android Platform and its libraries are analyzed. The next part describes needs of visually impaired people and their possibilities of interaction with mobile phones. The main part of this thesis is focused on implementation of two-phase navigation. In the rst phase the sighted user creates a desctiption of the route and in the second phase the application navigates visually impaired person through this route. The implementation has been extensively tested in several real world scenarios.

Abstrakt Tato diplomová práce se zabývá problematikou navigace zrakov¥ postiºených osob v exteriéru pomocí mobilního telefonu s opera£ním systémem Google Android. V první £ásti této práce jsou analyzovany moºnosti platformy Google Android a jejích knihoven. Dále jsou popsány pot°eby zrakov¥ postiºených a moºnosti jejich interakce s mobilními technologiemi. Hlavní £ást této práce se pak zabývá implementací dvou-fázové navigace, kde p°i první fázi vidící uºivatel vytvo°í popis cesty a ve druhé fázi aplikace naviguje zrakov¥ postiºenou osobu po této cest¥. V záv¥ru práce je proveden test pouºití aplikace v reálném prost°edí.

ix

x

Obsah 1 Úvod

1

2 Existující °e²ení elektronických naviga£ních pom·cek

3

3 Google Android Platform - GAP

7

2.1 2.2 3.1 3.2 3.3

3.4

3.5

SONS - Naviga£ní centrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapten Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architektura Google Android Platform . . . . . . Aplikace pro GAP - obecn¥ . . . . . . . . . . . . Komponenty aplikací . . . . . . . . . . . . . . . . 3.3.1 Activities - aktivity . . . . . . . . . . . . . 3.3.2 Services - sluºby . . . . . . . . . . . . . . 3.3.3 Content providers - poskytovatelé obsahu 3.3.4 Broadcast receivers - p°ijíma£e broadcast· 3.3.5 Aktivování komponent . . . . . . . . . . . Knihovny GAP . . . . . . . . . . . . . . . . . . . 3.4.1 Voice recognition . . . . . . . . . . . . . . 3.4.2 Text to speech . . . . . . . . . . . . . . . 3.4.3 SQLite . . . . . . . . . . . . . . . . . . . . 3.4.4 Google Maps library . . . . . . . . . . . . 3.4.5 Search API . . . . . . . . . . . . . . . . . Externí Google Maps API . . . . . . . . . . . . . 3.5.1 Geocoding API . . . . . . . . . . . . . . . 3.5.2 Directions API . . . . . . . . . . . . . . . 3.5.3 Elevation API . . . . . . . . . . . . . . . .

4 Analýza 4.1

Specikace cílové skupiny . . . . . . . . . 4.1.1 Orientace v prostoru . . . . . . . . 4.1.2 Pom·cky pro nevidomé . . . . . . 4.1.2.1 Bílá h·l . . . . . . . . . . 4.1.2.2 Akustický maják . . . . . 4.1.2.3 Vodící pes . . . . . . . . . 4.1.3 Nevidomí a technika . . . . . . . . 4.1.3.1 PC pro zrakov¥ postiºené xi

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 4

7 7 8 9 9 9 9 9 10 10 11 11 12 12 13 14 16 17

19

19 19 20 20 20 21 21 21

xii

OBSAH

4.2

4.3

4.4

4.1.3.2 Mobilní telefony pro zrakov¥ postiºené Informace o trase . . . . . . . . . . . . . . . . . Positioning System - GPS . . . . . . . . . . . . Historie . . . . . . . . . . . . . . . . . . . . . . Struktura systému . . . . . . . . . . . . . . . . 4.2.2.1 Kosmický segment . . . . . . . . . . . 4.2.2.2 ídící segment . . . . . . . . . . . . . 4.2.2.3 Uºivatelský segment . . . . . . . . . . 4.2.3 P°esnost GPS . . . . . . . . . . . . . . . . . . . 4.2.4 Alternativy . . . . . . . . . . . . . . . . . . . . 4.2.4.1 Asistovaný GPS . . . . . . . . . . . . 4.2.4.2 Diferenciální GPS . . . . . . . . . . . Interakce s uºivatelem . . . . . . . . . . . . . . . . . . 4.3.1 Výstup . . . . . . . . . . . . . . . . . . . . . . 4.3.1.1 Accessibility . . . . . . . . . . . . . . 4.3.2 Vstup . . . . . . . . . . . . . . . . . . . . . . . 4.3.2.1 Hlasový vstup . . . . . . . . . . . . . 4.3.2.2 Gesta . . . . . . . . . . . . . . . . . . 4.3.2.3 Vyuºití accessibility . . . . . . . . . . Rozpoznávání °e£i . . . . . . . . . . . . . . . . . . . . 4.1.4 Global 4.2.1 4.2.2

5 Návrh 5.1

5.2

5.3

Správa cest . . . . . . . 5.1.1 Zadávání bod· . 5.1.2 Zdroje informací 5.1.3 Cvi£ný pr·chod . Naviga£ní £ást aplikace . 5.2.1 Výb¥r cesty . . . 5.2.2 Navigace . . . . . 5.2.3 Opu²t¥ní trasy . Správa pr·chod· cest . .

6.1 6.2

6.3

6.4

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

Struktura aplikací GAP . . . . . . Ukládání dat . . . . . . . . . . . . 6.2.1 Struktura dat cesty . . . . . 6.2.2 Struktura dat pr·chod· . . 6.2.3 Uloºení do SQLite databáze Správa cest . . . . . . . . . . . . . 6.3.1 Vytvá°ení cesty . . . . . . . 6.3.2 Detekce kopc· . . . . . . . Naviga£ní £ást aplikace . . . . . . . 6.4.1 Ovládání hlasem . . . . . . 6.4.2 Navigace . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

6 Implementace

. . . . . . . . .

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

22 22 23 24 24 24 25 25 25 26 26 26 27 27 28 28 29 29 30 31

33

33 35 35 36 36 36 37 38 39

41 41 43 43 44 44 45 46 48 49 49 50

xiii

OBSAH

7 Testování

53

8 Záv¥r

57

Literatura

59

A Seznam pouºitých zkratek

61

B Instala£ní a uºivatelská p°íru£ka

63

7.1 7.2 7.3

Cesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Pr·b¥h testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Vyhodnocení testu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

B.1 Instala£ní p°íru£ka . . . . . . . B.2 Uºivatelská p°íru£ka . . . . . . B.2.1 Vytvá°ení cesty . . . . . B.2.2 Nastavení klí£ových slov B.2.3 Navigace . . . . . . . . . B.2.4 Uloºené pr·chody cest .

C Obsah p°iloºeného CD

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

63 63 63 64 64 65

67

xiv

OBSAH

Seznam obrázk· 2.1 2.2

Street view - Karlovo nám¥stí, Praha . . . . . . . . . . . . . . . . . . . . . . . Za°ízení Kapten Plus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3 3.4

Architektura Google Android Platform . . . . . . . . Struktura Google Android aplikace . . . . . . . . . . MapView se zobrazenou cestou a vyzna£enými body Vyhledávací dialog s na²eptáváním . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 8 . 10 . 12 . 14

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Vlevo Nokia 3390, vpravo Google Nexus One Ukázka ob¥ºných drah GPS satelit· . . . . . Ukázka GPS p°ijíma£e . . . . . . . . . . . . . Princip asistovaného GPS . . . . . . . . . . . Princip diferenciálního GPS . . . . . . . . . . Mobilní telefon s Qwerty klávesnicí . . . . . . Seznam gest a jejich pouºití . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

22 24 25 27 27 28 30

5.1 5.2 5.3 5.4 5.5 5.6

Diagram p°ípadu uºití pro správu cest . . . . . . Sekven£ní diagram vytvo°ení cesty . . . . . . . . Sekven£ní diagram uloºení cesty . . . . . . . . . . Diagram p°ípadu uºití pro navigaci . . . . . . . . Kone£ný automat vybírání cesty . . . . . . . . . Diagram p°ípadu uºití pro správu pr·chod· cest

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

33 34 34 36 37 39

6.1 6.2 6.3 6.4 6.5

Struktura Google Android aplikace Diagram t°íd . . . . . . . . . . . . Diagram t°íd . . . . . . . . . . . . Ukázka výb¥ru poºadovaného bodu Ukázka vytvo°ené cesty . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

41 43 44 47 49

7.1 7.2

Testovaná cesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Pr·chod trasy uºivatelem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

. . . . . . . . . cesty . . .

. . . . .

. . . . .

. . . . .

. . . . . . .

. . . . .

. . . . .

4 5

B.1 Vlevo úvodní obrazovka vytvá°ení cesty. Vpravo obrazovka s vytvo°enou cestou 64 B.2 Obrazovka nastavení klí£ových slov . . . . . . . . . . . . . . . . . . . . . . . . 65 B.3 Obrazovka uloºených pr·chod· cesty . . . . . . . . . . . . . . . . . . . . . . . 66

xv

xvi

SEZNAM OBRÁZK

Seznam tabulek 4.1

Tabulka pro výsledky rozpoznávání klí£ového slova Opakovat . . . . . . . . . . 31

6.1

Tabulka klí£ových slov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

xvii

xviii

SEZNAM TABULEK

Kapitola 1

Úvod Samostatný pohyb je pro zrakov¥ postiºené osoby, stejn¥ jako mnoho dal²ích úkon·, velice obtíºný. Pomocí r·zných pom·cek jsou v²ak schopni rozeznat a obejít mnohé p°ekáºky. Ve chvíli, kdy se mají pohybovat v neznámém prost°edí, je tento úkon o mnoho komplikovan¥j²í. V takovém p°ípad¥ £asto vyuºívají pomoci asistent·, kte°í je po neznámém prost°edí provází. Poskytování této sluºby zrakov¥ postiºeným je ale nan£n¥ náro£né a po£ty asistent· jsou omezené. Zrakov¥ postiºení lidé si tak £asto nechají jen vypracovat itinerá°, ve kterém je popsán pr·chod dané trasy. Tyto itinerá°e se pak u£í nazpam¥´ a nebo si je nahrávají jako audio poznámky a p°ehrávají si je b¥hem pr·chodu trasy. Zde se nabízí otázka, zda jim tento postup nelze usnadnit pomocí výpo£etní techniky - v na²em p°ípad¥ pomocí mobilního telefonu. Hlavní motivací pro vznik této práce bylo tedy usnadnit zrakov¥ postiºeným osobám pohyb po neznámém venkovním prost°edí. Na podobné téma uº vzniklo na p·d¥ FEL VUT n¥kolik studentských prací a v¥t²ina z nich byla realizována na mobilních telefonech s klasickou hardwarovou klávesnicí. Narozdíl od nich jsme se rozhodli pouºít mobilní za°ízení s platformou Google Android. Tato platforma se vyskytuje p°eváºn¥ na mobilních telefonech s dotykovým displejem, coº je samo o sob¥ pro zrakov¥ postiºené velikou p°ekáºkou. V posledních letech se ale podíl dotykových telefon· na trhu stále zv¥t²uje a klasické telefony s hardwarovými tla£ítky, které jsou pro zrakov¥ postiºené o mnoho vhodn¥j²í, p°echázejí do ústraní. Proto lze p°edpokládat, ºe se u dotykových telefon·, Google Android platformu nevyjímaje, bude stále zvy²ovat pot°eba vytvá°et i aplikace uzp·sobené zrakov¥ postiºeným. Z tohoto d·vodu jsme se rozhodli práv¥ pro tuto platformu, která má na poli dotykových telefon· jedno z nejv¥t²ích zastoupení. Samotná aplikace je zaloºena na principu dvoufázové navigace. P°i první fázi vytvo°í vidící uºivatel danou cestu a vloºí do ní informace pot°ebné k navigaci a orientaci zrakov¥ postiºeného. Zde je samoz°ejm¥ £ást informací tvo°ena automaticky, ale mnohé informace, d·leºité pro zrakov¥ postiºené, jsou v sou£asné dob¥ automaticky nezjistitelné. Proto musí informace o typu p°echodu £i výskytu vodících pás· vkládat vidící uºivatel ru£n¥. Druhou fází je pak samotná navigace, kde jsou zrakov¥ postiºenému vhodn¥ interpretovány dané informace.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Existující °e²ení elektronických naviga£ních pom·cek V posledních letech se jak ve sv¥t¥, tak v R, objevilo mnoºství projekt·, které se pomocí výpo£etní techniky snaºí pomoci zrakov¥ postiºeným v jejich kaºdodenním ºivot¥. V této kapitole zmíníme, dva z nich, které jsou p°ímo zam¥°eny na podporu samostatného pohybu pomocí navigace.

2.1 SONS - Naviga£ní centrum Sjednocená organizace nevidomých a slabozrakých (SONS) je ob£anské sdruºení s p·sobností po celém území eské republiky. Vzniklo v roce 1996 slou£ením eské unie nevidomých a slabozrakých a Spole£nosti nevidomých a slabozrakých v R. Toto sdruºení poskytuje zrakov¥ postiºeným celou ²kálu sluºeb, ale pro nás to nejzajímav¥j²í je jejich Naviga£ní centrum. Hlavním cílem Naviga£ního centra je umoºnit zrakov¥ postiºeným samostatný pohyb bez asistenta po neznámém prost°edí. Krom¥ pr·vodce v neznámém prost°edí plní pro své uºivatele i funkci jízdního °ádu, telefonního seznamu, mapy, atd. Samotná navigace probíhá následovn¥: 1. Na vyºádání je uºivateli (zrakov¥ postiºenému) zhotoven itinerá° trasy, po které se má vydat. 2. Uºivatel se vydá po trase podle pokyn· z itinerá°e, s sebou má GPS lokátor. 3. V p°ípad¥, ºe dojde ke ztrát¥ orientace, zavolá uºivatel na bezplatnou linku Naviga£ního centra. Zde si operátor na£te údaje z GPS lokátoru a podle nich uºivateli poradí, jak postupovat dál. Sou£ástí samotného GPS lokátoru je i GSM modul, který umoº¬uje p°es GPRS pr·b¥ºn¥ posílat informace o poloze uºivatele do Naviga£ního centra. Operátor k vytvá°ení tras a k p°ípadné pomoci nej£ast¥ji vyuºívá Street view, poskytovaného v rámci Google Maps [7]. Tato sluºba jim poskytne dobrý p°ehled o situaci na jednotlivých segmentech trasy. Bohuºel jsou takto zmapovaná pouze velká m¥sta a navíc informace takto na£erpané nemusí být 3

4KAPITOLA 2.

EXISTUJÍCÍ EENÍ ELEKTRONICKÝCH NAVIGANÍCH POMCEK

aktuální. S p°ípadnými rozdíly si je ale v¥t²ina uºivatel· schopna poradit bez potíºí. Obrázek 2.1 ukazuje výstup sluºby Street view pro Karlovo nám¥stí v Praze.

Obrázek 2.1: Street view - Karlovo nám¥stí, Praha Podstatná £ást nan£ních prost°edk· na provoz Naviga£ního centra pochází z grantu poskytovaného Nadací Vodafone eská republika. Spole£nost Vodafone také umoº¬uje provoz bezplatné telefonické linky a poskytuje ve své síti GPRS bezplatné datové p°enosy pro provoz naviga£ních jednotek.

2.2 Kapten Plus Katpen Plus je za°ízení, které plní funkci hlasem ovládaného navigátoru. Ten je speciáln¥ uzp·soben pro vyuºití zrakov¥ postiºenými osobami. Tento GPS navigátor byl vyvinut spole£ností Kapsys, která je známá práv¥ svými výrobky v oblasti navigací. Toto za°ízení neobsahuje displej a ve²keré ovládání se provádí pomocí hardwarových tla£ítek, £i pomocí hlasových p°íkaz· (viz obrázek 2.2). Zdrojové mapy pouºívané pro samotnou navigaci jsou uzp·sobeny pro chodce a vytvo°ené cesty jsou tvo°eny jen úseky pro n¥ vhodné (chodníky, podchody, parky, p¥²í zóny). Tento navigátor také poskytuje n¥kolik nadstandardních funkcí:

free navigation mode

naviga£ní mód, p°i kterém je uºivateli poskytována hlasová informace o jeho okolí - jména ulic, významné body.

map discovery mode

tento mód umoºní uºivateli prozkoumat vloºené mapy a dozv¥d¥t se tak více o svém okolí.

MP3 p°ehráva£

hlasem ovládaný mp3 p°ehráva£ je pro zrakov¥ postiºené osoby uºite£ný ve chvíli, kdy si cht¥jí p°ehrát nahraný itinerá°, £i jiné uloºené informace.

5

2.2. KAPTEN PLUS

Obrázek 2.2: Za°ízení Kapten Plus

Nahrávání audio vstupu

umoº¬uje uºivateli nahrávat nap°íklad poznámky.

N¥které verze tohoto za°ízení dokonce umoº¬ují párování s mobilním telefonem p°es bluetooth, takºe m·ºe být pouºit pro p°ijímáni a zahajování hovor·. Bohuºel Kapten plus uzp·sobený pro pouºití na území R není dostupný.

6KAPITOLA 2.

EXISTUJÍCÍ EENÍ ELEKTRONICKÝCH NAVIGANÍCH POMCEK

Kapitola 3

Google Android Platform - GAP Google Android je opera£ní systém pro mobilní za°ízení a jak uº je z názvu patrné, za jeho vývojem stojí mimo jiné spole£nost Google. Krátce po své vydání se tato platforma stala velmi oblíbenou mezi uºivateli, ale hlavn¥ mezi vývojá°i. Dává jim totiº nebývalou volnost a moºnost jednoduchého vyuºití systémových aplikací a jejich sluºeb. Kaºdý, kdo by si cht¥l naprogramovat svou vlastní aplikaci má voln¥ k dispozici kvalitní Android SDK (Software-Development-Kit), které poskytuje uºite£né nástroje a knihovny. Navíc je tento systém vyvíjen pod Open Source licencí, coº umoº¬uje výrobc·m, distributor·m ale i °adovým vývojá°·m upravovat tento systém podle pot°eby. Tato kapitola se zabývá architekturou GAP, strukturou jejich aplikací a v neposlední °ad¥ n¥kolika knihovnami, které budou p°i samotném vývoji této diplomové práce uºite£né.

3.1 Architektura Google Android Platform Z obrázku 3.1 je patrné, ºe celý systém je zaloºen na Linux Kernel, který se stará o základní systémové funkce (správa pam¥ti a proces·, ovlada£e, atd.) a slouºí také jako abstraktní vrstva mezi softwarem a hardwarem. Na dal²í úrovni jsou C/C++ knihovny pouºívané r·znými komponentami systému Android. Nap°. surface manager má na starosti ve²keré vykreslování na display, OpenGL ES je knihovna slouºící k tvorb¥ graky a SQLite umoº¬uje ukládat data na disk (SD karta, interní úloºi²t¥). Tyto knihovny jsou vývojá°·m zp°ístupn¥né p°es Application framework. Android runtime je úrove¬ obsahující core libraries - klasické java knihovny jako kolekce atd. Dále pak obsahuje Dalvik Virtual Machine, jenº je obdobou Java Virtual Machine (dále jen JVM), ale ²et°í pam¥´ i nároky na výkon procesoru, coº je u mobilních za°ízení ºádoucí. P°edposlední úrove¬ je Aplication Framework, který práv¥ umoº¬uje vývojá°·m vytvá°et aplikace, které mohou p°ímo ovliv¬ovat chod samotného systému (p°idávat upozorn¥ní, nastavovat alarm, posílat sms, volat, atd.). Poslední vrstvou jsou pak samotné aplikace.

3.2 Aplikace pro GAP - obecn¥ Aplikace pro GAP jsou psané v programovacím jazyce Java. Android SDK zkompiluje zdrojové kódy a soubory(viz kapitola - doplnit) a vytvo°í jediný soubor se suxem .apk. Takto 7

8

KAPITOLA 3. GOOGLE ANDROID PLATFORM - GAP

Obrázek 3.1: Architektura Google Android Platform

vytvo°ený soubor obsahuje celou aplikaci a je pouºit pro její instalování na za°ízení. Jak uº bylo °e£eno v kapitole 3.1, Google Android je linuxový systém. Velice d·leºitý je také fakt, ºe se jedná o systém mnoho-uºivatelský (multi-user), kde kaºdá aplikace p°edstavuje konkrétního uºivatele. Je to realizováno tak, ºe systém kaºdé aplikaci p°id¥lí uºivatelské ID (je unikátní a aplikace ho nezná) a v²echny soubory mohou být pouºívány jen aplikacemi, které je vlastní. Tento mechanismus chrání soubory p°ed pouºitím z cizí aplikace. Na druhou stranu tento fakt omezuje moºnosti aplikace - £asto chce programátor p°istupovat ke sdíleným prost°edk·m systému. Proto m·ºe vývojá° své aplikaci ud¥lit mnoºství povolení(permissions), které jí k dané v¥ci ud¥lí p°ístup (nap°. £tení a zápis kontakt· v telefonu). P°i samotné instalaci se uºivateli vºdy zobrazí seznam povolení, která daná aplikace pot°ebuje a on sám se potom rozhodne, zda instalaci povolí. Tímto má kaºdý, kdo pouºívá za°ízení s Google Android, p°ehled o p·sobení nainstalovaných aplikací a m·ºe snadno odhalit moºné nebezpe£í.

3.3 Komponenty aplikací V kaºdé aplikaci pro GAP jsou komponenty základními stavebním kameny. Existují £ty°i druhy komponent a mezi sebou se li²í svým ú£elem a mají r·zný ºivotní cyklus.

3.3. KOMPONENTY APLIKACÍ

3.3.1

9

Activities - aktivity

Aktivita je jedna z nejzákladn¥j²ích £ástí v¥t²iny aplikací, protoºe kaºdá p°edstavuje jednu obrazovku uºivatelského rozhraní. Nap°íklad v aplikaci pro posílání email· bude jedna aktivita zobrazovat seznam doru£ených email· a dal²í bude slouºit k napsání nového. Takto vytvo°ené aktivity spolu mohou spolupracovat, ale jsou vzájemn¥ nezávislé. V situaci, kdy vývojá° programuje vlastní aplikaci pro správu kontakt· a chce p°idat funkci poslat kontakt emailem, sta£í zavolat aktivitu z aplikace pro správu email·, která se stará o psaní nového mailu a dát jí informace, které chce vývojá° odeslat (samoz°ejm¥ tato aktivita musí být na spolupráci uzp·sobena). Tímto zp·sobem tedy m·ºete vyuºívat £ásti jiných aplikací ve své vlastní. 3.3.2

Services - sluºby

Sluºba je typ komponenty, které b¥ºí na pozadí systému, vykonává systémové operace nebo spolupracuje s ostatními procesy. Ze své podstaty sluºby nemají uºivatelské rozhraní. P°íkladem sluºby je p°ehrávání hudby ve chvíli, kdy uºivatel pracuje s úpln¥ jinou aplikací. Ostatní komponenty (jako aktivity) mohou takovéto sluºby spou²t¥t a zastavovat, nebo vyuºívat to, co poskytují. 3.3.3

Content providers - poskytovatelé obsahu

Poskytovatelé obsahu slouºí ke správ¥ aplika£ních dat. Pomocí ní m·ºeme pracovat se systémem soubor·, SQLite databázemi a dal²ími úloºi²t¥mi, ke kterým máme p°ístup. Zaji²´ují také p°ístup k systémovým informacím, takºe nap°íklad umoºní programátorovi £íst a upravovat kontakty uloºené v telefonu. Samotná aplika£ní data mohou být uloºena jako sdílená (pro více aplikací) nebo privátní. 3.3.4

Broadcast receivers - p°ijíma£e broadcast·

Poslední z komponent má na starosti p°ijímání (zachycování) oznámení na úrovni systému. Takovýmto oznámením se myslí nap°. slabá baterie, p°íchozí sms, atd. Na základ¥ t¥chto oznámení provede p°ijíma£ poºadovanou akci - nap°íklad vytvo°í upozorn¥ní na nov¥ p°íchozí sms. Aplikace ale také mohou tyto broadcasty vytvá°et. Ve výsledku slouºí p°ijíma£e broadcast· jako vstupní brána pro ostatní komponenty a samy vykonávají minimum práce. 3.3.5

Aktivování komponent

T°i z vý²e zmín¥ných komponent - aktivity, sluºby a p°ijíma£e broadcast· - vyºadují spu²t¥ní (aktivování). K tomuto ú£elu jsou v GAP pouºívány asynchronní zprávy zvané Intent, ty za b¥hu programu navazují vztah mezi jednotlivými komponentami. Samotný Intent je vytvo°en pomocí Intent objektu. U aktivit a sluºeb Intent denuje jakou komponentu má oslovit (jakou akci má vyºádat) a £asto také URI dat, pot°ebných k vykonání dané akce. Samoz°ejm¥ v mnoha p°ípadech nechce programátor pouze, aby n¥jaká jiná komponenta provedla akci, ale chce obdrºet i výsledek této akce. K tomuto ú£elu

10


u aktivit slouºí metoda startActivityForResult(), které se p°edá jako parametr daný Intent a kód poºadavku. Po ukon£ení akce v cizí aktivit¥ obdrºí programátor výsledek v metod¥ onActivityResult(), která je spu²t¥na automaticky. Pomocí kódu poºadavku (který si musím uchovat) získám výsledek. P°edstavme si následující p°íklad: vývojá° vytvá°í aplikaci, ve které chce vyfotit fotku. Ví, ºe jiº v systému má komponentu, která mu toto umoºní a proto vytvo°í Intent s poºadovanou akcí - vyfotit snímek. URI data obsaºená v Intent mohou nap°. stanovovat poºadované rozli²ení fotky atd. Spustí se cizí aktivita, pomocí které ud¥lá snímek. V aplikaci pak daná aktivita, která vytvo°ila Intent obdrºí nap°. cestu, kde je fotka uloºena.

3.4 Knihovny GAP Android SDK poskytuje vývojá°·m velké mnoºství r·zných knihoven. V této kapitole si p°edstavíme n¥kolik knihoven a systémových funkcí, které se nám p°i samotném vývoji diplomové práce budou velice hodit. 3.4.1

Voice recognition

Ve verzi GAP 2.1 se je²t¥ roz²í°ilo vyuºití rozpoznávání °e£i (voice recognition). Uºivatel·m umoºnila nap°. diktovat obsah textových zpráv. Navíc byla tato moºnost zp°ístupn¥na i samotným vývojá°·m Android aplikací. Navíc nedochází k zat¥ºování samotného za°ízení. GAP totiº vyuºívá faktu, ºe datové tarify jiº dnes vyuºívá velké mnoºství lidí a proto telefon pouze zaznamená zvukový vstup uºivatele a následn¥ ho po²le p°ímo na servery Googlu, kde dochází k samotnému rozpoznání. Mobilní za°ízení pak obdrºí vý£et moºných výsledk· v podob¥ textu. Celý tento proces je zobrazen na obrázku 3.2.

Obrázek 3.2: Struktura Google Android aplikace

3.4. KNIHOVNY GAP

11

Velice dobrá zpráva pro obyvatele R p°i²la na podzim roku 2010, kdy na oslavu výro£í zaloºení £eské pobo£ky Google tato spole£nost spustila rozpoznávání °e£i s podporou £eského jazyka. Tato sluºba m·ºe být ve vlastních aplikacích vyuºita pomocí asynchronní zprávy Intent - viz kapitola 3.3.5. 3.4.2

Text to speech

V aplikacích postavených na platform¥ Google Android je od verze 1.6 integrovaná funkcionalita Text to Speech, tedy moºnost p°evést text na zvukový výstup (syntetizovanou °e£). Pouºití Text-to-speech API je velice jednoduché a vývojá°i m·ºou snadno do svých aplikací p°idat i audio výstupy (nap°. pro informování nevidomého o stavu aplikace, moºnostech, atd.). Krom¥ ociálního stroje pro p°evod textu na °e£ povoluje Google Android vyuºívat i jiné - vyvíjené t°etí stranou. Tím se seznam podporovaných jazyk· velice roz²í°il a díky rm¥ SVOX m·ºeme na Android Marketu stáhnout i £e²tinu. 3.4.3

SQLite

SQLite je softwarová knihovna implementující SQL databázový stroj, který je podle [12] nejroz²í°en¥j²ím na sv¥t¥. V porovnání s databázemi MySQL, MSSQL nebo ORACLE má velké mnoºství rozdíl·:

•

Self-Contained - sob¥sta£nost - mezi d·leºité vlastnosti této knihovny pat°í fakt, ºe je minimáln¥ závislá na externích knihovnách nebo opera£ním systému. To umoº¬uje jednak nasazení aplikace s SQLite na r·zná malá za°ízení a také zaru£í, ºe daná aplikace se chová na r·zných OS stejn¥.

•

Serverless

•

Zero-Conguration - bez kongurace - jak uº bylo °e£eno vý²e, SQLite nevyºaduje

- bez serveru - toto je z°ejm¥ nejzásadn¥j²í rozdíl oproti klasickým SQL databázovým stroj·m. Tato knihovna totiº nevyºaduje ºádný separátní proces, na kterém b¥ºí server, ale pomocí SQLite p°istupujeme p°ímo k databázovým soubor·m na disku. Nemusíme nic instalovat, kongurovat a kaºdý program, který má p°ístup na disk, m·ºe pouºívat SQLite. ºádnou konguraci databázového stroje.

•

Public domain - ve°ejn¥ dostupná - tento databázový stroj m·ºeme vyuºívat jak pro soukromé tak komer£ní ú£ely.

Díky t¥mto vlastnostem je SQLite výbornou volbou pro aplikace, které pot°ebují uchovat men²í aº st°edn¥ velké mnoºství dat a bylo by pro n¥ zbyte£n¥ sloºité, pouºívat n¥jaké serverové databázové stroje. Ukázkovým p°íkladem jsou Mozilla Firefox a Skype - hlavn¥ díky t¥mto program·m se SQLite dostalo mezi stovky milion· uºivatel·. Navíc díky své sob¥sta£nosti nalezla tato knihovna velké uplatn¥ní i v oblasti mobilních za°ízení (Symbian, iPhone, Android), MP3 p°ehráva£ích, set-top boxech, atd. Své uplatn¥ní ale nalezl i v oblastí webových stránek - podle [12] jich existovalo v roce 2006 p°es 100 milion·. Bliº²í informace o pouºití SQLite databází na Google Android platform¥ naleznete na [13].

12

3.4.4


Google Maps library

Tato knihovna (API) není sou£ástí základního Android SDK, ale je sou£ástí nadstavby Google APIs. Na rozdíl od mnoha jiných externích knihoven je opravdu velice jednoduchá na instalaci - funguje jako add-on pro Android SDK. Z názvu je patrné, ºe je tato knihovna zam¥°ená na Google mapy. Uº del²í dobu tato spole£nost umoº¬uje vyuºívat prvky Google Maps v libovolných webových stránkách. S vydáním této knihovny jde je²t¥ dál. Poskytuje vývojá°·m aktivitu zobrazující mapy p°ímo v na²í aplikaci a tím umoº¬uje tvorbu r·zných mash-ups - aplikací, r·zným zp·sobem upravujících (roz²i°ujících) funkcionalitu Google map. Daná aktivita musí d¥dit od MapActivity, a musí také obsahovat MapView - coº je komponenta, která zobrazuje samotné mapy. Aby komponenta m¥la p°ístupná tyto data, je pot°eba vytvo°it si vlastní Maps API klí£ - tím se zde zabývat nebudeme, pro bliº²í informace se podívejte na [10]. Vývojá° m·ºe na MapView p°idávat tzv. Overlay objects - objekty (v¥t²inou obrázky, ikonky), které p°ekrývají £ást mapy. Pouºívají se £asto na vyzna£ení cesty, nebo ozna£ení d·leºitých bod·. Takovou to aktivitu s pouºitím Overlay objekt· m·ºete vid¥t na obrázku 3.3. Podrobný návod pouºití MapView je na [6].

Obrázek 3.3: MapView se zobrazenou cestou a vyzna£enými body

3.4.5

Search API

Ve chvíli, kdy chce programátor p°idat n¥jaký druh vyhledávání do aplikace, uvítá skute£nost, ºe Android SDK pro tento ú£el nabízí uºivatelské rozhraní. A je to stejné rozhraní, se kterým

3.5. EXTERNÍ GOOGLE MAPS API

13

se m·ºete setkat ve v²ech systémových aplikacích. Díky tomu si uºivatelé nemusí v kaºdé aplikaci zvykat na jiné uºivatelské rozhraní a vývojá° pomocí n¥kolika °ádk·m kódu získá dob°e vypadající vyhledávání. Nyní blíºe k tomu, jak to funguje. V první °ad¥ je pot°eba v AndroidManifestu aplikace specikovat, ºe daná aktivita umoº¬uje vyhledávání a musíme p°idat následující kód.

<meta-data android:name="android.app.searchable" android:resource="@xml/searchable"/> ... Dále pak do sloºky res/xml vloºíme soubor searchable.xml, který blíºe specikuje vlastnosti vyhledávání a vypadá následovn¥:

<searchable xmlns:android="http://schemas.android.com/apk/res/android" android:label="@string/app_name" android:hint="@string/search_hint"> Nyní uº jen sta£í v samotné aktivit¥ odchytit, co chce uºivatel vyhledat a podle toho provést danou akci (doMySearch()). Do metody onCreate() vloºíme následující kód:

Intent intent = getIntent(); if (Intent.ACTION_SEARCH.equals(intent.getAction())) { String query = intent.getStringExtra(SearchManager.QUERY); doMySearch(query); } Kdyº to tedy shrneme, Android SDK nám umoºní v na²ich aplikacích vyuºít vyhledávací dialog, který dané aktivit¥ °ekne, co si uºivatel p°eje vyhledat a my uº s tím naloºíme podle pot°eby. Snadno také m·ºeme vyuºít dal²ích funkcí jako na²eptávání atd. Výsledný dialog m·ºete vid¥t na obrázku 3.4

3.5 Externí Google Maps API Kapitola 3.4.4 popisuje knihovnu, která nám umoº¬uje p°idávat do aplikací mapy (Google Maps), tato knihovna ale neposkytuje stejné moºnosti, jaké máme k dispozici na webových stránkách. Firma Google proto vytvo°ila n¥kolik webových sluºeb, pomocí kterých mohou vývojá°i své aplikace je²t¥ více obohatit. Navíc je toto °e²ení nezávislé na cílové aplikaci resp.

14


Obrázek 3.4: Vyhledávací dialog s na²eptáváním

programovacím jazyku, který je pouºit. Google Maps API totiº funguje tak, ºe jako odpov¥¤ na http request (poºadavek) v ur£itém tvaru, po²le xml soubor. A s takto získaným souborem, který obsahuje poºadované informace si kaºdá aplikace naloºí podle svého. V²echna API také umoº¬ují odpov¥¤ ve form¥ json (JavaScript Object Notation) objektu. Google takto poskytuje následující sluºby:

• Geocoding API • Directions API • Elevation API • Places API Podrobnou dokumentaci k t¥mto sluºbám m·ºete najít na [9]. První t°i sluºby na²ly uplatn¥ní i v této diplomové práci a proto si je blíºe specikujeme. 3.5.1

Geocoding API

Pomocí této sluºby m·ºeme adresu (jako nap°. Karlovo Nám¥stí, Praha) p°evést na sou°adnice GPS (zem¥pisná ²í°ka a vý²ka) a obrácen¥. HTTP request má v takovém p°ípad¥ tvar:

https://maps.googleapis.com/maps/api/geocode/output?parameters kde jako output (výstup) mohou být moºnosti:


15

• xml • json A parametry, které mohou uºivatelé tohoto API vyuºít jsou následující (mezi sebou odd¥leny znakem &):

•

address or latlng - povinné - podle toho, zda mám k dispozici adresu £i zem¥pisnou vý²ku a ²í°ku, vyberu jednu z t¥chto moºností.

•

region - nepovinné - kód daného regionu, ve kterém chceme vyhledávat.

•

language - nepovinné - specikuje jazyk, ve kterém bude výsledek zapsán

•

sensor - povinné - zadáme true nebo false podle toho, zda má za°ízení, ze kterého http

poºadavek posíláme, GPS senzor. Tento parametr z°ejm¥ slouºí pro interní pot°eby Geocoding API.

•

bounds - nepovinné - pro vyhledávání adresy jen v dané oblasti (specikované zem¥pisnou vý²kou a ²í°kou)

Výsledný HTTP request tedy vypadá nap°. takto:

http://.../geocode/xml?address=na+vysluni+212+slany&sensor=true&language=cs A výsledný xml soubor tohoto poºadavku je:

<status>OK street_address Na Výsluní 212, 274 01 Slaný-Kví£ek, eská republika ... 50.222341814.0757581 ... Zde se vºdy jako první potomek tagu GeocodeResponse objevuje status, podle kterého m·ºe kaºdý uºivatel tohoto API poznat, zda v²e prob¥hlo podle v po°ádku. Význam v²ech ostatních tag· je dob°e pochopitelný.

16


3.5.2

Directions API

Tato sluºba je pro tuto diplomovou práci velice d·leºitá. Pomocí ní totiº m·ºeme získat informace o tom, jak se dostat z jednoho místa do druhého. Parametry této sluºby jsou následující:

• • •

origin - povinné - adresa nebo zem¥pisná ²í°ka a vý²ka, ve které za£íná va²e cesta. destination - povinné - adresa nebo zem¥pisná ²í°ka a vý²ka, ve které kon£í va²e cesta. mode - nepovinné - velice d·leºitý parametr. Pomocí n¥ho zadáte, jak budete cestu

absolvovat. Na výb¥r máte ze t°í moºností: autem (defaultní), p¥²ky, na kole. Kde u posledních dvou je pot°eba po£ítat s faktem, ºe jsou tyto módy stále ve vývoji a m·ºe se tedy stát, ºe nap°íklad na n¥kterých úsecích p¥²í trasy budou chyb¥t chodníky.

•

waypoints - nepovinné - pomocí tohoto parametru m·ºete zadat libovolný po£et pr·chozích bod·

• • • •

region - nepovinné - kód daného regionu, ve kterém chceme vyhledávat. language - nepovinné - specikuje jazyk, ve kterém bude výsledek zapsán units - nepovinné - jednotka, ve které chce udat výsledné vzdálenosti sensor - povinné - zadáme true nebo false podle toho, zda má za°ízení, ze kterého tento poºadavek posíláme GPS senzor. Tento parametr z°ejm¥ slouºí pro interní pot°eby tohoto API.

Jako odpov¥d na poºadavek

http://maps.googleapis.com/maps/api/directions/xml?origin=50.226494,14.081391 &destination=50.226644,14.077808&mode=walking&sensor=false získáme xml soubor ve tvaru:

<step> WALKING <start_location>50.226450014.0814300 <end_location>50.225730014.0795400 <polyline> <points>izpqH}g}tAnCxJ BB 1252 min Je¤te na jihozápad na ... 1570,2 km Directions API strukturuje jednotlivé pokyny do tag· step, který obsahuje samotnou instrukci a dále také vzdálenost do dal²í instrukce p°ibliºný £as trvání. Samotné body tvo°ící tuto cestu jsou jsou zakódované v tagu overview polyline (který není v p°íkladu vý²e zmín¥n). Více informací o zp·sobu kódování resp. dekódování zem¥pisné ²í°ky a vý²ky, ale i o ostatních podrobnostech se m·ºete do£íst na [9].

17


3.5.3

Elevation API

Poslední sluºbou, kterou si v této kapitole p°estavíme je Elevation API. Pomocí ní m·ºete zjistit nadmo°skou vý²ku daných bod·. Pracuje ve dvou variantách - vrátí nadmo°ské vý²ky zadaných bod· a nebo vrátí nadmo°ské vý²ky bod·, které se nacházejí na dané cest¥. Parametry této sluºby se tedy li²í podle toho, kterou variantu si p°ejeme. V p°ípad¥ konkrétních bod·:

•

locations - vý£et jednotlivých bod·

a pro cestu:

•

path - cesta specikovaná n¥kolika body

•

examples - poºadovaný po£et hodnot nadmo°ské vý²ky na cest¥

Pro ob¥ varianty je pak op¥t povinný parametr

sensor. Výstupem pro poºadavek

http://maps.googleapis.com/maps/api/elevation/xml?path= 50.22247,14.07577|50.22191,14.07486&samples=2&sensor=true je obdobný xml soubor jako u p°edchozích API.

18


Kapitola 4

Analýza 4.1 Specikace cílové skupiny Podle Sv¥tové zdravotnické organizace (WHO - World Health Organization) se zraková postiºení d¥lí do n¥kolika skupin: 1. St°ední slabozrakost 2. Silná slabozrakost 3. T¥ºce slabý zrak 4. Praktická slepota 5. Úplná slepota Tyto skupiny jsou rozd¥leny podle zrakové ostrosti a zúºení zorného pole. Diplomová práce je zam¥°ená hlavn¥ na poslední t°i skupiny, protoºe aplikace bude obsahovat minimum vizuálních informací. Obecn¥ mají ale v²echny tyto skupiny problém s mobilitou a orientací v prostoru. Mobilitou se rozumí schopnost zrakov¥ postiºeného £lov¥ka pohybovat se v prostoru pomocí nau£ených technik pohybu a doprovodných informací. Pokud samostatný pohyb £lov¥k nezvládne, je pro n¥j velice t¥ºké se zapojit do pracovního procesu a do ºivota ve spole£nosti v·bec. 4.1.1

Orientace v prostoru

Z faktu, ºe £lov¥k p°ijímá pomocí zraku velkou v¥t²inu informací o svém okolí, plynou pro osoby se zrakovým postiºením váºné problémy s orientací v prostoru a s pohybem obecn¥. Hlavními orienta£ními smysly se tedy stávají sluch, hmat, £asto i £ich a p°ípadné zbytky zraku. Zrakov¥ postiºený £lov¥k si pomocí t¥chto smysl· vytvá°í své orienta£ní body podobn¥, jako ostatní. Ale aby tyto body mohl zp¥tn¥ rozeznat, musí se k nim daleko více p°iblíºit, aby se jich nap°. dotkl holí, sly²el zvuk nebo cítil v·ni. Osoby se zrakovým postiºením jsou tedy nuceny u£it se speciálním metodikám pohybu a orientace v prostoru. Osvojení si t¥chto schopností je velice d·leºité pro za£len¥ní £lov¥ka do spole£nosti, ale i po psychické stránce je povzbuzující, pokud jsou schopni ur£ité samostatnosti pohybu. 19

20

KAPITOLA 4. ANALÝZA

4.1.2

Pom·cky pro nevidomé

Pro usnadn¥ní orientace v prostoru a samostatného pohybu mají lidé se zrakovým postiºením k dispozici n¥kolik pom·cek. V této kapitole popí²eme n¥kolik základních a nejpouºívan¥j²ích.

4.1.2.1 Bílá h·l Nejb¥ºn¥j²í pom·ckou pro zrakov¥ postiºené je tzv. bílá h·l. Podle [5] jsou funkce této pom·cky následující:

• Signaliza£ní - bílá barva na holi upozor¬uje kolemjdoucí, °idi£e, atd. na osobu se zrakovým postiºením • Ochranná - pomocí hole m·ºe zrakov¥ postiºený osoba odhalit p°ípadné p°ekáºky a tím se chrání p°ed st°etem • Orienta£ní - h·l slouºí k vnímání r·zných hmatových podn¥t· a pomáhá tak p°i orientaci v prostoru a pohybu • Op¥rná - slouºí jako opora p°i pohybu - hlavn¥ v p°ípad¥ star²ích lidí a lidí s pohybovými obtíºemi Bílých holí existuje n¥kolik typ·, ale z technického hlediska není moºné, aby jeden typ poskytoval v²echny funkce (nap°. u op¥rných holí je velice obtíºné je pouºívat pro vnímání hmatových podn¥t·).

• Bílá h·l orienta£ní - pouºívá se pro usnadn¥ní prostorové orientace a samostatného pohybu. P°i jejím pouºití dochází k tém¥° neustálému kontaktu se zemí ve snaze rozpoznat moºné p°ekáºky a zjistit co nejvíce o okolí. Plní tedy funkce orienta£ní, signaliza£ní a ochrannou • Bílá h·l signaliza£ní - v¥t²inou slouºí jako doprovodná pom·cka p°i ch·zi s pr·vodcem nebo vodícím psem. Hlavní je tedy funkce signaliza£ní eventuáln¥ ochranná. • Bílá h·l op¥rná - svou konstrukcí pomáhá p°i samotném pohybu osob se zrakovým postiºením, plní tedy funkci op¥rnou a signaliza£ní

4.1.2.2 Akustický maják Dal²í d·leºitou pom·ckou, p°i orientaci zrakov¥ postiºených jsou akustické majá£ky. Jsou to za°ízení, která jsou umíst¥na na d·leºitých místech (typicky vstup do metra, eskalátory, nástupi²t¥, zastávky MHD, atd.) a poskytují zrakov¥ postiºeným osobám informace, p°ípadn¥ provedou poºadovanou akci. Zrakov¥ postiºení lidé mají k dispozici ovládací za°ízení se ²esti tla£ítky, kde kaºdé tla£ítko p°i stisknutí spustí jinou funkci akustického majá£ku. Takto je moºné zjistit, kde je vstup do metra (usnad¬uje orientaci v rozlehlých vestibulech vysílá akustický signál, p°ípadn¥ doprovodnou mluvenou informaci), ale také umoºní zrakov¥ postiºené osob¥ informovat °idi£e p°ijíºd¥jící soupravy o jeho p°ítomnosti. Zmín¥ný ovládací panel se také £asto integruje p°ímo do bílé hole. Bohuºel takovéto akustické majá£ky m·ºeme nalézt pouze ve velkých m¥stech.

4.1. SPECIFIKACE CÍLOVÉ SKUPINY

21

4.1.2.3 Vodící pes Vodící pes velkou m¥rou podporuje mobilitu a bezpe£nost p°i pohybu zrakov¥ postiºených lidí. Je schopen plnit hlasové p°íkazy a to jak ve známém i neznámém prost°edí. Tito speciáln¥ vycvi£ení psi jsou schopni ozna£it (najít) nejr·zn¥j²í objekty jako jsou p°ekáºky, p°echody pro chodce, tla£ítka semaforu, vstup/výstup z dopravního prost°edku, po²tovní schránku, atd. 4.1.3

Nevidomí a technika

V p°edcházející £ásti kapitoly byly zmín¥ny orienta£ní problémy nevidomých a zrakov¥ postiºených. V dne²ní dob¥ se ale objevuje dal²í zásadní omezení a to pouºívání informa£ních a komunika£ních technologií (IKT). Hlavní problémem je fakt, ºe drtivá v¥t²ina t¥chto za°ízení podává uºivateli p°eváºn¥ gracký výstup. Mezi nejpouºívan¥j²í za°ízení z této skupiny bezesporu pat°í PC a mobilní telefon a jsou sou£ástí kaºdodenního ºivota v¥t²iny lidí. Proto vzrostla i pot°eba uzp·sobit PC a mobilní telefony pro pouºití nevidomým £i zrakov¥ postiºeným £lov¥kem.

4.1.3.1 PC pro zrakov¥ postiºené Pod tímto pojmem se neskrývá nic sloºitého, základ tvo°í klasický osobní po£íta£ (£i notebook), který ov²em disponuje nestandardním softwarovým i hardwarovým vybavením:

• Hmatový displej - braillský °ádek - který reprezentuje text na obrazovce PC • Skener - pro snímání ti²t¥ného textu do digitální podoby • Software pro rozpoznávání textu snímaného skenerem • Hlasová reprezentace grackého výstupu • Softwarová lupa Vyuºití jednotlivých prvk· (pot°eba je pouºívat) se li²í podle váºnosti zrakového postiºení dané osoby (kapitola 4.1). Vnímat textovou informaci jsou schopni jen uºivatelé z kategorie lehké aº st°ední slabozrakosti a i ti k tomu pot°ebují softwarovou lupu. Ta poskytuje moºnost n¥kolikanásobn¥ zv¥t²it poºadovanou £ást grackého výstupu. Softwarová lupa ale nepom·ºe uºivatel·m ze skupin t¥ºké slabozrakosti aº úplné slepoty. Proto je pot°eba reprezentovat výstup jinak neº gracky a jak je zmín¥no vý²e, pouºívá se bu¤ hlasový nebo hmatový výstup realizovaný reproduktorem £i hmatovým displejem. To jsou ale jen koncová za°ízení, která daným zp·sobem interpretují informaci p°ijatou od tzv. ode£íta£e obrazovky. To je program, který poskytuje informace o aktuálním objektu (seznamu, poloºce v menu, textu) a jeho stavu. D·sledkem toho je £ist¥ lineární vnímání informace, protoºe nevidomý uºivatel má zp°ístupn¥n v danou chvíli práv¥ jeden objekt. P°ichází tak o moºnost, jakou mají lidé bez zrakové vady a to vnímat najednou více r·zných zdroj· informací. Zjednodu²en¥ °e£eno pracuje nevidomý uºivatel s lineárním seznamem objekt·, které jsou zp°ístupn¥ny hlasovým £i hmatovým výstupem.

22


Vyuºití skeneru je pro ob¥ tyto skupiny stejné. Slouºí k tomu, aby uºivatel mohl zjistit obsah ti²t¥ného textu. Naskenovaný dokument (obrázek) se pomocí rozpoznávacího programu p°evede na digitální text a ten je poté interpretován podle pot°eby.

4.1.3.2 Mobilní telefony pro zrakov¥ postiºené Vzhledem k tomu, ºe mobilní telefony (v£etn¥ smartphon·) disponují daleko men²ími displeji neº PC £i notebooky, je daleko obtíºn¥j²í i pro uºivatele s lehkou a st°ední slabozrakostí, vnímat gracký výstup. Navíc se jedná o p°enosné za°ízení, coº je omezující z hlediska p°ípadného hardwarového vybavení. Pro reprezentaci výstupu se tedy nej£ast¥ji pouºívá hlas a funguje velice podobn¥ jako u PC. Mobilní telefon tedy poskytuje uºivateli mluvenou informaci o aktuálním objektu. Co se týká zadávání vstupu uºivatelem, byly vhodn¥j²í star²í modely telefonu, které zpravidla obsahovaly malou hardwarovou klávesnici. To usnad¬ovalo zrakov¥ postiºeným ovládání telefonu a dal²í modikace zadávání vstupu nebyla nutná. Daleko v¥t²í problém p°edstavuje ovládání dnes velice roz²í°ených tzv. smartphon· - chytrých telefon·. Dotykový displej zde totiº zabírá velkou v¥t²inu za°ízení a p°ítomnost hardwarových kláves je omezen na minimum. Této problematice se podrobn¥ v¥nujeme v kapitole 4.3.

Obrázek 4.1: Vlevo Nokia 3390, vpravo Google Nexus One

4.1.4

Informace o trase

Kaºdý zrakov¥ postiºený £lov¥k je n¥kdy nucen absolvovat neznámou trasu. V takové chvíli je velice uºite£né mít k dispozici podrobný popis této trasy (itinerá°). Jak bylo °e£eno v kapitole 2, existují moºnosti, jak tyto itinerá°e získat. Tato kapitola se zam¥°uje na specikaci

4.2. GLOBAL POSITIONING SYSTEM - GPS

23

informací, které by v takovém popisu nem¥ly chyb¥t. Samoz°ejm¥ pot°eby kaºdého £lov¥ka jsou individuální a jsou závislé na typu postiºení a pouºitých pom·ckách. Základem kaºdého popisu dané trasy je základní sm¥rování. Tím je my²leno nap°. na k°iºovatce zahn¥te doprava na ulici Na Výsluní, zde je d·leºité si uv¥domit, ºe název kaºdé ulice je pro zrakov¥ postiºenou osobu velice d·leºitý. M·ºe se totiº v p°ípad¥ pot°eby ujistit, ºe jde správn¥ a nebo poºádat kolemjdoucí o radu ve chvíli, kdy se ztratil. Dále jsou pro osoby se zrakovým postiºením velice d·leºité údaje o vzdálenosti, protoºe jim pomáhají získat lep²í p°edstavu o samotné cest¥. P°i udávání vzdálenosti je snaha trochu nadsazovat konkrétní hodnoty, protoºe velké mnoºství lidí má pocit, ºe u²lo v¥t²í vzdálenost neº ve skute£nosti. Dal²í d·leºitou sou£ástí itinerá°· je popis samotného okolí. Na první pohled se to m·ºe zdát jako irelevantní informace, ale pro zrakov¥ postiºené lidi je d·leºité udrºet si p°edstavu v jakém prost°edí se pohybují. Zde je ale d·leºité brát v potaz fakt, ºe informace o okolí jsou pouze doprovodné a tomu i p°izp·sobit jejich mnoºství. Velice d·leºité jsou i informace o výskytu podp·rných mechanism· v pr·b¥hu trasy. Tím jsou my²leny akustické majáky, signální pásy na chodníku a p°echodech atd. Toto jsou totiº spolehlivé záchytné body a jsou p°ímo uzp·sobeny pro nevidomé. Z hlediska samotného pohybu zrakov¥ postiºené osoby je vºdy problematické p°echázení ulice (silnice). Proto je zde nutné uvést co nejvíce informací:

• Zda se na míst¥ p°echázení vyskytuje p°echod • Typ p°ípadného p°echodu - zda má signaliza£ní pás, semafor, akustickou signalizaci • Informace o samotné cest¥ - jak je frekventovaná, zda je jednosm¥rná £i obousm¥rná P°echázení mají zjednodu²ené zrakov¥ postiºení s vodícím psem. Ten na jejich pokyn najde p°echod a bezpe£n¥ oba p°evede na druhou stranu. Mezi dal²í uºite£né informace také pat°í:

• Informace o p°ípadných schodech v pr·b¥hu trasy • Specikace okraje chodníku v daných úsecích • Informace o terénu - stoupání/klesání • Informace o ne£ekaných p°ekáºkách v pr·b¥hu cesty Ukázky hotových itinerá°· jsou na [8].

4.2 Global Positioning System - GPS GPS je globální naviga£ní satelitní systém (GNSS Global Navigation Satellite System), který pouºívá alespo¬ 24 satelit·, umíst¥ných na ob¥ºné dráze Zem¥, které vysílají sm¥rem k povrchu mikrovlné signály. S jejich vyuºitím je moºné na Zemi získat informace o poloze, £asu, rychlosti a sm¥ru p°ípadného pohybu.

24


4.2.1

Historie

Projekt NAVSTAR GPS (dnes pouze GPS) vznikl v roce 1973 spojením systému pro ur£ování polohy Letectva Spojených stát· (USAF) a systémem pro p°esné ur£ování £asu Námo°nictva Spojených stát· (Timation). Mezi léty 1974-1979 se za£aly provád¥t testy na pozemních stanicích a také byl zkonstruován první experimentální p°ijíma£. D·leºitým milníkem projektu byl rok 1983, kdy tehdej²í prezident USA oznámil, ºe projekt GPS bude po svém dokon£ení k dispozici i pro civilní ú£ely. Z po£átku byla ale dostupnost selektivní - b¥hem války v Zálivu byla dokonce dostupnost pro civilní (neautorizované) ú£ely úpln¥ zru²ena. V roce 1994 byla na orbit umíst¥na kompletní sestava 24 druºic. Denitivní zru²ení selektivní dostupnosti pak p°i²lo v roce 2000. 4.2.2

Struktura systému

Celý systém GPS lze rozd¥lit na t°i segmenty:

• kosmický • °ídící • uºivatelský

4.2.2.1 Kosmický segment Kosmický segment byl p·vodn¥ projektován na 24 druºic, tento po£et byl ale postupem £asu navý²en aº na stávajících 32 a pro dal²í navý²ení jejich po£tu by byla pot°eba zm¥na vysílaného signálu. Samotné druºice obíhají kolem Zem¥ v 6 kruhových drahách s inklina£ním úhlem 55 stup¬·. Dráhy jsou vzájemn¥ posunuty o 60 stup¬· a na kaºdé se pohybují p·vodn¥ £ty°i satelity, dnes jiº 5-6 satelit· ve vzdálenosti 20200 km od povrchu Zem¥. Ob¥ºná doba jedné druºice je 11h 58m. Obrázek 4.2 zobrazuje ob¥ºné dráhy GPS satelit·.

Obrázek 4.2: Ukázka ob¥ºných drah GPS satelit·

4.2. GLOBAL POSITIONING SYSTEM - GPS

25

4.2.2.2 ídící segment O samotnou kontrolu satelit· se stará °ídící segment systému. Ten se skládá z:

ídící st°edisko

(Master Control Station) Hlavní °ídící centrum celého systému (v Coloredo Springs), podle informací z monitorovacích stanic vysílá °ídící zprávy pro jednotlivé satelity pomocí povelových stanic. Pro p°ípad zni£ení £i nefunk£nosti je k dispozici záloºní °ídící st°edisko v Merylandu.

povelové stanice

ty°i stanice slouºící pro p°edávání °ídících zpráv z °ídícího st°ediska satelit·m. Obsahem zpráv je predikce dráhy druºice, korekce atomových hodin, p°ibliºné pozice ostatních druºic a jejich stav.

monitorovací stanice

Osmnáct monitorovacích stanic stanic, které sledují GPS druºice a dané informace p°edávají °ídícímu st°edisku.

ídicí segment také komunikuje s uºivatelským segmentem. Zve°ej¬uje plánované odstávky druºic a jejich p°ípadné ukon£ení/zahájení provozu.

4.2.2.3 Uºivatelský segment Uºivatelé pomocí GPS p°ijíma£e p°ijímají signály z jednotlivých druºic. Pro p°íjem signálu z druºice je pot°eba p°ímého výhledu a komunikace probíhá pouze sm¥rem od druºice k p°ijíma£i (jedná se tedy o pasivní p°ijíma£). Na základ¥ dat, obdrºených od druºic (£asových zna£ek a jejich polohy) vypo£ítá p°ijíma£ svoji polohu, nadmo°skou vý²ku a £as. Velikost GPS p°ijíma£e se pohybuje v °ádech milimetr· (viz obrázek 4.3).

Obrázek 4.3: Ukázka GPS p°ijíma£e

4.2.3

P°esnost GPS

Armáda USA uvádí údaje pro civilní GPS - horizontální p°esnost 13 metr· a vertikální p°esnost 22 metr·. as s p°esností do 40 nanosekund. Výsledná p°esnost GPS je ale nejv¥t²í m¥rou ovlivn¥na dostupností výhledu na otev°enou oblohu (tedy mnoºství viditelných satelit·). Tento fakt negativn¥ ovliv¬uje pouºití GPS ve m¥stech. Zvlá²t¥ pak v p°ípad¥, ºe se GPS p°ijíma£ (anténa p°ijíma£e) nalézá v úzké uli£ce nebo u vysokých budov. Chyba p°esnosti ur£ení polohy pak nar·stá a její pouºití pro navigaci se komplikuje.

26


4.2.4

Alternativy

Do budoucna se jako nejvýznamn¥j²í alternativou pro GPS jeví globální naviga£ní satelitní systém Galileo. Je to projekt realizovaný státy Evropské Unie a m¥l by poskytovat vysoce p°esné ur£ování polohy (p°esn¥j²í neº GPS) na území Evropy. Galileo má být spu²t¥n aº v roce 2013. Existují ale i mechanismy, které se dají pouºít ke zp°esn¥ní ur£ování polohy pomocí GPS.

4.2.4.1 Asistovaný GPS Asistovaný GPS (A-GPS) je systém, který za ur£itých okolností m·ºe zlep²it spou²t¥cí výkon a zkrátit £as do prvního ur£ení polohy pomocí GPS. Vyuºívá se p°eváºn¥ u mobilních telefonu a krom¥ samotné GPS vyuºívá i zdroj· mobilní sít¥. Assisted GPS vyuºívá informace o p°ilehlých BTS z GSM sít¥. Z asisten£ního serveru potom m·ºe získat informace o t¥chto BTS, které mohou být pouºity následovn¥:

• Informace jsou vyuºity k rychlej²ímu zam¥°ení dostupných satelit· • Informace jsou vyuºity k vypo£ítání pozice na asisten£ním serveru (spolu s údaji z GPS p°ijíma£e) V prvním p°ípad¥ si situaci lze p°edstavit tak, ºe asisten£ní server má o kaºdé BTS informaci, na které satelity vidí - které jsou v této oblasti dostupné a tak se zrychlí celý proces startu GPS (zkrátí se £as do prvního ur£ení polohy). Také m·ºe mít asisten£ní server k dispozici ionosférické a jiné podmínky v oblasti dané BTS, pomocí kterých se m·ºe znateln¥ zp°esnit výpo£et polohy. V druhém p°ípad¥ se vyuºívá faktu, ºe asisten£ní server má dobrý signál ze satelit· a daleko v¥t²í výpo£etní sílu neº mobilní telefony. Vyhodnocení polohy tedy probíhá na stran¥ severu a pak je odeslána zp¥t do mobilního za°ízení. Tohoto mechanismu se vyuºívá u v¥t²iny stávajících mobilních telefonu s Google Android platformou. Obdobn¥ se také £asto vyuºívá informací o okolních Wi- sítích. Princip Asistovaného GPS je na obrázku 4.4.

4.2.4.2 Diferenciální GPS Diferenciální GPS je dal²í moºným vylep²ením pro GPS. Vyuºívá sít¥ pevn¥ daných, pozemních referen£ních stanic, které vysílají rozdíl mezi pozicí zm¥°enou satelity a jejich pevn¥ danou (správnou) pozicí. Tato informace je danou referen£ní stanicí typicky vysílána pomocí UHF rádiových vln. Za°ízení schopna p°ijímat toto vysílání mohou vyuºít p°ená²ené informace k zp°esn¥ní výpo£tu jejich polohy. Pr·m¥rná chyba takto získané polohy je necelý 1m na kaºdých 100km vzdálenosti od dané referen£ní v¥ºe. Princip Diferencionálního GPS je na obrázku 4.5.

4.3. INTERAKCE S UIVATELEM

27

Obrázek 4.4: Princip asistovaného GPS

Obrázek 4.5: Princip diferenciálního GPS

4.3 Interakce s uºivatelem U kaºdé aplikace pro nevidomé £i zrakov¥ postiºené je velice d·leºité, jakým zp·sobem je vy°e²ena interakce s uºivatelem. Tedy jakým zp·sobem uºivatel aplikaci ovládá (vstup uºivatele) a v jaké form¥ dostává výstup. 4.3.1

Výstup

V kapitole 4.1.3.2 bylo °e£eno, ºe v p°ípad¥ aplikací pro mobilní telefony je p°eváºná £ást výstupní informace reprezentovaná hlasem. Také se ale vyuºívá hmatového výstupu. V tomto p°ípad¥ se nejedná o hmatový displej, ale o vibrace telefonu. Samoz°ejm¥ se tato informace dá jen velice obtíºn¥ vyuºít pro interpretaci n¥jaké p°esné a detailní informace (jednou z moºností by bylo p°evád¥ní informace do Morseova kódu) a vyuºívá se tedy p°eváºn¥ pro upozorn¥ní na ur£ité události.

28


4.3.1.1 Accessibility U kaºdého mobilního telefonu s OS Google Android lze zapnout tzv. accessibility (dostupnost). Jedná se univerzální zp·sob jak aplikace pro GAP zp°ístupnit zrakov¥ postiºeným. Jedná se vlastn¥ o klasického ode£íta£e obrazovky, který jiº byl zmín¥n v kapitole 4.1.3. Ten je roz²í°en o doprovodné funkce jako je ozvu£ení/vibrace p°i akci uºivatele (kliknutí na displej, pouºití hardwarové klávesy). Vývojá°i také mohou vytvo°it vlastní sluºbu pro accessibility a tak upravit výsledný výstup pro uºivatele. 4.3.2

Vstup

Pro ovládání aplikace existuje více moºností. Zaºitým zp·sobem je pro zrakov¥ postiºené ovládání pomocí hardwarové klávesnice, pokud moºno s velkými a hmatem dob°e rozli²itelnými tla£ítky (viz obrázek 4.1). Zde se funk£ní tla£ítka pouºívají klasicky pro pohyb v aplikaci, numerická tla£ítka pak £asto slouºí k rychlé volb¥ dané akce. V poslední dob¥ ale dochází k velkému roz²i°ování telefon· s dotykovým displejem, které disponují jen opravdovým minimem hardwarových kláves a nebo mají tzv. Qwerty klávesnici - obdoba klasické po£íta£ové klávesnice. Ob¥ tyto moºnosti jsou v sou£asné dob¥ pro zrakov¥ postiºené velice obtíºn¥ vyuºitelné. Jak je patrné z obrázku 4.6, Qwerty klávesnice obsahuje velké mnoºství malých hardwarových kláves, které jsou tím pádem velice t¥ºko rozli²itelné. Hlavní problém je ale vºdy samotný dotykový displej, jehoº vyuºití je pro zrakov¥ postiºené velice problematické.

Obrázek 4.6: Mobilní telefon s Qwerty klávesnicí Na druhou stranu jsou dotykové displeje pouºívány p°eváºn¥ u tzv. chytrých telefon· (Smart phones), které £asto disponují GPS p°ijíma£em, p°ipojením k wi-, polohovým senzorem, atd. Tím se velkou m¥rou roz²i°ují moºnosti, jak m·ºe být telefon svému uºivateli uºite£ný a to platí i pro zrakov¥ postiºené. Proto je snaha jim i tyto telefony resp. jejich ovládání p°izp·sobit. Protoºe je tato diplomová práce ur£ena pro mobilní telefony s opera£ním systémem Google Android, zmíníme moºnosti poskytované práv¥ touto platformou.

4.3. INTERAKCE S UIVATELEM

29

4.3.2.1 Hlasový vstup My²lenka tohoto °e²ení je velice jednoduchá. Pomocí p°edem daných klí£ových slov uºivatel ovládá aplikaci a provádí dané akce. Tato metoda s sebou ale nese n¥kolik problém·:

Rozpoznávání °e£i

Základním problémem je samotné rozpoznání toho, co uºivatel °ekl. Na GAP k tomuto ú£elu m·ºe vývojá° vyuºít Voice recognition API (viz kapitola 3.4.1). I zde ale existuje chyba, kdy uºivatel °ekl n¥co jiného, neº je výsledkem rozpoznávání. Z toho vyplývá, ºe tento zp·sob ovládání není nikdy stoprocentní a uºivatel musí £asto opakovat sv·j p°íkaz, neº se do£ká poºadované akce. Navíc je pro samotné rozpoznávání °e£i pot°eba p°ipojení k internetu, coº m·ºe být kritické v oblastech se slabým signálem.

Volba klí£ových slov

Kaºdý £lov¥k má ur£itou slovní zásobu a klí£ová slova pouºitá pro ovládání aplikace se tak n¥kterým uºivatel·m mohou jevit jako nep°irozená a t¥ºko zapamatovatelná. Tento problém ovliv¬uje p°eváºn¥ po£áte£ní osvojení ovládání aplikace, pro uºivatele pracující s danou aplikací del²í dobu uº není nijak podstatný.

Po£et klí£ových slov

D·leºité je také vhodn¥ zvolit po£et klí£ových slov. V p°ípad¥, ºe se jedná o rozsáhlej²í aplikaci s mnoha spustitelnými akcemi, je nevhodné, aby m¥la kaºdá akce p°i°azené klí£ové slovo. Jejich po£et by byl p°íli² vysoký a uºivatel by si je jen t¥ºko pamatoval. Lep²í je proto dané akce uspo°ádat do nabídky (nap°íklad stromové struktury), kterou se bude uºivatel pohybovat a klí£ová slova p°i°adit jen t¥m nejpouºívan¥j²ím.

Vliv okolí

Tento problém se do velké míry odvíjí od toho, kde je daná aplikace pouºívána. V p°ípad¥ ru²n¥j²ího prost°edí jako jsou frekventované ulice, £i ve°ejné budovy je do samotného hlasového vstupu p°idán i hluk z okolí. P°i rozpoznávání hlasového vstupu se tedy musí myslet i na p°ípadné odstran¥ní t¥chto hluk·. To je v n¥kterých p°ípadech velice obtíºné a proto dochází k dal²ímu nár·stu p°ípadné chybovosti této metody.

Na druhou stranu je hlasový vstup pro uºivatele p°irozený a v p°ípad¥ vhodných podmínek umoºní rychlé zp°ístupn¥ní poºadované akce.

4.3.2.2 Gesta Dal²í moºností, jak umoºnit zrakov¥ postiºené osob¥ ovládat mobilní telefon s dotykovou obrazovkou je pomocí gest. Jsou jimi r·zné obrazce kreslené na dotykový displej. Na základ¥ p°edem denovaného gesta, které uºivatel nakreslí na displej se provedena daná akce (podobn¥ jako u klí£ových slov p°i hlasovém ovládání). K tomuto ú£elu Android SDK poskytuje n¥kolik t°íd, pomocí kterých lze jednodu²e vytvo°it knihovnu gest a pouºít jí v konkrétní aplikaci. Výsledné aktivity mohou vypadat jako na obrázku 4.7. Op¥t se ale objevuje n¥kolik problém· p°i vyuºití tohoto zp·sobu ovládání (obdobné jako u hlasového ovládání):

Rozpoznávání gest

Zde pro rozpoznávání m·ºe vývojá° pouºít Android SDK, které, jak uº bylo °e£eno, obsahuje n¥kolik t°íd pro správu a rozpoznávání gest. Na rozdíl od rozpoznávání °e£i není rozpoznávání gest tak sloºitý programátorský úkol a vývojá°

30


Obrázek 4.7: Seznam gest a jejich pouºití

je tedy schopen vyvinout vlastní znaky, které p°izp·sobí pot°ebám aplikace. V obou p°ípadech je ale reálné riziko chybného zadání/rozpoznání gesta. Nap°íklad kdyº gesta specikuje levák a výsledný uºivatel je pravák, je gesto £asto kresleno jinak, neº jeho p°edloha ve smyslu sm¥ru kreslení. Pokud jsou povolena gesta z více £ástí (jako nap°íklad plus na obrázku 4.7), m·ºe se li²it posloupnost kreslení t¥chto £ástí. Samoz°ejm¥ vývojá° m·ºe ve svém vlastním rozpoznávání tyto rozdíly ignorovat, ale tím omezí velikost moºné skupiny gest.

Volba gest

Pro sníºení chybovosti této metody je vhodné zvolit gesta, která se pokud moºno co nejmén¥ podobají jedno druhému.

Po£et gest

Zde se jedná o stejný problém jako u hlasového ovládání, tedy velký po£et gest ztíºí uºivateli jejich zapamatování a tím i ovládání celé aplikace.

Dotyková obrazovka

Celá tato metoda je zaloºená na vyuºití dotykové obrazovky. To je ale pro zrakov¥ postiºené velký problém i kdyby obrazovka slouºila jen pro zadávání gest a uºivatel by tedy nemohl omylem spustit n¥jakou akci, £i aktivovat jinou komponentu. Zrakov¥ postiºení uºivatelé mají z jakéhokoliv pouºití dotykové obrazovky obavy. I tak je ale tato metoda d·leºitá, protoºe podíl dotykových telefon· na trhu stále stoupá a ovládání pomocí gest se jeví jako rozumné vyuºití dotykového displeje pro zrakov¥ postiºené.

4.3.2.3 Vyuºití accessibility Jednou z moºností je i vytvo°it aplikaci pro vidící uºivatele a pro zrakov¥ postiºené pouze vyuºít moºností accessibility (viz 4.3.1.1). K ovládání aplikace by se pak vyuºívalo pouze hardwarových kláves, coº v n¥kterých p°ípadech znamená pouze trackball (jako Nexus One na obrázku 4.1, pro který bude aplikace vyvíjena). Toto °e²ení je velice jednoduché, ale velkou m¥rou zpomaluje ovládání samotné aplikace.

31

4.4. ROZPOZNÁVÁNÍ EI

Rozpoznaná slova po£et opakovat opakova£ popelková opelková opakování

10 10 8 6 5

Tabulka 4.1: Tabulka pro výsledky rozpoznávání klí£ového slova Opakovat Ovládání £ásti aplikace ur£ené pro zrakov¥ postiºené musí být velice jednoduché. Ve v¥t²in¥ p°ípad· mají totiº p°i pohybu na volném prostranství k dispozici jen jednu ruku. Druhá pouºívá bílou h·l nebo drºí vodícího psa. Kdyº k tomu p°ipo£teme aktuální nejistotu zrakov¥ nevidomých p°i pouºívání dotykových displej·, jeví se jako vhodn¥j²í hlasové ovládání. V n¥kterých £ástech aplikace je spolu s hlasovým ovládáním vyuºito i sluºeb accessibility.

4.4 Rozpoznávání °e£i U rozpoznávání °e£i pomocí Voice recognition (viz kapitola 3.4.1) £asto dochází k situaci, kdy se výsledek neshoduje se zadaným slovem, ale je mu velice podobný (nap°íklad zp¥t sp¥t ). Vzhledem k tomu, ºe slovník na²í aplikace obsahuje jen t°ináct klí£ových slov, m·ºeme si dovolit r·zné optimalizace. Z vý²e uvedeného p°íkladu se nabízí vyuºití Hammingovy vzdálenosti1 . Vºdy se pro výsledek rozpoznávání spo£ítá Hammingova vzdálenost vzhledem k daným klí£ovým slov·m a pokud bude pod stanovenou hranicí, vykonáme stejnou akci jako p°i p°esné shod¥. V tabulce 4.1 jsou výsledky rozpoznávání klí£ového slova Opakovat. Rozpoznávání bylo provedeno desetkrát a pokaºdé bylo zaznamenáno p¥t nejpravd¥podobn¥j²ích výsledk·. Ve sloupci po£et je udáno, kolikrát bylo dané slovo výsledkem rozpoznávání. Z výsledk· je patrné, ºe se rozpoznaná slova oproti klí£ovému li²í i v po£tu znak·. Bylo by tedy na míst¥, místo Hammingovy vzdálenosti pouºít Levenshteinovu vzdálenost2 . I tak jsou ale rozpoznaná slova £asto velice odli²ná (nap°íklad opakovat - popelková ) a hranice p°ípustné Levenshteinovy vzdálenosti by musela být vysoká. To by m¥lo za d·sledek velké omezení výsledného slovníku a zp·sobilo by to problémy p°i rozli²ování podobných klí£ových slov (nahrát - p°ehrát ). Z t¥chto d·vod· jsme se rozhodli pouºít více praktické °e²ení. Do aplikace p°idáme nastavení klí£ových slov. Pro kaºdé klí£ové slovo, které se v aplikaci pouºívá, provede uºivatel n¥kolik pokus· o jeho rozpoznání. Výsledky t¥chto pokus· jsou uloºeny a je vybráno p¥t nej£ast¥j²ích slov. P°i kaºdém rozpoznávání (mimo nastavení klí£ových slov) jsou potom výsledky porovnávané nejen se samotným klí£ovým slovem, ale s celou p¥ticí k n¥mu 1

Hammingova vzdálenost mezi °et¥zcem x a y (stejné velikosti) je rovna minimálnímu po£tu operací

zm¥nit, pot°ebným k p°evedení x na y 2

Levenshteinova vzdálenost mezi °et¥zcem x a y je rovna minimálnímu po£tu operací zm¥nit, smazat a

vloºit, pot°ebným k p°evedení x na y

32


p°i°azených slov. Díky tomuto mechanismu tak odstraníme nej£ast¥j²í chyby p°i rozeznávání. Bohuºel tento zp·sob ale neodstraní chyby zp·sobené hlukem z okolí.

Kapitola 5

Návrh 5.1 Správa cest Samotná aplikace musí umoº¬ovat vidícímu uºivateli vytvá°et trasu mezi dv¥ma pevn¥ danými body. K tomu je pot°eba vy°e²it n¥kolik problém·, které se p°i vytvá°ení trasy objevují. Cesta je tvo°ena kontrolními body, které obsahují informaci o své poloze a pokyny pro zrakov¥ postiºené uºivatele.

Obrázek 5.1: Diagram p°ípadu uºití pro správu cest Na obrázku 5.1 je zobrazen diagram p°ípad· uºití správy cest (v²echny UML diagramy jsou vytvo°eny v souladu s principy uvedenými v [1]). Jak je uvedeno v diagramu, vidící uºivatel m·ºe vytvá°et, upravovat a mazat cesty. Pro upravování a mazání je pot°eba vyhledat poºadovanou cestu a p°i tvorb¥ nové cesty musí uºivatel zadat výchozí body cesty (start a 33

34

KAPITOLA 5. NÁVRH

cíl). B¥hem upravování cesty m·ºe uºivatel p°idávat, upravovat £i mazat jednotlivé kontrolní body. Na obrázku 5.2 je zobrazen sekven£ní diagram, který charakterizuje p°ípad uºití vytvo°it cestu. Uºivatel nejd°ív pomocí mapy zadá výchozí body cesty a zvolí vytvo°it cestu.

AdminActivity p°edá vybrané body GoogleMapsDAO coº je t°ída, která se stará o komunikaci s webovými sluºbami Google Maps. Pomocí url poºadavku v daném tvaru získá informace pot°ebné k vytvo°ení cesty.

Obrázek 5.2: Sekven£ní diagram vytvo°ení cesty

Sekven£ní diagram na obrázku 5.3 ukazuje, jakým zp·sobem se provádí ukládání cesty. Uºivatel zvolí uloºit cestu. AdminActivity tento poºadavek p°edá t°íd¥ RouteDAO, které se provádí operace s SQLite databází.

Obrázek 5.3: Sekven£ní diagram uloºení cesty

5.1. SPRÁVA CEST

5.1.1

35

Zadávání bod·

D·leºitým faktorem, který ovlivní pouºitelnost této £ásti aplikace je zp·sob zadávání bod· (nap°íklad start a cíl trasy). Nabízí se n¥kolik moºností:

• Ur£ení bodu pomocí adresy • Ur£ení bodu podle aktuálních GPS sou°adnic • Ur£ení bodu pomocí mapy Zadávání bod· pomocí adresy je sice intuitivní, ale samotný proces získání sou°adnic zadané adresy je sloºit¥j²í a m·ºe se objevit problém s p°esností. Sou°adnice zadané adresy m·ºeme zjistit pomocí Geocoding API (viz 3.5.1), kde je nutné p°ipojení k internetu. V p°ípad¥, ºe bod nemá p°esn¥ danou adresu (neobydlená £ást ulice - nemá £íslo popisné), se m·ºe nep°esnost pohybovat aº v °ádech stovek metr·. Proto je tato metoda pro zadávání konkrétních bod· nevhodná. Ur£ování polohy pomocí GPS je ve v¥t²in¥ p°ípad· p°esné a spolehlivé, jak uº ale bylo °e£eno v kapitole 4.2.3, problémem je pouºití GPS ve velkých m¥stech (s omezeným výhledem na oblohu). I zde je tedy riziko nep°esného zadání bod·. Ve chvíli, kdy by aplikace vyuºívala GPS k ur£ování bod·, se objevuje problém pouºitelnosti. Uºivatel by totiº pokaºdé musel fyzicky projít trasu, kterou chce vytvo°it. Jako nejlep²í se proto jeví, zadání daných bod· pomocí mapy, která je sou£ástí aplikace. Uºivatel jednoduchým kliknutím na mapu ur£í polohu daného bodu. Ve chvíli, kdy pouºije maximálního moºného p°iblíºení mapy, dosáhne i velice dobré p°esnosti. Ale i zde se m·ºe objevit problém s rychlou orientací v map¥. Na základ¥ t¥chto fakt· jsme se rozhodli pouºít zadávání bod· pomocí mapy. K urychlení práce uºivatele, který tvo°í trasu, p°idáme moºnost vyhledání adresy v map¥. 5.1.2

Zdroje informací

Vytvo°ená trasa musí obsahovat informace, d·leºité pro orientaci a navigaci zrakov¥ postiºených (viz refrouteinfo). Následující informace aplikace získává automaticky:

• Základní sm¥rování • Vzdálenosti • Kopce Tyto informace aplikace získává prost°ednictvím Direction API a Elevation API (viz 3.5). K vytvá°ení trasy je tedy zapot°ebí p°ipojení k internetu. Z takto získaných informací je vytvo°ena základní struktura trasy, kterou m·ºe uºivatel dále upravovat. Velké mnoºství informací, které zrakov¥ postiºení pot°ebují, je v sou£asné dob¥ velice obtíºné aº nemoºné získat automaticky. Proto aplikace umoº¬uje uºivateli p°idávat nové informace do popisu trasy. Hlavní £ást informace je zadána textov¥, ale je moºné p°idat i hlasovou poznámku.

36

5.1.3

KAPITOLA 5. NÁVRH

Cvi£ný pr·chod

Pro otestování vytvo°ené cesty aplikace se nabízí moºnost cvi£ného pr·chodu, který simuluje navigaci zrakov¥ postiºeného uºivatele a zárove¬ poskytuje mapové podklady, na kterých zobrazuje danou trasu a aktuální pozici. Uºivateli, který tvo°il cestu, tak umoºní odhalit její nedostatky.

5.2 Naviga£ní £ást aplikace Naviga£ní £ást aplikace krom¥ navigace zrakov¥ postiºeného uºivatele umoºní i cvi£ný pr·chod vybrané cesty. Cvi£ný pr·chod simuluje vidícímu uºivateli navigaci pro zrakov¥ postiºené. K tomu jim poskytne mapové podklady s vybranou cestou a jeho aktuální pozici ur£enou GPS. Pomocí cvi£ného pr·chodu tedy m·ºe uºivatel, který tvo°il cestu, zjistit p°ípadné nedostatky popisu cesty. V p°ípad¥, ºe je tato aktivita pouºívána k reálné navigaci zrakov¥ postiºeného, nejsou zobrazeny ºádné gracké komponenty. Tím jsme cht¥li dosáhnout toho, aby zrakov¥ postiºení uºivatelé nem¥li p°i pouºívání navigace obavy, ºe omylem aktivují n¥jakou komponentu na displeji. Moºnosti, které aplikace poskytuje zrakov¥ postiºenému uºivateli p°i navigaci, jsou znázorn¥ny na diagramu p°ípadu uºití na obrázku 5.4. Jak jsme se rozhodli v kapitole 4.3, pro ovládání naviga£ní £ásti aplikace pouºijeme hlasové p°íkazy. Pro spu²t¥ní rozpoznávání klí£ového slova uºivatel stiskne "výb¥rové - potvrzovací"tla£ítko.

Obrázek 5.4: Diagram p°ípadu uºití pro navigaci

5.2.1

Výb¥r cesty

Pro samotný výb¥r cesty, kterou chce zrakov¥ postiºený uºivatel projít, jsme pouºili v aplikaci kone£ný automat (obrázek 5.5). Uºivatel má dv¥ moºnosti, jak se dostat k poºadované cest¥.

5.2. NAVIGANÍ ÁST APLIKACE

37

V p°ípad¥, ºe zná £íslo cesty, pouºije ve stavu 0 klí£ové slovo £íslo. Dále pak ve stavu 3 zadá konkrétní £íslo cesty. Dal²í moºností je vybrat cestu ze seznamu, do n¥hoº se uºivatel dostane ze stavu 0 pomocí klí£ového slova seznam. Ve stavu 1 poté pomocí p°íkaz· dal²í, p°edchozí a vybrat zvolí poºadovanou cestu. Ob¥ tyto moºnosti vedou do koncového stavu 2.

Obrázek 5.5: Kone£ný automat vybírání cesty

5.2.2

Navigace

Základní princip samotné navigace je jednoduchý. Kontrolní body dané cesty jsou se°azeny dle jejich po°adí na cest¥. P°i kaºdé zm¥n¥ pozice zji²t¥né GPS se provede kontrola, zda se uºivatel nachází u aktuálního kontrolního bodu. Pokud ano, jsou p°e£teny instrukce tohoto bodu a aktuálním se stává dal²í bod v po°adí. V opa£ném p°ípad¥ se £eká na dal²í zm¥nu pozice. Zde je t°eba brát v potaz moºnou chybu ur£ení polohy GPS a proto má kaºdý kontrolní bod zadaný rádius (defaultní je 20m), který ur£uje akceptovatelnou odchylku mezi polohou kontrolního bodu a uºivatele. Dále navigace obsahuje následující funkce:

• O²et°ení p°esko£ení kontrolního bodu • Ur£ení za£átku trasy M·ºe nastat situace, ºe uºivatel mine n¥který kontrolní bod. To m·ºe být zp·sobeno do£asnou odchylkou nam¥°ené GPS polohy, nebo chybným postupem uºivatele. Pokud tedy dojde k p°esko£ení (minutí) kontrolního bodu, aplikace tyto p°ípady detekuje a oznámí uºivateli pokyny minutého kontrolního bodu, které mohou být d·leºité pro jeho dal²í postup. Kaºdá cesta má pevn¥ daný po£áte£ní a koncový bod. Dá se ale p°edpokládat, ºe se uºivatel rozhodne projít danou trasu bez pomoci a aº ve chvíli, kdy si není jistý dal²ím postupem, vyuºije navigaci. Proto se po výb¥ru dané cesty vºdy ur£í aktuální kontrolní bod. Následující funkce nejsou automatické, ale jsou k dispozici na vyºádání uºivatele:

38

KAPITOLA 5. NÁVRH

• Libovolné procházení kontrolních bod· • Opakování pokyn· kontrolního bodu • Vzdálenost k aktuálnímu kontrolnímu bodu • Ur£ení polohy uºivatele (adresa) • Nahrání audio kontrolního bodu B¥hem navigace aplikace umoº¬uje uºivateli libovoln¥ procházet kontrolní body. Umoºní tak zrakov¥ postiºeným osobám prostudovat si p°edem trasu, kterou cht¥jí procházet, ale hlavn¥ umoºní vyuºívání aplikace (v omezeném reºimu) i p°i výpadcích a nep°esnostech GPS. V p°ípad¥ ru²n¥j²ího prost°edí £i sloºit¥j²ích instrukcí kontrolního bodu je d·leºité, aby aplikace umoºnila uºivateli zopakovat dané pokyny. Ur£ení vzdálenosti k dal²ímu kontrolnímu bodu a adresy uºivatele (podle jeho polohy) slouºí hlavn¥ jako kontrolní informace pro uºivatele, který si tak ov¥°í, zda jde po správné ulici a kolik mu je²t¥ zbývá k dosaºení dal²ího bodu. U t¥chto funkcí je d·leºité upozornit uºivatele, ºe údaje jsou p°ibliºné (v závislosti na p°esnosti GPS) a proto by je nem¥l pouºívat p°íli² £asto. U vzdálenosti by totiº mohlo dojít k situaci, kdy se uºivatel p°ibliºuje k danému kontrolnímu bodu, ale hodnota této funkce se zv¥t²í (GPS ²patn¥ ur£í polohu). V takovém p°ípad¥ dojde ke zmatení uºivatele, který si nebude jistý, zda jde správným sm¥rem. Tomu se dá do ur£ité míry p°edejít vhodným zaokrouhlováním vzdálenosti nap°íklad na desítky metr·. Nahrání audio kontrolního bodu má dv¥ vyuºití. Jednak m·ºe slouºit jako zp¥tná vazba pro uºivatele, který tvo°il cestu - zrakov¥ postiºený uºivatel zaznamená p°ípadné nedostatky, ozna£í problémová místa. Dále pak umoºní zrakov¥ postiºenému vkládat do trasy své vlastní poznámky a informace. 5.2.3

Opu²t¥ní trasy

Obecn¥ se b¥hem navigace £asto objevuje situace, kdy uºivatel nedokáºe postupovat podle pokyn· (²patn¥ odbo£í) a dochází k opu²t¥ní trasy. V p°ípad¥, ºe k tomu dojde existují dv¥ základní moºností, jak tuto situaci °e²it:

• P°epo£ítání trasy • Navedení zp¥t na trasu P°i p°epo£ítání se vytvo°í nová trasa, kde se jako výchozí bod pouºije stávající pozice. Kdybychom ale tento postup pouºili v na²í aplikaci, p°i²li bychom o informace zadávané uºivatelem a popis cesty by byl pro zrakov¥ postiºené nedostate£ný. Proto vyuºíváme druhé varianty - navedení zp¥t na trasu. Kdyº tedy b¥hem navigace dojde k opu²t¥ní stanovené trasy, je uºivatel vyzván, aby se vrátil po stejné cest¥. Ve chvíli kdy je uºivatel zp¥t na trase je znovu p°e£ten poslední kontrolní bod, který byl p°edtím z°ejm¥ ²patn¥ pochopen.

5.3. SPRÁVA PRCHOD CEST

39

5.3 Správa pr·chod· cest Správa pr·chod· cest slouºí hlavn¥ jako zp¥tná vazba pro uºivatele, kte°í tvo°ili cestu. Kaºdý pr·chod dané trasy zrakov¥ postiºeným je zaznamenán a vidící uºivatel pak m·ºe zkontrolovat správnost jeho postupu, p°ípadn¥ mu uleh£í identikovat místa, kde se²el z trasy atd. P°ípady uºití jsou zobrazeny na diagramu na obrázku 5.6.

Obrázek 5.6: Diagram p°ípadu uºití pro správu pr·chod· cest Tato £ást aplikace tedy umoºní uºivateli zobrazit poºadované pr·chody cest na map¥ (ozna£ené datem a £asem konání) a porovnávat je s denovanou cestou a mezi sebou. V p°ípad¥, ºe by m¥la být aplikace p°ístupná ²iroké ve°ejnosti, bylo by takovéto automatické zaznamenávání pozice p°i navigaci v rozporu s principy ochrany osobních údaj·. Aplikace by musela informovat uºivatele o této funkci a umoºnit její vypnutí £i omezení.

40

KAPITOLA 5. NÁVRH

Kapitola 6

Implementace Tato kapitola se podrobn¥ v¥nuje d·leºitým £ástem samotné implementace aplikace pro GAP. Vývojem aplikací pro GAP se podrobn¥ zabývá [3] a uºite£né materiály (návody, rady) m·ºete nalézt na [4]. B¥hem implementace byly pouºity návrhové vzory Library Class, MVC a DAO. Podrobný popis návrhových vzor· je v [2].

6.1 Struktura aplikací GAP V úvodu této kapitoly specikujeme základní strukturu aplikací pro Google Android (viz obrázek 6.1). Ve sloºce src (Source code) se nacházejí v²echny t°ídy implementované v programovacím jazyku Java a to jak komponenty aplikace, tak v²echny pomocné t°ídy. Tyto t°ídy mohou být dále d¥leny do balík· (packages).

Obrázek 6.1: Struktura Google Android aplikace Sloºka res (Resources) je d·leºitou sou£ástí kaºdé Android aplikace. Poskytuje totiº totiº vývojá°·m moºnost, jak snadno odd¥lit logiku (java kód) programu od v¥cí jako jsou texty, 41

42

KAPITOLA 6. IMPLEMENTACE

obrázky, specikace rozloºení, atd. A práv¥ ve sloºce res jsou v²echny tyto v¥ci, které by mohly vývojá°·m znep°ehlednit kód, uloºeny. Ve sloºce layout jsou umíst¥ny soubory s p°íponou .xml, které specikují rozloºení komponent a tedy výsledný vzhled jednotlivých obrazovek (aktivit). Takto vytvo°ené rozloºení pak vývojá° v Java kódu p°i°adí dané aktivit¥. Velice podobn¥ je tomu i u text· - je dobré mít v²echny texty pohromad¥, jednodu²e se pak m·ºe nap°. p°ejít na jiný jazyk nebo p°ípadné zm¥ny v daném textu se provedou na jen jednom míst¥. Texty jsou op¥t uloºeny v xml souboru ve sloºce values, kde kaºdému °et¥zci p°i°adí vývojá° unikátní id, podle kterého ho m·ºe v aplikaci pouºít. U obrázk· (drawable) mám k dispozici t°i sloºky, jejich obsah je pouºit podle toho, jakým displejem za°ízení disponuje. Tak snadno dosáhnu toho, aby se na kvalitn¥j²ím displeji zobrazil podrobn¥j²í (nebo klidn¥ i úpln¥ jiný) obrázek, neº na displeji mén¥ kvalitním. P°ípadné menu nabídky jednotlivých aktivit jsou specikovány ve sloºce menu. S obsahem sloºky res velice úzce souvisí sloºka gen (generated). Je v ní totiº vytvo°ena Java t°ída, která obsahuje prom¥nné se jmény podle id v²ech poloºek z res a jejich hodnotou je adresa v pam¥ti dané poloºky. Provázání mezi zdrojovými kódy v Jav¥ a poloºkami sloºky res je tedy provád¥no práv¥ p°es tuto t°ídu, která je vºdy nazvána R.java. Více o této problematice se m·ºete dozv¥d¥t na [11] Poslední a velice d·leºitou £ástí kaºdé Android aplikace je AndroidManifest.xml. Tento soubor se musí nalézat v ko°enovém adresá°i kaºdého Android projektu a vývojá° v n¥m mimo jiné specikuje, jaké komponenty aplikace obsahuje. Pokud n¥jaká komponenta není zapsána v manifestu, jako by neexistovala. Následující zdrojový kód ukazuje, jak tato specikace m·ºe vypadat.

<manifest ... > ... Zde je °e£eno, ºe aplikace obsahuje komponentu - aktivitu, jejíchº jméno je MainActivity. Dále je pak °e£eno, ºe je tato aktivita pouºita jako vstup do aplikace - první obrazovka, která se po spu²t¥ní aplikace zobrazí. Krom¥ specikace komponent se manifest vyuºívá k mnoha dal²ím ú£el·m:

• Vý£et Permissions - povolení, které aplikace pro sv·j b¥h pot°ebuje. Tyto povolení jsou p°i instalaci p°edloºeny uºivatel·m ke schválení.

43

6.2. UKLÁDÁNÍ DAT

• Stanovení minimální verze systému, na které m·ºe být aplikace nainstalována. • Specikuje, která softwarové a hardwarové prvky aplikace vyuºívá (nap°. kamera, bluetooth) • Uvádí knihovny, které aplikace vyuºívá.

<uses-permission android:name="android.permission.INTERNET" /> <uses-library android:name="com.google.android.maps" />

6.2 Ukládání dat 6.2.1

Struktura dat cesty

Cesta je v aplikaci realizovaná pomocí t°íd Route a Placemark. Na obrázku 6.2 je zobrazen diagram t°íd, který je specikuje. Pro zvý²ení p°ehlednosti jsme u t°íd neuvád¥li metody getter a setter jednotlivých atribut·.

Obrázek 6.2: Diagram t°íd T°ída Route p°edstavuje cestu, která obsahuje kolekci instancí t°ídy Placemark - kontrolní bod. Atributy t°ídy Route obsahují následující informace:

• Identika£ní £íslo cesty - atribut id • Jméno cesty - atribut name • Jméno a pozice startovního a cílového bodu - atributy sourceName, sourcePoint, destName a destPoint • Typ cesty - atribut routeType - pro interní pot°eby aplikace • Kolekci bod· tvo°ících cestu - atribut geoPoints - úse£ky mezi t¥mito body tvo°í trasu Samotné informace pro zrakov¥ postiºené ale obsahuje t°ída Placemark. Jsou strukturované následovn¥:

• Identika£ní £íslo kontrolního bodu a cesty, které náleºí - atribut id a routeId

44


• Základní sm¥rování - atribut directions • Informace o terénu - atribut altitude • Poznámka - atribut note • Audio informace - atribut voicePath - tento atribut obsahuje pouze cestu k uloºenému souboru 6.2.2

Struktura dat pr·chod·

Pr·chody cest zrakov¥ postiºenými jsou v aplikaci realizovány pomocí t°íd Test a TestSample viz obrázek 6.3. T°ída Test obecné informace o pr·chodu:

Obrázek 6.3: Diagram t°íd

• Datum a £as konání pr·chodu - atribut date • Identika£ní £íslo pr·chodu a cesty, kterou uºivatel procházel - atribut id a routeId Ve t°íd¥ TestSample je uloºena konkrétní pozice uºivatele zm¥°ená pomocí GPS (geoPoint) a informace o p°esnosti GPS v dané chvíli. 6.2.3

Uloºení do SQLite databáze

V aplikaci ukládáme data z objekt· t°íd Route, Placemark, Test a TestSample do SQLite databáze (viz 3.4.3). O vytvo°ení databáze a pot°ebných tabulek se stará t°ída SQLiteHelper, která d¥dí od t°ídy SQLiteOpenHelper (sou£ást Android SKD). V metod¥ onCreate poté vytvo°íme dané tabulky následovn¥:

db.execSQL("CREATE TABLE " + TABLE_NAME_ROUTE + "(_id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, sourceName TEXT, destName TEXT, sourceLat INTEGER, sourceLng INTEGER, destLat INTEGER, destLng INTEGER, routeType INTEGER, geoPoints TEXT)"); db.execSQL("CREATE TABLE " + TABLE_NAME_PLACEMARK + "(id INTEGER PRIMARY KEY AUTOINCREMENT, idRoute INTEGER, directions TEXT, pointLat INTEGER, pointLng INTEGER, voicePath TEXT, note TEXT, altitude TEXT, radius INTEGER, type INTEGER)");

6.3. SPRÁVA CEST

45

db.execSQL("CREATE TABLE " + TABLE_NAME_TEST + "(id INTEGER PRIMARY KEY AUTOINCREMENT, idRoute INTEGER, date DATE)"); db.execSQL("CREATE TABLE " + TABLE_NAME_TEST_SAMPLE + "(id INTEGER PRIMARY KEY AUTOINCREMENT, idTest INTEGER, lat INTEGER, lng INTEGER, accuracy DOUBLE)"); Dal²í d·leºitou metodou této t°ídy je onUpdate - ta je zavolána, kdyº dojde k inkrementaci verze databáze a její obsah závisí na podstat¥ zm¥ny, ke které v databázi do²lo. K takto vytvo°ené databázi aplikace p°istupuje p°es rozhraní RouteDAOInterface a jeho implementací RouteDAO. RouteDAOInterface obsahuje metody pot°ebné k ukládání a na£ítání vý²e zmín¥ných objekt·. Nap°íklad implementace metody newRoute, který uloºí novou cestu vypadá následovn¥:

private SQLiteStatement insertRouteStmt; private int newRoute(Route route) { insertRouteStmt = this.db.compileStatement(SQLiteHelper.INSERT_ROUTE); insertRouteStmt.bindString(1, route.getName()); insertRouteStmt.bindString(2, route.getSourceName()); insertRouteStmt.bindString(3, route.getDestName()); insertRouteStmt.bindLong(4, route.getSourcePoint().getLatitudeE6()); insertRouteStmt.bindLong(5, route.getSourcePoint().getLongitudeE6()); insertRouteStmt.bindLong(6, route.getDestPoint().getLatitudeE6()); insertRouteStmt.bindLong(7, route.getDestPoint().getLongitudeE6()); insertRouteStmt.bindLong(8, route.getRouteType()); insertRouteStmt.bindString(9, RouteController.f(route.getGeoPoints())); int idRoute = (int) this.insertRouteStmt.executeInsert(); savePlacemarks(route.getPlacemarks(), idRoute); return idRoute; } Zde se p°i°azují jednotlivé atributy t°ídy Route do insertRouteStmt, který je denován v jiº zmín¥né t°íd¥ SQLiteHelper. Po uloºení cesty se je²t¥ provede uloºení kolekce kontrolních bod·. Obdobn¥ je implementováno ukládání zmín¥ných objekt·. Pro úplnost - SQL dotaz INSERT_ROUTE má následující tvar:

public static final String INSERT_ROUTE = "insert into " + TABLE_NAME_ROUTE + "(name, sourceName, destName, sourceLat, sourceLng, destLat," + "destLng, routeType, geoPoints) values (?,?,?,?,?,?,?,?,?)";

6.3 Správa cest Hlavní aktivitou, umoº¬ující vidícím uºivatel·m vytvá°et cesty a jejich popis je AdminActivity. Tak d¥dí od t°ídy MapActivity a pomocí které aplikace zobrazuje mapu získanou z Google Maps library (viz 3.4.4). Pro samotné zobrazení mapy slouºí komponenta MapView a její vytvo°ení je následující:

46


Díky MapView aplikace zp°ístup¬uje i n¥které základní funkce jako zoom, animace na zadaný bod, zm¥na na satelitní mapu, atd.

MapView mapView = (MapView) findViewById(R.id.mapview); mapView.setBuiltInZoomControls(true); // zobrazení zoom tla£ítek mapView.getController().setZoom(18); // ru£ní nastavení zoom mapView.getController().animateTo(GeoPoint); // animace na zadaný bod mapView.setSatellite(true); // reºim satelitní mapy 6.3.1

Vytvá°ení cesty

Uºivatel kliknutím na mapu vybere poºadovaný startovní, cílový a p°ípadn¥ pr·chozí bod cesty. Vytvá°ení t¥chto bod· je v aplikaci implementováno ve t°íd¥ MapPointsOverlay. Ta d¥dí od t°ídy ItemizedOverlay. V p°ípad¥, ºe chce uºivatel zadat body cesty (vybere danou poloºku v menu) je instance t°ídy MapPointsOverlay p°ídána do Overlay kolekce MapView:

Drawable drawable = this.getResources().getDrawable(R.drawable.flag); mapPointsOverlay = new MapPointsOverlay(drawable, this, this); mapOverlays.add(mapPointsOverlay); mapView.postInvalidate(); Kliknutí na mapu uºivatelem je potom odchytáváno ve t°íd¥ MapPointsOverlay metod¥ OnTap, ve které aplikace zobrazí dialogové okno, kde uºivatel vybere o jaký bod se jedná (viz obrázek 6.4):

@Override public boolean onTap(GeoPoint p, MapView m) { final GeoPoint point = p; AlertDialog.Builder dialog = new AlertDialog.Builder(mContext); dialog.setTitle(R.string.admin_mapTapTitle); dialog.setItems(R.array.mapTapDialogItems, new DialogInterface.OnClickListener() { public void onClick(DialogInterface dialog, int which) { ... }); dialog.setIcon(R.drawable.icon);

6.3. SPRÁVA CEST

47

Obrázek 6.4: Ukázka výb¥ru poºadovaného bodu cesty

}

dialog.show(); return true;

Jak uº bylo ukázáno v sekven£ním diagramu na obrázku 5.2, o samotné vytvá°ení cesty se stará t°ída GoogleMapsDAO, které p°istupuje k externím webovým sluºbám poskytovaným v rámci Google Maps API Web Services (kapitola 3.5). Ze zadaných bod· tedy vytvo°í URL v poºadovaném tvaru a ode²le HTTP poºadavek. Obdrºený tok dat p°evede do xml dokumentu pomocí DOM (document object model) parseru:

private Document getDocument(URL url) { Document doc = null; HttpURLConnection urlConnection = null; try { urlConnection = (HttpURLConnection) url.openConnection(); urlConnection.setRequestMethod("GET"); urlConnection.setDoOutput(true); urlConnection.setDoInput(true); urlConnection.connect(); DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); DocumentBuilder db = dbf.newDocumentBuilder(); doc = db.parse(urlConnection.getInputStream()); doc.normalizeDocument();

48

}


} catch (IOException e) { e.printStackTrace(); } catch (ParserConfigurationException e) { e.printStackTrace(); } catch (SAXException e) { e.printStackTrace(); } return doc;

Z takto získaného xml dokumentu aplikace vybere informace pot°ebné k vytvo°ení cesty. P°i vytvá°ení cesty t°ída GoogleMapsDAO komunikuje s Directions API (získání základního sm¥rování a vzdáleností) a Elevation API (získání nadmo°ské vý²ky - detekce kopc·). Výsledná cesta je poté uºivateli zobrazena op¥t pomocí Overlay objekt·. V tomto p°ípad¥ jsou pouºity dv¥ t°ídy:

• RouteOverlay • PlacemarkOverlay T°ída RouteOverlay se stará o zobrazení trasy dané kolekcí geograckých bodu (GeoPoint). Výslednou trasu tvo°í úse£ky spojující tyto body. T°ída PlacemarkOverlay zobrazuje samotné kontrolní body cesty a navíc umoº¬uje uºivateli kliknutím na kontrolní bod zobrazit jeho informace a nebo p°idávat nové kontrolní body. Výsledné zobrazení vytvo°ené cesty je na obrázku 6.5. 6.3.2

Detekce kopc·

V kapitole 5.1.2 jsme uvedli, ºe krom¥ základního sm¥rování bude aplikace automaticky poskytovat i informace o kopcích na cest¥. Pro jejich indikaci pouºívá aplikace Elevation API, která umoº¬uje získat nadmo°skou vý²ku daného bodu. Indikaci kopc· jsme realizovali pomocí následujících krok·: 1. Zji²t¥ní nadmo°ské vý²ky bod· na cest¥ 2. Vyhledávání kopc· v získaných hodnotách 3. Vytvo°ení nového kontrolního bodu s informací o kopci V prvním bodu aplikace zjistí nadmo°skou vý²ku pro daný bod kaºdých p°ibliºn¥ dvacet metr· cesty. V daného bodu a získané nadmo°ské vý²ky je vytvo°ena instance t°ídy AltitudeSample. St¥ºejní je bod £íslo dv¥, kde se podle kolekce t¥chto vzork· (AltitudeSample) vyhledávají kopce. Vºdy jsou porovnávány dva sousedící vzorky a z jejich vzdálenosti a rozdílu v nadmo°ské vý²ce je vypo£ítán sklon (úhel) dané £ásti cesty. D·leºité bylo tedy stanovit, pod jakým sklonem uº se dá daný úsek povaºovat za kopec. Ur£ení této hodnoty tak, aby vyhovovala v²em uºivatel· je velice obtíºné ne-li nemoºné a proto jsme ur£ili sklon n¥kolika pro nás


49

Obrázek 6.5: Ukázka vytvo°ené cesty

známých kopc· a podle výsledk· jsme stanovili tuto hranici na dva stupn¥. V p°ípad¥, ºe by aplikace detekovala kopec, který podle uºivatele kopcem není £i naopak, m·ºe tuto informaci libovoln¥ zm¥nit. Na základ¥ této analýzy nadmo°ských vý²ek jsou vytvo°eny instance t°ídy Hill, která nese informace o po£átku a konci kopce, jeho délce, celkovému sklonu a orientaci. Na základ¥ t¥chto informací jsou vytvo°eny nové kontrolní body v míst¥ za£átku kopce. V p°ípad¥, ºe se za£átek kopce nachází v blízkosti jiného kontrolního bodu, není vytvo°en nový bod, ale informace jsou p°idány do stávajícího.

6.4 Naviga£ní £ást aplikace Aktivitou, která zaji²´uje navigaci zrakov¥ postiºených po zvolené cest¥ je NavigationActivity. Stejn¥ jako v p°ípad¥ AdminActivity tato t°ída d¥dí od MapActivity. Mapa a dal²í gracké komponenty jsou zobrazeny pouze v p°ípad¥ cvi£ného pr·chodu. 6.4.1

Ovládání hlasem

K rozpoznávání klí£ových slov vyuºívá aplikace Voice recognition (viz kapitola 3.4.1). Tato sluºba je do na²í aplikace zavolána pomocí Intent objektu:

Intent intent = new Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH); intent.putExtra(RecognizerIntent.EXTRA_LANGUAGE_MODEL, RecognizerIntent.LANGUAGE_MODEL_FREE_FORM); intent.putExtra(RecognizerIntent.EXTRA_MAX_RESULTS, 3);

50


Klí£ové slovo Funkce zp¥t opakovat £íslo seznam dal²í p°edchozí vybrat start stop nahrát p°ehrát adresa vzdálenost

návrat v kone£ném automatu pro výb¥r cesty opakování posledních pokyn· (p°i navigaci a výb¥ru cesty) kone£ný automat pro výb¥r cesty p°ejde k zadání £ísla cesty kone£ný automat pro výb¥r cesty p°ejde do seznamu cest p°e£tení dal²í poloºky v seznamu cest a kontrolních bod· p°e£tení p°edchozí poloºky v seznamu cest a kontrolních bod· vybere aktuální poloºku ze seznamu cest spustí navigaci ukon£í navigaci nahraje audio poznámku p°i navigaci p°ehraje audio poznámku kontrolního bodu p°e£te adresu aktuální pozice uºivatele p°e£te vzdálenost do dal²ího kontrolního bodu Tabulka 6.1: Tabulka klí£ových slov

intent.putExtra(RecognizerIntent.EXTRA_LANGUAGE, "cs_CZ"); intent.putExtra(RecognizerIntent.EXTRA_PROMPT, "Speech recognition"); startActivityForResult(intent, VOICE_RECOGNITION_REQUEST_CODE); Danému Intent objektu p°idáváme data pot°ebná k vyhledání (po£et poºadovaných výsledk·, jazyk) a na konec zavoláme metodu startActivityForResult, která Intent objekt spustí. Objeví se dialog, který slouºí k nahrání audio vstupu a po jeho ukon£ení £eká na výsledek, který obratem za²le zp¥t p·vodní aktivit¥. Bohuºel po£áte£ní spu²t¥ní tohoto dialogu v krajním p°ípad¥ trvá i n¥kolik vte°in (v závislosti na p°ipojení k internetu) a zrakov¥ postiºený uºivatel by proto mnohdy nev¥d¥l, kdy p°esn¥ za£ít se zadáváním. Pro odstran¥ní tohoto nedostatku jsme se rozhodli pouºít sluºbu Accessibility (kapitola 4.3.1.1), která po zapnutí indikuje, kdy je rozpoznávací dialog schopen p°ijímat audio vstup. Výsledky rozpoznávání jsou porovnány s klí£ovými slovy. Podle principu uvedeném v záv¥ru kapitoly 4.4 jsou porovnány nejen se samotnými klí£ovými slovy, ale i se slovy, se kterými je klí£ové slovo £asto zam¥¬ováno. Seznam samotných klí£ových slov je uveden v tabulce 6.1. 6.4.2

Navigace

Samotná navigace uºivatele je realizovaná pomocí t°ídy Navigation. Samotné informace o poloze zji²t¥né GPS jsou posílané poslucha£i (listener) GPSLocationListener d¥dící od LocationListener, který byl registrován p°i poºadavku o zasílání polohy:

private GPSLocationListener locationListener; private LocationOverlay locationOverlay; ...


51

locationListener = new GPSLocationListener(this); locationManager =(LocationManager)getSystemService(Context.LOCATION_SERVICE); locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, MIN_TIME, MIN_DISTANCE, locationListener); P°i poºadavku je specikován minimální £as a rozdíl vzdálenosti, p°i kterém mají být posílané aktualizace polohy (v na²em p°ípad¥ nastavené na t°i vte°iny a p¥t metr·). P°i aktualizaci polohy je zavolána metoda onLocationChanged t°ídy GPSLocationListener.

@Override public void onLocationChanged(Location location) { activity.showGPSLocation(location); if(activity.isNavigating()){ GeoPoint point = new GeoPoint((int) (location.getLatitude() * 1E6), (int) (location.getLongitude() * 1E6)); activity.getNavigation().locationChanged(point); } } V této metod¥ ov¥°íme, zda je spu²t¥na navigace a t°íd¥ Navigation po²leme aktualizaci (zavoláme metodu locationChanged). Tato metoda aktualizuje informace o pozici a spustí naviga£ní algoritmus (princip naviga£ního algoritmu byl popsán v kapitole 5.2.2).

public void locationChanged(GeoPoint location) { currentLocation = location; navigate(); } B¥hem navigace je také ºádoucí, aby nedocházelo k neustálému vypínání displeje p°i ne£innosti uºivatele. Z tohoto d·vodu je vºdy p°i spu²t¥ní aktivity NavigationActivity aktivován WakeLock, který vypínání displeje zabrání.

private WakeLock wakeLock; ... PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE); wakeLock = pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK, "Tag"); wakeLock.acquire(); Tento zámek je v metod¥ onPause a onDestroy odstran¥n.

wakeLock.release(); Jak bylo stanoveno v kapitole 5.2.2, navigace by m¥la zahrnovat i mén¥ standardní funkce:

52


• O²et°ení p°esko£ení kontrolního bodu • Ur£ení za£átku trasy V obou p°ípadech je pot°eba zjistit z aktuální pozice uºivatele který z kontrolních bod· cesty je aktuální (dal²í na °ad¥). K ur£ení tohoto bodu musí aplikace z dané polohy ur£it, kde na trase se uºivatel nalézá. V tomto výpo£tu jsme vyuºili faktu, ºe se kaºdá cesta skládá z úse£ek mezi body (viz 6.2.1). Pouºíváme lehce upravenou vzdálenost bodu od p°ímky - v na²em p°ípad¥ se jedná o vzdálenost bodu od úse£ky, kde bod je poloha uºivatele a úse£ka rovnou £ástí cesty. V první fázi zjistíme sou°adnice bodu x na pr·se£íku p°ímky (protaºená úse£ka - £ást cesty) a kolmice p°ímky z bodu aktuální polohy. Pokud bod x leºí na úse£ce je výsledná vzdálenost bodu od úse£ky rovná vzdálenosti mezi bodem x a bodem aktuální polohy. Pokud bod x neleºí na úse£ce výsledná vzdálenost rovna vzdálenosti mezi bodem aktuální polohy a bliº²ím krajním bodem úse£ky. Tento výpo£et se provede pro v²echny £ásti (úse£ky) dané cesty. Nejkrat²í výsledná vzdálenost ur£í, na které £ásti cesty se uºivatel nachází a pak uº aplikace jednodu²e zjistí, který kontrolní bod je dal²í na °ad¥. Takto vypo£tený kontrolní bod je v p°ípad¥ ur£ení za£átku trasy startovním bodem. V pr·b¥hu pr·chodu trasy m·ºe dojít k situaci, kdy se tento vypo£tený kontrolní bod li²í od bodu, na který práv¥ aplikace naviguje. V takovém p°ípad¥ nejspí²e do²lo k p°esko£ení jednoho £i více kontrolních bod·. Aplikace informuje uºivatele o vzniklé situaci, stanoví nový aktuální kontrolní bod a p°e£te informace p°esko£eného bodu.

Kapitola 7

Testování Testování aplikace bude probíhat v exteriéru v centru Prahy v oblasti Karlova nám¥stí. V tomto prost°edí se díky úzkým uli£kám a vysokým budovám dá otestovat, jak se aplikace bude chovat v p°ípad¥, ºe nam¥°ené GPS pozice budou nep°esné. Zrakov¥ postiºená osoba bude procházet p°edem vytvo°enou cestu pomocí této aplikace. Testování bude probíhat na mobilním telefonu Google Nexus One od HTC. P°ed samotným testem bude uºivateli vysv¥tleno ovládání aplikace, nastavena klí£ová slova a vypln¥n pretest dotazník. B¥hem pr·chodu cesty uºivatel p°emý²lí nahlas a jeho poznámky jsou zaznamenávány. Po skon£ení testu je vypln¥n posttest dotazník. Uºivatel si samoz°ejm¥ p°ed samotným pr·chodem musí pomocí hlasových p°íkaz· vybrat poºadovanou cestu.

7.1 Cesta Testovaná cesta za£íná na ulici Resslova (u vchodu do budovy VUT) a kon£í na ulici Myslíkova. Cesta je dlouhá cca 450m, obsahuje p¥t kontrolních bod· a je zobrazena na obrázku 7.1. Informace kontrolních bod· jsou následující: 1. Délka cesty je 450m. Po£et kontrolních bod· je p¥t. Jd¥te po ulici Resslova sm¥rem od Karlova nám¥stí. 2. K°iºovatka ulic Resslova a Na Zderaze. P°ejd¥te p°echod v p°ímém sm¥ru a za ním zahn¥te doprava na ulici Na Zderaze. P°echod není ozna£en 3. K°iºovatka ulic Na Zderaze a Záho°anského. P°ejd¥te ulici v p°ímém sm¥ru a pokra£ujte rovn¥ po ulici Na Zderaze. Pozor, není zde p°echod pro chodce, ulice je ale málo frekventovaná. Cesta po ulici Na Zderaze vede z kopce. 4. K°iºovatka ulic Na Zderaze a Myslíkova. Zahn¥te doprava a p°ejd¥te p°es p°echod. Pak pokra£ujte rovn¥ po ulici Myslíkova. P°echod je ozna£en vodícím pásem na chodníku. 5. Dorazili jste do cíle, d¥kujeme za pouºití na²eho naviga£ního systému. Tyto informace jsou výsledkem syntézy automaticky získaných informací a informací dodaných uºivatelem, který tvo°il cestu. Údaje o vzdálenosti jsou vytvá°eny automaticky a nemusí být sou£ástí kontrolního bodu. 53

54

KAPITOLA 7. TESTOVÁNÍ

Obrázek 7.1: Testovaná cesta

7.2 Pr·b¥h testování Po vysv¥tlení ovládání aplikace a nastavení klí£ových slov byl vypln¥n pretest dotazník následovn¥: 1.

Kolik vám je let?

2.

Jak dlouho a jaké máte postiºení?

3.

Pohybujete se £asto po neznámém prost°edí?

4.

Máte zku²enosti s pouºíváním GPS navigace?

5.

Máte zku²enosti s pouºíváním mobilních telefon·?

57

Úplná slepota od 14 let.

Pouze v krajních p°ípadech. V¥t²inou si obstarám doprovod. Ne, pouze s navigací v interiérech.

Ano, mobilní telefon pouºívám aktivn¥ n¥kolik let.

Po vypln¥ní dotazníku jsme p°istoupili k samotnému testu. Prvním úkolem uºivatele bylo vybrat poºadovanou cestu, k tomuto ú£elu mu bylo sd¥leno, ºe se jedná o cestu £íslo 12. Výb¥r cesty prob¥hl bez potíºí, pouze dané £íslo 12 nebylo napoprvé rozpoznáno správn¥ a uºivatel jej musel zopakovat. Hned na za£átku pr·chodu cesty (po spu²t¥ní aplikace) se objevil první problém s ovládáním telefonu. Ten totiº obsahuje £ty°i dotyková tla£ítka a

7.2. PRBH TESTOVÁNÍ

55

uºivatel p°i manipulaci s telefonem omylem jedno aktivoval a telefon p°e²el do zobrazení základní plochy. Uºivatel byl proto na tyto tla£ítka znovu upozorn¥n a b¥hem dal²ího pr·chodu s nimi jiº nebyl problém. Druhý a t°etí kontrolní bod byl absolvován bez problém·. Mezi t°etím a £tvrtým bodem ale do²lo k výpadku GPS a k obnov¥ spojení do²lo aº t¥sn¥ p°ed koncem cesty. K °e²ení tohoto problému ale v aplikaci existuje manuální procházení kontrolních bod·. Pomocí n¥j uºivatel bez problém· absolvoval zbytek cesty. Upozornil ale na problém, ºe u kontrolních bod· chybí informace o tom, kde se nalézá dal²í kontrolní bod. V p°ípad¥, ºe dojde k výpadku GPS je velice d·leºitá informace typu: Dal²í kontrolní bod se nalézá na k°iºovatce ... . Pr·chod uºivatele po cest¥ je zaznamenán na obrázku 7.2.

Obrázek 7.2: Pr·chod trasy uºivatelem Po pr·chodu celé cesty byl s uºivatelem vypln¥n posttest dotazník: 1.

Znal jste d°íve tuto cestu (její okolí)?

2.

Zdál se vám úkol obtíºný?

3.

Byly informace v pr·b¥hu trasy dosta£ující?

4.

Co se vám na navigaci líbilo?

5.

Co byste na navigaci zlep²il?

Tém¥° ne, pouze úplný za£átek cesty. Ne, v trase nebyly obtíºn¥j²í místa.

Chyb¥la informace, kde se nalézá dal²í kontrolní bod. Vzdálenost mezi kontrolními body by m¥la být °e£ená i p°i opakování bodu. P°ijemn¥ m¥ p°ekvapilo spolehlivé ovládání hlasem - rozpoznávání klí£ových slov. Na vyºádání podat informace o stavu GPS.

56

KAPITOLA 7. TESTOVÁNÍ

7.3 Vyhodnocení testu Nejv¥t²ím problémem celého testu byl výpadek signálu GPS, zde se ale ukázalo, ºe manuální procházení kontrolních bod· je v praxi pouºitelnou alternativou. Kv·li problém·m s GPS je vhodné, aby u kontrolních bod· byla i informace o tom, kde se nalézá dal²í kontrolní bod (ne pouze jeho vzdálenost). Velice p°íjemným p°ekvapením bylo samotné ovládání aplikace pomocí hlasových p°íkazu. Problémy s hlasovým ovládáním se £ekaly na ulici Resslova, která je velice ru²ná a frekventovaná. I zde ale uºivatel provedl poºadovanou akci maximáln¥ na druhý pokus. Problému GPS signálu a p°esnosti je ale pot°eba v¥novat v¥t²í pozornost (i kdyº tento problém se týká p°eváºn¥ míst s vysokou zástavbou). Bylo by tedy vhodné, jak navrhoval uºivatel testu, podávat na vyºádání informace o stavu GPS, aby uºivatel v¥d¥l, zda na nam¥°enou polohu m·ºe spoléhat, nebo má pouºít manuální procházení kontrolních bod·.

Kapitola 8

Záv¥r Hlavním úkolem této diplomové práce bylo usnadnit pohyb zrakov¥ postiºených osob v neznámém prost°edí pomocí mobilního telefonu. Díky n¥kolika konzultacím ve Sjednocené organizaci nevidomých a slabozrakých (SONS) a u pana Ing. Zde¬ka Míkovce, Ph.D. se poda°ilo analyzovat konkrétní pot°eby zrakov¥ postiºených vzhledem k navigaci. V této oblasti jsme se zam¥°ili p°eváºn¥ na informace, které zrakov¥ postiºení pot°ebují a také na moºnosti ovládání dotykového mobilního telefonu s platformou Google Android. Zde jsme se rozhodli pro pouºití hlasového ovládání, které se p°i testování aplikace ukázalo jako rychlé a spolehlivé. Dále jsme v rámci této diplomové práce zkoumali moºnosti vyuºití knihoven poskytovaných platformou Google Android. Na základ¥ t¥chto poznatk· bylo navrºeno °e²ení dvoufázové navigace pro zrakov¥ postiºené s vyuºitím GPS a posléze implementováno pro GAP. Na záv¥r byla aplikace testována v reálném prost°edí p°i navigaci zrakov¥ postiºené osoby. Test ukázal, ºe ovládání aplikace je pro zrakov¥ postiºené uºivatele vhodné a samotná navigace fungovala bez v¥t²ích problém·. Vyrovnala se i s do£asným výpadkem GPS signálu. Testováním jsme tedy potvrdili korektnost navrºeného °e²ení i samotné implementace. Navíc jsme na základ¥ výsledk· testu navrhli n¥kolik drobných zm¥n, které je²t¥ více usnadní zrakov¥ postiºeným vyuºívání této aplikace. Krom¥ samotné aplikace je d·leºitým p°ínosem této práce i prozkoumání moºností platformy Google Android z hlediska vyuºitelnosti zrakov¥ postiºenými uºivateli. Pro budoucí projekty na této platform¥ je uºite£né i ov¥°ení hlasového ovládání pomocí knihovny Voice Recognition v reálném prost°edí. V²echny body zadání tak byly zdárn¥ spln¥ny. Dal²ím krokem v p°ípad¥ pokra£ování tohoto projektu by mohlo být nap°íklad z°ízení ve°ejných webových stránek, kde by mohli registrovaní uºivatelé vytvá°et popisy daných cest. Z t¥chto stránek by mohly být popisy staºeny do mobilního telefonu zrakov¥ postiºené osoby. Tím by se zjednodu²ilo samotné vytvá°ení popisu cesty (zadávání informací na mobilním telefonu je pomalej²í neº na PC) a p°edávání t¥chto informací zrakov¥ postiºené osob¥ uºivatel vytvá°ející cestu nemusí mít v ruce mobilní telefon zrakov¥ postiºené osoby. V tomto p°ípad¥ by se do procesu vytvá°ení cest mohli zapojit i ²kolení pracovníci r·zných organizací podporujících zrakov¥ postiºené, kte°í by mohli vytvá°et popisy pro ²ir²í ve°ejnost. Pokud by byla dána specikace formy popisu cesty (nap°íklad p°esný tvar xml dokumentu), mohly by tento systém vyuºívat i dal²í aplikace. Z hlediska ovládání mobilních telefon· s platformou Google Android a dotykových telefon· obecn¥, se jako jedna z moºností jeví vyuºití p°ídavného ovládacího za°ízení, p°ipo57

58

KAPITOLA 8. ZÁVR

jeného k telefonu nap°íklad pomocí technologie Bluetooth. To by obsahovalo základní ovládací prvky, které by byly pot°eba pro ovládání aplikací uzp·sobených pro zrakov¥ postiºené. Reálné je i integrování tohoto ovládacího za°ízení do bílé hole jako je tomu u akustických majá£k· a zrakov¥ postiºený uºivatel by u sebe nemusel nosit dal²í za°ízení (pom·cku).

Literatura [1] I. N. Jim Arlow. UML2 a unikovaný proces vývoje aplikací. computer Press, nám. 28. dubna 48, Brno, 2. edition, 2007. [2] R. Pecinovský. Návrhové vzory. computer Press, nám. 28. dubna 48, Brno, 1. edition, 2007. [3] J. L. Rick Rogers. Android application development. O REILLY, 1. edition, 2010. [4] Android development community. http://www.anddev.org/, stav z 3. 3. 2011. [5] SONS - Bílá h·l. http://www.sons.cz/docs/bilehole/01.php, stav z 4. 4. 2011. [6] Google Android Dev Guide hello, views. http://developer.android.com/resources/tutorials/views/index.html, stav z 17. 3. 2011. [7] Mapy Google. http://maps.google.com/, stav z 5. 4. 2011. [8] Naviga£ní centrum - SONS - uºite£né dokumenty. http://navigace.sons.cz/dokumenty.html, stav z 4. 4. 2011. [9] Google maps api web services. http://code.google.com/intl/cs/apis/maps /documentation/webservices/index.html, stav z 28. 3. 2011. [10] Obtain a maps api key. http://code.google.com/intl/cs/android /add-ons/google-apis/mapkey.html, stav z 25. 3. 2011. [11] Google android dev guide application resources. http://developer.android.com/guide/topics/resources/index.html, 21. 3. 2011. [12] SQlite Home page. http://www.sqlite.org/, stav z 25. 3. 2011. 59

stav

z

60

LITERATURA

[13] Google Android Dev Guide data storage. http://developer.android.com/guide/topics/data/data-storage.html#db, stav z 25. 3. 2011.

P°íloha A

Seznam pouºitých zkratek GAP VM

Google Android Platform

Virtual Machine - virtuální stroj

JVM OS

Java Virtual Machine

Opera£ní systém

json

JavaScript Object Notation

WHO IKT

World Health Organization - Sv¥tová zdravotnická organizace

Informa£ních a komunika£ních technologií

GSM

Globální Systém pro Mobilní komunikaci

GPRS GPS

General Packet Radio Service

Global Positioning System

GNSS

Global Navigation Satellite System

DOM

Document Object Model

DAO

Data Access Object

MVC

Model View Controller

.. .

61

62

PÍLOHA A. SEZNAM POUITÝCH ZKRATEK

P°íloha B

Instala£ní a uºivatelská p°íru£ka B.1 Instala£ní p°íru£ka Pro instalaci aplikace je zapot°ebí mobilní telefon s platformou Google Android, verze API minimáln¥ 8. Pro samotnou instalaci je pot°eba zkopírovat soubor ImparedNavigation.apk z p°iloºeného CD ve sloºce apk. Spu²t¥ním tohoto souboru v mobilním telefonu dojde k instalaci. Ke správnému chodu aplikace je zapot°ebí mít na daném mobilním telefonu £eský Text to Speech stroj (jako je nap°íklad SVOX TTS). Pro b¥h aplikace je také nezbytné p°ipojení k internetu. P°i navigaci pro zrakov¥ postiºené doporu£ujeme mít zapnutou sluºbu Accessibility, konkrétn¥ KickBack.

B.2 Uºivatelská p°íru£ka Po spu²t¥ní aplikace v mobilním telefonu se uºivateli zobrazí základní nabídka s následujícími moºnostmi:

Navigace Správa cest Nastavení klí£ových slov Uloºené pr·chody cest B.2.1

Vytvá°ení cesty

Pro vytvo°ení nové cesty zvolte po spu²t¥ní aplikace poloºku Správa cest a v na dal²í obrazovce zadejte menu/Vytvo°it novou cestu. Po tomto kroku se vám objeví nová obrazovka se zobrazenou mapou (obrázek B.1). Pro urychlení práce s mapou doporu£ujeme poºadovanou adresu vyhledat pomocí tla£ítka vyhledat na mobilním telefonu, nebo pouºít poloºku menu/vyhledat adresu. Pro zadání za£áte£ního a koncového bodu (p°ípadn¥ i pr·chozích bod·) zvolte menu/Zadat cestu. Po zvolení této poloºky pomocí kliknutí na mapu zadáte poºadované body - za£áte£ní 63

64

PÍLOHA B. INSTALANÍ A UIVATELSKÁ PÍRUKA

Obrázek B.1: Vlevo úvodní obrazovka vytvá°ení cesty. Vpravo obrazovka s vytvo°enou cestou

a koncový bod je povinný, pr·chozí body jsou nepovinné. Po zadání bod· zvolte menu/Najít cestu. Tato akce m·ºe trvat i n¥kolik vte°in a v jejím pr·b¥hu je vytvo°ena základní kostra cesty (viz obrázek B.1). Kliknutím na mapu (p°esn¥ na daný kontrolní bod) vyberete kontrolní bod, zobrazí se dialogové okno, které zobrazuje informace o daném kontrolním bodu. Pomocí tla£ítka Upravit dialogového okna m·ºete tyto informace zm¥nit, £i kontrolní bod smazat. Pomocí tla£ítka plus, které se nachází v levém dolním rohu mapy, m·ºete p°idávat nové kontrolní body. Po stisku tla£ítka vyberete kliknutím na mapu poºadovanou pozici nového kontrolního bodu a poté op¥t pomocí dialogového okna vloºíte dané informace. Tla£ítko v pravém dolním rohu slouºí k p°epínání typu mapy (z klasické na satelitní). Vytvo°enou cestu uloºíte pomocí menu/Uloºit cestu. B.2.2

Nastavení klí£ových slov

Tato £ást aplikace je velice d·leºitá pro rozpoznávání klí£ových slov a bez jejího vypln¥ní nebude navigace schopna p°ijímat p°íkazy zrakov¥ postiºeného uºivatele. V základní nabídce zvolte poloºku Nastavení klí£ových slov. Na následující obrazovce je seznam klí£ových slov pouºitých v aplikaci. Pro kaºdé klí£ové slovo je pot°eba minimáln¥ 3x stisknout tla£ítko p°idat a zadat dané klí£ové slovo. Výsledky t¥chto rozpoznávání se ukládají. V p°ípad¥ chyby m·ºete pouºít tla£ítko reset a se zadáváním za£ít znovu. Obrazovku slouºící pro nastavování klí£ových slov m·ºete vid¥t na obrázku B.2. B.2.3

Navigace

Pro spu²t¥ní navigace zrakové postiºených uºivatel· zvolte v základní nabídce Navigace. Zde si pomocí klí£ových slov a pokyn· mobilního telefonu vyberete poºadovanou cestu. Klí£ová slova jsou zadávána po stisknutí tla£ítka ok na mobilním telefonu. V p°ípad¥, ºe je zapnutá sluºba KickBack, je uºivateli pomocí vibrace dáno najevo, kdy m·ºe za£ít se zadáváním

B.2. UIVATELSKÁ PÍRUKA

65

Obrázek B.2: Obrazovka nastavení klí£ových slov

klí£ového slova. Doba rozpoznání klí£ového slova je závislá na rychlosti p°ipojení k internetu a m·ºe trvat i n¥kolik vte°in. Cesta m·ºe být vybrána ze seznamu nebo podle identika£ního £ísla cesty, které ale musí uºivatel znát p°edem. Po výb¥ru cesty uºivatel spustí navigaci pomocí klí£ového slova start. B¥hem navigace m·ºe uºivatel manuáln¥ procházet informace kontrolních bod· pomocí klí£ových slov dal²í a p°edchozí. Dále pomocí klí£ových slov vzdálenosti a adresa získá informace o vzdálenosti od dal²ího kontrolního bodu a adrese, na které se nachází. Tyto informace jsou pouze orienta£ní a jsou závislé na p°esnosti GPS, proto nedoporu£ujeme je pouºívat £asto (maximáln¥ 1-2x na jednom úseku cesty). Pomocí klí£ového slova nahrát m·ºe zrakov¥ postiºený uºivatel b¥hem pr·chodu p°idávat své vlastní audio poznámky. B.2.4

Uloºené pr·chody cest

V p°ípad¥, ºe si chcete prohlédnou pr·chod uºivatele p°i navigaci po dané cest¥, zvolte v základní nabídce poloºku Uloºené pr·chody cest a dal²í obrazovce vyberte cestu, pro kterou chcete pr·chody zobrazit. Výsledná obrazovka je na obrázku B.3. Zde je zobrazena zvolená cesty a pr·chod uºivatele podle sou°adnic nam¥°ených GPS. Pomocí poloºek v menu Zobrazit záznamy a Smazat záznamy m·ºete vybírat záznamy, které záznamy chcete zobrazit nebo n¥které z nich smazat.

66

PÍLOHA B. INSTALANÍ A UIVATELSKÁ PÍRUKA

Obrázek B.3: Obrazovka uloºených pr·chod· cesty

P°íloha C

Obsah p°iloºeného CD | |--readme.txt // Popis obsahu CD, instalace a pouºití | |--src | | ... // Eclipse projekt, zdrojové kódy aplikace | |--apk | |--ImpairedNaviation.apk // Instala£ní soubor | |--text | |--jan.peska-thesis-2011.pdf // Text diplomové práce

67

Na tomto míst bude ociální zadání va²í práce

Recommend Documents