Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Diplomová práce ČVUT Navigátor - WP klient II Bc. Tomáš Bezouška Vedoucí práce: Ing. Jiří Chludil 8. května 2014

4

5 Poděkování Všem členům týmu ČVUT Navigátor za bezproblémovou spolupráci a Vadimu Petrovovi za návrh vzhledu markeru.

6

7 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen Dílo ), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či spracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla. V Praze dne 8. května

8 České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Tomáš Bezouška. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Bezouška, Tomáš. ČVUT Navigátor - WP klient II. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.

9 Abstrakt Předmětem této práce je dokončení vyvíjené mobilní aplikace ČVUT Navigátor pro systém Windows Phone. Tato aplikace si klade za cíl usnadnit život všem členům akademické obce Českého vysokého učení technického. Dokáže uživatele navigovat mezi místnostmi a budovami ČVUT, navíc se umí synchronizovat s webovou službou a zobrazit uživateli jeho rozvrh. Klíčová slova navigace, windows phone, KOS, ČVUT, rozvrh Abstract Purpose of this thesis is to finish a mobile application CTU Navigator being developed for Windows Phone operating system. This application aims to make life easier for every member of the academia of Czech Technical University. It can navigate users between various CTU buildings and rooms in those buildings as well as show users their timetable, which is synchronized with a web service. ix

10 Keywords navigation, windows phone, KOS, CTU, timetable x

11 Obsah Úvod 1 1 Analýza Stav projektu Analýza předešlých závěrečných prací Windows Phone Návrh Napojení klientské aplikace na server Offline mapové podklady Další body zájmu Rozšířená realita Zpětná vazba Hlášení chyb Shrnutí návrhu Implementace Vývoj pro více platforem Použité knihovny Řešené problémy Testování Napojení na server Uživatelské testování Závěr 55 Návrhy na vylepšení xi

12 Literatura 61 A Seznam použitých zkratek 63 B Uživatelská příručka 65 B.1 Instalace aplikace B.2 První spuštění B.3 Agenda B.4 Rozvrh B.5 Předměty a učitelé B.6 Mapa a navigace B.7 Vyhledávání B.8 Live tile C Obsah přiloženého CD 73 xii

13 Seznam obrázků 1.1 Struktura projektu ČVUT Navigátor [1] Vzhled WP7 aplikace Schéma procesu přihlašování s použitím protokolu OAuth [1] Tržní podíl systémů WP7 a WP8 v únoru 2014 [2] Shodné části systémů Windows Phone a Windows 8.1 [3] Ukázka vzhledu QR kódu Návrh vzhledu markeru, který vytvořil Vadim Petrov Rozšířená realita Změny UI pro sledování polohy uživatele Class diagram pro schování implementace za rozhraní Závislost doby běhu testu na počtu paralelních instancí Hodnocení aplikace Nový vzhled agendy B.1 QR kód s odkazem na stažení aplikace B.2 Instalace aplikace B.3 První spuštění a nastavení B.4 Obrazovky agendy B.5 Obrazovky rozvrhu B.6 Obrazovky předmětů a jejich detailu B.7 Obrazovky vyučujících a jejich detailu B.8 Mapa a navigace B.9 Vyhledávání B.10 Přední a zadní strana dlaždice xiii

14

15 Úvod ČVUT Navigátor je projekt, jehož počátky se datují až do roku Klade si za cíl značně zjednodušit život všem členům akademické obce ČVUT. Z pohledu uživatele se jedná o aplikaci pro mobilní telefon, která mu pomůže se zorientovat v životě na ČVUT. Dokáže mu zobrazit jeho aktuální rozvrh, v kolik hodin a v jaké místnosti má následující hodinu a kudy se tam dostane. U budov dokáže zobrazit plány jednotlivých pater včetně místností a dalších bodů zájmu. Celkově se jedná o systém několika aplikací postavený na architektuře klient-server. Serverová část obstarává komunikaci se systémem KOS, aplikací pro správu mapových podkladů a případně dalšími nezbytnými aplikacemi. Tato data pak dále poskytuje mobilním klientům skrze jednotný komunikační protokol. Klientské aplikace jsou momentálně ve vývoji tři verze pro Android, ios a Windows Phone. V této práci se budu zabývat vývojem verze pro poslední zmíněnou platformu. Tato práce má navázat na mou bakalářskou práci ČVUT Navigátor Klient WP7 I[4], kterou jsem obhájil před dvěma lety. V té době byl celý projekt teprve v počátcích. Existovala pouze Android verze aplikace a návrh komunikačního protokolu. Od té doby byl zprovozněn webový server a vznikly další aplikace, které bude potřeba analyzovat a zajistit, že budou s klientskou aplikací bez potíží komunikovat. V závěru pak dojde k širšímu testování samotnými uživateli, tedy především studenty ČVUT. Popis zadání ČVUT Navigátor je systém pro podporu orientace studentů na fakultách Českého Vysokého Učení Technického. Systém využívá architekturu klient- 1

16 Úvod server, kde server slouží ke komunikaci s IS fakulty, resp. mapovými zdroji a poskytuje je ve vhodné formě mobilním klientům přes komunikační API. Následuje seznam bodů zadání tak, jak by měly být vypracovány. Navažte na svoji úspěšně obhájenou bakalářskou práci ČVUT Navigátor Klient WP7 I. V roce 2012 jsem úspěšně obhájil výše zmíněnou práci. Její hlavní náplní bylo vytvoření klientské aplikace, která by dokázala zobrazovat studentův rozvrh, mapu se seznamem bodů zájmu a dokázala by zobrazit trasu mezi libovolnými dvěma body. Toto zadání jsem splnil, nicméně povaha celé aplikace je taková, že spoléhá na data z webového serveru, který ovšem nebyl náplní mé práce. Jelikož tento server nebyl včas implementován, navrhl jsem pouze mock server uvnitř aplikace, který zprostředkovával statická data. Celá architektura aplikace ovšem s budoucím napojením na skutečný server počítá, proto by tento krok měl být přímočarý. Upravte klienta platformy WP tak, aby získával potřebná data (mapové podklady a data uživatelů) ze serverové části systému. Jak píši o odstavec výše, klient momentálně zobrazuje pouze statická data. Od doby napsání mé bakalářské práce se do projektu zapojilo několik dalších lidí, jejichž úkolem mimo jiné bylo celý server zprovoznit. K dnešnímu dni tak již základní verze funguje a poskytuje mapové podklady a data uživatelů. Přepojení aplikace ze statického serveru uvnitř aplikace na skutečný webový server by mělo být vzhledem použitému dynamickému návrhu jednoduché. Navrhněte rozšíření klienta o následující funkcionality: podpora různých typů bodu zájmu, kešování mapových podkladů, podpora technologie rozšířené reality, zpětná vazba pro efektivní navigaci a navržené změny implementujte. Pro zvýšení užitečnosti aplikace a uživatelského komfortu při jejím užívání je potřeba dodělat některé další funkce. V době tvorby klienta pro platformu Windows Phone 7 nebylo možné jednoduše kešovat mapové podklady, při 2

17 každém zobrazení plánku podlaží se tedy musely stáhnout z webové serveru, což jednak zbytečně zdržuje, také to ale může zatížit uživatelův FUP limit 1. Je tedy vhodné znovu analyzovat, zda nyní tato platforma neposkytuje prostředky, jak kešování implementovat. Různé body zájmu usnadní uživateli orientaci po budově. Jedná se např. o toalety, výtahy, schodiště a další. Rozšířená realita je v dnešní době velmi populární technika. Uživatel zamíří telefon na nějaký objekt, přičemž je aktivována kamera, která snímá okolní prostředí. Navíc se na displeji zobrazují další virtuální objekty, které skutečnou realitu nějakým způsobem rozšiřují. Např. v režimu navigace se při namíření telefonu na předem definovanou značku na displeji dokreslí šipka, která bude ukazovat tím směrem, kudy se má uživatel dále vydat. Posledním bodem je zpětná vazba pro efektivní navigaci. Aplikace bude schopna během navigace sledovat pohyb uživatele a odesílat tato data na server, díky čemuž bude možné lépe optimalizovat trasu pro konkrétní dny či denní doby (např. ráno je lepší jet výtahem, v poledne je ale rychlejší jít po schodech). Důležitou vlastností této funkce je možnost ji na přání uživatele vypnout. Klienta podrobte vhodným testům. Zaměřte se na testování uživatelské přívětivosti a na komunikaci se serverem. Před ostrým nasazením je potřeba každou aplikaci důsledně otestovat, ani tato aplikace není výjimkou. Kromě běžných programových testů, které by měly odhalit základní chyby v aplikaci, jsou velmi důležité také uživatelské testy, které odhalí, jak se uživatelům s aplikací pracuje. Tyto testy představují pro programátora velmi důležitou zpětnou vazbu a pokud jsou provedeny v dostatečné míře, mohou značně pomoci vylepšit uživatelskou přívětivost celé aplikace. Analyzujte a ověřte přenositelnost Vaší aplikace na další platformy společnosti Microsoft. Kromě Windows Phone vytvořil Microsoft také další platformy. Aby se aplikace rozšířila mezi co největší počet uživatelů, je vhodné je všechny analyzovat a rozhodnout, zda je možné a vhodné aplikaci dodat i na některou z nich. 1 Fair User Policy, limit na množství stažených dat 3

18

19 Kapitola 1 Analýza Před započetím samotné práce na aplikaci je třeba analyzovat aktuální stav celého projektu ČVUT Navigátor. Je možné částečně vyjít z analýzy, kterou jsem provedl ve své bakalářské práci, jelikož je ale v současnosti dva roky stará, je potřeba zjistit, co se v projektu od té doby změnilo. Na začátek jen v krátkosti shrnu soudobý stav celého projektu a Windows Phone klienta v okamžiku odevzdání mé bakalářské práce před dvěma lety. Poté rozeberu další závěrečné práce, které od té doby vznikly, a jejich přínosy a poznatky. Nebudu analyzovat všechny práce spadající do tohoto projektu, ale pouze na ty, které jsou nějaký způsobem relevantní pro tuto práci. Jelikož je klient cílený na mobilní operační systém, u kterých je zvykem mnohem rychlejší vývoj než u tradičních velkých operačních systémů, v druhé části této kapitoly také zmíním novinky v tomto ohledu. Zároveň také zmíním další systémy od Microsoftu, na které by mělo smysl aplikaci portovat, jak vyžaduje poslední bod zadání. 1.1 Stav projektu Celková architektura byla navržena jako klient-server. Server bude komunikovat s různými zdroji dat (např. KOS nebo aplikace pro správu mapových podkladů) a bude je zprostředkovávat jednotlivým klientským aplikacím pomocí komunikačního API, který ve své práci definoval Ondřej Čermák [5]. Pohled na celkovou architekturu je vidět na obrázku 1.1. Hlavní myšlenkou celého projektu byl fakt, že aplikace budou fungovat vesměs v offline režimu. Jinými slovy při prvním spuštění aplikace dojde ke stažení všech podstatných dat (body zájmu, mapové podklady, uživatelův 5

20 1. Analýza Obrázek 1.1: Struktura projektu ČVUT Navigátor [1] 6

21 1.2. Analýza předešlých závěrečných prací rozvrh apod.) a dále již aplikace ke svému fungování nebudou potřebovat připojení k internetu. Jedinou výjimku tvoří vyhledávání tras mezi jednotlivými body. To může být pro mobilní zařízení relativně náročná operace, proto tato jediná funkce měla vyžadovat připojení k internetu, aby mohla být delegována přímo na server. Komunikační API bylo této specifikaci přizpůsobeno a obsahovalo metody pro prvotní stažení všech dat a následující rozdílové aktualizace. Pro přihlašování byl vybrán protokol OAuth 2.0 [6]. Z klientských aplikací existovaly 2 pro Windows Phone 7 a pro Android, kterou vytvořil Ondřej Čermák. 1.2 Analýza předešlých závěrečných prací Klient WP7 I - Tomáš Bezouška Cílem mé bakalářské práce bylo vytvoření klientské aplikace pro Windows Phone 7, která by dokázala komunikovat s webovým serverem a zobrazovat poskytnutá data o uživatelově rozvrhu. Dále měla přes GPS určovat jeho pozici a vyhledávat trasy z bodu do bodu. Mým hlavním podkladovým materiálem pro tvorbu aplikace byla výše zmíněná diplomová práce Ondřeje Čermáka, která detailně popisovala architekturu celého projektu a návrh komunikačního API. Zadání jsem splnil, jedinou problematickou částí byla komunikace s webovým serverem. Ten měl být realizován v týmovém projektu, jehož jsem nebyl součástí a jeho vývoj jsem nemohl nijak ovlivnit. V době odevzdávání mé práce tento server ještě nefungoval, proto jsem navrhl rozhraní pro komunikaci se serverem (tato komunikace ve formě REST API byla již navržena a zdokumentována) a toto rozhraní implementoval tzv. mock třídou, která vracela pouze statická data. Aplikace se tak tvářila, že poskytuje správná data, ve skutečnosti ale s webovým serverem vůbec nekomunikovala. Vzhled existující aplikace lze vidět na obrázcích 1.2. Jedná se o standardní vzhled aplikace v rámci Windows Phone ekosystému. Hlavní obrazovka slouží jako rozcestník a tvoří ji několik dlaždic, stejně jako je tomu na hlavní obrazovce systému. V horní části uživatel vidí nadcházející událost ze svého rozvrhu, kdy se koná a kdy. Také se uživateli zobrazuje informace o aktuálním výukovém týdnu. 7

22 1. Analýza (a) Hlavní obrazovka (b) Rozvrh (c) Mapa budovy Obrázek 1.2: Vzhled WP7 aplikace Na dalších dvou obrazovkách je vidět rozvrh a procházení plánů budovy. Kompletní seznam všech obrazovek aplikace je součástí přílohy mé bakalářké práce Komunikační API Zdeněk Pecka Zdeněk Pecka se ve své závěrečné práci [1] věnuje komunikačnímu API pro spolupráci serveru a klientských aplikací. Ačkoliv základní API navrhl již Ondřej Čermák, došlo k podstatné změně, která vyžadovala zcela nové řešení. Jak jsem již zmínil dříve, původní návrh počítal s tím, že klientské aplikace budou většinu času fungovat v offline režimu a připojovat online se budou pouze při synchronizaci nebo při vyhledávání tras. Nový návrh počítá s tím, že klientské aplikace budou kompletně online. V praxi to bude fungovat tak, že aplikace si při prvním spuštění stáhne pouze to nejnutnější pro své fungování a ostatní data budou dostupná skrze další API na vyžádání. V okamžiku, kdy tato data bude aplikace vyžadovat, zašle serveru požadavek a ten jí je vrátí. Aplikace si tato data uloží a v okamžiku, kdy k nim bude přistupovat podruhé, zobrazí lokální kopii. Navíc se zeptá serveru, zda u nich nedošlo ke změně. Pokud došlo, server pošle novou verzi a aplikace si aktualizaci uloží a zobrazí. Tento posun od napůl offline módu ke zcela online dává smysl, vytváří to ale velký problém pro můj původní návrh, který s online módem vůbec nepočítal. Pecka ve své práci píše, že původní API navržené Čermákem je 8

23 1.2. Analýza předešlých závěrečných prací v protokolu zachováno, realita je ovšem taková, že není momentálně implementováno, je dostupné pouze nové API. Webový server by měl fungovat dle původní specifikace jako RESTful služba, detailnější popis této technologie lze nalézt v Peckově práci. Důležité pro klientskou aplikaci je, že služba poskytuje své zdroje skrze HTTP požadavky na předem známé adrese. V požadavku jsou pak dle specifikace přítomny hlavičky, a případně tělo obsahující data ve formátu json 2. Takový požadavek vypadá například takto: POST /authorize HTTP/1.1 Content-Type: application/json { "username": "johndoe", "password": "A3ddj3w" } Odpověď má pak následující strukturu: HTTP/ OK Content-Type: application/json;charset=utf-8 { "access_token":"2yotnfzfejr1zcsicmwpaa", "token_type":"navigator", "expires_in":3600, "refresh_token":"tgzv3jokf0xg5qx2tlkwia" } Obecný tvar adresy je následující: Zajímavé je, že se již dopředu počítá s verzováním protokolu. Pokud by tedy někdy v budoucnu došlo k vytvoření jeho nové verze, která by obsahovala výrazné změny, je velmi jednoduché ji od té stávající oddělit. Původní klientské aplikace by stále bez problému fungovaly a nové by již využívaly novější verzi protokolu. Seznam všech dostupných zdrojů je v příloze Peckovy práce. Obecně se však dají rozdělit do 4 částí. 2 JavaScript Object Notation, 9

24 1. Analýza Obrázek 1.3: Schéma procesu prihlašování s použitím protokolu OAuth [1] Zabezpečení Do této skupiny patří především metody pro autentizaci uživatele. Ta využívá protokolu OAuth 2 a jeho metody Resource Owner Password Credentials Grant [7]. Funguje tak, že uživatel zadá přihlašovací údaje přímo aplikaci, která je posléze zašle serveru k ověření. Server ČVUT Navigátora pošle tyto údaje fakultnímu autentizačnímu serveru, který je ověří a vrátí odpověď. Celý proces znázorňuje obrázek 1.3. Po prvotním ověření přihlašovacích údajů server klientovi vygeneruje unikátní access token a refresh token. V následné komunikaci již klient v každém požadavku přikládá pouze daný access token. Uživatelské jméno a heslo se nepoužívá. Access token má určenou platnost, po jejím vypršení je potřeba požádat server o vygenerování nového. K tomu slouží refresh token. Důležitým poznatkem na tomto postupu je fakt, že si klientská aplikace nemusí pamatovat uživatelovy přístupové údaje, čímž se snižuje riziko např. při ztrátě 10

25 1.2. Analýza předešlých závěrečných prací mobilního telefonu. Celá komunikace mezi klientskou aplikací a serverem musí být pochopitelně šifrovaná, nejjednodušší variantou je nasadit na server SSL certifikát a komunikovat výhradně přes protokol HTTPS. V době vývoje byl na serveru nasazen pouze self signed certifikát (podepsaný sám sebou), což se na platformě Windows Phone nečekaně projevilo jako problém. Telefon totiž obsahuje databázi důvěryhodných certifikačních autorit. Pokud má dojít k šifrovanému spojení přes HTTPS a daný certifikát není vydán jednou z těchto autorit, systém takové spojení automaticky odmítne. Toto nastavení bohužel není možné v telefonu nijak změnit. Možnosti jsou tudíž dvě. Uživatel si může certifikát použitý na serveru stáhnout a nainstalovat do telefonu, což je ovšem uživatelsky velmi nepříjemné. Druhou možností je na server nainstalovat certifikát vydaný uznávanou certifikační autoritou KOS Do druhé skupiny metod patří ty, které zprostředkovávají data z IS KOS. Jedná se o data o uživatelích, předmětech, rozvrzích a konzultačních hodinách učitelů. Citelně zde chybí možnost vyhledávání mezi uživateli a předměty. Bylo by například hezké, kdybych si mohl zobrazit rozvrh libovolného uživatele, stejně jako je to možné na timetable.fit.cvut.cz. Momentálně API podporuje zobrazení rozvrhu pouze osob, u kterých znám jejich školní uživatelské jméno. To lze získat z uživatelova seznamu zapsaných předmětů, který API poskytuje, občas ale může uživatele zajímat i rozvrh někoho, ke komu na přednášku ani na cvičení nechodí Mapové podklady Mapové API poskytuje informace potřebné pro navigaci a ke správnému fungování map. Patří mezi ně informace o budovách, místnostech, bodech zájmu a také umožňuje vyhledávání nejkratší trasy mezi 2 zadanými body. K dispozici je také metoda pro získání informací o markeru. Markery podrobněji popíši níže v analýze závěrečné práce Tomáše Kohouta Harmonogram Poslední skupinou jsou metody pro práci s harmonogramem předmětu. Harmonogram předmětu obsahuje důležité události, které se ho týkají. Může se jednat například o domácí úkoly, testy na cvičeních, přesuny výuky a podobně. 11

26 1. Analýza Mobilní ios klient Tomáš Kohout Tomáš Kohout ve své závěrečné práci[8] úspěšně vytvořil klientskou aplikaci pro další hlavní mobilní platformu ios od společnosti Apple. Jelikož tato aplikace již zcela využívá nové API serveru, je velmi zajímavé se podívat na konkrétní specifikace a u některých problémů se inspirovat. Kohout také ve své práci analyzoval mou aplikaci pro Windows Phone, které vytkl několik drobností: Použití slova segment v navigaci, což může být pro uživatele matoucí Při prvotním přihlášení není specifikováno, jaké heslo se má použít (fakultní nebo školní) Některé chybějící funkce kvůli neexistenci serveru Řešení prvního problému je jednoduché, je pouze potřeba použít vhodnější terminologii. Druhý problém se vyřešil částečně sám, jelikož došlo k přechodu na jediné společné heslo Heslo ČVUT. I tak by ale v popisu přihlášení mělo být zmíněno, že se jedná právě o toto heslo a ne jiné. Poslední výtka byla mířena spíše na serverovou část a je nyní také vyřešena, jelikož došlo k implementaci serveru Navigace uvnitř budov Vnitřní navigace tvoří podstatnou část Kohoutovy práce. Po analýze několika možností dospěl k řešení pomocí markerů a rozšířené reality. V praxi by to mělo fungovat tak, že se po budovách ČVUT rozlepí speciální značky, markery, které v sobě budou obsahovat jedinečný identifikátor. Uživatel pak fotoaparátem telefonu takový marker naskenuje a ihned se mu zobrazí, kde se nachází. Pokud je navíc v módu navigace, tak se mu na displeji telefonu zobrazí 3D šipka ukazující směrem, kterým se má dále vydat, jak lze vidět na obrázku 1.4b. Prototyp takového markeru lze vidět na obrázku 1.4a. Momentálně se jedná pouze o předběžný návrh, konkrétní podobu ještě bude třeba doladit. Tento vzhled má totiž několik zásadních nevýhod. Jednou z nich je nemožnost do něj umístit jakoukoliv informaci. Mobilní aplikace tak musí obsahovat seznam všech takovýchto obrázků. Těch navíc může být pouze 512 variací a při naskenování skutečného markeru se musí se všemi těmito obrázky porovnat. To je samozřejmě jak časově, tak paměťově náročné. V 12

27 1.3. Windows Phone (a) Návrh vzhledu markeru (b) Rozšířená realita budoucnu se dá očekávat, že se počet rozvěšených markerů rozšíří na několik set, ne-li tisíců. Je velmi nepraktické, aby si telefon uchovával seznam všech těchto značek v paměti. Další nevýhodou je fakt, že takováto podoba markeru studentovi, který není obeznámen s projektem, nic neřekne. Jelikož tato podoba nenese žádnou informaci, telefony bez nainstalované aplikace ČVUT Navigátor nemají možnost, jak takový obrázek dekódovat. Obsahuje sice adresu projektu, ale pro uživatele je nepohodlné ji přepisovat ručně a spíše ji bude ignorovat. Kohout ve své práci zmiňuje jednu podmínku pro grafický návrh markeru. Tou je černý rámeček, který celý marker ohraničuje. V aplikaci pro ios totiž používá pro vykreslování 3D objektů do prostoru na marker knihovnu, která má problémy se správným umístěním, pokud marker daný černý rámeček neobsahuje. 1.3 Windows Phone Operační systém Windows Phone se snaží být odpovědí od Microsoftu na stále rostoucí popularitu systémů ios od Apple a Android od Google. Jeho vytvořením Microsoft zcela opustil od vývoje tehdy populárního Windows Mobile, který ovšem nebyl optimalizovaný pro ovládání prsty. Změna to byla natolik radikální, že žádné starší aplikace na novém systému nefungovaly. Vše bylo potřeba vytvořit od nuly, na míru této platformě. V zadání mé bakalářské práce bylo specifikováno, že aplikace má být cílena na systém Windows Phone ve verzi 7. Od té doby vzniklo několik aktualizací systému (tou poslední je verze 7.8), mnohem zásadnější však bylo představení Windows Phone 8. Tato verze byla zásadním milníkem ve vývoji tohoto systému, jelikož opět došlo k částečnému restartu nová verze využívá jiné jádro a aplikace napsané pro ni nejsou zpětně kompatibilní. 13

28 1. Analýza Obrázek 1.4: Tržní podíl systémů WP7 a WP8 v únoru 2014 [2] Starší aplikace ovšem ve verzi 8 fungují. Co je také důležité zmínit je fakt, že starší telefony není možné na verzi 8 aktualizovat [9]. Při vývoji nových aplikací je tedy teoreticky možné cílit na starší verzi a aplikace bude automaticky fungovat také na verzi 8, nicméně pak není možné využívat některé novinky systému. Navíc takto aplikace běží v prostředí telefonu v emulátoru, čímž se stává pomalejší, než kdyby byla napsaná přímo pro novou verzi systému. Při výběru cílového systému, případně kombinací systémů, je tudíž vhodné analyzovat náročnost přenositelnosti kódu a výhodnost této práce. Důležité je také zastoupení jednotlivých verzí systému na trhu. To demonstruje graf 1.4. K 18. únoru měla tedy verze 7 téměř 20% zastoupení ze všech telefonů s Windows Phone. Jelikož se jedná o mrtvou platformu, kterou již Microsoft nebude dále podporovat, toto číslo bude do budoucna pouze klesat. Proto by bylo vhodné vytvořit klientskou aplikaci přímo pro verzi 8 a volitelně ji zachovat pro verzi Offline mapové podklady Jedním z hlavních nedostatků systému Windows Phone 7 byl fakt, že neexistoval žádný jednoduchý způsob, jak ukládat mapové podklady jednotlivých 14

29 1.3. Windows Phone budov do paměti telefonu, aby se při každém spuštění nemusely znovu stahovat ze serveru. Problém způsobila systémová komponenta pro vykreslování map, která pro zobrazení jiných map než těch z webu Bing 3, vyžadovala URL adresu, na které se tyto mapy nacházely. V systému Windows Phone se ale do vnitřního úložiště URL adresou odkázat nedá. Windows Phone 8 v tomto ohledu představují značný pokrok. Sice je stále pro zobrazení vlastních mapových podkladů vyžadována URL adresa, je ale již možné v telefonu spustit lokální webovou službu [10], která dokáže přijímat požadavky stejně, jako by to byl vzdálený server. Tímto způsobem je tedy teoreticky možné obelstít mapovou komponentu a donutit ji, aby zobrazovala mapy uložené v paměti telefonu Rozšířená realita Pro zcela funkční rozšířenou realitu, tak jak ji navrhl Tomáš Kohout ve své práci, je potřeba, aby systém umožňoval aplikacím dvě věci. První je zobrazení prostředí fotoaparátu přímo uvnitř aplikace. To v systému Windows Phone není problém. Každý element umístěný ve vizuálním stromě aplikace má vlastnost Background (pozadí), která lze nastavit na Brush (štetec). Kromě běžných štětců, které vykreslují jednu barvu nebo přechod mezi barvami, existuje také VideoBrush, který zobrazuje prostředí kamery. Druhou podmínkou pro plně funkční rozšířenou realitu je možnost vykreslování 3D modelů a jejich umístění na libovolné místo na displeji za použití různých transformací. To je důležité pro scénář, kdy je aplikace v navigačním módu a měla by uživateli zobrazit 3D šipky a další objekty pro snažší orientaci v prostoru. Tyto objekty by zároveň měly měnit svou pozici, velikost a natočení v závislosti na relativní pozici pozorovatele a jeho telefonu. Vykreslování 3D objektů se ve Windows Phone verzích 7 a 8 značně liší. Zatím co ve verzi 7 je podporován framework XNA, který je vhodný pro tvorbu her a podobných aplikací, ve verzi 8 již podporován není. Místo něj je nutné použít kombinaci nativního kódu a DirectX (v případě WP8 zvaný Direct3D). Popis této technologie značně přesahuje jak rozsah této práce, tak mé technické znalosti. Jelikož se jedná pouze o nekritickou a doplňkovou vlastnost klientské aplikace, rozhodl jsem se 3D vykreslování objektů dále nevěnovat

30 1. Analýza Windows Phone Store Jak jsem již popsal ve své bakalářské práci, aplikace pro platformu Windows Phone lze instalovat pouze z oficiálního obchodu Windows Phone Store. Jedná se o centrální databázi všech aplikací, podobnou těm ze systémů ios nebo Android. Pro vývojáře je podstatné, že k nahrání svých aplikací do tohoto obchodu je potřeba mít vývojářský účet. Ten je dle aktuálního ceníku 4 pro studenty zdarma, pro jednotlivce za 19 $ na rok a pro společnosti 99 $ na rok. V každém případě je potřeba ověřit identitu vývojáře zadáním čísla platné kreditní karty. Microsoft z ní pak strhne malou částku a v popisu této transakce bude také kód, který musí vývojář do systému přepsat. Tím dojde k ověření identity dotyčného. V případě společnosti je pro ověření identity potřeba ještě další krok, viz zmíněný odkaz. Při posílání aplikace má vývojář několik možností, jak ji zveřejnit. Nejběžnější možností je Publish, pak je aplikace dostupná každému a lze ji při vyhledávání v obchodě nalézt. Druhou možností je Publish, hide from search results, v takovém případě si aplikaci může stáhnout kdokoliv, kdo na ni má odkaz, ale nezobrazuje se ve výsledcích hledání v obchodě. Poslední možností je Publish beta, v tomto případě je nutné zadat seznam beta testerů, kteří si aplikaci budou moci stáhnout. Nikdo jiný k ní nebude mít přístup. Kromě nahrání samotné aplikace je potřeba před odesláním dodat několik dalších věcí: Název aplikace jedná se pouze o alias, přímo v obchodě se název vezme z aplikačního manifestu Cena může být nula nebo více, lze specifikovat různou cenu pro jednotlivé země Způsob zveřejnění popsáno výše Popis aplikace pro každý jazyk, který aplikace podporuje Logo aplikace obrázek 300 x 300 pixelů Minimálně jeden screenshot Při nahrání aplikace dojde ke statické kontrole. Při ní dochází ke kontrole aplikačního manifestu, přítomnosti obrázků dlaždice, nastavení správné výchozí jazykové mutace a dalších. Také zde dochází ke kontrole použití

31 1.3. Windows Phone zakázaného API v background agentovi pokud je aplikace spuštěna na pozadí, nesmí např. zobrazovat dialogy apod. Po úspěšném zaslání aplikace do obchodu ji nejprve musí Microsoft schválit, poté je do dvou hodin dostupná ke stažení. Při testování se tester Microsoftu zaměřuje na několik oblastí, kompletní seznam je na stránkách MSDN 5. Při zaslání aplikace jako beta k žádnému schvalování nedochází. V opačném případě trvá od několika hodin až po 5 pracovních dní. V minulosti schvalovací proces trval v průměru 4 až 5 dní, nicméně v posledních týdnech a měsících jej Microsoft značně urychlil a většinou je aplikace schválena do 24 hodin Windows 8.1 & Windows RT Vedle Windows Phone mohou být zajímavé také platformy Windows 8.1 a Windows RT. V těchto systémech se Microsoft inspiroval u svého mobilního operačního systému a představil zcela nové prostředí Modern UI (dříve známé jako Metro ). Toto prostředí se skládá z dlaždic a je pro něj možné vytvářet zcela nové, pro dotykové ovládání optimalizované, aplikace. Rozdíl mezi Windows 8.1 a RT je ten, že verze RT umí běžet na ARM procesorech a nepodporuje běh tradičních aplikací, vyjma těch dodaných přímo Microsoftem (např. Office). Windows Store (obdoba Windows Phone Store, oficiálního obchodu s aplikacemi) je tak jedinou možností, jak do systému nainstalovat další aplikace. Jelikož jsou oba systémy v jiných ohledech víceméně stejné, budu v budoucnu oba společně nazývat Windows 8.1, bez ztráty na obecnosti. Zmíněné nové prostředí běží na jádře WinRT (neplést s Windows RT), které je zčásti sdílené s WinPRT (jádro systému Windows Phone). O tom, kolik obsahují obě jádra společných částí, vypovídá obrázek 1.5. V současnosti z mých zkušeností vyplývá, že vytvořit aplikaci, která by měla pouze jeden kód pro Windows 8.1 i Windows Phone 8, je možné pouze z poloviny. Výkonný kód jako takový většinou není problém sdílet mezi oběma projekty, nicméně pro každou platformu je potřeba vytvořit zcela jiné uživatelské prostředí. Také některá specifická API, jako je geolokace nebo přepínaní mezi stavy aplikace, nejsou shodná. Proto se v současnosti v žádném případě nejedná o dvě aplikace za cenu jedné a je potřeba zvážit, zda se tvorba Windows 8.1 aplikace vyplatí. 5 hh184843%28v=vs.105%29.aspx 17

32 1. Analýza Obrázek 1.5: Shodné části systémů Windows Phone a Windows 8.1 [3] Windows Phone 8.1 V budoucnu Microsoft plánuje obě jádra (a všechny tři platformy) ještě více sblížit. To bude platit především pro novou verzi Windows Phone 8.1, která byla představena letos v dubnu na vývojářské konferenci Microsoft Build 6. Vzhledem k datu představení této verze jsem již nebyl schopen dopodrobna analyzovat představené změny, nicméně dle známých novinek je v této verzi konečně možné napsat jednu aplikaci, která bude fungovat jak na Windows Phone, tak na Windows 8.1. Důležité je především hlubší sjednocení systémů na úrovni jádra. Naprostá většina API z Windows 8.1 je tak v nezměněné podobně dostupná na Windows Phone 8.1. Velmi důležité je také sjednocení vizuálních komponent, je tedy možné vytvořit jeden vzhled aplikace pro obě platformy a

33 1.3. Windows Phone pouze upravit specifické části. Pro vývoj ve Windows Phone 8.1 je momentálně zapotřebí Visual Studio 2013 Update 2. V této aktualizace firma také představila novou šablonu Universal Windows App. Ta obsahuje tři projekty Windows 8.1, Windows Phone 8.1 a Shared. Do posledního jmenovaného lze umístit všechny sdílené části aplikace včetně jejich vzhledu, pokud to návrh aplikace umožňuje. Do zbývajících projektů se pak umístí pouze specifické části obou aplikací. Dobrou zprávou je, že aplikace napsané pro starší verzi systému budou nadále fungovat i v této aktualizaci, obráceně ale nikoliv. Zůstane tedy zachováno také stávající API a komponenty pro tvorbu grafického rozhraní. Aby bylo možné mezi staršími a novými projekty rozlišovat, Microsoft zavedl novou terminologii při pojmenovávání jednotlivých projektů. Windows Phone 8.1 Silverlight app aplikace využívající staré API z verze 8.0 Windows Phone 8.1 app aplikace využívající nové API, které je shodné s tím z Windows 8.1 Windows 8.1 app aplikace pro Windows 8.1 Windows Universal app šablona pro tvorbu Windows a Windows Phone aplikace Další důležitou novinkou verze 8.1 je vylepšená komponenta pro správu mapových podkladů [11]. Ta by měla již nativně podporovat jejich zobrazování z lokálního úložiště, neměly by tedy být potřeba různé berličky, které jsem musel použít při tvorbě aplikace pro verzi 8.0, viz Jak jsem již napsal výše, vzhledem k datu představení novinek jsem nebyl schopen provést důslednější analýzu. Jelikož tuto aktualizaci dostanou všechny stávající zařízení s verzí 8.0, případný pokračovatel této práce by se jí měl věnovat mnohem podrobněji a zvážit vytvoření Windows 8.1 aplikace za použití výše zmíněných nástrojů. 19

34

35 Kapitola 2 Návrh V této kapitole popíši návrh pro řešení jednotlivých požadavků zadání. Vycházet přitom budu především z poznatků, které jsem získal díky analýze v předchozí kapitole. Nejdůležitější částí návrhu je vyřešení napojení klientské aplikace na server, návrh řešení některých chybějících funkcí a celkové zprovoznění aplikace. 2.1 Napojení klientské aplikace na server Zprovoznění komunikace mezi mobilní aplikací a serverem je nejdůležitějším bodem zadání, bez kterého by celá aplikace postrádala smysl. Jak ovšem vyplynulo z analýzy, došlo v celé filozofii projektu k velkému posunu. Jednotliví klienti již nemají možnost získat všechna data jedním požadavkem, případně následujícími aktualizacemi, nýbrž se o ně mají dotazovat tak, jak to bude potřeba. Tento přístup zcela odporuje mému řešení, které vyplynulo z původního Čermákova řešení. Jak jsem také zmínil v analýze, ačkoliv jsou původní metody pro synchronizaci v protokolu zachovány, ve skutečnosti nejsou implementovány. K dispozici jsou tedy pouze metody z nového API. Na výběr jsou tedy dvě možnosti. První možností je aplikaci celou znovu navrhnout a od začátku předělat, aby plně využívala nové možnosti serveru. Tato metoda je pochopitelně velmi časově náročná, na druhou stranu má tu výhodu, že bude plně využívat všechny možnosti serveru a bude se chovat stejně jako aplikace pro ios. Druhou možností je zachovat stávající návrh aplikace a v implementaci komunikace se serverem původní řešení simulovat. Celá aplikace zůstane beze změny, pouze se vytvoří modul zprostředkovávající komunikaci se ser- 21

36 2. Návrh verem, který se bude navenek tvářit, že využívá metody dle původního návrhu. Ve skutečnosti ale bude používat nové metody. Vzhledem k časové náročnosti první možnosti jsem se rozhodl pro druhý způsob. Časová náročnost zároveň nebyla jediným důvodem pro toto rozhodnutí. První aplikace je nejen již napsaná, ale také částečně otestovaná a relativně funkční. Pokud bych ji měl celou od začátku přepsat, je velká pravděpodobnost, že bych ji nestihl před odevzdáním této práce vypustit mezi studenty. Z tohoto pohledu je dle mého názoru mnohem důležitější aplikaci dostat k uživatelům, aby ji začali používat a především aby se do celého projektu mohli zapojit například zasláním svého názoru na fungování nebo chybějící funkce Synchronizace Jak jsem již popsal výše, návrh synchronizace dat prošel velkou změnou. Nyní by měla probíhat tak, že aplikace si stáhne data až v okamžiku, kdy si je uživatel vyžádá. Při dalším požadavku na tato data se pak uživateli zobrazí již jejich uložená verze, ale zároveň se aplikace serveru zeptá, zda nedošlo k jejich změně a případně je opět stáhne a jejich lokální kopii aktualizuje. Pro podporu tohoto chování je součástí každého požadavku hlavička If-Modified-Since [12], která obsahuje časovou značku určující okamžik poslední synchronizace. Pokud od tohoto okamžiku došlo na serveru ke změně požadovaných dat, jsou klientské aplikaci vrácena. Pokud ne, vrátí server status 304 Not-Modified. V současnosti ovšem server s hlavičkou If-Modified-Since neumí pracovat, vrací tedy data pokaždé, a to i když k jejich změně nedošlo. To může mít velký dopad jak na celkové vytížení serveru, který je nucen neustále klientským aplikacím vracet stále ta samá data, ale také na uživatele, který může mít datový limit. Na této funkci nicméně v současnosti pracuje Jan Mráček v rámci své bakalářské práce [13] a měla by být v brzké době zprovozněna. Bohužel toto není jediná vlastnost serveru, která limituje tento způsob synchronizace dat. Jak popisuji v sekci 3.3.3, server negarantuje neměnnost identifikátorů jednotlivých položek. Je tedy dobře možné, že při první synchronizaci bude mít některá místnost ID = 133, při další synchronizaci pak úplně jiné. Tato změna navíc nejde nijak detekovat. Pokud se místnost se starým ID smaže, rozbije to návaznost ostatních položek na ni (např. položky v rozvrhu). Pokud se nesmaže, bude v aplikaci dvakrát. 22

37 2.2. Offline mapové podklady Posledním nedostatkem, který značně komplikuje navržený způsob synchronizace dat, je nemožnost vyhledávat na serveru. Pokud by tedy skutečně došlo k implementaci stávajícího návrhu, aplikace by si stáhla pouze nezbytná data. Pokud by si uživatel chtěl najít, kde se nachází místnost, kterou aplikace nemá staženou, měl by jednoduše smůlu. Kvůli výše zmíněným nedostatkům serveru jsem se rozhodl zachovat pouze jednorázový způsob synchronizace. Při prvním spuštění dojde ke kompletnímu stažení všech dat a následující fungování aplikace (s výjimkou markerů a vyhledávání tras) je již pouze offline. Uživatel pak může v nastavení kdykoliv provést synchronizaci znovu a získat tak aktuální data. 2.2 Offline mapové podklady Jak vyplynulo v analýze, ve Windows Phone 8 je možné docílit toho, aby se mapové podklady (v následujícím textu mám výrazem mapové podklady na mysli mapové podklady budov ČVUT ) načítaly z paměti telefonu. Otázkou tak již pouze zůstává, kdy je tam uložit. Na výběr jsou tři možnosti, které zmíním níže Distribuce aplikace s veškerými mapovými podklady Teoreticky je možné aplikaci k uživatelům distribuovat s již předinstalovanými podklady. Toto řešení má tu výhodu, že se uživatel nemusí zabývat jejich ručním stahováním a zároveň nedochází k plýtvání jeho datového tarifu, pokud není připojen k wifi síti. Problémem ovšem je fakt, že zatím nejsou zmapovány všechny budovy ČVUT. Jakmile by v budoucnu některé budovy byly přidány, bylo by potřeba vyřešit, jak uživatelům nabídnout možnost, aby si mapové podklady mohli aktualizovat. Nezanedbatelným faktem je také výsledná velikost celé aplikace Ruční stažení uživatelem Další možností je aplikaci distribuovat bez mapových podkladů, ale dát uživateli možnost si je dodatečně stáhnout k požadovaným budovám. To má několik výhod - malou velikost celkové aplikace, uživatel si stáhne pouze ty budovy, ve kterých se vyskytuje, a také je možné podklady k některým budovám dodělat dodatečně. Nevýhodou je však právě nutnost si podklady stáhnout ručně - je to krok navíc, který musí uživatel učinit a který by ho 23

38 2. Návrh zbytečně zdržoval. Také by se tomu muselo přizpůsobit uživatelské rozhraní aplikace Automatické stahování při jejich zobrazení Poslední variantou offline mapových podkladů je nijak neměnit uživatelské rozhraní aplikace a nadále stahovat podklady z webového serveru Navigátora. Teprve v okamžiku jejich prvotního stažení se uloží do paměti telefonu. V momentě, kdy k nim uživatel přistoupí podruhé, se již nebudou znovu stahovat, ale zobrazí se z lokálního úložiště. Toto řešení je ze všech nejjednodušší na implementaci a zároveň uživatelsky nejpřívětivější. Není potřeba, aby uživatel musel něco ručně stahovat, vše je automatické. Jedinou možnou nevýhodou je, že uživatel nemá zcela pod kontrolou, kdy ke stahování map dochází. Pokud tedy zrovna není připojen k wifi síti, může dojít k vyčerpání jeho limitu v rámci datového tarifu. Jelikož je však celý areál ČVUT pokryt bezdrátovou wifi sítí Eduroam, je toto riziko relativně malé Závěr Pro zpřístupnění mapových podkladů v offline režimu jsem se rozhodl pro poslední řešení, které je nejjednodušší na implementaci a uživatelsky nejpřívětivější. Vzhledem k tomu, že uvedné řešení není možné implementovat v aplikaci pro Windows Phone 7, bude dostupné pouze pro verzi 8, starší verze zůstane beze změn a bude mapové podklady stahovat z webového serveru při každém zobrazení. Toto rozdělení mezi jednotlivými verzemi je naštěstí velmi jednoduché, viz Vývoj pro více platforem. 2.3 Další body zájmu Rozšíření bodů zájmu je díky dobrému původnímu návrhu jednoduché. Původní seznam je potřeba rozšířit o následující položky: 24 Toalety Jídelny Šatny Studovny Kanceláře

39 2.4. Rozšířená realita (a) Mapa podlaží (b) Informace o vybraném bodě Spolu s tímto rozšířením jsem ke každému typu položky přidal odpovídající obrázek, který se na mapě zobrazí 7. Aby byl celkový vzhled jednotný, rozhodl jsem se přidat podobný obrázek také pro zobrazení budov ČVUT na venkovní mapě. Textový popis (např. název místnosti) se zobrazí po kliknutí na danou položku. 2.4 Rozšířená realita Markery Základem rozšířené reality jsou vhodně zvolené markery. Jak jsem již v analýze nastínil, jejich původní podoba, kterou zvolil Tomáš Kohout v rámci své bakalářské práce, není úplně vhodná pro reálný provoz. Proto jsem se rozhodl navrhnout jiné řešení. Celá myšlenka zůstává stejná, pouze se změní jejich vzhled a jejich identifikace. 7 Maps Icons Collection

40 2. Návrh Obrázek 2.1: Ukázka vzhledu QR kódu Základní podmínkou je, aby markery byly strojově čitelné a bylo možné do nich umístit libovolnou, byť velikostně omezenou informaci. Další podmínkou je, aby takový marker byl všeobecně znám a dnešní telefony jej dokázaly strojově přečíst. Z těchto podmínek vyplývá jako nejvhodnější kandidát QR kód, což je dvourozměrný čárový kód. Popis struktury QR kódu je nad rámec této práce, důležité však je, že splňuje všechny výše zmíněné podmínky. Jak QR kód může vypadat je vidět na obrázku 2.1. Důležité je také zvolit, jakou informaci budou QR kódy obsahovat. Hlavní informací je v tomto případě identifikátor konkrétního markeru. Uživatel v aplikaci daný QR kód naskenuje, ta pošle dotaz na webový server a dostane více informací o daném markeru, včetně jeho souřadnic, informací o budově a konkrétním patře. Na základě toho si pak může uživatel zobrazit svou pozici na mapě. V tomto scénáři funguje tato možnost dobře. Nicméně je třeba počítat také s uživateli, kteří nemají aplikaci ČVUT Navigátor nainstalovanou a daný QR kód si naskenují pouze vestavěnou aplikací. Ta by zobrazila pouze nic neříkající číselný identifikátor. Proto by bylo lepší, kdyby obsažená informace byla WWW adresa na web projektu a identifikátor markeru by byl obsažen pouze jako parametr. Pokud si uživatel naskenuje tento kód pouze vestavěnou aplikací, je přesměrován na web projektu, kde může být jeho stručný popis a odkazy pro stažení mobilních klientů. Pokud si jej naskenuje aplikací ČVUT Navigátor, ta dokáže z dané adresy vyextrahovat potřebný identifikátor markeru a dále s ním pracovat. 26

41 2.4. Rozšířená realita Navrhuji proto, že by tato adresa mohla vypadat takto: Důležité jsou v ní dvě části prefix m., který udává, že se má zobrazit verze webu upravená pro mobilní telefony, a parametr markerid. Ten je aplikací ČVUT Navigátor rozpoznán a extrahován, mobilní verze webu jej může ignorovat, nebo může také zobrazit další informace o poloze. Důležité ovšem je, aby na webu byly umístěny odkazy ke stažení mobilních klientů. To už je ovšem mimo rozsah této práce. Při vylepování těchto markerů po budovách ČVUT by jejich součástí kromě samotného QR kódu mohlo být také logo celého projektu, případě psaný odkaz na jeho webové stránky. V současnosti projekt své logo nemá, to by mohlo vzejít např. ze studentské soutěže, případě z některého předmětu vyučovaného na fakultě. Jelikož grafika není obor mně blízký, na doporučení Jiřího Chludila jsem požádal kolegu studenta Vadima Petrova o vytvoření prototypu takového markeru, který by splňoval všechny zmíněné požadavky. Jeho návrh můžete vidět na obrázku 2.2. Tento návrh lze použít jako referenční řešení v případě soutěže, případně se může lehce upravit a použít rovnou Vykreslování objektů Jak jsem již popsal v analýze, vykreslování 3D objektů ve Windows Phone aplikaci není úplně triviální záležitost. Proto jsem se rozhodl přistoupit k rozšířené realitě poněkud odlišně, než jak učinil Tomáš Kohout ve své aplikaci pro ios. Místo vykreslování šipky do prostředí kamery v době, kdy aplikace uživatele naviguje do cílové lokace, bude po naskenování markeru vykreslovat seznam okolních místností a dalších bodů zájmu. Po naskenování markeru se určí, na jakých souřadnicích a na jakém patře se uživatel nachází. Podle těchto údajů aplikace načte seznam okolních bodů zájmu a podle aktuální polohy telefonu je zobrazí. Jak bude uživatel telefonem natáčet, bude se měnit seznam vykreslených bodů. Tato funkce vyžaduje přístup k senzorům telefonu, které dokážou určit směr natočení telefonu v prostoru. V praxi telefon dokáže sledovat pouze natočení telefonu, nedokáže však sledovat pohyb uživatele. Využití této implementace rozšířené reality má tedy svá omezení, jakmile se uživatel začne pohybovat, zobrazované informace přestanou dávat smysl, jelikož si telefon stále bude myslet, že se nachází v blízkosti markeru. I tak si ovšem myslím, že se jedná o zajímavou funkci, jejíž implementace by neměla být náročná. 27

42 2. Návrh Obrázek 2.2: Návrh vzhledu markeru, který vytvořil Vadim Petrov Na obrázcích 2.3a a 2.3b lze vidět návrh uživatelského rozhraní rozšířené reality. Dominuje mu prostředí kamery, spolu s ním obsahuje také krátký popisek pro uživatele. V okamžiku, kdy aplikace detekuje platný marker, se povolí tlačítko pro zobrazení pozice na 2D mapě. 2.5 Zpětná vazba Zpětná vazba je úplnou novinkou a zajímavým rozšířením celého projektu. Jak jsem popsal v rozboru zadání, mělo by se jednat o schopnost aplikace sledovat pohyb uživatele v prostorách školy a zasílat tyto údaje na server. Ten díky těmto informacím dokáže vyhodnotit, ve kterých časových intervalech se na chodbách a ve výtazích vyskytuje nejvíce studentů. Pomocí 28

43 2.5. Zpětná vazba Obrázek 2.3: Rozšířená realita této analýzy pak dokáže vyhodnotit, zda je pro uživatele výhodnější počkat na výtah, nebo jít po schodech. Na straně serveru má tuto funkcionalitu na starost Daniel Kucbel v rámci své bakalářské práce [14]. Pro implementaci zasílání pohybu studentů po prostorách ČVUT bylo potřeba rozšířit komunikační API. Byla navržena následující služba, která slouží pro sběr dat: Metoda: POST URI: /watch/<nodeid> Tělo: Odpověď: Možné HTTP kódy odpovědí: 200 OK 401 Nedostatečná oprávnění k vykonání této akce Je potřeba podotknout, že sledování uživatele bude probíhat pouze uvnitř 29

44 2. Návrh budovy, proto je jako parametr specifikován NodeId, který udává, v jaké budově, patře a konkrétní pozici se uživatel nachází. Zajímavější je ovšem řešení na straně klientské aplikace. Jelikož GPS signál nemá dostatečnou sílu, aby pronikl do budovy, není možné uživatele sledovat v reálném čase. Je proto potřeba vymyslet jiný způsob, jak zjistit jeho aktuální polohu. Možných řešení je několik Sledování pomocí markerů Nejpřesnější je bezpochyby detekce pozice uživatele díky rozšířené realitě. V okamžiku, kdy si uživatel fotoaparátem naskenuje marker, aplikace okamžitě pozná, kde se nachází. V tomto momentě tedy lze na server odeslat jeho aktuální pozici. Je třeba podotknout, že není možné spoléhat pouze na službu pro získání informací o markeru na základě jeho identifikátoru. Teoreticky by bylo v tomto okamžiku možné, aby služba automaticky studentovu pozici zaznamenala, má to ale přinejmenším dva háčky. Tím prvním je fakt, že student může mít v nastavení sledování své pozice zakázáno. Druhým háčkem je pak možné kešování informací o jednotlivých markerech v klientské aplikaci při druhém skenování stejného markeru se již nedotazuje na server, ale použije informace uložené lokálně v paměti Sledování při navigaci Druhým způsobem sledování uživatele je sledování v režimu navigace. To je možné díky tomu, že celá cesta je rozdělena na několik úseků. Vnější úsek nás v tomto případě nezajímá, uživatele sledujeme pouze uvnitř budov. Zde je každé patro, přes které musí uživatel projít, bráno jako samostatný úsek. A právě toho lze využít. V okamžiku, kdy se uživatel v aplikaci přepne do dalšího úseku, lze totiž určit jeho stávající pozici. Data získaná tímto způsobem lze ovšem brát pouze s rezervou, nelze se na ně totiž zcela spolehnout. Často se může stát, že se uživatel chce pouze podívat, kudy musí jít, rychle si zobrazí všechny úseky cesty a poté aplikaci vypne. V takovém případě nemají shromážděná data žádnou vypovídající hodnotu. Proto je potřeba trochu upravit UI aplikace při navigaci. Rozhodl jsem se přidat nové tlačítko Jsem zde, které bude vedle tlačítka Přejít do další části, viz obrázek 2.4. Bude tak již pouze na uživateli, zda takto bude svoji polohu hlásit, či nikoliv. I tak je ale potřeba takto získaná data brát s rezervou, jelikož je možné, že budou uživatelé svou polohu hlásit nepravdivě. 30

45 2.5. Zpětná vazba Obrázek 2.4: Změny UI pro sledování polohy uživatele Soukromí uživatele Pozice uživatele v daném čase je samozřejmě citlivý údaj. Je proto potřeba, aby uživatel mohl své sdílení polohy vypnout. Tuto možnost lze umístit např. do nastavení. Aby ale tato funkce získávala co nejvíce údajů, bude standardně zapnuta s tím, že uživatel bude na tuto skutečnost při prvním spuštění upozorněn. Veškerá zaslaná data serveru budou navíc anonymní. Nebude se tedy posílat uživatelské jméno, ani žádný jeho identifikátor. Jediná informace o uživateli, která se zasílá, je jeho access token. Zasílání tohoto tokenu je naprosto nezbytné, jinak by bylo možné, aby kdokoliv začal server zaplavovat nesmyslnými hlášeními a data tak přišla o svůj význam. Je sice stále možné, že si server bude pamatovat všechny vydané tokeny a dokáže je spárovat s konkrétním uživatelem, to už je ale věc, kterou klientská aplikace nedokáže nijak ovlivnit. 31

46 2. Návrh 2.6 Hlášení chyb Pro budoucí rozvoj celého projektu je naprosto nezbytná spolupráce jeho autorů a uživatelů. Pro vkládání nových mapových podkladů a položek vznikla webová aplikace 8, díky které může kdokoliv z akademické obce ČVUT navrhovat změny existujících plánů. Tyto návrhy zkontroluje administrátor a případně je schválí. Jedná se tak o skvělý způsob, jak do procesu vzniku mapových podkladů a dalších bodů zapojit samotné uživatele. Tato webové aplikace sama o sobě ale není dostatečná, neumožňuje totiž uživatelům hlásit návrhy na vylepšení přímo z terénu. Je navržena tak, aby se dobře ovládala u běžného počítače, případně tabletu. Nicméně nepokrývá situaci, kdy je uživatel ve škole a v mobilní aplikaci si všimne, že v systému chybí nějaká místnost, je špatně označená nebo špatně umístěná. V takovém případě by musel spustit webový prohlížeč, přihlásit se, vybrat budovu, ve které se nachází, vybrat patro a navrhnout změnu. Tento proces je přípustný u běžného počítače, ale na mobilu by každého odradil. Proto jsme se v týmu rozhodli do protokolu zabudovat 2 nové služby pro zasílání chyb a návrhů na vylepšení. Jejich popis následuje: Metoda: POST URI: /maps/feedback Tělo: <feedback> Odpověď: - Možné HTTP kódy odpovědí: 200 OK 401 Nedostatečná oprávnění k vykonání této akce feedback { coordinates : <coordinates>, building : <integer>, floor : <integer>, message : <string> } building Udává id budovy, ke které se hlášení vztahuje floor Číslo podlaží coordinates Stuktura obsahující GPS souřadnice 8 navigator.fit.cvut.cz/maps 32

47 2.6. Hlášení chyb message Zpráva uživatele Tato služba slouží k navržení nového bodu na mapě. Pomocí atributů lze specifikovat konkrétní umístění tohoto uzlu, v atributu message pak může uživatel svůj návrh přesněji specifikovat. Metoda: POST URI: /maps/feedback/<nodeid> Tělo: <feedbacknode> Odpověď: - Možné HTTP kódy odpovědí: 200 OK 400 Špatně zadaný parametr nodeid uzel s daným Id neexistuje 401 Nedostatečná oprávnění k vykonání této akce feedbacknode { message : <string>, type : <string> } message Volitelná zpráva uživatele nodeid Id uzlu, ke kterému se chyba vztahuje type Řetězec, který může nabývat hodnot misnamed, misplaced, remove nebo other Tato služba slouží k zaslání opravného návrhu pro existující uzel, případně návrhu na jeho vymazání. Prozatím jsou možné tři typy návrhů, špatně pojmenovaný, špatně umístěný a jiné. Stejně jako v předchozím případě pomocí atributu message může uživatel svůj návrh blíže specifikovat. V případě mobilní aplikace je potřeba vymyslet pro uživatele co nejjednodušší uživatelské rozhraní. Bylo by určitě možné nabídku pro zaslání chyby schovat do menu, ale tam je riziko, že ji uživatel nenajde. Místo toho jsem se rozhodl, že v případě existujícího uzlu se možnost pro zaslání chyby zobrazí vedle existující možnosti navigovat sem, viz obrázek 2.5a. V případě návrhu vytvoření zcela nového uzlu pak stačí poklepat kdekoliv na mapě. 33

48 2. Návrh (a) Informace o daném bodě (b) Dialog pro zaslání chyby Obě zmíněné možnosti jsou dostupné pouze při prohlížení vnitřního plánu budovy, u venkovní mapy se nezobrazují. Při potvrzení se zobrazí jednoduchý dialog, kde může uživatel specifikovat druh chyb, dopsat vlastní zprávu a odeslat ji. 2.7 Shrnutí návrhu Z celkového seznamu změn je vidět, že je potřeba původní návrh aplikace značně rozšířit, a to jak v uživatelském rozhraní, tak v aplikačním kódu. Důležitou částí celé aplikace je samotná komunikace se serverem. Již ve své bakalářské práci jsem samotnou implementaci schoval za rozhraní INetService. Díky tomu zbytek aplikace netušil, zda se data získávají skutečně z webového serveru nebo jsou uložena pouze lokálně. Spolu s novými funkcemi je tedy potřeba toto rozhraní doplnit. Jak lze vidět z diagramu 2.5, rozhraní INetService implementují dvě třídy - FakeNetService a OnlineClient. Již z názvu lze poznat, že FakeNet- Service poskytuje pouze statická data, kdežto OnlineClient komunikuje s 34

49 2.7. Shrnutí návrhu Obrázek 2.5: Class diagram pro schování implementace za rozhraní webovým serverem. Na jednu stranu udržování obou těchto tříd znamená více práce, na druhou stranu falešná implementace má tu výhodu, že lze použít v návrhu vzhledu aplikace. Visual Studio totiž obsahuje grafický editor, který automaticky vytváří instance závislých tříd a vyplňuje textová pole, seznamy a další položky daty, která z nich získá. Zároveň ale obsahuje několik omezení, aby v době grafického návrhu (kdy samotná aplikace něbeží) nemohlo dojít k odeslání HTTP požadavku. Pokud by v době návrhu byla nastavena závislost na třídu OnlineClient, nezobrazila by se žádná data, jelikož by připojení k webovému serveru selhalo. Proto je v době návrhu použita třída FakeNet- Service, která obsahuje statická data, která jsou pro tvorbu vzhledu aplikace zcela dostatečná. O vytváření závislostí se stará třída ViewModelLocator. 35

50

51 Kapitola 3 Implementace V této části se zaměřím na specifické detaily implementace. Nebudu již do detailu rozebírat všechny použité knihovny a postupy, to jsem již sepsal ve své bakalářské práci. Spíše se zaměřím na nově použité knihovny, provedené implementační změny a způsoby, kterými jsem docílil vytvoření projektů cílených na specifické platformy (WP7, WP8). V závěru této kapitoly se pak zmíním o problémech, kterým jsem při implementaci čelil, a jejich řešení. 3.1 Vývoj pro více platforem Jak jsem již zmínil výše, ve výsledku vzniknou 2 aplikace pro Windows Phone 7 a 8. Každá z těchto aplikací má v rámci hlavního projektu (solution) svůj vlastní podprojekt (project). Aby nedocházelo k duplikování kódu, je možné do druhého projektu zdrojové soubory přidat jako odkazy. To samé platí pro obrázky a další zdrojové soubory. Jiná situace je u třídy BuildingTileSource. Jak jsem naznačil v návrhu, verze pro WP7 bude nadále používat implementaci, která mapové podklady nekešuje, implementace pro WP8 je kešovat bude. Zde jsou na výběr dvě možnosti. První možností je do zdrojových kódů umístit instrukce podmíněného překladu (#if a #endif), které fungují stejně jako v jazyce C++, nebo do druhého projektu umístit vlastní soubor s implementací této třídy. Instrukce pro podmíněný překlad je vhodné používat, pokud je většina kódu v dané třídě shodná pro obě platformy, pokud je celá implementace v obou případech zcela rozdílná, vyplatí se použít zcela nový soubor s vlastní implementací. Z tohoto důvodu jsem vybral druhou možnost. 37

52 3. Implementace 3.2 Použité knihovny Reactive Extensions Při tvorbě aplikace jsem se ve své bakalářské práci rozhodl použít knihovnu Reactive Extensions 9. Jejím hlavním přínosem byl velmi jednoduchý a jednotný přístup k datům, zároveň výrazně zjednodušila asynchronní programování. Použita byla především pro vyhledávání tras, a to jak venkovních, tak uvnitř budov. Základní práce s touto knihovnou spočívá v použití rozhraní IObservable<T> jako návratové hodnoty všech volání. Toto rozhraní obsahuje metodu Subscribe(), pomocí níž lze zažádat o data daného typu a tato data začnou k volajícímu proudit. Výhoda tohoto přístupu je, že se volající nemusí aktivně o data dotazovat, pouze voláním řekne, že o ně má zájem a co se s nimi má stát, když dorazí. To má výrazný dopad pro celou aplikaci - nestane se, že by aktivní čekání na data způsobilo její vytížení a zamrznutí uživatelského prostředí. Nevýhodou této knihovny je její přílišná robustnost, nároky na paměť a malá integrace do zbytku systému. Spolu s jazykem C# 5.0 Microsoft představil 2 nová klíčová slova - async a await 10. Pomocí nich Microsoft poskytl programátorům velmi jednoduchý a přímočarý způsob, jak psát asynchronní aplikace. Tradičně, pokud chce programátor asynchronně zavolat metodu, musí specifikovat callback funkci, která se zavolá v okamžiku, kdy asynchronní operace doběhne. To s sebou nese několik problémů. Pokud je těchto volání více, stává se kód značně nepřehledným. Také dojde ke ztracení stacku, a tedy lokálních proměnných, které se v případě potřeby musí složitě předávat callback funkci. Pomocí klíčových slov async a await vše toto odpadá. Kód se tváří, jako by byl synchronní, ale ve skutečnosti není. Vlastnosti těchto klíčových slov a způsob jejich použití demonstruje následující ukázka. async Task<string> GetString() { var address = GenerateAddress(); var request = new HttpRequest(address); var result = await request.downloadstringasync(); return result; }

53 3.2. Použité knihovny Každá metoda, která obsahuje klíčové slovo await, musí být označena jako async. Dále musí vracet Task<T>, kde T je požadovaný návratový datový typ. Volání metody GenerateAddress() se provede tak, jak každý očekává, zajímavější je volání DownloadStringAsync(). Jelikož je označeno klíčovým slovem await, tak na tomto řádku dojde k opuštění celé metody GetString() zpět k volajícímu. Vykonávání těla této metody tedy skončí, proto není blokováno vlákno, ve kterém došlo k jejímu zavolání. V okamžiku dokončení metody DownloadStringAsync() vykonávání skočí zpět na tento řádek a pokračuje se dále. Toto chování lze použít při mnoha příležitostech. Praktický příklad užití jsou vlastní dialogy. Ty lze zobrazit pouze na UI vlákně, zároveň ale toto volání nesmí být blokující. Pokud tedy chci získat návratovou hodnotu zobrazení dialogu (zda jej uživatel potvrdil nebo ne), musel bych mu složitě předat callback funkci, kterou by dialog zavolal po svém zavření. Díky async a await mohu napsat následující: var result = await dialog.showasync("message"); if (result) {... } Samotná implementace dialogu je také jednoduchá: public Task<bool> ShowAsync(string message) { this.show(); this.tasksource = new TaskCompletionSource(); return this.tasksource.task; } private void ButtonOkTap(object sender) { this.tasksource.setresult(true); } private void ButtonCancelTap(object sender) { this.tasksource.setresult(false); } Třída TaskCompletionSource zjednodušuje použití třídy Task<T>. V okamžiku, kdy uživatel stiskne tlačítko OK, tak nastaví výsledek na hodnotu true, čímž se vykonávání vrátí k volajícímu, který použil await. Analogicky je to v případě tlačítka Storno. 39

54 3. Implementace Daná klíčová slova jsou standardně dostupná pro Windows Phone 8, Microsoft nicméně vydal knihovnu BCL Async 11, díky níž je možné je použít také na starší verzi systému. Instalace je velmi jednoduchá díky balíčkovacímu systému Nuget, který je dostupný ve Visual Studiu. Proto jsem se rozhodl opustit Reactive Extensions a začít využívat právě async/await. Jedním z důvodů je také fakt, že je celé Windows Phone SDK ve velké míře využívá, jedná se tedy dle mého o dobrou investici do budoucna. Implementačně byla tato změna navíc relativně jednoduchá Json.NET Nová knihovna, kterou jsem do projektu zařadil, se jmenuje Json.NET 12. Jedná se o velice rychlou a výkonnou knihovnu pro serializaci a deserializaci objektů do formátu json. Její použití je velice jednoduché, pro serializaci se používá metoda JsonConvert.Serialize<T>(T object) a deserializaci JsonConvert.Deserialize<T>(string json). Pomocí speciálních atributů se dá i specifikovat, jak se mají jednotlivé členské proměnné. To se hodí především z toho důvodu, že v jazyce C# je zvykem tyto proměnné pojmenovávat s velkým počátečním písmenem, kdežto ve specifikaci jsou s malým ZXing ZXing 13 je knihovna pro dekódování čárových, QR a dalších kódů. Její použití bylo bezproblémové, hlavní byla třída BarcodeReader a její metoda Decode(), do které se vyšle výstup z fotoaparátu. Pokud detekuje QR kód, jsou informace o něm předány dál. Jelikož knihovna dokáže rozpoznat několik formátů, lze specifikovat, že má hledat pouze QR kódy, což je drobná optimalizace GART Geo AR Toolkit, zkráceně GART 14, je knihovna pro práci s rozšířenou realitou. Její použití bylo jednoduché, základní třídou je ARDisplay, což je kontejner pro ostatní třídy. Na výběr je jich několik, nicméně já použil pouze jednu WorldView. Ta dokáže správně vykreslit do prostoru objekty, které jsou dány svými GPS souřadnicemi

55 3.3. Řešené problémy Tato knihovna je dostupná jak pro WP7, tak WP8. Problém ovšem je, že výsledná assembly se jmenuje pro každý systém jinak (GART.dll, resp. GART.WP8.dll). Z tohoto důvodu nelze mít obrazovku rozšířené reality sdílenou pro oba systémy, ale musí existovat pro každý z nich vlastní verze. Ty jsou zcela identické, liší se pouze v názvu použité assembly. 3.3 Řešené problémy Během vývoje aplikace a jejího napojování na server jsem musel řešit několik problémů. Nemá smysl popisovat všechny, pokusím se pouze vypíchnout ty, které by mohly pomoci případným pokračovatelům tohoto projektu Data neodpovídající dokumentaci Při implementaci komunikačního API s webovou službou jsem z větší části vycházel z diplomové práce Zdeňka Pecky, resp. z její první přílohy, která obsahuje seznam všech webových služeb a datových typů. Existuje také tzv. mock server, který běží na adrese poskytuje pouze statická data a lze oproti němu API testovat. Problém je v tom, že tento server vrací odpovědi, které často neodpovídají Peckově specifikaci. Jeden příklad za všechny dle specifikace by struktura TimetableEntry měla (mimo jiné) obsahovat položku Day, která bude nabývat hodnot 0 7. Mock server vrací hodnotu Monday. Je proto lepší od začátku vyvíjet přímo proti ostrému serveru. Nicméně ani ten přesně neodpovídá specifikaci. Např. položka type ve struktuře TimetableEntry by měla pro cvičení nabývat practice, ve skutečnosti server vrací hodnotu tutorial. Dále některé API není na serveru implementované, ačkoliv je zdokumentované. Např. GET /search vrací HTTP chybu 500. Se všemi těmito nedokonalostmi se dá vypořádat, nicméně by bylo vhodné vytvořit jednotnou dokumentaci, která bude pokud možno dostupná online všem členům týmu a bude průběžně aktualizována. S rostoucím množstvím funkcí, které server nabízí, je zcela neudržitelné, aby každý nový člen týmu musel na aktuální specifikaci přijít metodou pokus omyl Nekompletní data Při prvotním vývoji aplikace jsem, poněkud naivně, spoléhal na kompletnost a celistvost poskytnutých dat ze strany serveru. V kódu tak nebylo ošetřeno 41

56 3. Implementace mnoho scénářů z reálného provozu. Většina těchto případů se dá zařadit do jedné kategorie chybějící data. Nepočítal jsem např. s tím, že by existoval záznam v rozvrhu, který nebude mít přiřazenou místnost. Dále nebyl ošetřen případ, kdy budova nemá zmapované patro, na kterém se nachází vstup. Při vyhledávání trasy z venkovní pozice k určité místnosti se totiž musí projít přes nejbližší vstup. Pokud tento vstup neexistuje (což by sice při uvedení do reálného provozu nemělo nastat, nicméně momentálně takto situace vypadá v případě budovy T7), aplikace spadla. Podobných scénářů bych mohl vyjmenovat ještě několik, hlavní ponaučení zde však je, že všechna data získaná z webové služby musí projít důslednou validací, protože se nedá spoléhat na jejich kompletnost Měnící se identifikátory uzlů Závažnou chybou, která byla bohužel odhalena až při uživatelském testování, které je popsané v kapitole 4.2.2, jsou měnící se identifikátory uzlů na straně serveru. Pokaždé, když v mapové aplikaci dojde ke změně uzlu (ať už jeho pozice nebo popisu), změní se také jeho identifikátor. Popsané chování má závažný dopad na integritu dat v klientské aplikaci, jelikož tato změna nelze nijak rozpoznat. Dojde tak např. ke ztrátě provázanosti mezi položkami v rozvrhu a danou místností. Co je ovšem ještě horší, je skutečnost, že při dotazu na seznam uzlů v dané budově je vrácena množina, která obsahuje neplatné identifikátory. Například při dotazu na všechny uzly v Nové budově je ve výsledcích zahrnuta místnost T9:348 s ID = 133. Nicméně při zaslání dotazu na uzel s tímto identifikátorem vrací server chybu 404 nenalezeno. Při dotazu na uživatelův rozvrh každá položka obsahuje celou strukturu uzlu (místnosti), kde se daná přednáška nebo cvičení koná. Jejich identifikátor neodpovídá tomu ze seznamu všech uzlů pro danou budovu (tedy např. místnost T9:348 má ID = 768). To také způsobilo pády klientské aplikace, díky testování byla chyba objevena a opravena. Před ostrým nasazením do provozu je ovšem toto chování na serveru potřeba opravit Problémy s certifikátem Jak jsem zmínil v Analýze, platforma Windows Phone obsahuje nečekanou nepříjemnost při zabezpečené komunikaci se serverem, kde je nainstalovaný SSL certifikát, který byl vydán certifikační autoritou, kterou telefon nezná. 42

57 3.3. Řešené problémy V takovém případě totiž systém spojení odmítne a vrátí HTTP chybu 404 (Not Found), což je značně matoucí. Dvě možná řešení jsem již nastínil. V týmu jsme rozhodli, že na server umístíme stejný certifikát, který se používá na zbytku fakulty. Ten je vydán společností TERENA 15, kterou Windows Phone uznává jako certifikační autoritu. Po nahrání na server telefon okamžitě začal povolovat všechny HTTPS požadavky a problém byl vyřešen. Certifikát má platnost do roku 2017, z týmu Navigátora jej má na starost vedoucí Ing. Jiří Chludil

58

59 Kapitola 4 Testování Testování je nezbytnou, ačkoliv velmi často opomíjenou součástí vývoje software. V rámci této práce rozdělím testování na strojové a uživatelské. V rámci strojového testování je naším cílem eliminovat co nejvíce chyb ve zdrojovém kódu a v integraci jednotlivých částí projektu. V uživatelském testování, jak již název napovídá, je hlavním bodem zájmu uživatelská přívětivost. Tato kapitola je rozdělena do dvou částí, které reflektují zadání celé práce. V první rozeberu testování komunikace se serverem, což je ryze strojový test. V druhé části se pak budu zabývat uživatelským testováním. Je potřeba podotknout, že otestována aplikace již byla v rámci mé bakalářské práce. V ní proběhlo opět ve dvou částech. Otestování existující podmnožiny zdrojových kódu proběhlo pomocí unit testů. Ty jsou samozřejmě zachovány a snaží se zaručit správnost pokrytých částí kódu. Pokud tedy v budoucnu dojde k přepsání či úpravě existujících součástí, tyto testy by měly odhalit případně zanesené chyby. Samozřejmě se ale nedá spolehnout pouze na ně samotné, jelikož pouhé neodhalení chyby ještě neznamená, že v kódu žádná není. Uživatelské rozhraní jsem v bakalářské práci také otestoval na prototypu. Tento test proběhl dle předem stanoveného scénáře, jehož jednotlivé kroky měli jeho účastníci sledovat. Účelem bylo odhalit zásadní nedostatky v celkovém rozložení a struktuře aplikace. V rámci této práce nebudu přesně opakovat již proběhlé testy, ale pokusím se na ně částečně navázat novými, případě původní o něco rozšířit. 45

60 4. Testování 4.1 Napojení na server Kritickou částí celé klientské aplikace je komunikace s webovým serverem, proto je tato komunikace vhodným kandidátem pro testy. Je potřeba otestovat samotnou komunikaci jako takovou a dále schopnost korektně zpracovat přijatá data. Navíc po konzultaci s vedoucím této práce a zbytkem týmu dojde ještě k zátěžovému testu celého serveru. Jelikož pro veškerou komunikaci se serverem je potřeba prvotní přihlášení, všechny test potřebují korektní uživatelské údaje. V průběhu svého testování jsem použil vlastní uživatelské jméno a Heslo ČVUT, nicméně ze zdrojových souboru, které jsou v příloze na CD, jsem tyto údaje odstranil. Případný zájemce tak bude muset použít své údaje. Kam přesně je vyplnit je popsáno v souboru README.txt, který je rovněž nahrán na CD Komunikace se serverem Tato skupina testů se zaměřuje na komunikaci se serverem jako takovou. Nejdříve musí dojít k ověření uživatelských údajů. Jeden z testů se také zaměřuje, zda je správně ošetřena situace, kdy uživatel zadá neplatné přístupové údaje. Hlavní pointou těchto testů je ujistit se, že klientská aplikace dokáže s webovou službou korektně komunikovat a předávat jí správná data. Jako vedlejší efekt dochází zároveň ke kontrole správné serializace lokálních objektů na JSON data. Pokud by zde došlo k chybě, server by nedokázal požadavek přijmout a vrátí chybu. V těchto testech je chyba detekována jako neodpovídající návratový HTTP kód. Ve většině případů se očekává kód 200 (OK), např. test nesprávných přihlašovacích údajů ale očekává kód 401 (Unauthorized). Je samozřejmě nutno podotknout, že k provedení této skupiny testů je potřeba, aby byly splněny dvě podmínky. První je, aby zařízení, na kterém se spustí, mělo aktivní připojení k internetu. Bez něj samozřejmě všechny testy selžou. Druhou podmínkou je pak dostupnost serveru. Pokud z nějakého důvod nebude server fungovat, opět testy selžou Zpracování příchozích dat Druhá skupina se zaměřuje na korektní zpracování přijatých dat. Tedy zda klientská aplikace dokáže přijmout odpovědi od webové služby, přetransformovat je na lokální datové struktury a ty pak bezpečně uložit do lokálního úložiště. 46

61 4.1. Napojení na server Ověření správného zpracování dat je v tomto případě trochu problematické. To, že dojde k bezchybné deserializaci přijatých JSON dat, totiž ještě neznamená, že se skutečně korektně zpracovala všechna data. Některá totiž mohla být přeskočena nebo zpracována špatně, proto se musí zkontrolovat také jejich samotný obsah. To je ovšem problematické, jelikož jsou tato data dynamická a na serveru může dojít k jejich změně, což způsobí selhání testu. Proto jsem se rozhodl netestovat zpracování dat oproti skutečnému serveru, ale oproti lokálnímu. Nejdřív jsem vybral množinu dat, kterou budu testovat. Poté jsem se serveru na ně ručně dotázal (použil jsem doplněk do prohlížeče Firefox RESTClient 16 ) a odpovědi v textové podobě uložil. Na základě těchto dat jsem poté vytvořil lokální instanci webového serveru, který vrací tyto statické odpovědi, které korespondují s těmi ze skutečného serveru ČVUT Navigátora. Testy se pak automaticky pouští oproti tomuto lokálnímu serveru, čímž je garantována jejich neměnnost. Proti této metodě lze namítnout, že testování neodhalí případné změny v komunikačním protokolu a jeho novou implementaci na straně serveru. Nicméně jak vyplynulo z analýzy, komunikační protokol je verzován a případné změny by měly být provedeny až v jeho další verzi právě z toho důvodu, aby stávající klientské aplikace nepřestaly ze dne na den fungovat. Samotné testování se neprovádí ihned na přijatých datech, ale až po jejich převodu na lokální struktury. Tím dojde také ke kontrole transformačních funkcí. Pokud tyto testy proběhnou v pořádku, dojde na závěr k pokusu o uložení těchto dat do místní databáze Zátěžové testování serveru Tento test měl za úkol ověřit možnosti serveru přijímat mnoho požadavků najednou. Cílem je vytížit jej reálnými požadavky potenciálních uživatelů a zjistit, zda je potřeba provést optimalizaci, ať už na straně serveru nebo na straně klientské aplikace. Při tomto testování jsem úzce spolupracoval s Janem Mráčkem, který má v rámci své bakalářské práce [13] za úkol možnosti serveru měřit. Já se v tomto textu tedy nebudu zabývat konkrétními metrikami a postupy, které byly použity při měření na serveru, pouze popíši navržené testy a jejich průběh. Případného zájemce o další podrobnosti tak odkáži na již zmíněnou bakalářskou práci Jana Mráčka Návrh testů Hlavní snahou při zátěžovém testování bylo simulovat mnoho klientských aplikací zasílajících požadavky na server najednou. K tomuto účelu jsem

62 4. Testování vytvořil jednoduchou konzolovou aplikaci, která při spuštění zahájí prvotní přihlášení a synchronizaci. Ta se provádí při prvním spuštění aplikace mobilní. Tato konzolová aplikace byla distribuována na celkem pět počítačů, postupně se spuštěla jednou až desetkrát. Celkově byl tedy server vytěžován pěti až padesáti instancemi. Kromě prvotní synchronizace také zažádala o vyhledání trasy mezi dvěma body. Vyhledání trasy v každém běhu testu proběhlo desetkrát, synchronizace dvakrát, výsledné časy se průměrovaly. Pro průběh testu bylo důležité, aby všechny začaly pokud možno ve stejný okamžik. Při ručním spouštění na každém počítači by se zátěž na server rozložila v čase a výsledné měření by mělo menší vypovídající hodnotu. Proto testování nezačalo ihned po spuštění aplikace, ale až v okamžiku, kdy byla aplikace spuštěna na všech strojích. Prakticky je toto implementováno tak, že je na serveru uložen soubor, který má příznak, zda již má testování začít. Jednotlivé aplikace tento soubor v krátkých intervalech kontrolují a jakmile zjistí, že je příznak nastaven, okamžitě test spustí Průběh a výsledky testování Jak je na grafu 4.1 vidět, doba odpovědi na dokončení synchronizace roste lineárně s počtem paralelně se dotazujících zařízení. Stejná je situace pro dotaz na nalezení cesty mezi dvěma body. Znázorněné časy nelze brát zcela dogmaticky, záleží na velkém množství faktorů, jako je internetové připojení, konfigurace zařízení, na kterém testy běží, apod. Jasná tendence ovšem vidět je. Toto měření proběhlo ještě před implementací kešování dat na straně serveru, což je náplní práce Jana Mráčka. Testovací aplikaci jsem mu předal, testování tedy může provést sám v okamžiku, kdy kešování na serveru zprovozní. 4.2 Uživatelské testování I přes množství automatických testů, které byly popsány v předchozích odstavcích, je stále velmi pravděpodobné, že aplikace obsahuje chyby. Nemusí se nutně jednat o chyby v kódu, ale také uživatelského rozhraní, které je velmi obtížné až nemožné otestovat. Pouze skutečný uživatel může vývojáře upozornit, že některé nabídky v daném kontextu nedávají smysl nebo že se některá animace spouští trhaně. Proto přichází na řadu uživatelské testování. Jak jsem již zmínil výše, v rámci své bakalářské práce jsem provedl uživatelské testování prototypu s vybranou skupinou uživatelů dle předem 48

63 4.2. Uživatelské testování Obrázek 4.1: Závislost doby běhu testu na počtu paralelních instancí stanoveného scénáře. Tento postup byl vhodný v počátcích návrhu aplikace, kdy uživatelé mohli odhalit zásadní chyby a nedokonalosti v celkovém návrhu uživatelského rozhraní. Nyní, když už je aplikace téměř hotová, jsem zvolil jiný postup. Rozhodl jsem zpřístupnit aplikaci všem zájemcům v rámci otevřeného beta testu. To znamená, že kdokoliv má zájem se testu zúčastnit, tak si může aplikaci stáhnout a zasílat zpětnou vazbu. Zároveň neexistuje žádný předem stanovený scénář, kterého by se měli uživatelé držet, ale mohou aplikaci využívat tak, jak uznají za vhodné. Dochází tak k mnohem přirozenějšímu testování celé aplikace, kdy se mohou odhalit také chyby, které by se v případě použití scénáře neprojevily Windows Phone Store Pro implementaci uživatelského testování jsem se rozhodl použít standardní možnosti platformy Windows Phone umístění aplikace do obchodu s aplikacemi Windows Phone Store. Jelikož jsem již několik soukromých aplikací publikoval, vlastním vývojářský účet. Pod ním jsem dočasně aplikaci zveřejnil, nicméně do budoucna by bylo vhodné, aby FIT (nebo optimálně celé ČVUT) měl vlastní účet, pod kterým by se všechny školní aplikace publikovaly. Jak jsem popsal v Analýze, existuje několik způsobů, jak aplikaci zveřejnit. Pro otevřený beta test je nejlepší verze Publish, hide from search 49

64 4. Testování results. Stáhnout si aplikaci tak může kdokoliv s odkazem 17 na ni. O testování jsem nejdříve požádal několik mých spolužáků, aby pokud možno odhalili nejočividnější chyby. Následná veřejná distribuce odkazu na stažení aplikace měla proběhnout odesláním hromadného u všem studentům, vzhledem k nalezeným chybám na straně serveru od toho nakonec bylo upuštěno - viz níže. Zpětnou vazbu mohou uživatelé zasílat přímo z jejich mobilních telefonů. Kromě počtu hvězdiček (čím více, tím lepší hodnocení) mohou zaslat také volitelný vzkaz. Ten má hlavní vypovídací hodnotu, jelikož v něm může uživatel vysvětlit, co se mu na aplikaci líbí nebo nelíbí. K tomuto hodnocení se může uživatel kdykoliv později vrátit a upravit ho. Přesměrování na toto hodnocení je také přímo uvnitř aplikace na hlavní stránce, aby bylo pro uživatele co nejjednodušší svůj názor zaslat. Jak vypadá prostředí hodnocení aplikace je vidět na obrázcích 4.2a a 4.2b. Vývojář může mezi těmito komentáři procházet ve webovém rozhraní 18. Momentálně na ně nemůže reagovat, to by se ale s Windows Phone 8.1 mělo změnit [15]. Také u některých hodnocení vidí, z jakého telefonu byly zaslány, nicméně se nejedná o pravidlo, u některých je vidět pouze nic neříkající kód. Proto jsem své spolužáky požádal, aby u každého hodnocení napsali také jejich model telefonu Vyhodnocení Následují výsledky testování mých spolužáků. Ne všichni poslali své připomínky přímo do obchodu, ale někteří mi je sdělili osobně. Nejčastější byly následující: Načítání při každém spuštění Tlačítko navigovat v agendě nic nedělá V agendě chybí některé položky z rozvrhu V agendě by bylo vhodné u položek zobrazit i celé datum Zdvojení některých ikonek při vyhledání trasy a jejich posunutí Při hledání trasy se dlouho nic neděje Zdlouhavé načítání mapových podkladů v budovách 17 Aplikaci lze stáhnout na tomto odkazu: f cce-422b-ab23-b51db788c17f

65 4.2. Uživatelské testování (a) Odkaz na hodnocení v prostředí aplikace (b) Hodnocení aplikace v prostředí Windows Phone Store Obrázek 4.2: Hodnocení aplikace V okně navigovat nelze vyhledávat podle částečného názvu Nezobrazují se položky z rozvrhu S většinou těchto připomínek jsem se dokázal vypořádat. Nejčastěji zmiňované načítání při každém spuštění bylo způsobeno obnovováním access tokenu při spuštění. To jsem nakonec vyřešil tak, že se access token obnovuje až v okamžiku zaslání dotazu na server, takže uživatel při spuštění není zdržován. Tlačítko pro navigaci na další hodinu na obrazovce Agenda skutečně nic nedělalo, oprava této chyby byla jednoduchá. Dále si v agendě uživatelé stěžovali na to, že se zobrazuje pouze jméno dne, kdy se daná položka vyskytuje. Tento výpis se stává nepřehledným, pokud uživatele zajímá, co má v rozvrhu příští týden, protože kvůli nepřítomnosti data všechny události splývají. To jsem vyřešil tak, že všechny položky v agendě slučuji do skupin dle týdne, jak je vidět na obrázku 4.3a. Navíc po kliknutí na číslo týdne 51

66 4. Testování (a) Události sdružené do týdnů (b) Rychlé přepínání mezi týdny Obrázek 4.3: Nový vzhled agendy dojde k zobrazení nabídky všech týdnů, mezi kterými může uživatel rychle přepínat, viz obrázek 4.3b. Toto chování je pro platformu Windows Phone standardní a pro uživatele by mělo být přirozené. U vyhledávání trasy záleží ve velké míře na rychlosti serveru a následném zpracování odpovědi, aby ale uživatel nebyl zmaten nečinností aplikace, umístil jsem na vrch obrazovky progress bar, který indikuje, že probíhá zpracování uživatelova požadavku. Bohužel, zdlouhavé načítání se mi nepodařilo adekvátně adresovat. Na vině je v tomto případě mapová komponenta, která nedovoluje skokový zoom. Při přechodu z venkovní mapy do vnitřní musí dojít k velkému přiblížení, což se tato komponenta snaží animovat postupným přechodem přes všechny ostatní průběžné úrovně přiblížení (zoom level), což velmi zdržuje. Na venkovních mapách to tolik nevadí, protože se průběžně pro všechny úrovně zobrazují adekvátní mapové podklady, pro vnitřní mapy tyto podklady ale neexistují. Možným řešením může být použití nové mapové komponenty, která je dostupná v nové verzi systému, to jsem ovšem již neměl 52

67 4.2. Uživatelské testování čas ověřit. Poslední chyba, která se projevila u některých uživatelů, bylo nezobrazení položek z rozvrhu. Chybu jsem vysledoval k automatickému parsování přijatých dat od serveru na instance lokálních struktur. Ukázalo se, že některé identifikátory, které server vrací, mohou nabývat hodnot více než dvě miliardy. To způsobilo problém, protože jsem ve své aplikaci všude používal pouze 32bitové integery. Řešení je jednoduché, stačilo v celé aplikaci pro identifikátory místo integerů použít 64bitové longy. Po opravě většiny zjištěných nedostatků jsem aktualizovanou aplikaci zaslal znovu do Windows Phone Store. Z testování ovšem také vyplynula závažná chyba na straně serveru, která je popsána v sekci Z tohoto důvodu jsme se s vedoucím této práce rozhodli veřejné testování odložit. 53

68

69 Závěr Hlavním cílem této práce bylo zprovoznění síťové komunikace mezi Windows Phone aplikací, kterou jsem vytvořil v rámci své bakalářské práce, a webovou službou. Dodatečně bylo potřeba aplikaci upravit, aby využívala nové možnosti komunikačního protokolu. Důležité bylo také otestování celé aplikace, a to jak mezi koncovými uživateli, tak při komunikaci s webovým serverem. Ve výsledku se podařilo splnit všechny body zadání. Aplikaci jsem rozšířil o požadované vlastnosti. Nyní korektně komunikuje se webovým serverem, konečně tedy poskytuje pro uživatele relevantní data. Co se týče jednotlivých funkcí, o které jsem měl aplikaci rozšířit, ty se mi také podařilo implementovat. Kešování mapových podkladů V první verzi aplikace při každém novém spuštění bylo potřeba stáhnout mapové podklady jednotlivých podlaží znovu. To bylo způsobeno mapovou komponentou, která nedokáže zobrazit podklady uložené v paměti telefonu. Toto stále platí v případě verze aplikace pro Windows Phone 7. Nicméně ve verzi 8 byla jednou z novinek možnost spustit v aplikaci lokální webový server. Mapová komponenta se pak na adresu tohoto lokálního serveru pouze přesměruje. Díky tomu je kešování mapových podkladů možné. Zpětná vazba pro efektivní navigaci U této funkce bylo hlavním požadavkem možnost anonymně sledovat pohyb uživatele. Webový server dokáže pohyb uživatelů analyzovat a na základě toho optimalizovat spočítané trasy při vyhledávání. Např. v době obědů je rychlejší jít po schodech, protože se u výtahů tvoří fronty, po třetí hodině ale už jsou výtahy opět rychlejší. 55

70 Závěr Pro tuto funkci jsem spolu s Danielem Kucbelou navrhl rozšíření komunikačního protokolu. Aplikace také byla patřičným způsobem upravena, aby bylo sledování pohybu uživatele možné. Důležitou podmínkou byla anonymita uživatele a také možnost toto sledování vypnout. Proto je při prvním spuštění uživatel na jeho anonymní sledování upozorněn a je mu nabídnuta možnost jej v nastavení zakázat. V současnosti tato funkcionalita není implementována na serveru, proto klientská aplikace polohu ve skutečnosti nehlásí. V okamžiku implementace této funkce na serveru je zprovoznění této funkce na straně klientské aplikace velmi jednoduché. Rozšířená realita V oblasti rozšířené reality jsem modifikoval původní návrh markerů, který uvedl ve své práci Tomáš Kohout. Díky novému návrhu by mělo být jejich generování i zpracování v mobilních aplikacích velmi jednoduché. Dále jsem implementoval zobrazování okolních bodů na detekovaném patře přímo v prostředí fotoaparátu. Jak uživatel otáčí telefonem kolem dokola, zobrazují se mu ty místnosti, které jsou v zorném poli kamery. Další body zájmu Protokol byl rozšířen o několik dalších bodů zájmu. To má uživateli zjednodušit orientaci po budovách ČVUT. O tyto změny tedy musela být rozšířena klientská aplikace. Pro přehlednější zobrazení těchto bodů jsem přidal ke každému druhu také obrázek. Návrhy na vylepšení Ačkoliv je nyní aplikace a celý projekt v použitelném stavu, kdy je možné jej postupně uvolnit studentům, stále existuje několik oblastí, které je potřeba vylepšit. A to jak na straně serveru, tak na straně klientské aplikace. Vyhledávání na serveru Vyhledávání je dle mého názoru naprosto kritická a zcela nezbytná vlastnost mobilních aplikací. V klientské aplikaci pro Windows Phone mám vyhledávání v omezené míře vytvořeno, nicméně se nejedná o optimální řešení. Aby fungovalo, musí si aplikace veškerá potřebná data stáhnout a hledat v nich lokálně. To samozřejmě není úplně možné, proto se stahuje pouze seznam všech budov, bodů zájmu a rozvrh s předměty a učiteli, kteří se v něm vyskytují. 56

71 Návrhy na vylepšení Momentálně tedy např. nelze vyhledávat mezi vyučujícími. Protokol sice podporuje zobrazení rozvrhu libovolného uživatele, ale jelikož není možné mezi uživateli vyhledávat, tato vlastnost má jen velmi omezenou možnost využití. Stejná situace platí pro předměty. Se zprovozněním vyhledávání by začaly být mobilní aplikace mnohem použitelnější. Nemusely by při prvním přihlášení stahovat kompletní balík všech dat, ale až v okamžiku, kdy by to bylo potřeba. Typickým příkladem je seznam všech bodů zájmů (tedy místností, toalet, výtahů apod.), které se nyní musí stahovat všechny najednou. Zkoušky Dalším důležitým bodem je rozšíření typů událostí. Momentálně položky z rozvrhu mohou být označeny jako cvičení, přednášky nebo ostatní. Uživatelé by jistě uvítali, kdyby si mohli zobrazit také seznam zkoušek. Momentálně je možné je zobrazit pouze spolu s ostatními událostmi (jako jsou např. jednorázové akce, školení apod.). S tím souvisí také možnost komunikačního protokolu se na zkoušky, případně další jednorázové události, přímo serveru dotázat. Problém je totiž momentálně v tom, že toto vše spadá do rozvrhu. A při libovolné změně rozvrhu se musí stáhnout kompletně celý znovu. V případě běžných přednášek či cvičení to není takový problém, protože ty se nemění tak často. Jinak je tomu ovšem u zkoušek, které se ve zkouškovém období mění relativní často. Bylo by proto vhodné komunikační protokol rozšířit o možnost dotázat se pouze na zkoušky a další jednorázové události. Tuto kontrolu by pak mohla klientská aplikace provádět automaticky na pozadí. Uživatel tak může být upozorněn na nadcházející zkoušku, aniž by aplikaci musel spustit. Další druhy týdne Momentálně protokol podporuje pouze dva druhy týdne lichý a sudý. Rozhodně by bylo vhodné přidat další typy např. zkouškové období nebo prázdniny. K tomu se také váže číslo týdne, právě o zkouškovém období nebo prázdninách zcela pozbývá platnosti. Během zkoumání zdrojových kódů webového serveru jsem si navíc všiml jedné problematické části. Server momentálně udává lichost, resp. sudost výukového týdne na základně kalendářního týdne. To je v pořádku pro naši fakultu, nicméně ostatní fakulty se kalendářním týdnem řídit nemusí, proto by chtělo vymyslet obecnější řešení, které bude fungovat pro všechny fakulty. Markery a rozšířená realita Systém markerů, které budou vyvěšeny po budovách ČVUT, považuji za skvělý nápad, který uživatelům značně 57

72 Závěr zjednoduší orientaci ve škole. Jak jsem popsal v Návrhu, Vadim Petrov vytvořil prototyp vzhledu tohoto markeru, který může sloužit jako provizorní řešení. Před ostrým spuštění by měl být tento návrh analyzován a případně upraven, aby s ním vedení ČVUT souhlasilo a mohlo se začít s hromadným vylepováním ve školních prostorách. Další prostor pro vylepšení také skýtá rozšířená realita jako taková. V současné verzi se po naskenování markeru do prostředí kamery vykreslí seznam bodů v okolí. Bylo by ale určitě zajímavé toto řešení zkombinovat s vykreslováním 3D objektů, ukazujících správný směr v případě, že má uživatel vyhledanou trasu k cílovému bodu. Toto řešení nicméně už nebude úplně jednoduché a bude vyžadovat znalosti C++ a Direct3D. Dlouhodobá analýza uživatelské zpětné vazby Ačkoliv jsem během uživatelského testování nasbíral několik důležitých podnětů od uživatelů, stále se nejedná o reprezentativní vzorek. Je potřeba dát uživatelům více času, aby v aplikaci přišli na to, co jim chybí, či co je omezuje. Je také třeba aplikaci nechat otestovat čerstvě přijatými studenty prvních ročníků. Testování navíc proběhlo pouze mezi studenty Fakulty informačních technologií, což je svým způsobem specifická skupina uživatelů. V budoucnu by aplikace měla být vypuštěna také mezi studenty ostatních fakult. Zveřejnění aplikace pod školním účtem Momentálně je aplikace umístěna v rámci beta testování ve Windows Phone Store pod mým vývojářským účtem. Výhledově ji zde samozřejmě ponechám volně ke stažení, nicméně do budoucna je potřeba, aby pokračovatelé v tomto projektu měli vlastní účet, případně aby se zřídil účet školní, kam se aplikace přesune. Rozšíření mapových podkladů V době psaní této práce byla zmapována pouze Nová budova a 9. patro bývalé budovy architektury. Aby v budoucnu mohli aplikaci využívat také studenti ostatních fakult, je třeba seznam pokrytých budov značně rozšířit. Kritické jsou především samotné plány budov. Jednotlivé místnosti a další body již mohou dodávat samotní uživatelé prostřednictvím aplikace pro správu mapových podkladů. Verze pro Windows Phone 8.1 a Windows 8.1 Aplikace v současnosti existuje pro Windows Phone verze 7 a 8. Udržování kódu pro verzi 7 je dle mého do budoucna zbytečné, jelikož není již Microsoftem dále 58

73 Návrhy na vylepšení vyvíjena, proto by měla být s klidným svědomím v budoucnu zcela opuštěna. Zároveň došlo s uvedením verze 8.1 k několika novinkám, které mimo jiné umožní širší sdílení kódu s případnou verzí aplikace pro Windows 8.1. Případný pokračovatel této práce by rozhodně měl tyto novinky analyzovat a rozhodnout se, zda rovnou aplikaci nemodifikovat tak, aby jich naplno využívala. Dále by bylo jistě zajímavé analyzovat, nakolik je skutečně možné vytvořit pouze jednu aplikaci, která dokáže běžet jak na mobilních, tak velkých Windows. Jednotná dokumentace Jak jsem již popsal v sekci Data neodpovídající dokumentaci, kvůli nekonzistentní dokumentaci nebyla implementace síťové komunikace se serverem úplně bezproblémová. Jediná existující dokumentace webové služby navíc existuje pouze v závěrečných pracích jednotlivých autorů. Do budoucna by bylo vhodné mít jednotonou dokumentaci, aby se pokračovatelé dokázali v celém projektu lehce zorientovat. Kritický je především detailní popis API webové služby a vracených datových typů. Stejně tak by ale měly být zdokumentovány projekty pro jednotlivé klientské aplikace, aby jejich hlavní know-how neodešlo spolu s jejich autory. Nová verze webu Stávající verze webu projektu, která se nachází na adrese navigator.fit.cvut.cz, je ještě z doby, kdy byl tento projekt veden v rámci předmětů BI-SP1 a BI-SP2. Od té doby všichni původní autoři z projektu odešli, i přesto jsou na stránkách stále uvedeni, narozdíl od současných autorů. Celkově nebyl web již přes dva roky aktualizován. Kromě aktualizace těchto webových stránek stojí za úvahu vytvoření jejich mobilní verze, která by byla na adrese m.navigator.fit.cvut.cz. Mohly by zde být být umístěny odkazy pro stažení jednotlivých klientských aplikací a krátký popis projektu. 59

74

75 Literatura [1] Zdeněk, P.: ČVUT Navigator - Klientské API: Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, Dostupné z: peckazde_2014dipl.pdf [2] Windows Phone OS Version - Worldwide. [online], stav ze dne Dostupné z: -l5r1znsf7-u/uwcwcbdgzpi/aaaaaaaak7o/a7w9pkxghxw/s1600- h/clip_image003.png [3] Shodné části Windows a Windows Phone Runtime. [online], stav ze dne Dostupné z: markedupblog.blob.core.windows.net/wordpress/2013/06/ WinRTWP8CompatibilityMSDN.png [4] Bezouška, T.: ČVUT Navigator - Klient WP I: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, Dostupné z: bezoutom_2012bach.pdf [5] Čermák, O.: ČVUT Navigator: Diplomová práce. Praha: České vysoké učení technické, Dostupné z: browse/pdfcache/cermaond_2012dipl.pdf [6] OAuth 2.0. [online], stav ze dne Dostupné z: oauth.net/2/ [7] The OAuth 2.0 Authorization Framework. [online], stav ze dne Dostupné z: 61

76 Literatura [8] Kohout, T.: Mobile ios client for the CTU Navigator. Praha: Czech Technical University in Prague, Faculty of Information Technology, Dostupné z: kohouto7_2013bach.pdf [9] Microsoft confirms no upgrade path to Windows Phone 8, unveils 7.8 for legacy devices. [online], stav ze dne Dostupné z: [10] Janke, T.: Offline maps with Windows Phone 8. [online], stav ze dne Dostupné z: [11] Windows Phone 8.1 for Developers Maps. [online], stav ze dne Dostupné z: archive/2014/04/22/windows-phone-8-1-for-developersmaps.aspx [12] HTTP Header Field Definitions. [online], stav ze dne Dostupné z: sec14.html [13] Mráček, J.: ČVUT Navigátor - Rozšíření modulů serverové části II. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, [14] Kucbel, D.: ČVUT Navigátor - Navigační modul: Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, [15] Zamora, B.: You May Soon Get a Response to Your Windows Phone App Review. [online], stav ze dne Dostupné z: archive/2014/04/17/you-may-soon-get-a-response-to-yourwindows-phone-app-review.aspx 62

77 Příloha A Seznam použitých zkratek FUP Fair User Policy UI User Interface WP Windows Phone WinRT Windows Runtime WinPRT Windows Phone Runtime POI Point of Interest REST Representational State Transfer API Application Programming Interface IS Informační Systém HTTP Hyper Text Transfer Protocol SSL Secure Socket Layer HTTPS HTTP Secure XNA herní framework pro WP7 QR kód Quick response kód 63

78

79 Příloha B Uživatelská příručka Tato příloha popisuje způsob instalace aplikace a její způsob použití. B.1 Instalace aplikace Aplikace je v současnosti dostupná ke stažení ve Windows Phone Store na následujícím odkazu: Pro případné zájemce přikladám i QR kód, který zmíněnou adresu obsahuje, viz obrázek B.1. Po jeho naskenování telefonem jste přesměrováni do Windows Phone Store, kde lze aplikaci nainstalovat. Po instalaci se ČVUT Navigátor objeví v seznamu aplikací, jak je vidět na obrázku B.2b. Obrázek B.1: QR kód s odkazem na stažení aplikace 65

80 B. Uživatelská příručka (a) ČVUT Navigátor ve Windows Phone Store (b) ČVUT Navigátor v seznamu nainstalovaných aplikací Obrázek B.2: Instalace aplikace B.2 První spuštění Při prvním spuštění musí uživatel zadat své uživatelské jméno a heslo ČVUT. K tomu ho vyzve dialog, který lze vidět na obrázku B.3a. Zároveň je upozorněn na to, že může být jeho poloha anonymně zasílána na server a že toto chování lze v nastavení vypnout. Pokud uživatel údaje nevyplní, je mu oznámeno, že může aplikaci využívat pouze velmi omezeně pro prohlížení mapy. Přihlašovací údaje může také vyplnit v nastavení, jak je vidět na obrázku B.3b. B.3 Agenda Agenda zobrazuje chronologický seznam položek z rozvrhu. Vzhled této obrazovky prošel menší úpravou, jejíž potřeba vyplynula z uživatelského testování, jak je popsáno v kapitole Položky jsou nyní seskupeny do skupin podle týdne. Navíc lze mezi jednotlivými týdny rychle přepínat. Po vybrání položky se zobrazí její detail. Všechny tyto změny jsou vidět na obrázku B.4. 66

81 B.3. Agenda (a) Dialog pro přihlášení (b) Nastavení Obrázek B.3: První spuštění a nastavení (a) Seznam položek agendy (b) Rychlé přepínání mezi týdny (c) Detail položky agendy Obrázek B.4: Obrazovky agendy 67

82 B. Uživatelská příručka Obrázek B.5: Obrazovky rozvrhu B.4 Rozvrh Položky rozvrhu jsou barveně rozděleny na přednášky a cvičení. Po kliknutí na položku si uživatel může nechat zobrazit více informací o daném předmětu, nechat se navigovat do přiřazené místnosti nebo si ji pouze zobrazit na mapě. Pokud daná položka nemá přiřazenu místnost, jsou poslední dvě možnosti neaktivní. Obrazovka rozvrhu je vyobrazena na obrázku B.5. B.5 Předměty a učitelé Tyto obrazovky nabízí přehled všech předmětů, které má uživatel zapsané, a jejich vyučujících. Pro rozkliknutí se k dané položce zobrazí další detaily. U předmětu se jedná o odkaz na edux, seznam přednášejících a cvičících a seznam místností. Všechny tyto položky jsou interaktivní, po kliknutí vykonají další akci. V detailu vyučujícího je možné mu jednoduše poslat na školní adresu nebo si jeho profil vyhledat na Pokud má vyučující přidělený kabinet, je možné si zobrazit jeho polohu na mapě. Všechny obrazovky týkající se předmětů a vyučujících jsou vidět na obrázcích B.6 a B.7. 68

83 B.5. Předměty a učitelé Obrázek B.6: Obrazovky předmětů a jejich detailu Obrázek B.7: Obrazovky vyučujících a jejich detailu 69

84 B. Uživatelská příručka B.6 Mapa a navigace Obrázek B.8: Mapa a navigace Výchozím bodem pro navigaci je obrazovka navigovat, která je vidět na obrázku B.8a. Zde si uživatel může zvolit počáteční a cílový bod a vybrat mezi pěší a automobilovou navigaci. Pokud jsou oba body v rámci jedné budovy, je dostupná pouze pěší navigace. B.7 Vyhledávání Vyhledávání je dostupné pouze na hlavní obrazovce a na obrazovce mapy. Vyhledávací políčko se zobrazí po klepnutí na ikonku lupy, po vybrání hledaného bodu je tento zobrazen na mapě. Je možné vyhledávat mezi místnostmi a body zájmu (budovami). B.8 Live tile Aplikaci si je možné připnout jako dlaždici (live tile) na hlavní obrazovku. V takovém případě na své zadní straně zobrazuje nadcházející položku z agendy uživatele. Tato informace se obnovuje každých třicet minut, což je omezení dané operačním systémem. 70

85 B.8. Live tile Obrázek B.9: Vyhledávání Obrázek B.10: Přední a zadní strana dlaždice 71