Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie

Diplomant: Bc. Vít Čurda Vedoucí diplomové práce: Ing. Tomáš Bruckner, Ph.D. Oponent diplomové práce: Ing. Radek Skoupý

Tvorba mapové aplikace pro sledování polohy v Cloudu klientská část Windows Phone 7

školní rok 2012/2013

Prohlášení

Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal.

V Praze dne

20. 4. 2012 ……………………………. podpis

Stránka | 2

Poděkování

Rád bych na tomto místě poděkoval především vedoucímu práce Ing. Tomáši Brucknerovi, Ph.D. za užitečné rady, trpělivost a ochotu, čímž mi výrazně pomohl při vytváření práce. Dále bych rád poděkoval společnosti Microsoft a především Ing. Filipu Řehoříkovi za zapůjčení mobilního telefonu a také za zajištění spolupráce se společností GINA Software a Ing. Zbyňkem Políčkem, kterému bych tímto chtěl také poděkovat za spolupráci.

Stránka | 3

Abstrakt Diplomová práce se zabývá vývojem aplikace na platformě Windows Phone 7. Aplikace se zaměřuje na cílové skupiny vozíčkářů a cyklistů. Těm nabízí možnost navigace po městě a obtížným terénem. Aplikace je rozdělena na dvě části – klientskou část a serverovou část. Vývoj serverové části je analyzován v diplomové práci Tvorba mapové aplikace pro sledování polohy v Cloud – serverová část Windows Azure, která je zpracovávána Bc. Vojtěchem Růžičkou. Hlavním cílem práce je nabídnout nová řešení při vývoji na platformě Windows Phone 7, zejména zaměřená na komunikaci mezi klientem a serverem. Druhým cílem je nabídnout veřejnosti bezplatnou aplikaci, která pomůže cyklistům a vozíčkářům při navigaci ve městě. Prvního záměru bude dosaženo samotným řešením problémů během vývoje a jejich následným zobecněním a udělením doporučení. Druhý cíl bude splněn zveřejněním samotné aplikace.

Klíčová slova Windows Phone 7, Silverlight, vývoj, mapová aplikace, GPS, navigace, Windows Azure, Microsoft, tělesně postižení, cyklisté, SQL Azure

Stránka | 4

Abstract This thesis deals with developing applications on Windows Phone 7. The application focuses on two main target groups; cyclists and individuals who are confined to wheelchairs. Application offers the possibility of navigating around the city and over difficult terrain, and is divided into two parts - the client side application, and server side application. Development of the server side application will be analyzed in the thesis Development of map application for tracking in cloud - Server side on Windows Azure, by Bc. Vojtěch Růžička. The primary objective of this thesis is to offer new solutions for development on Windows Phone 7, with attention being given to the communication between client and server. The second objective is to provide the public with the free application, which will help cyclists and handicapped individuals to navigate through cities around the world. The primary goal of this thesis will be achieved by identifying any problems that may arise during development, whereby a simplified description of the problem will be formed and a solution provided. Realization of the second goal will be in the use of application by the public, by providing them with an efficient means of increasing their mobility throughout their surroundings.

Keywords Windows Phone 7, Silverlight, development, map, GPS navigation, Windows Azure, Microsoft, disabled individuals, cyclists, SQL Azure

Stránka | 5

Obsah Prohlášení ............................................................................................................................................................................. 2 Poděkování ........................................................................................................................................................................... 3 Abstrakt ................................................................................................................................................................................. 4 Klíčová slova ........................................................................................................................................................................ 4 Abstract .................................................................................................................................................................................. 5 Keywords .............................................................................................................................................................................. 5 Obsah ...................................................................................................................................................................................... 6 1.

2.

3.

4.

Vymezení diplomové práce .................................................................................................................................. 8 1.1.

Úvod ..................................................................................................................................................................... 8

1.2.

Cíle ........................................................................................................................................................................ 9

1.3.

Přínos .................................................................................................................................................................. 9

Výchozí stav ............................................................................................................................................................. 10 2.1.

Motivace .......................................................................................................................................................... 10

2.2.

Dosavadní práce v dané oblasti ............................................................................................................. 10

2.3.

Partneři ............................................................................................................................................................ 12

Vývoj v týmu............................................................................................................................................................ 15 3.1.

Rozdělení práce ............................................................................................................................................ 15

3.2.

Metodika vývoje ........................................................................................................................................... 16

Analýza ...................................................................................................................................................................... 19 4.1.

Popis a cíle aplikace .................................................................................................................................... 19

4.2.

Globální analýza ........................................................................................................................................... 22

4.2.1.

Uživatelské role a jejich požadavky ........................................................................................... 22

4.2.2.

Uživatelské požadavky dle subsystému ................................................................................... 25

4.2.3.

Procesní mapa ..................................................................................................................................... 26

4.2.4.

Use Case diagram ............................................................................................................................... 28

4.2.5.

Use Case scénáře ................................................................................................................................ 29

4.3.

5.

Detailní analýza ............................................................................................................................................ 39

4.3.1.

Architektura aplikace ....................................................................................................................... 39

4.3.2.

Architektura klienta.......................................................................................................................... 42

4.3.3.

Detailní specifikace procesů .......................................................................................................... 44

4.3.4.

Procesní modely ................................................................................................................................. 51

Teoretický základ .................................................................................................................................................. 59 5.1.

Představení Windows Phone 7 .............................................................................................................. 59

5.1.1.

Historie Windows Phone 7 ............................................................................................................ 59

Stránka | 6

6.

5.1.2.

Uživatelské rozhraní ......................................................................................................................... 60

5.1.3.

Windows Phone 7 – Základní informace.................................................................................. 62

Implementace ......................................................................................................................................................... 64 6.1.

Struktura programu ................................................................................................................................... 64

6.1.1.

Modely .................................................................................................................................................... 65

6.1.2.

Aplikační logika .................................................................................................................................. 66

6.1.3.

Uživatelské rozhraní a jeho logika .............................................................................................. 69

6.2.

Problémy a jejich řešení ........................................................................................................................... 71

6.2.1.

Multitasking a stavy aplikace ve Windows Phone 7............................................................ 71

6.2.2.

Zabezpečení komunikace ............................................................................................................... 74

6.2.3.

Navigace mezi stránkami ve Windows Phone 7 ................................................................... 76

6.2.4.

Asynchronní volání metod v mobilním klientu ..................................................................... 78

6.2.5.

Rozhraní INotifyProperityChanged............................................................................................ 82

6.3.

Vývoj a zveřejnění aplikace pro Windows Phone 7 ...................................................................... 85

7.

Možné pokračování .............................................................................................................................................. 88

8.

Vyhodnocení............................................................................................................................................................ 90

9.

Závěr ........................................................................................................................................................................... 93

Citovaná literatura ......................................................................................................................................................... 94 Terminologický slovník ................................................................................................................................................ 97 Seznam tabulek................................................................................................................................................................ 99 Seznam obrázků ............................................................................................................................................................100 Přílohy ...............................................................................................................................................................................101

Stránka | 7

1. Vymezení diplomové práce 1.1. Úvod Diplomová práce se zabývá vývojem aplikace na mobilní platformě Windows Phone 7. Téma této práce jsem vybral ve spolupráci s Microsoft a GINA Software. Diplomová práce však není přímým přínosem ani pro jeden zmiňovaný subjekt. Jedná se o vývoj aplikace, která pomůže cílovým skupinám uživatelů při plánování cest. Těmito cílovými skupinami jsou vozíčkáři a cyklisté. Počítám přitom s tím, že při vývoji aplikace narazím na různé problémy, které se následně pokusím zobecnit a řešení uvést v práci. Celá aplikace se skládá z mobilního a webového klienta a serverové části. Tato práce se přitom zabývá vývojem klientů. Serverová část je popsána v diplomové práci

Tvorba mapové aplikace pro sledování polohy v Cloud –

serverová část Windows Azure vypracovávané Bc. Vojtěchem Růžičkou. Diplomová práce je rozdělena do několika kapitol. V prvních kapitolách jsem popsal, proč jsem si vybral právě toto téma a jsou zde také definovány cíle. Protože vývoj klienta není úplně nezávislý na vývoji serverové části, je ve 3. kapitole popsána metodika, která byla při vývoji v týmu použita. Následují kapitoly Globální analýza a Detailní analýza. V těchto kapitolách je návrh aplikace, jehož součástí je popis struktury aplikace a také její funkcionalita. Protože by v práci nemělo chybět alespoň základní představení systému, na kterém klientská aplikace běží, je tak učiněno v kapitole Teoretický základ. Následující kapitola Implementace je nejdůležitější kapitolou v celé práci. Je rozdělena na dvě podkapitoly, přičemž v obou se snažím ze zkušeností, které jsem nabyl při vývoji, vyvodit doporučení pro další vývojáře. V první kapitole

Struktura programu jsou uvedena doporučení vztahující se spíše ke

specifikům vývoje a v druhé podkapitole Problémy a jejich řešení jsem popsal nejobtížnější problémy a jejich řešení. Poslední dvě kapitoly se věnují možnému navázání na vypracovávané téma a také vyhodnocení cílů, které jsem si stanovil před samotným vývojem aplikace.

Stránka | 8

1.2. Cíle V této kapitole seznámím čtenáře s cíli, které jsem stanovil. Cíle jsou definovány pouze na hrubé úrovni, protože pro detailnější stanovení cílů je nutné seznámit se lépe s možnostmi aplikace. Proto jsou cíle rozepsány v kapitole Popis a cíle aplikace. Při výběru cílů jsem se je snažil stanovit tak, aby byly konkrétní, měřitelné, dosažitelné, relevantní vůči tématu a samozřejmě dosažitelné v časovém horizontu jednoho roku, který jsem si vymezil na diplomovou práci. Protože při vývoji aplikace byly použity relativně nové technologie, a to jak na straně serveru, tak na straně klienta, je hlavním cílem této práce prozkoumat vývoj a možnosti platformy Windows Phone 7, upozornit na problémy vzniklé při vývoji a navrhnout jejich řešení. Druhým cílem je vyvinout program, který umožní vozíčkářům a cyklistům lepší plánování trasy při cestách po městě, ale i za městem a na vesnicích. Toho by mělo být dosaženo veřejně dostupnou aplikací, pomocí níž bude možné zobrazit trasy, po kterých je průjezd městem snadný a bezpečný.

1.3. Přínos Cílem této kapitoly je vysvětlit přínos práce a objasnit, proč je právě tato práce prospěšná společnosti. Přínosy této práce vyplývají z jejích dvou hlavních cílů. Těmi jsou jednak uvedení aplikace do provozu a její následné využití při plánovaní cest a dále upozornění a možné problémy při vývoji na nové platformě a nastínění řešení. Z prvního cíle tedy logicky vyplývá přínos, který je zaměřen na poměrně širokou skupinu obyvatel. Touto skupinou jsou cyklisté a vozíčkáři pohybující se po městě „plném překážek“. Přínos této skupině spočívá v nabídnutí možnosti, jak efektivně naplánovat svoji cestu tak, aby nenaráželi na překážky, které by mohly cestování výrazně znepříjemnit. Z druhého cíle pak plyne přínos především pro skupinu vývojářů, kteří využívají nebo se chystají využít mobilní platformy Windows Phone 7. Těm by měla práce v obecné rovině popsat základy vývoje mobilních aplikací a detailněji pak upozornit na problémy, které jsem v průběhu vývoje řešil. Řešení těchto problémů jsem následně zobecnil a zformuloval další doporučení, jak v takovýchto případech nejlépe postupovat.

Stránka | 9

2. Výchozí stav 2.1. Motivace V této kapitole objasním, proč jsem si vybral právě téma vývoje WP 7 mobilní aplikace. Při výběru tématu diplomové práce jsem si stanovil několik kritérií, dle kterých jsem následně vybíral. Chtěl jsem si zvolit takové téma, jehož součástí bude vývoj nějaké aplikace, která bude prospěšná pro společnost. Druhým důležitým požadavkem byla spolupráce s firmou, která by mi mohla přinést jednak cenné zkušenosti z praxe, a pak také pohled na práci z jiného úhlu.

2.2. Dosavadní práce v dané oblasti V této kapitole seznámím čtenáře s dosavadními akademickými a odbornými pracemi, jejichž obsah se dotýká tématu, které zpracovávám a z kterého jsem vycházel. Protože žádná akademická práce by neměla vycházet takříkajíc z ničeho, ale naopak by měla navázat na dosavadní poznání v dané oblasti, je nutné se s ním seznámit a toto poznání rozšířit vlastní výzkumnou činností. Okruhy problémů, z kterých jsem se následně snažil získat co nejvíce znalostí, jsem rozdělil na tři skupiny. Průjezdnost městem (cyklisté) Průjezdnost městem (tělesně handicapovaní) Vývoj aplikací pro Windows Phone 7

Průjezdnost městem (cyklisté) V této oblasti jsem hledal především informace, zda je opravdu průjezdnost města na jízdním kole problémem. Dále jsem hledal informace, zda někdo již problém hledání vhodné trasy při dopravě po městě na kole řešil podobným způsobem, tedy aplikací, která bude monitorovat průjezdy po jednotlivých trasách a na základě těchto dat následně nabízet cyklistům snadno průjezdné trasy. Bohužel žádný takový projekt dosud neexistuje, nebo jsem ho nedokázal najít. Dále jsem zjišťoval, jestli jsou dostupné práce, které by potvrzovaly mou domněnku, že je obtížné vybrat si při cestě po městě tu správnou trasu. Práce na toto téma existují a zdá se, že problém výběru trasy při cestování po městě skutečně existuje. Například Nejedlý uvádí ve své bakalářské práci, že nedostatečná infrastruktura, tedy cesty, po kterých se dá s kolem bezpečně projet, je druhý největší demotivující faktor pro potencionální cyklisty (1 str. 25). Otázkou ovšem zůstává, zda jdou závěry výzkumu z několika měst zobecnit na celou planetu, přesněji řečeno na země, kde je dostupný Marketplace. Na druhou stranu je potřeba říci, že ambicí toho projektu není oslovit co nejvíce uživatelů WP7, ale spíše přinést pro část z nich užitečný program, který nebyl do této chvíle k dispozici.

Stránka | 10

Průjezdnost městem (tělesně hendikepovaní) Obdobně jako při výzkumu dosavadních prací pro průjezdnost města na kole jsem i v tomto případě hledal práce, které se dotýkají celkové průjezdnosti různých (českých) měst na invalidním vozíku. Dále jsem se snažil zjistit, zda je pro vozíčkáře i dnes nedostatečná bezbariérovost stále problém. V neposlední řadě jsem hledal, zda se problém bariér někdo pokoušel řešit podobným způsobem. Ze získaných prací jsem usoudil, že problém fyzických bariér v životě vozíčkářů stále přetrvává. Toto lze doložit například výsledky průzkumu, který provedla ve své bakalářské práci Jitka Hantová. Na otázku, jak by tělesně hendikepovaní hodnotili bezbariérovost ve městě, v němž žijí, odpověděla necelá půlka respondentů známkou 3, při hodnocení 1 (nelepší) až 5 (nejhorší) (2 str. 34). Tato otázka zahrnuje jak fyzickou bezbariérovost v samotném městě, tak například bezbariérový přístup do administrativních nebo kulturních budov. Další výzkum provedený Bc. Kateřinou Volfovou za účelem vypracování diplomové práce o barierách ve městě České Budějovice ukazuje, že 41 % kulturních zařízení je pro hendikepované lidi zcela nedostupných (3 str. 60). Přestože aplikace by měla upozornit vozíčkáře i na budovu, která není přístupná, jejím hlavním smyslem by mělo být nalézt a upozornit na bariéry, na které narážejí vozíčkáři při průjezdu městem. Proto je dobré se podívat ještě na jednu otázku z výše zmíněného výzkumu, a to: Myslíte si, že nájezdy u chodníků jsou ve městě, kde žijete, dostačující? Na tuto otázku odpovědělo 81 % Ano a 19 % Ne (2 str. 38). Z toho vyvozuji, že existují alespoň nějaké bariéry, na které může vozíčkář během cestování po městě narazit. Dále jsem se snažil zjistit, zda se již někdo pokusil vyvinout podobnou aplikaci, tedy aplikaci, která by umožnila vozíčkářům nalézt vhodnou cestu a upozornit na bariéry, na které by mohli narazit při cestování po městě. K dispozici je ale bohužel pouze jedna práce, a to bakalářská práce Martina Biskupiče. V své práci spolupracoval se sdružením Liga vozíčkářů a jeho cílem bylo zobrazit jejich databázi přístupnosti objektů jako novou vrstvu v Google Maps1 . Z Martinova řešení by z technologické stránky šlo využít napojení objektů z databáze na Google Maps. V průběhu vývoje aplikace jsem se rozhodl zvolit jinou technologii (Bing Maps2) a nemohl tudíž využít Martinovo řešení.

Technologie Protože samotný vývoj aplikace je stěžejní část mé práce a chtěl bych, aby se řešení problémů, na které při vývoji narazím, dalo v budoucnu použít znovu a pomohlo při vývoji dalších aplikací, přikládám této rešerši největší význam. Vzhledem k tomu, že jednou z hlavních funkcí programu by mělo být zaznamenávání polohy uživatele pomocí GPS3, vyhledával jsem práce, které se dotýkají navigace a GPS, ve spojení s Windows Phone 7. Práci, která by zpracovávala toto téma, jsem ale bohužel nenašel. Nejspíše je to způsobeno tím, že platforma WP7 patří stále ještě mezi nejméně používané mobilní platformy (4). Přesto se poměrně mnoho prací zabývá fungováním systému GPS. Využil jsem informace z diplomové práce Bc. Karla Holana z VŠE, který srozumitelným způsobem popisuje GPS. 1 2

Google Maps – internetová mapa a technologie od společnosti Google Bing Maps - internetová mapa a technologie od společnosti Microsoft

Stránka | 11

Z této práce jsem načerpal poznatky, jak systém funguje a také jsem objevil možné problémy, na které bych mohl v průběhu vývoje narazit. Nyní krátce popíši, jak systém GPS funguje. Systém využívá k určení polohy soustavu družic, které krouží okolo Země, přičemž z každého bodu na Zemi by v jeden okamžik měly být viditelné nejméně 4 družice. Každá družice přitom vysílá signál o svém stavu a poloze. Tento signál se nazývá almanach. V almanachu se přenáší aktuální poloha družice a čas, kdy byl signál vyslán. Přijímač pak vypočítá časovou prodlevu mezi vysláním a přijetím zprávy a převede ji na vzdálenost. Ze čtyř vzdáleností (satelitů) pak může přijímač vypočítat aktuální polohu. Při příjmu signálu GPS ale může docházet k různým poruchám, při špatné viditelnosti na oblohu nebo v případě, že je přijímaný signál z družic několikerým odrazem (např. od budov) zkreslen. Proto zvláště ve městě může trvat dlouhou dobu, než přijímač dokáže určit svoji polohu. Je to také dáno tím, že přenos dat z GPS vysílače (družice) probíhá rychlostí 50 bps (5 stránky 811). Toto by v případě projektu aplikace mohl být vážný problém, protože málokdo chce před cestou čekat několik minut na nalezení své polohy mobilním telefonem. Pomoci rychlejšímu vyhledání polohy v mobilních telefonech má systém AGPS. Ten dokáže přes mobilní internetové připojení nebo jakékoliv jiné připojení k internetu mobilnímu telefonu zaslat informace o polohách družic a další informace nutné k vypočítání časového rozdílu při odeslání a přijetí zprávy almanachu. Tím umožňuje rychlejší vyhledání polohy (6). Bylo by tedy vhodné používat aplikaci na přístrojích, které nabízejí AGPS. Protože Microsoft podmiňuje užívání jejich mobilního operačního systému několika minimálními požadavky na hardware a jedním z nich je přítomnost AGPS (7), měly by být všechny přístroje, pro které má být aplikace dostupná, vybavené touto technologií.

2.3. Partneři V této kapitole seznámím čtenáře s partnery (subjekty), kteří se mnou na diplomové práci spolupracovali, a uvedu, jaký byl jejich přínos. Při výběru tématu diplomové práce bylo jedním z mých hlavních kritérií, aby práce byla ve spolupráci s nějakou firmou. Od spolupráce jsem si sliboval podporu při vývoji a zároveň jsem doufal, že výsledky práce budou užitečné a mohly by být použity v praxi. Také jsem ale vnímal, že nejenom časová náročnost diplomové práce by v tomto případě mohla být vyšší. Protože mě zajímají mobilní technologie, vybral jsem si nakonec téma Mobilní aplikace pro Windows Phone 7. Jak je zmíněno výše, celá diplomová práce byla prováděna ve spolupráci s mým spolužákem Vojtěchem Růžičkou. Zatímco já jsem vyvíjel část aplikace určenou pro mobilní telefon, Vojtěch Růžička vytvářel serverovou část. Jakou jsme použili metodiku pro vývoj softwaru a jak spolupráce probíhala, bude popsáno v další kapitole (Vývoj v týmu). Pro účely této kapitoly považuji sebe a Vojtěcha za jeden subjekt. Nyní krátce představím dva partnery, kteří se na práci podíleli, a následně popíši jejich úlohu.

Stránka | 12

Microsoft s.r.o. Česká pobočka nadnárodní americké společnosti Microsoft. Základní informace z obchodního rejstříku: Zapsána 18. září 1992, IČ: 47123737 Sídlo společnosti: BB Centrum, budova Alfa, Vyskočilova 1461/2a, Praha 4, PSČ 140 00 Předmět podnikání: Koupě zboží za účelem jeho dalšího prodeje a prodej Poskytování software Poradenská činnost v oblasti výpočetní techniky Zprostředkovatelská činnost v oblasti obchodu

GINA software Je to firma zabývající se mapovým softwarem. Informace z obchodního rejstříku: Zapsána 25. listopadu 2010 IČ: 292 54 191 Sídlo společnosti: Brno, U Vodárny 3032/2a, PSČ 616 00 Předmět podnikání: výroba, obchod a služby neuvedené v přílohách 1 až 3 živnostenského zákona Nyní popíši, jaká byla přesně role společností při vypracovávání práce. Prvním kontaktem se společností Microsoft byla registrace příslušného tématu (Windows Phone 7 + Windows Azure) na internetových stránkách k tomu určených (s2business.cz). Jako kontaktní osoba byl u tohoto tématu uveden Ing. Filip Řehořík. Toho jsem také po zapsání telefonicky kontaktoval a domluvil si s ním schůzku v sídle společnosti na Praze 4. Na schůzce se ukázalo, že toto téma je spíše okruh, na který by se diplomová práce mohla zaměřit a zadané téma není přímo spojeno s konkrétním projektem. Je tedy chápáno tak, že student diskutuje se zástupcem společnosti a společně pak téma upřesní a zhruba definují zadání. Výstupem ze schůzky a diskuze byl hrubý obrys aplikace, která by se měla zaměřit na využití map ve Windows Phone a spolupráci této aplikace se serverem. Na další schůzce mi pak bylo doporučeno spolupracovat se společností GINA Software, která se již v té době zabývala vývojem mobilní aplikace usnadňující koordinaci pracovníků v terénu. Ve spolupráci s GINA mělo být konkrétně zformulováno konečné zadání práce. Ing. Filip Řehořík zastupující Microsoft tedy spíše představuje prostředníka, který spojuje společnosti spolupracující s Microsoftem se studenty, kteří mají zájem zpracovávat diplomové práce, jejichž téma je spojené s technologiemi Microsoft. Je zde ovšem nutné uvést, že mi Microsoft nejprve na dobu jednoho měsíce zapůjčil telefon s Windows Phone 7 na testování. Výpůjčka mi pak byla

Stránka | 13

prodloužena na neurčitou dobu. Ing. Filip Řehořík se také zavázal, že pomůže aplikaci testovat. Se zástupcem společnosti GINA Software Ing. Zbyňkem Poulíčkem jsem se sešel několikrát a výsledkem našich jednání byly 2 možné verze zadání práce. První možnost byla konvertovat stávající verzi jejich aplikace určené pro koordinaci záchranářů v terénu, která běžela na systému Windows Mobile 6.5 na novou platformu Windows Phone 7 a Windows Azure. Druhé zadání, na kterém jsme se shodli, byla samostatná aplikace mapující trasy cyklistů a/nebo vozíčkářů. Toto zadání jsem si nakonec vybral proto, že se zde nabízelo více prostoru pro můj přínos a výzkumnou činnost. Ing. Zbyněk Poulíček přislíbil v obou případech výpomoc s vývojem. Především se mělo jednat o okruh problémů spojených s mapovou funkcionalitou klientské aplikace a dále problémem, jak vhodně vyřešit komunikaci klienta a serveru s ohledem na specifika mobilního klienta. Za tímto účelem jsme se několikrát sešli, ale v průběhu setkání se ukázalo, že rozdíly mezi novou platformou Windows Phone 7 a Windows Mobile 6.54 jsou tak velké, že lze jen těžko aplikovat znalosti získané vývojem na staré platformě na novou. Příliš informací ohledně problému, jak správně vyřešit komunikaci jsem bohužel také nezískal. Má aplikace totiž používá pro komunikaci Windows Communication Foundation5, zatímco aplikace firmy GINA využívají pro přenos dat jejich vlastní rozhraní postavené na protokolu SOAP. Další věc, o které jsem s GINA jednal, bylo poskytnutí testovacích dat, která jsem potřeboval do své aplikace vložit jako již uložené trasy a aplikaci pak s těmito testovacími daty vyzkoušet. V tomto mi společnost GINA vyšla vstříc a poskytla záznamy o pohybu záchranářů po zemětřesení na Haiti v roce 2010. Hlavní přínos subjektů, které se mnou spolupracovaly, spočíval v přesném definování zadání a v poskytnutí mobilního telefonu určeného k testování. Nemalý přinos pro práci představovalo také poskytnutí testovacích dat společností GINA. Celkově spolupráce probíhala v pořádku, menší problémy se vyskytly pouze při komunikaci s Ing. Filipem Řehoříkem, kdy bylo k domluvení schůzky nutné opakovaně psát e-maily a volat. Na druhou stranu je potřeba uvést, že bez zapůjčeného telefonu by bylo velice obtížné provést testování aplikace. Spolupráci s Microsoftem jsem si na začátku práce představoval spíše jako jasně zadaný úkol, který bude řešit nějaký problém z praxe. Nakonec se ukázalo, že spolupráce je míněna spíše jako podpora studenta, jehož zadání se kryje s okruhem technologií, které chce Microsoft předvést veřejnosti. Tento přístup mně osobně přijde poměrně logický a mohu říci, že jsem s ním byl spokojen.

4

Windows Mobile 6.5 – mobilní operační systém od Microsoft

Stránka | 14

3. Vývoj v týmu Cílem této kapitoly je objasnit, jak probíhal vývoj v týmu, jak a jaká metodika byla použita a stanovit hranici mezi klientskou a serverovou částí projektu.

3.1. Rozdělení práce V této kapitole objasním, jak jsme si rozdělili práci, kdy jsme spolupracovali a kdy práce probíhaly samostatně. Protože vypracovávání diplomových prací procházelo určitými fázemi, popsal jsem míru spolupráce pro každou fázi zvlášť Fáze příprav Tato fáze představuje vše od výběru diplomové práce po analýzu požadavků na výslednou aplikaci. Obsahuje tedy především jednání s Microsoft a GINA software, na těchto jednáních se upřesňovalo zadání obou prací a požadavky na ně. V této fázi jsem jednal vždy společně s Vojtěchem Růžičkou, protože rozhodnutí vždy ovlivňovala jak klientskou, tak serverovou část. Fáze návrhu V této fázi je zahrnut návrh samotné aplikace. To znamená detailní navržení funkcionality aplikace, návrh komunikace serverové a klientské části, časový plán vývoje a také definování Use Case scénářů. Návrh aplikace probíhal, stejně jako předchozí fáze, společně, protože pro bezproblémový vývoj bylo nutné se shodnout na všech výše zmíněných bodech. Fáze návrhu a implementace klientské / serverové části Fáze představuje v této práci návrh klientské aplikace a následně implementaci tohoto návrhu. V této fázi pracoval samozřejmě každý samostatně. Díky velké propojenosti obou částí ale byla nutná časová kooperace při implementaci jednotlivých funkčních celků na serveru / v klientu. Bližší informace o kooperaci v této části jsou v následující kapitole Metodika vývoje.

Stránka | 15

Fáze testování Tato fáze se prolíná s předchozí fází a obsahuje, jak již název napovídá, testování aplikace. To probíhalo samostatně, ale v případě chyby bylo často nutné spolupracovat, protože objevená chyba byla v mnoha případech v druhé části aplikace.

3.2. Metodika vývoje Cílem této kapitoly je popsat metodiku, kterou jsme používali při vývoji aplikace. Při výběru metodiky jsme stanovili několik základních požadavků, které musí vybraná metodika splňovat. Tím byla minimální časová náročnost na „administrativní“ práci spojenou s obsluhou metodiky. Zároveň bylo potřeba, aby metodika dokázala zohlednit to, že se v průběhu vývoje mohou měnit požadavky na aplikaci. Dále bylo požadováno, aby metodika, respektive její nástroje, dokázaly udržet kontrolu nad tím, kdo na čem pracuje, co bylo již uděláno a co zbývá udělat. Tento požadavek patřil mezi nejdůležitější, protože jsem předpokládal, že vývoj aplikace nebude probíhat v jednom časovém úseku, ale spíše v několika iteracích, přičemž v každé bude implementována nějaká funkcionalita. Protože vývoj aplikace vyžadoval specifický přístup, stanovili jsme si pravidla, tedy vlastně metodiku tak, že jsme si z různých agilních metodik vybrali to, co bylo pro náš vývoj vhodné. Vycházeli jsme přitom především z agilní metodiky SCRUM (8 stránky 27 - 36). Pojďme se podívat na základní pravidla, která jsme stanovili. Nastavili jsme iterace, které měly délku 14 dní. Na těchto 14 dní si každý stanovil, jakou funkcionalitu bude během iterace implementovat. Na konci každé iterace bylo naplánováno setkání, kdy jsme poslední iteraci zhodnotili, naplánovali úkoly pro další iteraci a v případě nedokončení některých úkolů (implementace funkcionality) přesunuli tyto úkoly do další iterace. Přestože vývoj neprobíhal konstantně po celou dobu práce, tyto iterace se vždy opakovaly po 14 dnech a v případě, že bylo jasné, že byl vývoj v iteraci pozastaven, převedli jsme úkoly do další iterace. Opakování iterací i v případě pozastaveného vývoje mělo vést k rychlejšímu vývoji (počítali jsme s tím, že bude nepříjemné každých 14 dní odkládat stejnou práci). Kromě iterací jsme stanovili další dvě pravidla, která bychom měli při vývoji dodržovat. Prvním z nich je pravidlo „Decide as late as possible“ z metodiky Lean Development. To znamená, že jsme se snažili rozhodovat vždy co nejpozději. Toto pravidlo bylo stanovené především proto, že v začátcích vývoje nebylo ještě úplně jasné, jak konkrétně jednotlivou funkcionalitu implementovat, a také proto, že se rychle měnily podmínky, v kterých probíhal vývoj (např. vydání nové verze Windows Phone). Poslední pravidlo, které jsme aplikovali, bylo tzv. „As early as possible“. To znamená vydat co

Stránka | 16

nejrychleji funkční verzi a k ní pak přidávat další funkcionalitu. Toto pravidlo jsme zavedli především kvůli testování. V praxi to pak znamenalo zveřejňování aplikace na Marketplace již v době, kdy byla implementována pouze základní funkcionalita. Po stanovení metodiky jsme vybírali vhodné nástroje, které by metodiku co nejlépe podporovaly. Jako základ jsme zvolili cloudovou službu Assembla6. Tato služba nabízí základní nástroje k týmovému vývoji software. Konkrétně jsme pak využili integrovaný verzovací systém SVN. Ten nám umožnil správu projektových souborů.

Dále jsme

z Assembla používali modul Scrum, který umožňuje správu jednotlivých iterací. To znamená, že lze pomocí něj vytvářet iterace a pro každou iteraci zadávat, na čem se pracovalo, na čem se bude pracovat v další iteraci a co brzdilo vývoj (problémy) v minulé iteraci. Druhým modulem v Assembla, který jsme se rozhodli využít, je modul Tickets. Ten umožňuje vytváření Ticket, který představuje nejčastěji implementaci nějakého funkčního celku. K němu pak lze psát komentáře a jakmile je funkční celek dokončen, ticket je uzavřen. Kromě Assembla jsme ještě využívali Dropbox7. Je to nástroj, který umožňuje sdílení souborů. Pro vývoj byl použit tím způsobem, že jsme se pomocí tohoto nástroje rozhodli sdílet soubory, které se vztahují k vývoji, ale zároveň to nejsou přímo soubory projektů. Příkladem souborů, které jsme sdíleli pomocí Dropbox, jsou například různé elektronické publikace, které se vztahují k vývoji. Před samotným vývojem, tedy v prvních fázích plánování jsme často využívali Microsoft OneNote8. Tento nástroj slouží k vytváření a správě poznámek a úkolů. Sdíleli jsme pomocí něj právě různé informace o schůzkách a hrubé časové plány vývoje aplikace. Pro komunikaci jsme si zvolili aplikaci Skype9. Tento program jsme si vybrali především proto, že umožňuje sdílení obrazovky, což bylo zejména při testování velmi důležité. V tomto odstavci se pokusím zhodnotit metodiku a nástroje, které jsme používali. Na začátku jsme uvažovali, zda bude opravdu nutné nějakou metodiku aplikovat. Při vývoji ve dvou lidech lze totiž poměrně snadno kontrolovat vývoj i bez různých nástrojů. Nakonec jsme se ale rozhodli metodiku využít a myslím, že to bylo dobré rozhodnutí. Je sice pravdou, že vývoj i bez použití metodiky by byl nejspíše poměrně transparentní a i funkční celky by byly implementovány v podobném pořadí, ale využití iterací a přidělování úloh pomocí ticket přineslo především lepší přehled o tom, jak se vyvíjelo. Díky tomu bylo například jasné, že

Assembla – cloudová aplikace sloužící k řízení vývoje software Dropbox – aplikace sloužící k sdílení souborů 8 Microsoft OneNote – aplikace sloužící k vytváření a správě poznámek 9 Skype – program sloužící ke komunikaci mezi dvěma a více uživateli 6 7

Stránka | 17

implementace nějakého funkčního celku trvá již nepřiměřenou dobu a je nutné provést nějakou akci, která by vývoj zrychlila (příkladem může být implementace šifrované komunikace). Hodnocení nástrojů, které jsme využívali je také poměrně příznivé, zejména musím vyzdvihnout Skype komunikaci se sdílenou obrazovkou, která znatelně přispěla k rychlejšímu řešení problémů. Nevýhodou vybraných nástrojů je, že ač se využití každého osvědčilo, bylo někdy obtížné kombinovat jejich funkčnost dohromady, zejména v případech, kdy se jejich funkcionalita překrývala (sdílení souborů pomocí Dropbox, soubory v OneNote). Spolupráci tedy hodnotím celkově kladně, metodika vývoje by ale jistě prošla větším „testem“ v případě, že by se na vývoji podíleli více než 2 lidé.

Stránka | 18

4. Analýza V této kapitole jsem specifikoval své úvahy a představy o dosažení stanovených cílů včetně časového rozvrhu a návrhu struktury aplikace:

4.1. Popis a cíle aplikace Představím podrobněji aplikaci a definuji cíle, kterých bych chtěl dosáhnout. Tyto cíle by měly být stanoveny tak, aby k jejich dosažení sloužila vyvinutá aplikace. Nejprve v obecné rovině definuji cíle, kterých by měl projekt dosáhnout. Při definování cílů se držím zásady, že stanovené cíle by měly být konkrétní, měřitelné, dosažitelné, relevantní ve vztahu k tématu a také dosažitelné ve stanoveném časovém horizontu. Cíle jsem rozdělil do dvou skupin. První a důležitější z obou skupin cílů je skupina vztažená k vývoji aplikace. Protože počet aplikací pro platformu Windows Phone 7 není stále příliš velký (9), předpokládám, že při vývoji narazím na problémy, jejichž řešení nebude nikde snadno dohledatelné. Tím spíše, že klientská aplikace bude komunikovat s webovou službou, která poběží v prostředí Windows Azure. Pokud se mi tyto problémy podaří vyřešit, mohlo by to být významným přínosem pro další vývojáře. Cíle jsem si v tomto případě stanovil dva. První je zobecnění zkušeností nabytých při vývoji aplikace a předání těchto zkušeností dalším vývojářům. Nemusí se přitom jednat přímo o vyřešení konkrétního problému, ale spíše o sumarizaci postupu při vývoji aplikace, vyvození závěrů a udělení konkrétních doporučení pro návrh a vývoj aplikací pro Windows Phone 7. Protože pro splnění tohoto cíle je velmi těžké stanovit tvrdé metriky, budu splnění cíle hodnotit měkkými metrikami, tedy pocitově. Platí přitom, že se budu snažit dosáhnout toho, aby doporučení byla co nejvíce zobecnitelná a využitelná v jiných aplikacích. Doporučení by také měla být chytrá a přinášet nový pohled na věc. Toto se opět bude poněkud složitě měřit a nezbývá, než spoléhat na úsudek. Druhý cíl v této skupině pak představuje vyřešení problémů, které se budou objevovat během vývoje. Pro to, aby byl tento cíl splněn, budu opět požadovat, aby byl řešen problém, který by se mohl vyskytnout v co nejširším spektru aplikací a zároveň nebyl ještě řešen, nebo byl řešen jiným způsobem. Druhá skupina cílů aplikace je spojena s aplikací samotnou a představuje užitek aplikace pro její uživatele. Hodnotit úspěch aplikace budu pomocí několika dílčích cílů. Prvním dílčím cílem jsem stanovil přínos pro její uživatele při plánování cest na kole nebo vozíku. Abych mohl změřit, zda jsem tohoto cíle dosáhnul, stanovil jsem si metriky, které

Stránka | 19

ukáží, zda byl cíl splněn. Metrikami jsou v tomto případě počet uživatelů aplikace a počet jejich cest odeslaný na server. Počet cest odeslaný na server je důležitý, protože z odeslaných cest se poté vypočítává vhodnost jednotlivých tras. Pro splnění cíle jsem stanovil minimální počet uživatelů 50 a také 50 uložených tras. Přestože stanovení přesných čísel se zdá dostačující, není tomu tak. Problémem je, že program bude dostupný ve všech zemích, kde lze stáhnout aplikace z Marketplace. Pokud by tedy aplikaci stáhlo např. 200 lidí, ale každý v jiném městě nebo státě, nebyl by přínos tak velký, jako například pouze 20 lidí z jednoho města. Při vyhodnocování splnění cíle je tedy ještě potřeba přidat jednu měkkou metriku, a to, zda jsou uložené trasy dostatečně blízko sebe a také zda se nějaké trasy překrývají. Cíl musí být také časově ohraničen. Chtěl bych proto, aby bylo výše zmiňovaných metrik dosaženo do 1 měsíce od zveřejnění aplikace na Marketplace. Druhým cílem je úspěch aplikace. Úspěchem by bylo, kdyby aplikaci používalo co nejvíce uživatelů a tito lidé byli s aplikací spokojeni. Úspěch budu opět měřit tvrdými a měkkými metrikami. Tvrdou metrikou pro splnění tohoto cíle jsem stanovil absolutní počet uživatelů, protože existuje vztah čím větší počet uživatelů, tím větší spokojenost uživatelů s aplikací. Za úspěšné splnění této metriky považuji opět počet 50 instalací aplikace. Další metrikou je průměrné hodnocení aplikace na Marketplace. Toto hodnocení provádějí uživatelé, a to udělením jedné až pěti hvězdiček. Jako úspěch jsem stanovil průměrné hodnocení nejméně 3 hvězdičky. Měkkou metrikou je pak slovní hodnocení aplikace. Toho hodnocení bude sbíráno ze stránky aplikace v Marketplace a následně vyhodnoceno jako pozitivní nebo negativní. Metriky budou vyhodnocovány opět po 1 měsíci. Třetím cílem je zajistit, aby byla aplikace kvalitní. To znamená, že aplikace bude stabilní a bude bezchybně fungovat na všech telefonech. Měřit kvalitu aplikace je poměrně složité a přesto, že jsem se snažil stanovit vhodné metriky, jak její kvalitu změřit, nelze se vyhnout určitému zjednodušení. Kvalitu aplikace jsem se rozhodl měřit opět pomocí tvrdých a měkkých metrik. Jako tvrdou metriku použiji počet pádů aplikace. Nelze však použít celkový součet pádů, protože ten je závislý na počtu instalací. V případě že by si aplikaci nikdo nenainstaloval, byl by samozřejmě počet pádů 0. To by ale neznamenalo, že je aplikace bezchybná. Proto jsem pro tuto metriku použil podíl instalací aplikace a jejích pádů. Za úspěch přitom považuji, pokud tento podíl bude větší nebo roven jedné. To znamená nejvýše jeden pád aplikace pro každého uživatele. Problém této metriky je, že nedokáže zohlednit počet pádů v čase. Pokud bude aplikace provozována delší dobu, bude vyšší riziko pádu aplikace, než v případě jednoho spuštění na 10 minut. Tento problém bohužel nelze nijak odstranit, protože Microsoft nenabízí zobrazení pádu v závislosti na délce spuštění aplikace. Druhou metrikou jsou komentáře uživatelů na stránce aplikace. V tomto případě ale budu

Stránka | 20

analyzovat komentáře týkající se především běhu aplikace. Nebudou tedy brány v potaz komentáře požadující rozšíření funkcionality aplikace apod. Cíle jsem pro přehlednost seřadil do tabulky (Tabulka 1 – Cíle aplikace). Tabulka 1 – Cíle aplikace

Identifikátor C-V01-01

Název cíle Poskytnutí zkušeností

C-V01-02

Řešení problémů

C-A01-01

Přínos aplikace

C-A01-02

Úspěch aplikace

C-A01-02

Kvalita

Popis Cílem je zobecnit zkušenosti nabyté při vývoji a udělit doporučení Cílem je tvůrčím způsobem vyřešit problémy při vývoji a toto řešení poskytnout veřejnosti Cílem je, aby bylo používání aplikace přínosné. Cílem je, aby byla aplikace na trhu úspěšná Cílem je zajistit co nejvyšší kvalitu aplikace

Metriky Udělená doporučení

Kreativně a úspěšně vyřešené problémy

Min. počet uživatelů:50 Min. počet tras:50 Blízkost tras Min. počet uživatelů:50 Min průměrné hodnocení: 3 Kladné komentáře Pády aplikace/Počet stažení < 1 Kladné komentáře

V tomto odstavci nastíním hrubý popis aplikace a její funkcionalitu tak, aby co nejlépe splňovala výše zmíněné cíle jak aplikace, tak celého projektu. Aplikace by tedy měla umožňovat trasovat cestu jejího uživatele a tuto cestu ukládat na server. Tyto cesty pak budou dostupné dalším uživatelům a měly by z nich jít vypočítat nejčastější (optimální) trasy při průjezdu městem. Aplikace bude umět uživateli zobrazit používané cesty v jeho okolí nebo v okolí místa, které uživatel vyhledá. To mu pomůže s plánovaním dalších tras. Myslím, že by nebylo rozumné se spolehnout na to, že uživatelé budou trasovat své cesty jenom proto, aby za nějakou dobu vznikla mapa průjezdnosti, přestože by jim mohla pomoci při jejich cestách v budoucnu. Protože pro posouzení průjezdnosti někdy nestačí pouze nabídnout používané trasy, aplikace by měla umožnit uživatelům přidat body, které upozorní ostatní uživatele na nějakou překážku nebo zvláštnost, se kterou je potřeba při plánování trasy počítat. Aplikace by však měla zaujmout při prvním použití, a přinést uživatelům přidanou hodnotu i v případě, že v databázi nebude dostatečný počet tras, které by mohly být uživateli nabídnuty při plánování. Touto přidanou hodnotou, která bude uživateli nabídnuta ihned po instalaci aplikace, je seznam jeho tras, které se ukládají na

Stránka | 21

server. Může si tedy svoje trasy ukládat na server a prohlížet si je pomocí webového nebo mobilního klienta. Aplikace také bude k trasám poskytovat základní údaje jako je délka trasy nebo čas potřebný k jejímu absolvování. U aplikace, která bude dostupná téměř po celém světě, hrozí, že počet uživatelů bude sice relativně velký, ale každý uživatel bude z jiného města nebo státu. Aby bylo toto riziko zmírněno, bude implementována možnost přidat ostatní uživatele aplikace jako své přátele. U nich uživatel uvidí jejich trasy a také kde byla naposledy zaznamenána jejich poloha. Díky funkci kamarádi by měl potenciální spokojený uživatel motivaci doporučit aplikaci i svým známým, kteří by s velkou pravděpodobností měli trasovat cesty ve stejném městě.

4.2. Globální analýza 4.2.1.

Uživatelské role a jejich požadavky

Protože aplikace má být zaměřena na dvě cílové skupiny uživatelů, popíši v této kapitole obě skupiny a nastíním, jaké budou rozdíly ve využívání aplikace. Aplikace bude zacílena na dvě skupiny uživatelů, tělesně postižené a cyklisty. Zprvu se může zdát, že obě skupiny nejsou příliš stejnorodými a vyvstává otázka, jak by mohl být projekt, při zachování stejné funkcionality, prospěšný pro obě skupiny. Z výše zmíněného vyplývá, že aplikace bude stejná pro skupinu vozíčkářů i pro skupinu cyklistů. Abych ukázal, že požadavky na funkcionalitu aplikace jsou pro obě skupiny podobné, definuji uživatelské požadavky každé skupiny. Cyklisté Pro tuto skupinu bude aplikace představovat jakýsi komplement k cyklocomputer. Pro zjednodušení budu uvažovat, že cyklocomputer měří při jízdě celkovou vzdálenost, aktuální rychlost a průměrnou rychlost. Zároveň budu uvažovat cyklistu, který má zájem měřit své trasy a tyto informace ukládat, případně sdílet na internetu. Bez použití aplikace má cyklista možnost ručně zapisovat statistiky o svých trasách a případně je sdílet na webu se svými přátele. Požadavky na aplikaci musí být definovány tak, aby bylo její použití pro cyklistu přínosem i v případě, že využívá cyklocomputer. Aplikace nemá nahradit cyklocomputer ale má představovat komplement, který rozšíří a zjednoduší možnosti ukládání informací o trase. Předpokládejme tedy, že cyklista požaduje minimálně takové informace o trase, jaké mu poskytuje jeho cyklocomputer. Z tohoto kritéria lze stanovit několik uživatelských požadavků a to: je nutné, aby aplikace měřila vzdálenost a čas jízdy. Protože uvažujeme cyklistu, který chce údaje o svých cestách

Stránka | 22

ukládat a publikovat, definuji další skupinu uživatelských požadavků s tímto spojených. Prvním z těchto požadavků je možnost ukládání informací o trasách na server a jejich archivace. Dalším uživatelským požadavkem je měření a uchovávání geografických informací o trase, tím je myšleno trasování cesty cyklisty a její následné uložení. Neméně podstatným uživatelským požadavkem je pak možnost zobrazit trasy na mapě ve webovém nebo mobilním klientu. Nyní poněkud více rozvedu uživatelský požadavek ukládání tras na server. Uživatel totiž chce pravděpodobně ukládat informace na server nejen proto, že pro něj budou snáze dostupné odkudkoli, ale také proto, aby tyto informace byly dostupné i ostatním uživatelům webu. Z toho je možné stanovit další, sociální skupinu požadavků na aplikaci. Hlavním požadavkem je v tomto případě možnost sdílet trasu s ostatními uživateli. Předpokládám, že většina uživatelů si nepřeje zveřejňovat informace (trasy) tak, aby byly veřejně dostupné, ale spíše si chce vybrat, s kým trasu sdílet. Toho lze nejlépe docílit tak, že si uživatel vytvoří skupinu přátel a s tou bude informace sdílet. Uživatelským požadavkem je v tomto případě možnost spravovat v aplikaci přátele a spravovat, jaký obsah s nimi chce uživatel sdílet. Obdobné požadavky jako všechny výše zmíněné jsou kladeny také na konkurenci pro tento projekt, myslím tím například Endomondo 10 nebo Runkeeper 11 . Potenciální uživatelé mé aplikace však kladou na aplikaci další požadavky. Díky uspokojení těchto požadavků by se měl můj projekt lišit od výše zmiňovaných aplikací. Těmito jsou možnost zobrazení využití jednotlivých cest ve městě a dle tohoto zobrazení možnost naplánovat trasu. Tento požadavek je kladen především cyklisty, kteří používají kolo jako dopravní prostředek po městě.

Vozíčkáři Při výzkumu dosavadních prací na téma možnost pohybu po městě jsem došel k názoru, že bezbariérovost je v českých městech stále problém (viz kapitola Dosavadní práce v dané oblasti). Vím, že tento projekt nemůže situaci nijak znatelně vylepšit, ale jeho cílem je pomoci alespoň několika vozíčkářům vybrat tu správnou trasu. Na začátku je třeba podotknout, že aplikace zřejmě nepomůže hendikepovaným, kteří plánují trasu na místo, kam cestu dobře znají, ale spíše lidem, kteří plánují cestu na místo, o jehož dostupnosti na vozíku nemají prakticky žádné informace. Projekt přitom počítá s určitou solidaritou hendikepovaných. Počítá s tím, že hendikepovaný, přestože se pohybuje známou cestou, 10 11

Endomondo – aplikace sloužící k trasování cest a jejich uveřejnění na webu Runkeeper – aplikace sloužící k trasování cest a jejich uveřejnění na webu

Stránka | 23

bude chtít tuto cestu označit za vhodnou tím, že ji zaznamená a uloží na server. Lze říci, že pro skupinu vozíčkářů je zde pouze jediný globální požadavek, a tím je právě nalezení vhodné trasy při cestě po městě. Z tohoto požadavku je ale nutné odvodit další požadavky. Nejprve je nutno uvést, že prakticky neexistuje žádná mapa která by zobrazovala, kvalitu a možnost průjezdnosti v jednotlivých ulicích. Toto platí pro Prahu, ale lze předpokládat, že takováto mapa neexistuje ani v jiných městech České republiky. Protože mapa neexistuje, je potřeba ji nějakým způsobem vytvořit. Toho lze dosáhnout právě trasováním cest a následnému výpočtu, která z cest je nejpoužívanější. Toto je tedy jeden z požadavků na aplikaci: možnost trasovat cestu a uložit ji na server. Při dostatečném počtu uložených cest pak může server hendikepovanému zobrazit trasy, které jsou nejpoužívanější, a tudíž by se na nich nemělo nalézat mnoho překážek a/nebo jsou nejvhodnější z možných tras. Protože ukládání cest a následné zobrazení četnosti jejich průjezdů nemusí být vždy jednoznačné a nelze pouze pomocí něj poradit vozíčkáři jakou zvolit vhodnou cestu, je nutné hledat ještě jinou možnost jak umístit do mapy informace o průjezdnosti. Z uživatelského hlediska se jeví jako nejlepší možnost ukládat do mapy textové informace umožňující popsat nějakou překážku v daném místě. Je to tedy další uživatelský požadavek: možnost vkládat do mapy body (body zájmu) a k těmto bodům přidávat informace o nich samotných a důvod, proč byl bod do mapy vložen. Dalším požadavkem je pak zobrazení toho bodu ostatním uživatelům takovým způsobem, aby při plánování trasy mohli vzít v potaz informace, na které tento bod upozorňuje.

Průnik zájmů Z výše uvedeného vyplývá, že požadavky obou skupin se téměř stoprocentně překrývají. Rozdíl je především v důležitosti, jakou skupiny jednotlivým požadavkům přikládají. Pro cyklisty je důležitější samotné trasování jejich cest a zobrazení cest jejich přátel. Jako výhodu oproti konkurenčním aplikacím pak mohou vnímat možnost vyhledání vhodné trasy po městě nebo zobrazení průjezdnosti jednotlivých ulic. Předpokládám ovšem, že důležitost, jakou přikládají oběma skupinám požadavků, je zhruba stejná. Naopak nepočítám s tím, že by se cyklisté příliš zajímali o možnosti přidávání bodů zájmu. U druhé skupiny, tedy vozíčkářů, předpokládám zájem především v možnosti zobrazení vhodné trasy a zobrazení informací uložených u bodů zájmu na mapě. Nepředpokládám časté využití funkce správy sdílení informací o vlastních trasách s přáteli.

Stránka | 24

V posledním odstavci této kapitoly bych chtěl krátce nastínit možnosti implementace řízení skupin uživatelů v aplikaci. V úvahu připadaly dva modely implementace. Prvním je vydat dvě verze stejné aplikace pod různým názvem. Výhoda toho řešení spočívá v možné úpravě jednotlivých verzí pro cílové skupiny. Druhou možností je vydat pouze jednu verzi aplikace a v aplikaci poté řídit každou konkrétní skupinu. Po zvážení výhod a nevýhod jednotlivých řešení jsem se rozhodl použít druhou možnost, tedy vydat pouze jednu verzi a správu skupin řešit přímo v aplikaci. To znamená, že všechny funkce aplikace budou dostupné všem skupinám. Přestože např. u vozíčkářů nepředpokládám časté využití správy přátel, nelze vyloučit opak a nebylo by rozumné o tuto nebo kteroukoliv jinou funkci některou ze skupin připravit. V projektu bude tento přístup řešen tak, že uživatel při zakládání svého účtu vybere, jakou skupinu chce používat (cyklista, tělesně hendikepovaný) a podle tohoto výběru bude následně klient využívat data z té které skupiny. 4.2.2.

Uživatelské požadavky dle subsystému

V této kapitole popíši požadavky na obě části aplikace, tedy na mobilního i webového klienta. Požadavky jsou definovány z uživatelského hlediska. To znamená, že se nezabývají použitou technologií nebo platformou, ale zaměřují se na možnosti, které oba dva klienti musí uživateli nabídnout. Protože požadavky na oba klienty se v mnohém překrývají, připravil jsem tabulku (Tabulka 2 – Uživatelské požadavky na klienty), která ukazuje, zda je uživatelský požadavek kladen na webového, nebo mobilního klienta, případně na oba.

Stránka | 25

Tabulka 2 – Uživatelské požadavky na klienty

Uživatelský požadavek

Mobilní klient Ano

Webový klient Ne

Možnost synchronizovat trasy se serverem tak aby, když se uživatel přihlásí v jiném telefonu, než trasu uložil, byla jeho trasa viditelná

Ano

Ne

Možnost zobrazit již uložené trasy na mapě

Ano

Ano

Možnost smazat uloženou trasu

Ano

Ano

Zjistit délku trasy a dobu, za jakou byla absolvována

Ano

Ano

Zobrazit na mapě bod zájmu podle polohy uživatele

Ano

Ne

Zobrazit na mapě body zájmu podle aktuálního zobrazení na mapě Možnost přidat komentář k bodu zájmu

Ne Ano

Ano Ano

Možnost vytvořit bod zájmu

Ano

Ano

Klient musí uživateli zobrazit pouze data odpovídající typu účtu uživatele (vozíčkář, cyklista)

Ano

Ano

Možnost automaticky zobrazovat průjezdnost tras v okolí uživatele

Ano

Ne

Automaticky zobrazovat trasy podle aktuálního zobrazení na mapě Možnost spravovat své přátele

Ano Ano

Ne Ano

Možnost zobrazit poslední polohu přátel

Ano

Ano

Možnost vytvořit uživatelský účet

Ano

Ano

Možnost zobrazit kartu přátel s přehledem o jejich cestách

Ano

Ano

Možnost přiřadit ke svému účtu obrázek

Ano

Ne

Možnost odesílat trasu na server

4.2.3. Procesní mapa Procesní mapa znázorňuje hlavní byznys procesy i podpůrný byznys proces. Hlavní byznys procesy jsou znázorněny barevně, podpůrný byznys proces je znázorněn šedou barvou. Hlavní byznys procesy tvoří byznys model řešení s tím, že jsou seřazeny podle relativní blízkosti k zákazníkovi. Zákazníkem je v tomto případě myšlen jakýkoliv uživatel aplikace. Proces Správa tras představuje uchovávání uložených tras a jejich zpracování takovým způsobem, aby z nich bylo poté možné vytvořit model průjezdnosti. Proces Správa uživatelských informací představuje všechny procesy, které jsou spojené

Stránka | 26

s interakcí konkrétního uživatelského účtu a aplikace. Cílem těchto procesů je, aby uživatele práce s aplikací bavila, často se k ní vracel a doporučil ji svým přátelům. Mezi tyto procesy patří procesy spojené s využíváním přátel a prohlížením uživatelových tras. Třetím hlavním procesem je proces Poskytování informací o průjezdnosti. Přestože lze proces zahrnout do předchozího hlavního byznys procesu, je zde uveden zvlášť ze dvou důvodů. Prvním z nich je, že se jedná o poskytování informací bez návaznosti na konkrétní uživatelský účet. Druhým důvodem je pak fakt, že tento proces patří mezi nejdůležitější byznys procesy a na jeho kvalitě závisí celkový úspěch projektu.

Správa tras Správa uživatelských informací

Hodnocení

Poskytování informací o průjezdnosti Správa uživatelských účtů Obrázek 1 – Procesní mapa

Aby byl projekt úspěšný, je důležité brát v úvahu zpětnou vazbu a hodnocení projektu (aplikace) jejími zákazníky. Toto hodnocení bude probíhat za pomoci nástrojů v Marketplace. Podpůrným procesem je v tomto případě Správa uživatelských účtů. Proces představuje správu uživatelů a jejich dat ze strany uživatelů. Se správou uživatelských dat prostřednictvím administrace se v této verzi aplikace nepočítá.

Stránka | 27

4.2.4.

Use Case diagram

Use Case diagram představuje model systému při pohledu zvnějšku, tedy při pohledu uživatele na systém. Zachycuje tak požadavky uživatele na systém.

Obrázek 2 – Use case diagram

Stránka | 28

4.2.5.

Use Case scénáře

Use Case scénáře popisují detailněji interakci uživatelů (actor) při práci se systémem. V případě níže uvedených scénářů je ve většině případů stejný scénář pro Uživatele – Mobilního klienta i Uživatele – Webového klienta. Toto je možné, protože Use Case scénáře mají představovat logiku ovládání jednotlivých prvků a měli by abstrahovat od konkrétní implementace. V případě, že se Use Case scénář pro oba typy uživatelů liší, je to ve scénáři výslovně uvedeno. Tabulka 3 – Use Case Přidávat přátele

Název: Přidávat přátele Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Přidávající uživatel vybere v menu položku Přátele 2. Přidávající uživatel vybere akci Přidat přítele 3. Přidávající uživatel zadá jméno vyhledávaného nebo jeho e-mailovou adresu 4. Systém zobrazí uživateli výsledky hledání 5. Přidávající uživatel vybere přidávaného uživatele a potvrdí přidání 6. Systém zobrazí přidávanému uživateli potvrzení přátelství mezi přidávaným a přidávajícím 7. Přidávaný uživatel potvrdí přátelství 8. Systém zobrazí přidávanému i přidávajícímu uživateli přidávaného / přidávajícího v seznamu přátel Výstupní podmínky Přidávaný uživatel v seznamu přátel přidávajícího uživatele Chybový scénář Přidávaný uživatel není zobrazen v seznamu přátel

Stránka | 29

Tabulka 4 – Use Case Mazat přátele

Název: Mazat přátele Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Uživatel vybere v menu položku Přátele 2. Uživatel vybere mazaného přítele v seznamu přátel 3. Systém zobrazí uživateli detailní informace o mazaném příteli 4. Uživatel vybere akci smazat přítele 5. Systém zobrazí uživateli dotaz o potvrzení smazání přítele 6. Uživatel potvrdí smazání přítele 7. Systém odstraní smazaného přítele ze seznamu přátel Výstupní podmínky Smazaný kamarád je odstraněn ze seznamu přátel Chybový scénář Mazaný kamarád není smazán ze seznamu přátel

Stránka | 30

Tabulka 5 – Use Case Prohlížet přátele

Název: Prohlížet přátele Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Uživatel vybere v menu položku Přátele 2. Uživatel vybere hledaného přítele v seznamu přátel 3. Systém zobrazí uživateli následující informace o hledaném příteli a. Uložené trasy s informacemi, jak je trasa dlouhá, odkud vedla, jak dlouho trvalo její absolvování b. Fotografii (avatar) hledaného přítele c. Poslední známou polohu hledaného přítele Výstupní podmínky Detailní informace o hledaném příteli jsou zobrazeny Chybový scénář Neproběhne zobrazení detailních informací o hledaném příteli

Stránka | 31

Tabulka 6 – Use Case Přidávat trasy

Název: Přidávat trasy Aktéři: Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Systém vyhledá uživatelovu polohu 2. Systém zpřístupní uživateli akci Ukládání jeho trasy 3. Uživatel vybere akci Ukládání jeho trasy 4. Uživatel zastaví ukládání trasy 5. Systém se zeptá uživatele, zda chce s ukládáním trasy pokračovat, trasu zrušit nebo trasu uložit 6. Uživatel vybere akci Uložit trasu 7. Systém uloží trasu a zajistí další informace o trase Výstupní podmínky Uživatelova trasa je uložena a zobrazena v seznamu tras Chybový scénář Neproběhne uložení a trasa není zobrazena v seznamu uživatelových tras

Stránka | 32

Tabulka 7 – Use Case Zobrazovat trasy

Název: Zobrazovat trasy Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Uživatel vybere v menu akci Trasy 2. Systém zobrazí uživateli přehled jeho tras a u každé trasy zobrazí následující podrobnosti a. Délku trasy b. Kde trasa začíná, kde trasa končí c. Čas potřebný k absolvování trasy 3. Uživatel vybere akcí Zobrazit trasy ty trasy, které chce zobrazit na mapě 4. Systém zobrazí požadované trasy na mapě Výstupní podmínky Požadované trasy jsou zobrazeny na mapě Chybový scénář Požadované trasy nejsou zobrazeny na mapě

Stránka | 33

Tabulka 8 – Use Case Mazat trasy

Název: Mazat trasy Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Uživatel vybere v menu akci Trasy 2. Systém zobrazí uživateli přehled jeho trasy 3. Uživatel vybere akci Smazat trasu 4. Systém zobrazí požadavek o potvrzení smazání trasy 5. Uživatel potvrdí smazání 6. Systém smaže trasu Výstupní podmínky Mazaná trasa není zobrazena v seznamu uživatelových tras, ani na mapě Chybový scénář Trasa je zobrazena buď v seznamu uživatelových tras, nebo na mapě

Stránka | 34

Tabulka 9 – Use Case Vytvářet uživatelský účet

Název: Vytvářet uživatelský účet Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Základní scénář: 1. Uživatel vybere akci Vytvořit účet 2. Uživatel vyplní uživatelské jméno, heslo, jméno, e-mail a typ účtu 3. Uživatel vybere akci Registrovat uživatele 4. Systém zkontroluje zadané údaje 5. Systém vytvoří nový účet a přihlásí uživatele Výstupní podmínky Nový uživatelský účet je vytvořen a uživatel se pomocí tohoto účtu může přihlásit Chybový scénář Uživatelský účet není vytvořen a uživatel se nemůže přihlásit

Stránka | 35

Tabulka 10 – Use Case Získávat informace o průjezdnosti

Název: Získávat informace o průjezdnosti Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: Informace dle zadané adresy (Uživatel - Mobilní klient) 1. Uživatel vybere akci zobrazit průjezdnost dle aktuální polohy 2. Systém vyhledá uživatelovu polohu 3. Systém vyhledá průjezdnost v okolí uživatelovy současné polohy 4. Systém zobrazí na mapě vrstvu průjezdnosti Alternativní scénář: Informace dle aktuálního zobrazení mapy (Uživatel – Webový klient) 1. Uživatel vybere akci Zobrazovat průjezdnost 2. Systém detekuje aktuální pohled na mapě 3. Systém vyhledá průjezdnost dle aktuálního pohledu 4. Systém zobrazí na mapě vrstvu průjezdnosti Výstupní podmínky Vrstva průjezdnosti je zobrazena na mapě Chybový scénář Vrstva průjezdnosti není zobrazena na mapě

Stránka | 36

Tabulka 11 – Use Case Měnit uživatelskou fotografii

Název: Měnit uživatelskou fotografii Aktéři: Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Uživatel vybere v menu akci Nastavení 2. Uživatel vybere akci Vyfotit uživatelskou fotografii 3. Uživatel vyfotí fotografii 4. Uživatel vybere akci Jít zpět 5. Systém uloží uživatelovu fotografii Výstupní podmínky Uživateli je přiřazena fotografie Chybový scénář Uživateli není přiřazena fotografie Tabulka 12 – Use Case Přidávat body zájmu

Název: Přidávat body zájmu Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Uživatel vybere akci Přidat bod zájmu 2. Uživatel vyplní název bodu zájmu 3. Uživatel vyplní popis bodu zájmu 4. Uživatel vybere akci Uložit bod zájmu 5. Systém zkontroluje vložené hodnoty a bod uloží Výstupní podmínky Nový bod zájmu se zobrazí na mapě Chybový scénář Přidávaný bod zájmu není zobrazen na mapě

Stránka | 37

Tabulka 13 – Use Case Zobrazovat body zájmu

Název: Zobrazovat body zájmu Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: Zobrazit bod zájmu dle mapy 1. Uživatel vyhledá bod zájmu na mapě 2. Uživatel vybere akci Zobrazit informace o bodu zájmu 3. Systém zobrazí následující informace a. Jméno bodu zájmu b. Popis bodu zájmu c. Komentáře bodu zájmu Alternativní scénář: Zobrazit bod zájmu se seznamem bodů zájmu 1. Uživatel vybere akci Zobrazit seznam bodů zájmu 2. Uživatel vybere jeden bod zájmu 3. Systém ukáže bod zájmu na mapě 4. Systém zobrazí následující informace o bodu zájmu a. Jméno bodu zájmu b. Popis bodu zájmu c. Komentáře bodu zájmu Výstupní podmínky Zobrazení informací o bodu zájmu Chybový scénář Informace o bodu zájmu se neobrazí

Stránka | 38

Tabulka 14 – Use Case Komentovat body zájmu

Název: Komentovat body zájmu Aktéři: Uživatel – Webový klient, Uživatel – Mobilní klient Vstupní podmínky Registrovaný uživatel, Autorizovaný uživatel Základní scénář: 1. Uživatel zobrazí bod zájmu dle scénáře Zobrazovat body zájmu 2. Uživatel vloží komentář 3. Uživatel vybere akci odeslat komentář 4. Systém zkontroluje odesílaný komentář 5. Systém uloží komentář Výstupní podmínky Nový komentář je zobrazen u příslušného bodu zájmu Chybový scénář Nový komentář není zobrazen u bodu zájmu

4.3. Detailní analýza V detailní analýze budu transformovat konceptuální model do návrhu modelu na technologické úrovni. To znamená, že zde představený model bude muset respektovat implementační prostředí aplikace (použité technologie). Protože použitá technologie byla vybrána již zadáním práce, bylo cílem především transformovat konceptuální model z GAN tak, aby byla jeho implementace možná v prostředí Windows Phone 7 a Windows Azure. 4.3.1.

Architektura aplikace

V této kapitole bude popsána softwarová architektura aplikace. Popis hardwarové architektury aplikace jsem vynechal, protože celá serverová část běží v cloudu a jejímu bližšímu popsání se věnuje diplomová práce Vojtěcha Růžičky. Pokud bychom se tedy oprostili od serverové části v cloudu, zbývá pouze klient. Na následujícím obrázku (Obrázek 3 – Softwarová architektura) je vidět softwarová architektura aplikace. Přestože se tato práce zabývá především klientskou částí, krátce zde popíši i moduly aplikace na serveru. Z toho si bude moci čtenář vytvořit

Stránka | 39

komplexnější představu o aplikaci. Serverová část, jak již bylo řečeno, běží v cloudu, konkrétně na platformě Azure. Tato platforma by se dala zařadit Platform as a Serivice služeb. To znamená, že je přímo poskytováno prostředí pro vývoj aplikací. Zákazník se tedy nezajímá o vlastní hardwarovou architekturu. Výhodou cloudových řešení a tedy i této platformy, je její vysoká škálovatelnost. Uživatel nebo systém může regulovat počet instancí aplikace, které běží současně. Přitom platí, že čím větší počet instancí, tím lépe je zvládána zátěž, ale zároveň za každou instanci musí zákazník platit. Počet běžících instancí lze přitom velmi rychle regulovat. Výhodou je také to, že platforma Azure se snaží zajistit co největší stabilitu tím, že jsou jednotlivé instance geograficky rovnoměrně rozloženy po celém světě. Běh více instancí najedou umožňuje provádět aktualizace aplikace bez jejího dočasného vyřazení z provozu. Na následujících řádcích bude popsán každý modul aplikace.

Obrázek 3 – Softwarová architektura

Windows Phone 7 klient Na platformě Windows Phone 7 poběží klientská aplikace, pomocí níž uživatel přistupuje k funkčnosti Windows Azure. Protože lze u mobilního klienta přepokládat, že nebude mít neustále k dispozici připojení k Azure ani k internetu, je nutné aby klient poskytoval základní funkce i při přerušeném spojení a po obnovení dokázal data s Azure synchronizovat. Vývoj tohoto klienta je hlavní náplní této práce, a proto se budu jeho architektuře věnovat v dalších kapitolách.

Stránka | 40

Silverlight klient Je to klient, který k běhu využívá platformu Silverlight. Poběží na straně uživatele v prohlížeči. Klient se přitom na straně uživatele nebude ukládat, ale při každém spuštění bude znovu stažen ze serveru. Klient samotný bude přenesením Windows Phone klienta na Silverlight platformu. Web klient Bude představovat jednoduchou webovou prezentaci. Ta bude uživateli doručena jako soubor statických stránek, který je zobrazen v prohlížeči. Tato prezentace bude hostována na Azure. Web klient bude využívaný především pro sdělení informací o aplikaci uživatelům, kteří nejsou registrováni a / nebo přistupují k aplikaci z jiného operačního systému než MS Windows. Windows Communication Foundation Role Tato služba bude postavena na bázi Windows Communication Foundation (WCF) platformy. Tato platforma je určena k vývoji servisně orientovaných aplikací. V tomto případě bude služba představovat front-end pro mobilního i webového klienta. Služba bude definovat metody nebo také služby, které mohou klienti volat a prostřednictvím těchto služeb pracují s Azure. Dále bude definovat i datové objekty, které jsou použity pro přenos informací mezi klientem a službou. Služba bude využívat některých výhod Azure, jako jsou Load Balancing12 a ochrana proti selhání. Sql Azure Je to databáze, která běží na platformě Windows Azure. Přestože Windows Azure nabízí ještě další typy úložišť, např. Blob storage (představuje náhradu souborového systému), bude pro ukládání dat použita pouze Sql Azure databáze. Jedná se o relační databázi, která jako backend13 využívá SQL Server 200814. Výhodou tedy je, že dotazy do databáze lze provádět pomocí jazyka T-SQL. Worker Role Slouží k náročnějším výpočtům, které se provádějí na pozadí. Nemělo by se jednat o úlohy, kdy je potřeba uživateli co nejrychleji vrátit hodnotu. Tato část by měla zpracovávat úlohy, které jsou náročné na výpočty, ale není příliš důležité, jak rychle bude Load balancing – vhodné rozložení zátěže mezi více hardware Backend – běžící na pozadí 14 SQL Server 2008 – databázový systém od Microsoft 12 13

Stránka | 41

úloha zpracována. V aplikaci se využívá pro výpočet průjezdnosti jednotlivých tras. Úlohy, zpracovávané v Worker Role, jsou nahrávány z Azure. 4.3.2.

Architektura klienta

Cílem této kapitoly je popsat architekturu klienta takovým způsobem, aby po přečtení bylo jasné, z jakých komponent se bude klient skládat a jak mezi sebou budou jednotlivé komponenty komunikovat. Při návrhu softwarové architektury klienta jsem si stanovil dva základní požadavky, které by měla architektura splňovat. Prvním požadavkem na architekturu je její přehlednost a čitelnost pro programátora. Přehlednost a čitelnost je důležitá především proto, že výsledná aplikace bude poměrně komplexním a zároveň komplikovaným celkem. Při nedodržení tohoto požadavku by se pak vývoj mohl výrazně prodloužit a znesnadnit. Druhým požadavkem na aplikaci, respektive její architekturu je zajištění snadné přenositelnosti a znovupoužití kódu. Toto je důležité ze dvou důvodů. Prvním z nich je nutnost vývoje webové a mobilní verze klienta. Oba tito klienti by měli v zásadě nabízet stejnou funkcionalitu (viz kapitola Use Case scénáře). Z tohoto důvodu jsem se rozhodl, že nejprve bude vyvinut mobilní klient a ten následně upraven na webového klienta. Toto přenesení bude probíhat v iteracích, které budou ohraničeny ucelenou funkčností mobilního klienta. Snadná přenositelnost je také důležitá proto, že jedním z hlavních cílů této diplomové práce je vhodným způsobem vyřešit problémy, na které v průběhu vývoje narazím a jejich řešení popsat a nabídnout dalším vývojářům. Důležitá je přitom míra, do jaké lze nalezená řešení zobecnit. Je jasné, že tato míra by měla být co největší a právě vhodná architektura aplikace by toto měla z části zajistit. Pojďme se nyní podívat na navrženou architekturu aplikace (Obrázek 4 – Softwarová architektura klienta).

Obrázek 4 – Softwarová architektura klienta

Stránka | 42

Prezentační vrstva Prezentační vrstva představuje rozhraní, které zajišťuje interakci s uživatelem. Tato vrstva nebude držet žádnou logiku. Zároveň bude specifická pro webového i mobilního klienta. Konkrétní implementaci na platformě Windows Phone 7 i Silverlight bude představovat popis uživatelského rozhraní pomocí značkovacího jazyka (XAML). Logika uživatelského rozhraní Představuje spojení mezi logikou aplikace a její prezentační vrstvou. Toto spojení bude zajištěno tím, že vrstva kontroluje objekty vykreslené prezentační vrstvou. Zároveň je v této vrstvě řízen běh programu. Řízení bude probíhat tak, že uživatel provádí interakci s prezentační vrstvou. Události zachycené v prezentační vrstvě budou zpracovány v logice uživatelského rozhraní a dle konkrétní události bude volána funkční část ve vrstvě aplikační logika. Modely V této vrstvě budou drženy modely objektů, s kterými bude aplikace pracovat. Modely, které budou v této vrstvě drženy, budou představovat model cesty, model bodu zájmu a model uživatele. Pro každý typ modelu bude vytvořen seznam, který se bude starat o jednotlivé instance modelu. Samotný model přitom žádnou logiku držet nebude. Budou v něm uloženy pouze informace popisující skutečný objekt. Seznam, ve kterém budou drženy jednotlivé instance modelů by přitom měl obsahovat pouze logiku, která se přímo váže k modelům, které seznam drží. Aplikační vrstva by měla umožňovat přístup k modelům všem ostatním vrstvám. Aplikační logika Aplikační logika bude držet logiku funkcí, které bude aplikace nabízet. Může to být načítání, přidávání nebo mazaní přátel, správa bodů zájmu nebo správa tras. Aplikační logika bude přitom rozdělena do několika částí podle skupiny funkcí, které bude část obstarávat. Metody v této vrstvě budou nejčastěji volány z logiky uživatelského rozhraní a budou pracovat s modely uloženými ve vrstvě modely.

Stránka | 43

4.3.3.

Detailní specifikace procesů

V této kapitole detailně popíši procesy uvedením krátkého popisu procesu, základních informací o průběhu procesu, uvedením vstupů a výstupů a zákazníka a vlastníka procesu. Kapitolu Detailní specifikace procesů doplňuje následující kapitola Procesní modely. Přečtení obou kapitol by mělo čtenáři přinést základní informace o propojení funkcí aplikace a tím jak jsou tyto funkce implementovány z dynamického hlediska. Tabulka 15 – Specifikace procesů Přidání trasy

Název: Přidání trasy Popis procesu Tento proces ukazuje, jakým způsobem bude prováděno přidávání trasy. Přidáváním trasy je myšlen proces, kdy se zákazník rozhodne ukládat svoji trasu a tuto trasu následně uložit v klientu a případně na serveru. Základní informace Proces začíná zákazníkovým rozhodnutím o uložení jeho trasy (cesty) a spuštěním aplikace. Následuje zjišťování zákazníkovy polohy. Poté, co je zákazník lokalizován, pokračuje proces spuštěním akce ukládání trasy. Trasa je ukládána po dobu, než je proces ukládání zastaven zákazníkem. Po zastavení je trasa uložena do úložiště v mobilním klientu. Klient se následně pokusí uložit trasu na server. V případě úspěchu této akce je serverem vrácena délka trasy, která je zobrazena zákazníkovi. Po pokusu o uložení trasy na server v obou případech proces končí. Zákazník procesu Registrovaný uživatel Vstupy Typy dokladů a datových vstupů: požadavek na uložení trasy Předpokládané počty: jeden Termín pro zpracování: ihned Výstupy Typy dokladů a datových výstupů: trasa Předpokládané počty: jeden Termín pro zpracování: ihned Vlastník procesu Vít Čurda

Stránka | 44

Tabulka 16 – Specifikace procesů Načtení trasy

Název: Načtení trasy Popis procesu Tento proces popisuje způsob, jakým jsou načítány zákazníkovy trasy po spuštění aplikace. Proces pokrývá načítání tras v případě prvního přihlášení zákazníka procesu v daném klientovi i v případně dalších zákazníkových přihlášení. Základní informace Proces začíná zákazníkovým požadavkem na spuštění aplikace. Po spuštění jsou automaticky načteny uživatelovy trasy z úložiště v mobilním klientu. V případě, že nejsou žádné trasy uloženy, může uživatel načíst své trasy ze serveru. Pokud se uživatel rozhodne načíst trasy ze serveru, klient se pokusí trasy uložit do svého úložiště. V případě úspěchu, tedy když jsou trasy na serveru uloženy, jsou tyto trasy načteny v klientu. V případě neúspěchu nejsou trasy načteny. Zákazník procesu Registrovaný uživatel Vstupy Typy dokladů a datových vstupů: uložené trasy Předpokládané počty: nula až mnoho Termín pro zpracování: ihned Výstupy Typy dokladů a datových výstupů: trasa Předpokládané počty: nula až mnoho Termín pro zpracování: ihned Vlastník procesu Vít Čurda

Stránka | 45

Tabulka 17 – Specifikace procesů Načtení možných tras

Název: Načtení možných tras Popis procesu Tento proces zobrazuje způsob, jakým je zákazníkovi dodávána informace o možnosti průjezdu jednotlivých tras v jeho okolí. Tato informace by mu měla pomoci při rozhodování o volbě vhodné trasy při plánování cest. Základní informace Proces začíná zákazníkovým požadavkem na zjištění informací o vhodnosti jednotlivých tras a spuštěním aplikace. Po spuštění se čeká na zvolení hledání vhodných tras. Následně se zjišťuje poloha zákazníka proto, aby mu mohla být doručena co nejpřesnější informace. Poté následuje odeslání požadavku na server. Server vyhledá vhodné trasy a v případě nalezených tras jsou tyto trasy vráceny klientovi a zobrazeny na jeho mapě. Zákazník procesu Registrovaný uživatel Vstupy Typy dokladů a datových vstupů: informace o vhodnosti trasy Předpokládané počty: jeden Termín pro zpracování: ihned Výstupy Typy dokladů a datových výstupů: informace o vhodnosti trasy Předpokládané počty: nula až mnoho Termín pro zpracování: ihned Vlastník procesu Vít Čurda

Stránka | 46

Tabulka 18 – Specifikace procesů Přidání POI

Název: Přidání POI Popis procesu Tento proces zobrazuje postup, jakým může zákazník do systému přidat bod zájmu. Základní informace Proces začíná zákazníkovým požadavkem na přidání bodu zájmu do mapy. Tento požadavek je většinou vyvolán potřebou upozornit na nějaký bod na mapě. Po spuštění aplikace zákazník vyhledá místo, kam chce bod zájmu přidat. Pokud je místo vyhledáno, zákazník přidá bod zájmu a vyplní jeho jméno a popis. Poté zákazník bod zájmu uloží. Klient se pokusí uložit bod zájmu na server. V případě úspěchu je bod zájmu zákazníkovi zobrazen. V případě neúspěchu bod není zobrazen. Zákazník procesu Registrovaný uživatel Vstupy Typy dokladů a datových vstupů: informace o POI Předpokládané počty: jeden Termín pro zpracování: ihned Výstupy Typy dokladů a datových výstupů: POI uložený v databázi Předpokládané počty: jeden Termín pro zpracování: ihned Vlastník procesu Vít Čurda

Stránka | 47

Tabulka 19 – Specifikace procesů Zobrazení POI

Název: Zobrazení POI Popis procesu Tento proces zobrazuje mechanismus, jakým jsou zákazníkovi dodávány informace o bodech zájmu v jeho okolí. Základní informace Proces začíná zákazníkovým požadavkem na zobrazení bodů zájmu v jeho okolí a spuštěním aplikace. Následně klient zjišťuje, kde se zákazník nachází, aby bylo možné dodat přesné informace. Po vyhledání zákazníkovy polohy se čeká, až zákazník spustí akci Zobrazení POI. Po spuštění akce klient kontaktuje server s požadavkem na vyhledání bodů zájmu v okolí zákazníka. Pokud jsou nějaké body zájmu nalezeny, server je vrátí klientovi a ten tyto body zobrazí na mapě a v seznamu bodů zájmu. Zákazník procesu Registrovaný uživatel Vstupy Typy dokladů a datových vstupů: informace o poloze POI Předpokládané počty: nula až mnoho Termín pro zpracování: ihned Výstupy Typy dokladů a datových výstupů: zobrazený POI Předpokládané počty: jeden Termín pro zpracování: ihned Vlastník procesu Vít Čurda

Stránka | 48

Tabulka 20 – Specifikace procesů Přidání přítele

Název: Přidání přítele Popis procesu Tento proces zobrazuje postup jakým je v aplikaci řešeno přidávání přátel. Základní informace Proces začíná požadavkem žádajícího zákazníka procesu na přidání příjemce žádosti mezi své přátele. Dalším krokem po požadavku je spuštění aplikace a následně spuštění akce vyhledávání přátel. Poté žádající vyplní formulář, kam zadá jméno, uživatelské jméno nebo e-mail příjemce žádosti a spustí akci vyhledání záznamů. Pokud jsou nalezeny nějaké záznamy, klientská aplikace je zobrazí. Pokud nejsou záznamy nalezeny, může uživatel vyhledávat znovu. V případě nalezení záznamů pak žádající vybere příjemce žádosti o přátelství. Po spuštění klienta příjemcem je mu zobrazena zpráva o žádosti o přátelství. Pokud je žádost příjemcem akceptována, je příjemce přidán mezi přátele žádajícího a opačně. Pokud je žádost o přátelství odmítnuta, je tato žádost vymazána. Zákazník procesu Registrovaný uživatel, žádající; Registrovaný uživatel, příjemce žádosti Vstupy Typy dokladů a datových vstupů: Informace o poloze POI Předpokládané počty: nula až mnoho Termín pro zpracování: ihned Výstupy Typy dokladů a datových výstupů: zobrazený POI Předpokládané počty: jeden Termín pro zpracování: Ihned Vlastník procesu Vít Čurda

Stránka | 49

Tabulka 21 – Specifikace procesů Zobrazení přítele

Název: Zobrazení přítele Popis procesu Tento proces zobrazuje postup jakým je v aplikaci řešeno načítání a zobrazování přátel zákazníka. Základní informace Proces začíná uživatelovým požadavkem na jakoukoliv interakci s aplikací. Po spuštění aplikace je automaticky iniciován proces načítání přátel ze serveru. Pokud nejsou žádní přátelé nalezeni, proces končí. V opačném případě se pro každého přítele zjišťuje jeho poslední známá pozice. V případě, že je pozice nalezena, je tento přítel zobrazen na mapě v klientovi. V obou případech je pak přítel zobrazen v seznamu přátel. Zákazník procesu Registrovaný uživatel Vstupy Typy dokladů a datových vstupů: požadavek uživatele Předpokládané počty: jeden Termín pro zpracování: ihned Výstupy Typy dokladů a datových výstupů: zobrazení přátelé Předpokládané počty: nula až mnoho Termín pro zpracování: ihned Vlastník procesu Vít Čurda

Stránka | 50

Tabulka 22 – Specifikace procesů Přihlášení uživatele

Název: Přihlášení uživatele Popis procesu Tento proces zobrazuje postup, jakým probíhá přihlašování zákazníka procesu do aplikace. Základní informace Proces začíná zákazníkovým požadavkem na aplikaci. Po inicializaci aplikace kontroluje klient, zda byl zákazník již v minulosti přihlášen. V případě úspěchu je uživatel automaticky přihlášen s údaji použitými při předchozím přihlášení. V opačném případě se může uživatel rozhodnout, zda se chce přihlásit, nebo vytvořit nový účet. V případě přihlášení uživatel zadá své údaje a spustí akci přihlášení. Jeho údaje jsou na serveru zkontrolovány a v případě správných údajů je uživatel přihlášen. V opačném případě je vyzván k opakovanému zadání údajů. Pokud chtěl uživatel vytvořit nový účet, vyplní registrační formulář. Ten je zkontrolován klientem a serverem. V případě, že kontrola proběhne úspěšně, je uživatel zaregistrován a přihlášen. V opačném případě je vyzván k opětovnému vyplnění registrace. Zákazník procesu Registrovaný uživatel Vstupy Typy dokladů a datových vstupů: požadavek uživatele Předpokládané počty: jeden Termín pro zpracování: ihned Výstupy Typy dokladů a datových výstupů: přihlášený uživatel Předpokládané počty: jeden Termín pro zpracování: ihned Vlastník procesu Vít Čurda

4.3.4.

Procesní modely

Tato kapitola navazuje na předcházející kapitolu definující procesy a doplňuje ji modely těchto procesů. Cílem není zachytit detailně každý proces, ale poskytnout modely s takovou granularitou, aby bylo jasné, jak přesně bude aplikace reagovat při výskytu nejčastějších / nejdůležitějších událostí.

Stránka | 51

Přidání trasy

Obrázek 5 – Proces přidání trasy

Stránka | 52

Načtení trasy

Obrázek 6 – Proces načtení trasy

Stránka | 53

Načtení možných tras

Obrázek 7 – Proces načtení možných tras

Stránka | 54

Přidání POI

Obrázek 8 – Proces přidání POI

Stránka | 55

Zobrazení POI

Obrázek 9 – Proces zobrazení POI

Stránka | 56

Přidání přítele

Obrázek 10 – Proces přidání přítele

Stránka | 57

Zobrazení přátel

Obrázek 11 – Zobrazení přátel

Přihlášení uživatele

Obrázek 12 – Přihlášení uživatele

Stránka | 58

5. Teoretický základ 5.1. Představení Windows Phone 7 V této kapitole představím mobilní operační systém Windows Phone 7, na němž běží mobilní klient. Nejprve popíši historii systému a poté se podívám na systém z uživatelského hlediska a seznámím s ním čtenáře. 5.1.1.

Historie Windows Phone 7

Protože systém Windows Phone 7 nevznikl bez předchůdce, je dobré se podívat, jaký systém mu předcházel, jaké byly jeho výhody, nevýhody a proč musel být nakonec nahrazen, z hlediska uživatelského rozhraní, kompletně novým systémem. Dalo by se říci, že historie Windows Phone začíná v roce 2000 (10), kdy Microsoft začíná nabízet operační systém určený pro handheldy. Tímto systémem je PocketPC 2000. Systém využívá jádro z desktopového operačního systému Windows 9515. Jeho uživatelské rozhraní je přizpůsobeno pro ovládání dotykovým perem, tzv. stylusem. V základní programové výbavě systému byly obsaženy mobilní verze textového procesoru Microsoft Word 16 a tabulkového procesoru Microsoft Excel 17 . Mobilnímu zařízení byl také přizpůsobený webový prohlížeč Internet Explorer18. Zařízení vybavené tímto operačním systémem však ve většině případů nejsou vybavena GSM modulem. Pokud výrobce chce, aby bylo možné handheld používat jako mobilní telefon, musí ho vybavit vlastní telefonní aplikací. Aktualizace operačního systému přišla v říjnu 2001. Tato verze přinesla speciální edici pro handheldy vybavené GSM modulem. Další verze systému pak byla představena v roce 2003. Microsoft přejmenoval tuto novou verzi na Windows Mobile 2003. Přibylo několik nových aplikací a důležitou novou funkcí byla možnost otáčení zobrazení displeje. Zajímavostí této i všech předchozích verzí bylo, že celý systém byl uložen v paměti typu RAM. Toto řešení zajišťovalo poměrně rychlou odezvu systému a téměř okamžité spuštění. Nevýhodou ovšem bylo, že v případě vybití baterie přestala být paměť napájena a nastavení systému byla smazána. Microsoft proto nabízel poměrně sofistikované nástroje na zálohu celého systému. Následující verze systému se objevila v roce 2005. V této verzi byl systém přesunut do Flash paměti, takže při vybití baterie Windows 95 – desktopový operační systém od Microsoft Microsoft Word – textový procesor od Microsoft 17 Microsoft Excel – tabulkový procesor od Microsoft 18 Internet Explorer – Webový prohlížeč od Microsoft 15 16

Stránka | 59

nedocházelo k vymazání celého systému. Následující verze byly představeny v roce 2007 (Windows Mobile 6) a 2009 (Windows Mobile 6.5). Obě tyto verze pak nepřinesly do mobilní platformy Microsoft žádné velké funkční změny. Právě to se ale tomuto operačnímu systému stalo osudným. V roce 2007 začíná Apple prodávat iPhone19 a o rok později Google nabízí výrobcům mobilních telefonů mobilní operační systém Android20. Windows Mobile začíná díky této silné konkurenci ztrácet podíl na trhu (). Podíl Windows Mobile na trhu přitom znázorňuje červená křivka. Lze se domnívat, že za neúspěchem tohoto operačního systému stálo především uživatelské rozhraní, u nějž design ovládacích prvků pocházel ještě z první verze PocketPC 2000. Microsoft se tento nedostatek pokusil napravit v poslední verzi 6.5 a její aktualizaci na 6.5.3, kde některé prvky zvětšil a implementoval listování seznamem pomocí gest. Přesto tato, dle mého názoru nepříliš povedená, aktualizace nedokázala zaujmout větší počet zákazníků a podíl Windows Mobile stále klesal. Proto v roce 2010 Microsoft představuje úplně novou verzi mobilního operačního systému Windows Phone 7. Při prezentaci Microsoft představuje nový systém, jako OS určený do vyšší kategorie mobilních telefonů. Levnější modely se přitom stále měly nabízet se systémem Windows Mobile. Tento předpoklad Microsoftu se však nenaplnil a od uvedení nového systému byly téměř všechny telefony uvedené na trh vybaveny systémem Windows Phone 7. Přesto že nový systém měl znamenat a také nejspíše znamenal alespoň pro Microsoft revoluci, prodeje telefonů vybavených tímto systémem nelze co do objemu porovnávat s konkurenční platformou Apple nebo Googlu. 5.1.2.

Uživatelské rozhraní

Jak již bylo řečeno, Windows Phone se od svého předchůdce výrazně odlišuje. Uživatelské prostředí, které operační systém používá, nazývá Microsoft Metro. Protože uživatelské rozhraní je určitě jednou z nejdůležitějších inovací oproti Windows Mobile, popíši krátce principy toho rozhraní. Styl, jaký Metro prezentuje, nazývá Microsoft Metro Design Languague. To znamená, že Metro má být jazykem, jak popsat / vytvořit uživatelské rozhraní, které by splňovalo požadavky, jež definoval Microsoft a které, opět dle Microsoft, požadují zákazníci od uživatelského rozhraní. Pokud bych zde měl uvést základní filozofii Metro (11), je to odklon od vytváření uživatelského rozhraní pro uživatelské rozhraní. Při definování Metro bylo bráno jako nejdůležitější, co uživatelé od rozhraní očekávají. Uživatelským požadavkem je pak

19 20

iPhone – chytrý telefon od Apple Android – mobilní operační systém od Google

Stránka | 60

Obrázek 13 – Podíl na trhu mobilních operačních systémů

potřeba „dostat“ se do nějakého bodu / k nějaké informaci. Z toho vyplývá, že uživatelské rozhraní slouží především k navigaci. Microsoft se tedy podíval do reálného světa a zjistil, že k navigaci lidé nejčastěji používají různé nápisy a značky, u nichž je dominantní informace, kterou značka přináší. Naopak značky ve většině případů neobsahují žádné přebytečné obrázky / barvy atd., jsou navíc poměrně univerzální, takže lze snadno přečíst značky téměř po celém světě. Dále Microsoft zjistil, že jsou značky navrhovány tak, aby byla informace na nich uvedená co nejlépe čitelná. Touto skutečností se tedy Microsoft inspiroval u návrhu svého uživatelského rozhraní. Metro tedy definuje několik principů (12), které by měly být dodrženy při návrhu aplikace. Všechny tyto principy jsem se také pokusil aplikovat při vývoji Windows Phone klienta. Prvním principem je Clean, Light, Open, Fast. Dle tohoto principu by uživatelské rozhraní mělo být navrženo tak, aby bylo zaměřené na nejčastější použití aplikace, dále aby uživatel na každý vstup (dotek ovládacího prvku) dostal okamžitě odezvu a především aby neobsahovalo příliš mnoho ovládacích prvků a bylo jednoduché a intuitivní. Druhým principem je Celebrate Typography. To Albert Shum (12) vysvětluje jako nutnost nepoužívat typografii jenom jako nutný popis, ale chce zdůraznit, že typografie může být hezká a musí uživatele zaujmout. Dalším principem je Alive, not motion. Tento požadavek na uživatelské rozhraní lze vysvětlit jako využívání animací / pohybů v grafickém rozhraní za účelem zpřehlednění aplikace. Primárním cílem v tomto případě není, aby se animace prostředí uživateli líbily. Animace při pohybu v uživatelském prostředí by, dle Microsoft, měly především ukázat, odkud uživatel přišel, tedy myšleno z jaké obrazovky a dále nabídnout

Stránka | 61

pohled / náhled na informace, kam by mohl směřovat. Předposledním principem, který Microsoft deklaruje je, Content, Not Chrome. Tento princip se snaží apelovat na vývojáře aplikací, aby design jejich aplikace předkládal uživatelům především jejich informace / data. To je to, co uživatel chce vidět, nikoliv různé rámečky nebo ikonky. Prakticky to pak znamená například zobrazení uživatelových obrázků na pozadí aplikace Fotogalerie nebo zobrazení informací z aplikace na Tile. Tile přitom tvoří odkaz buď na aplikaci, nebo na nějaké místo v aplikaci. Poslední princip Authentically digital nabádá vývojáře, aby do uživatelského rozhraní aplikace vtiskli image své značky tak, aby se podle designu uživatelského rozhraní aplikace dala určit podobnost s ideami vývojáře. Microsoft ještě dále apeluje na vývojáře, aby při návrhu uživatelského rozhraní počítali s navigací pomocí hardwarových tlačítek. Prakticky to pak znamená, že by se v uživatelském rozhraní nemělo objevovat tlačítko zpět a pokud ano, mělo by mít stejnou funkci jako hardwarové tlačítko zpět. Je také třeba počítat s tím, že uživatel bude moci vždy stisknout hardwarové tlačítko zpět a to by ho mělo vždy vrátit na předchozí krok.

5.1.3.

Windows Phone 7 – Základní informace

V této kapitole se podívám na Windows Phone z vývojářského hlediska. Nastíním, jaké jsou možnosti vývoje, a popíši strukturu tohoto operačního systému. Při vývoji aplikace je vždy potřeba zohlednit hardware, na kterém aplikace poběží. Platí přitom, že čím různorodější hardware, tím složitější může být aplikaci optimalizovat tak, aby byla zkušenost uživatele s aplikací na všech typech hardwaru stejná. Proto Microsoft požaduje po výrobcích hardwaru (mobilních telefonů), aby jejich přístroje splňovaly několik minimálních požadavků (13). Tyto požadavky výrazně determinují podobu výsledného produktu. Jaké jsou tedy minimální požadavky na telefon, který využívá Windows Phone 7? Je to nutnost přítomnosti 3 hardwarových tlačítek na čelní straně telefonu. Těmito tlačítky jsou Vyhledávání, tlačítko Start, které vrací uživatele do základní nabídky, a tlačítko Zpět, které vrací uživatele na předchozí obrazovku. Žádné z těchto tlačítek přitom nelze v programu řídit, ale je nutné, aby vývojář počítal s tím, že uživatel může kdykoliv jedno z tlačítek stisknout a tím vypnout aplikaci. Standardem je také obrazovka, která musí mít rozlišení 800 x 480 pixelů. Toto je velká výhoda pro vývojáře, protože díky jednotnému rozlišení lze přesněji rozmístit ovládací prvky. Naopak nevýhodou tohoto řešení je jistá rigidnost. Zatímco v současné době není problém vyrobit displeje s vyšším rozlišením a konkurenční systémy tyto displeje podporují (14), mobilní telefony využívající Windows Phone musí mít stále nižší

Stránka | 62

rozlišení obrazovky. Obrazovka také musí být vybavena kapacitní dotykovou vrstvou, která dokáže rozpoznat nejméně 4 místa dotyku současně. Dále programátor může počítat s připojením k internetu pomocí mobilní sítě a Wi-Fi. Všechny telefony vybavené Windows Phone 7 musí mít instalováno nejméně 256 MB paměti RAM. To se může zdát málo. Dle mého názoru je to ústupek Microsoftu, který chtěl umožnit výrobcům mobilních zařízení používat tento operační systém i v levnějších přístrojích. Pokud ovšem vývojář nechce optimalizovat aplikaci pro přístroje s 256 MB paměti, může to při vydání aplikace deklarovat a aplikace pak nebude pro takovéto přístroje dostupná. Každý přístroj musí být také vybaven A-GPS přijímačem. To je pro účely této práce důležité, protože není potřeba nijak omezovat telefony, na kterých bude aplikace dostupná. Posledním požadavkem směřovaným k výrobcům mobilních telefonů je nutnost vybavit přístroj senzorem otočení přístroje.

Obrázek 14 – Windows Phone 7 Model architektury

Ozřejmil jsem čtenáři, na jakém hardwaru operační systém Microsoftu běží. Nyní krátce popíši architekturu systému a popíši možnosti vývoje aplikací. Systém je rozdělen do několika modulů, které navzájem spolupracují (Obrázek 14 – Windows Phone 7 Model architektury). Application runtime představuje v tomto případě Framework, který aplikace využívá. Windows Phone přitom nabízí 2 základní typy Framework, přičemž oba využívají prostředí .NET. První možností je využít Framework XNA. Aplikace napsané v tomto frameworku zobrazují na displeji výstup v podobě bitmapových obrázků. Zároveň Framework ulehčuje práci s 3D objekty. Proto je tento Framework zaměřen spíše na vývoj her. Druhou možností je využití Silverlight. Tento framework je zaměřen na vývoj aplikací a jako jeho základ je použit Silverlight 4, známý z desktopového prostředí. Poslední možností je pak využít kombinaci obou framework. Pojďme se ale ještě podívat na model architektury. Zatímco aplikace „sedí“ v Application runtime, Application model řídí jejich

Stránka | 63

běh. Každá aplikace totiž běží v takzvaném sandboxu. To znamená, že je izolována od zbylých částí systému a nemá například přístup k filesystému Windows Phone. UI model se stará o navigaci v systému tak, že drží historii pohybu uživatele v systému a stará se například o to, aby se uživatel po stisku hardwarového tlačítka zpět dostal na požadovanou obrazovku. Cloud integration modul se, jak již z názvu vyplývá, stará o synchronizaci přístroje s webovými službami (Live, Facebook, Twitter, Google). Kromě toho zajišťuje tento modul také přijímání, zpracování a zobrazení notifikací. Kernel pak představuje jádro systému, které zprostředkovává pomocí různých ovladačů propojení mezi hardwarem a zbylými částmi systému.

6. Implementace Tato část se věnuje implementaci aplikace. Konkrétní implementace je detailně popsána s tím, že při popisu jsem se snažil zdůraznit ty skutečnosti, které mohou pomoci dalším vývojářům. Každá podkapitola by tedy měla poradit při vývoji aplikací. V kapitolách je rozebrán vývoj aplikace od návrhu struktury až po zveřejnění na Marketplace. Pro každou fázi vývoje jsem se snažil napsat krátké doporučení, které by mělo shrnovat mé poznatky z dané fáze. Protože vývoj probíhal primárně pro mobilního klienta a tato aplikace byla následně přepracována pro webového klienta, budou všechny kapitoly zaměřeny primárně právě na vývoj mobilního klienta. Pokud budou mezi oběma verzemi aplikace odlišnosti, bude na ně upozorněno.

6.1. Struktura programu Cílem této kapitoly je seznámit čtenáře se strukturou aplikace. Protože aplikace má být poměrně robustní a zároveň musí být kód přehledný, bylo nutné věnovat návrhu značnou pozornost. Požadavky na strukturu aplikace, které jsem si na začátku stanovil, jsou v první řadě zajištění přehlednosti kódu. To proto, že v budoucnosti počítám s dalším vývojem aplikace a zároveň je zde možnost, že aplikace bude vyvíjena dalšími vývojáři. Požadavkem, jehož priorita je jen o něco nižší než požadavku na přehlednost kódu, je požadavek, aby byl kód znovupoužitelný. V praxi to pak znamená oddělovat od sebe jednotlivé logické části tak, aby je bylo možno použít i v jiných aplikacích. To by měl být jeden z přínosů mé práce. Struktura by také měla být navržena tak, aby ji bylo možné snadno přenést na jinou platformu. V tomto případě se jedná konkrétně o Microsoft Silverlight. Pro aplikaci to pak znamená důsledné oddělování logiky aplikace od její grafiky. Základní architektura (Obrázek 4 – Softwarová architektura klienta) je popsána v kapitole Architektura klienta. Tento návrh zde detailněji popíši a vysvětlím, jak jsem postupoval při jeho implementaci.

Stránka | 64

6.1.1.

Modely

Nejprve seznámím čtenáře s balíčkem Modely. V tomto balíčku jsou obsaženy třídy, které představují modely objektů z „reálného“ světa. K těmto modelům se pak přistupuje ze všech ostatních částí aplikace. V aplikaci jsou vytvořeny modely přátel, tras, komentářů a bodů zájmu. Konkrétně je pak implementace řešena tak, že pro každý model jsou vytvořeny 2 třídy. První z nich představuje samotný model, například přítele. Jména těchto tříd se skládají ze spojení jména třídy (např. friend) a koncovky model, tedy FriendModel. Druhá třída představuje seznam, v kterém jsou drženy jednotlivé instance tříd představujících přímo model. Jména těchto tříd jsou opět spojením typu modelu a tentokrát koncovky List, například FriendList. V těchto třídách je kromě instancí modelů držena také logika, která je nutná pro správu seznamu modelů. Nejčastěji jsou proto obsaženy metody, které se starají o vymazání modelu, přidání modelu nebo výběru konkrétní instance modelu. Nabízí se zde otázka, jestli je nutné vytvářet pro seznam modelů speciální třídu. Mazání nebo přidávání do seznamu (kolekce) je totiž možné přímo voláním metod seznamu. V případě této aplikace však bylo vytvoření samostatné třídy představující seznam instancí téměř nutné, a to z dvou důvodů. Tím prvním je implementace nových funkcí pro správu kolekce, která je v seznamu držena. Příkladem je seznam komentářů, kde se při přidávání komentáře konvertuje datový typ pole byte na obrázek (BitmapImage). Druhým, ale neméně důležitým důvodem je možnost implementovat rozhraní INotifyPropertyChanged. Co to ale vlastně znamená? Díky tomuto rozhraní je vždy při změně některého z atributů třídy vyvolána událost, která informuje, jaký atribut byl změněn. Jak implementovat toto rozhraní je popsáno detailněji v kapitole Rozhraní INotifyProperityChanged. Prozatím stačí říci, že díky tomuto rozhraní je snadné přiřadit jednotlivé atributy třídy k prvkům uživatelského rozhraní. Pro základní představu o jednotlivých modelech zde uvedu, jaké atributy tyto modely mají. V závorce je uveden název atributu třídy. Pro detailnější prozkoumání kódu je nutné se podívat do přílohy. Model představující přítele (FriendModel) obsahuje tyto atributy: přihlašovací jméno (username), jméno (name), obrázek uživatele (avatar), poslední známá lokace (lastLocation), naposledy přihlášen (lastSeenOn), seznam tras (tracks), počet tras (numberOfTracks). Model bodu zájmu drží tyto atributy: lokace bodu zájmu (nocation), jméno (name), popis (desc) a id. Model komentáře obsahuje datum jeho vytvoření (date), obrázek (image), jméno uživatele, který ho vytvořil (username) a komentář (comment).

Stránka | 65

6.1.2.

Aplikační logika

Při návrhu architektury aplikace jsem řešil, jak docílit co největšího oddělení logiky aplikace od její grafiky. Považoval jsem to za nutné z důvodu lepší čitelnosti kódu a také proto, aby bylo aplikaci možné co nejsnadněji přepracovat na webovou verzi. Určitá míra oddělení uživatelského rozhraní a kódu je standardně obsažena v Silverlight. Uživatelské rozhraní je psáno v značkovacím jazyce XAML zatímco logika je uložena v kódu, který je psán v některém z jazyků .NET. Toto uspořádání tedy umožňuje pohodlně vzít vrstvu uživatelského rozhraní a libovolně ji přenášet. Mým požadavkem však byla možnost co nejsnadněji přenést logiku s tím, že uživatelské rozhraní bude nutné znovu napsat. Proto jsem potřeboval zajistit, aby logika, která se nachází v takzvaných code-behind souborech byla co nejvíce vázána pouze na uživatelské rozhraní. Toho jsem docílil tím, že jsem vytvořil ještě jednu vrstvu, která drží logiku aplikace. Tato vrstva obsahuje třídy FriendControl, TrackControl, PoiContol, IsolatedStorage, User, Settings a ValidatedClient. Nyní

krátce

seznámím

čtenáře

s tím,

jaká

logika

je

v jednotlivých

třídách

implementována. Třídy jsem rozdělil do dvou skupin. První z nich obsahuje třídy FriendsControl, TrackControl a PoiControl. Třídy drží funkce, které jsou ve vztahu s modely uvedenými v předchozím odstavci. Tyto třídy jsou statické. To znamená, že nelze vytvořit jejich instanci. Třídy obsahují metody, které nejsou přímo spojeny s jednotlivými instancemi modelů, ale jejichž metody s typy modelů souvisí. Pro představu zde uvedu nejdůležitější funkční celky, které jsou v těchto třídách obsaženy. Prvním zástupcem je třída FriendControl. Ta se, jak z názvu vyplývá, stará o logiku spojenou se správou přátel. To znamená především správu přidávání a načítaní přátel a správu žádostí o přátelství. Třída PoiControl spravuje body zájmu a poslední třída z této skupiny, TrackControl, se stará o správu všech typů tras, které jsou v aplikaci přítomné. Mezi její funkce tedy patří Správa uživatelových tras a také načítání doporučených tras. Logika obsažená v těchto třídách je specifická pro tuto aplikaci a proto není bohužel možné vytvořit zobecnění a dát doporučení pro vývoj dalších aplikací. Druhá skupina tříd, IsolatedStorage, SettingsClass, ValidatedClient a User, představuje logiku, která není spjata přímo s konkrétním modelem, ale je používána všemi modely a části aplikace. Nejprve popíši třídu SettingsClass. Protože nastavení aplikace, tím rozumím logika nastavení, ne jednotlivé položky, se v mnoha aplikacích může opakovat, lze můj koncept použít i v dalších projektech založených na technologii WP7 nebo Silverlight. Při návrhu nastavení jsem vycházel z toho, že třída představující nastavení musí jednotlivá nastavení uchovávat, a zároveň má celá aplikace pouze jedno nastavení. Je tedy potřeba

Stránka | 66

zajistit aby nebylo možné vytvořit několik instancí této třídy. Protože položky nastavení se často mění, je nutné zajistit, aby byla jejich editace co nejsnadnější. Posledním požadavkem pak je aby se nastavení při každé změně okamžitě uložilo do úložiště telefonu nebo desktopového Silverlight. Tento požadavek je stanoven Microsoftem. Ten doporučuje ukládat potřebné objekty anebo soubory do úložiště okamžitě a ne až při ukončování programu, protože by to mohlo zdržovat ukončení a zhoršovalo uživatelovu zkušenost s aplikací. Abych vyhověl všem požadavkům, tak jsem při návrhu třídy použil návrhový vzor jedináček. Ten zajišťuje, že je v aplikaci možné vytvořit pouze jednu instanci třídy SettingsClass. Implementace tohoto návrhového vzoru probíhá tak, že je ve třídě vytvořen atribut Instance, který je stejného typu jako třída. Tento atribut zároveň musí být statický. To proto, aby k němu šlo přistoupit bez vytvoření instance třídy. Veřejná část atributu instance pak v případě, že atribut ještě nebyl zavolán, vytvoří novou instanci privátní části. V případě, že již volána byla, vrátí již vytvořenou instanci. Konstruktor třídy musí být privátní, aby bylo možné vytvořit instanci třídy pouze jednou a to přistoupením k atributu Instance dané třídy. Instanci třídy není možné vytvořit klasickým mechanismem, kde se instance vytváří pomocí klíčového slova new.

Obrázek 15 – Návrhový vzor jedináček

Požadavek, aby byly hodnoty uložené ve třídě co nejrychleji uloženy, jsem vyřešil tím, že každé nastavení, které třída drží, představuje atribut třídy. U té je při nastavení hodnoty, v takzvaném Setteru zavolána metoda, která toto nastavení ukládá do úložiště. Protože samotné ukládání probíhá asynchronně, nepředstavuje tato operace téměř žádné zpomalení aplikace. Posledním požadavkem je, aby bylo snadné spravovat jednotlivé položky nastavení. Toho jsem docílil tak, že jsem ve třídě implementoval rozhraní INotifyPropertyChanged . To zajišťuje, že v případě změny hodnoty atributu, je vyvolána událost s názvem atributu, který byl změněn. Celý koncept funguje tak, že v uživatelském

Stránka | 67

rozhraní je každá položka nastavení přiřazena k nějakému ovládacímu prvku. V případě, že uživatel změní nastavení ovládacího prvku na požadovanou hodnotu (tedy hodnotu, kterou chce nastavit), je tato hodnota automaticky nastavena také atributu třídy a automaticky uložena do úložiště. Díky implementaci rozhraní INotifyPropertyChanged je pak automaticky změněna i hodnota ve všech ovládacích prvcích, kde je tento atribut použit. IsolatedStorage je třída, která obsluhuje Isolated storage. IsolatedStorage představuje ve Windows Phone 7 / Silverlight úložiště, tedy jakousi náhradu disku. Do toho úložiště lze ukládat soubory, využít databázi, kterou nabízí nebo ukládat přímo objekty použité v aplikaci. Isolated storage tvoří vrstvu mezi souborovým systémem telefonu / počítače, takže program nepřistupuje přímo k souborovému systému, ale je pro něj vytvořen sandbox, který je vyhrazen pouze pro daný program. Díky tomu nemůže program narušit data jiných aplikací nebo přímo operačního systému. V mé třídě IsolatedStorage jsem implementoval logiku, která s tímto úložištěm pracuje. Při implementaci jsem se snažil, aby byly metody obsažené v IsolatedStorage, co nejuniverzálnější a bylo je možné znovu použít. Vytvořil jsem proto dvojici metod, v jejichž parametrech předávám třídě ukládaný / načítaný objekt a také název, pod kterým se má uložit. Do úložiště se ukládají, kromě nastavení, také uživatelovy trasy a status aplikace. To je nutné, protože mobilní aplikace může být kdykoliv vypnutá (Windows Phone7 nezná multitasking) a v některých případech je nutné uložit stav, v jakém se nachází. Kromě toho zajišťuje třída ukládání uživatelova obrázku (avataru). Nyní čtenáře seznámím s třídou ValidatedClient. Tato třída zajišťuje vytváření a správu klientů, pomocí nichž se klient připojuje k serveru. Této problematice se budu podrobněji věnovat v další kapitole Problémy a jejich řešení. Zde uvedu, jaká logika je v této třídě implementována. Protože je žádoucí, aby v celé aplikaci byla pouze jedna instance této třídy a právě ta spravovala klienty, použil jsem při návrhu návrhový vzor jedináček. V případě, že je potřeba kontaktovat server, je zavolána příslušná metoda. Ta vždy vytvoří novou instanci klienta, a uloží ho do seznamu klientů, který je držen ve třídě ValidatedClient. Vrácen je pak pouze odkaz na klienta. Toto řešení jsem zvolil, protože je nutné klienty držet v paměti do té doby, než je spojení řádně uzavřeno. V opačném případě totiž dochází k spotřebování maximálního množství možných spojení. Poslední třída obsažená v této vrstvě je User. Tato třída představuje právě přihlášeného uživatele. Jsou v ní implementovány metody, které zpracovávají uživatelův obrázek a také drží instanci třídy Account, která představuje uživatele na serveru. Myslím však, že

Stránka | 68

při dalším vývoji aplikace by bylo možné tuto třídu smazat a její metody přesunout do jiných tříd. 6.1.3.

Uživatelské rozhraní a jeho logika

Tato kapitola se bude zabývat návrhem a logikou uživatelského rozhraní a jejím cílem je čtenáři objasnit základní principy, které byly při návrhu rozhraní použity. Mobilní klient Při návrhu uživatelského rozhraní klienta jsem se snažil respektovat principy uvedené v kapitole Uživatelské rozhraní. Z toho tady vyplývá, že by uživatelské rozhraní mělo být přehledné a uživateli nabízet především informace a ne zbytečné ikonky, obrázky atd. Abych doporučení Microsoft dodržel, postupoval jsem při návrhu rozhraní tak, že jsem si stanovil několik základních případů užití aplikace a snažil jsem se uživatelské rozhraní navrhnout tak, aby bylo ovládání aplikace v těchto případech užití co nejjednodušší. Základní případy užití přitom jsou přidání trasy, zobrazení uživatelových tras, zobrazení tras v okolí uživatele a zobrazení přátel. Abych dosáhl co nejlepšího uživatelského rozhraní, použil jsem Pivot Control. Tato komponenta představuje záložky, přičemž každá záložka by měla představovat data nějak spojená s hlavním cílem aplikace (15). Na domovskou stánku PivotControl (Obrázek 16 – PivotControl - Home) jsem umístil mapu, kde uživatel vidí základní informace (tj. svou pozici, svou trasu, trasy poblíž, body zájmu a přátele). Pokud chce uživatel uložit svou trasu, stačí mu pouze spustit aplikaci a spustit akci Start tracking.

Obrázek 16 – PivotControl - Home

Ukládání trasy pak ukončí stejným tlačítkem, jako v případě spuštění akce. Další záložky jsou POI, na této záložce je zobrazen seznam bodů zájmu v okolí, Friends, tato záložka

Stránka | 69

zobrazuje přátele a zároveň je z ní možné otevřít novou stránku s přidáváním přátel. Na záložce tracks uživatel vidí podrobnosti o jeho trasách a u každé trasy může přepínat, zda ji zobrazit na mapě nebo ne. Je zde také tlačítko, které spouští akci zobrazení doporučených tras. Poslední záložkou na Pivot Control je Settings, zde může nastavit uživatel svůj obrázek, změnit heslo a měnit všechny ostatní nastavení. Protože všechny záložky na Pivot Control nejsou vidět najednou, Microsoft doporučuje omezit jejich počet na nejvýše 6. Při vyšším počtu by mohlo docházet k snížení přehlednosti aplikace (15). Tím zároveň vzniká problém, protože aplikace zpřístupňuje uživateli mnoho různých funkcí, k jejich ovládání je zapotřebí značné množství ovládacích prvků. Příliš mnoho ovládacích prvků na jedné záložce Pivot Control by přitom mohlo uživatele velice snadno zmást. V neposlední řadě je nutné uvést, že i Microsoft doporučuje minimální velikost ovládacích prvků (16). Pro funkce, které nejsou příliš často využívány, jsem vytvořil samostatné stránky, na které odkazuji z PivotControl. V záložce Settings jsem použil ovládací prvek Expander (17), který není standardní součástí Windows Phone SDK. Tento prvek jsem použil, protože bylo potřeba do této záložky přidat mnoho ovládacích prvků a zároveň jsem chtěl udržet přehlednost a celistvost uživatelského rozhraní. Přestože jsem se snažil vytvořit uživatelské rozhraní co nejintuitivnější, některé nabídky nejsou uživateli ihned zobrazeny, jsou skryté v menu telefonu. Je to proto, že jsou preferovány nejčastější případy užití a méně využívané funkce jsou proto částečně skryty. Proto jsem vytvořil průvodce, který je automaticky zobrazen při prvním spuštění aplikace. V něm může uživatel v několika základních krocích nastavit aplikaci a zároveň se seznámí se způsobem jejího ovládání. V průvodci se nastavuje, zda uživatel chce, aby aplikace ukládala jeho poslední pozici. Druhým nastavením je možnost vypnutí úsporného režimu v případě, že je telefon zamčený. Toto nastavení zde musí být přítomno, protože Microsoft požaduje, aby měl uživatel kontrolu nad spotřebou telefonu (18). Dále je zde uživateli nabídnuta možnost vytvoření účtu nebo přihlášení k jeho stávajícímu účtu. Webový klient Při vytváření uživatelského rozhraní webového klienta jsem se také snažil zaměřit na obsah. Obdobně jako v případě mobilního klienta jsem stanovil nejčastější scénáře a těm jsem se návrh snažil přizpůsobit. V tomto případě jsem předpokládal, že webový klient bude nejčastěji využíván k prohlížení uživatelových tras a k hledání vhodných anebo

Stránka | 70

doporučených tras při plánování cesty. Proto jsem na téměř celou obrazovku umístil přehlednou mapu. Na pravé straně obrazovky pak může uživatel celý program ovládat.

6.2. Problémy a jejich řešení V této kapitole popíši problémy, na něž jsem během vývoje narazil, a popíši, jak jsem tyto problémy vyřešil. Pokusím se přitom řešení co nejvíce zobecnit tak aby, ho bylo možné aplikovat nejen na stejné problémy ale i na problémy, které s těmito řešeními souvisí. Předem uvádím, že do této kapitoly se pokusím vložit co nejméně vlastního kódu. Pokud se na něj budu odkazovat, uvedu vždy třídu a metodu, kterou popisuji. Vlastní kód aplikace je přitom přiložen v příloze.

6.2.1. Multitasking a stavy aplikace ve Windows Phone 7 Jedním z největších problémů, kterému jsem v průběhu vývoje aplikace čelil, byla nemožnost multitaskingu ve Windows Phone 7. Zatímco první verze systému neumožňovaly žádný multitasking pro aplikace třetích stran, novější verze systému (od 7.5) umožnují aplikaci, aby v případě, že je aplikace ukončena / minimalizována, mohla mít na pozadí spuštěného takzvaného background agenta (19). Background agent je vlastně kód, který je spouštěn automaticky v případě, že aplikace není zapnutá. Systém nabízí 2 typy agentů. Periodic Agents (je spouštěn v pravidelném časovém intervalu) a Resource Intesive agent. Tento agent je spouštěn v případě, že je systém ve stavu, kdy jsou splněny požadavky jako připojení k externímu napájení, je zamčená obrazovka, systém je připojen k internetu apod. Tento agent je určen pro výpočet náročných operací a/nebo pro synchronizaci velkého množství dat. Zdálo se, že pro účely této aplikace bude vhodné využít Periodic Agent. Bohužel je tento agent spouštěn v intervalu 30 minut a toto nastavení nelze nijak změnit.

Stránka | 71

Multitasking by byl vhodný, protože díky němu by aplikace mohla ukládat uživatelovu trasu i v případě, že přepne na jinou aplikaci, někdo mu volá atd. Bohužel toto nelze na dané platformě zajistit. Snažil jsem se tedy zajistit alespoň to, aby byla v případě vypnutí

Obrázek 17 – Životní cyklus aplikace (20)

aplikace, v průběhu trasování, cesta uložena a po opětovném spuštění obnovena. Uživatel by tak mohl pohodlně přepnout na jinou aplikaci, poté se vrátit a pokračovat v trasování. Toho jsem dosáhl a na příkladu ukládání uživatelovy trasy ukáži, jak v případě nutnosti uložení / načtení stavu aplikace ve Windows Phone 7 postupovat. Nejprve je ale potřeba ukázat, jaké jsou možné stavy aplikace ve Windows Phone 7 (20). Poté ukáži jak na jejich změnu správně reagovat. Obrázek (Obrázek 17 – Životní cyklus aplikace ) představuje životní cyklus aplikace, tedy různé stavy, jakých může aplikace nabývat. V našem případě vycházejme z toho, že aplikace již běží. Je tedy ve stavu Running. Z tohoto stavu se může dostat do dvou jiných stavů. Prvním z nich je úplné vypnutí. To nastává v případě, když uživatel vypne aplikaci navigováním zpět (tedy tisknutím šipky zpět do té doby, než ho systém naviguje zpět z aplikace). Druhým možným stavem je Dormant. Tento stav nastává, když uživatel naviguje z aplikace směrem dopředu. Prakticky to pak znamená buď stisknutí tlačítka „Windows“, Hledání nebo případ že klikne na notifikaci, někdo mu volá atd. V tomto stavu je veškerá činnost aplikace pozastavena, ale všechna její data stále zůstávají v paměti telefonu. Telefon drží aplikaci v paměti, dokud toto místo aktivní aplikace nevyžaduje. V případě odstranění

Stránka | 72

z paměti pak operační systém změní status aplikace na Tombstoned. V tomto případě je aplikace vymazána z paměti, ale měla by zajistit obnovení dat. V následujícím příkladu ukáži, jak jsem v aplikaci implementoval logiku, která v případě, že uživatel aplikaci buď vypnul, nebo z ní navigoval vpřed a bylo spuštěné ukládání trasy, obnoví tuto trasu. Hlavní část logiky je obsažena ve třídě Application (App.cs) Tato třída představuje aplikaci. Pro zjištění, zda se trasa ukládá, jsem vytvořil v Application třídě proměnnou Tracking. Dále jsem vytvořil proměnnou, která představuje již uloženou trasu (tato proměnná představuje to, co je potřeba uložit). V Application třídě pak jsem editoval metody Application_Deactivated a Application_Closing. V první metodě jsem uložil požadovaný objekt (trasu uživatele) do State dictionary, což je úložiště, které je určeno právě k ukládání stavu aplikací. Trasa je uložena také do Isolated Storage, protože je možné, že aplikace bude úplně vypnuta. Metoda Application_Deactivated je volána při přechodu aplikace do stavu Dormant. Data do State dictionary jsou ukládána pro případ, že by byla vymazána z operační paměti a stav aplikace byl změněn na Tombstoned. Do Isolated Storage pak jsou pak data ukládána pro případ, že by aplikace již z Tombstoned stavu nebyla obnovena. V metodě Application_Closing jsou data uložena pouze do Isolated Storage (aplikace nemůže být obnovena). Trasa uživatele se ukládá pouze v případě, že bylo zaznamenávání trasy zapnuto, ale příznak říkající, zda se trasa ukládá, se musí ukládat vždy. Obnovení trasy je zajištěno v metodě Application_Activated a dále na úvodní stránce aplikace. V metodě Application_Activated nejprve zjišťuji, zda se aplikace neaktivuje pouze ze stavu Dormant. To by znamenalo, že všechna data byla v paměti zachována a není proto nutné cokoliv obnovovat. Pokud se aplikace neaktivuje ze stavu Dormant, je potřeba zajistit obnovení dat ze State dictionary a tato data uložit do proměnné představující uživatelovu trasu (ApplicationDataObejct). Pokud se aplikace spouští, nereaguji na tuto událost v této třídě nijak. Naopak je potřeba zareagovat na stránce PivotPage2. Ta představuje domovskou stránku aplikace, tedy stránku, která se načte po spuštění. V konstruktoru této stánky jsem vytvořil proměnnou (_isNewPageInstance) a nastavil jsem její hodnotu na true. Tato proměnná bude indikovat, zda se stránka načítá (vytváří poprvé), nebo již v paměti existuje. V kódu stánky jsem vytvořil metodu OnNavigatedTo. Tato metoda je automaticky volána při každém zobrazení (navigaci na) stránku. V této metodě testuji, zda byla právě vytvořena nová instance stránky. Pokud ano, nejspíše bude nutné obnovit data. Z Isolated Storage je tedy načten status, zda se trasa ukládala, nebo ne. Pokud ano, zkouším trasu načíst. Nejprve tedy testuji, zda se v proměnné ApplicationDataObject nacházejí data obnovená ze State Dictionary. Pokud ano, obnovím je, a pokud ne, obnovím data z Isolated Storage.

Stránka | 73

6.2.2.

Zabezpečení komunikace

V této kapitole se budu zabývat tím, jak zabezpečit komunikaci klientské a serverové části. Do problémů jsem tuto kapitolu zařadil, protože nastavit tuto komunikaci představovalo jeden z nejobtížnějších problémů, se kterými jsem se při implementaci setkal. Tato kapitola se bude zabývat implementací zabezpečené komunikace především ze strany klienta. Pokud má čtenář zájem o detailnější rozbor šifrované komunikace ze strany služby, může nahlédnout do diplomové práce Vojtěcha Růžičky. Aby bylo jasné, pro jaké případy je možné použít můj postup, uvedu zde konfiguraci služby, ke které se připojuji. Služba je šifrována pomocí SSL a komunikace tedy probíhá prostřednictvím standardního https. To zaručuje, že by služba měla být snadno dostupná, protože standardní https port (8080) není většinou firewally filtrován. WCF umožňuje několik stupňů nastavení šifrování, přičemž předpokládejme, že služba je nastavená na režim Transport With Message Credentials. To znamená, že přenášené zprávy budou šifrovány SSL a zároveň bude každá zpráva šifrována pomocí credentials. To představuje uživatelské jméno a heslo. Obecně lze říci, že šifrovaná komunikace není pro Windows Phone 7 problém, dokud je k zašifrování použit certifikát vydaný certifikační autoritou, která je akceptována systémem. Za vydání takového certifikátu je ovšem potřeba zaplatit. Já jsem se rozhodl jít jinou cestou a certifikát si vydat sám. Toto řešení je vhodné především v začátcích vývoje a ve fázi testování. Jak tedy začít používat šifrovanou WCF službu? Nejprve ukáži, jak konzumovat tuto službu ve webovém Silverlight. V tomto případě stačí přidat požadovanou webovou referenci a následně upravit vytváření instancí klienta tak, aby obsahovaly uživatelské jméno a heslo (Obrázek 18 – Nastavení credentials).

Obrázek 18 – Nastavení credentials

Ověření, zda je nastavené jméno a heslo správné, se provádí na serveru. Toto ověření přitom musí být implementováno přímo vývojářem služby. Jakmile je Silverlight aplikace spuštěna, kontaktuje webovou službu a vyžádá si certifikát. Po jeho akceptování uživatelem je možné webovou službu využívat. Nyní se se podívám na složitější případ, a to na komunikaci Windows Phone klienta a webové služby. Předem bych chtěl upozornit, že pokud chce programátor využít webovou službu, která šifruje komunikaci pomocí

Stránka | 74

certifikátu,

jehož

certifikační

autorita

není

operačním

systémem

standardně

akceptována, bude téměř jistě muset spolupracovat se správcem / vývojářem webové služby. Problémem totiž je, že v tomto případě neumí Windows Phone získat certifikát ze serveru a je tedy nutné tento certifikát do klienta ručně nainstalovat. Popisované řešení bych spíše doporučil využít při fázi vývoje a testování aplikace; pro skutečný provoz by bylo lepší využít certifikát podepsaný ověřenou certifikační autoritou. Protože Windows Phone je na vydané certifikáty velice citlivý, jediný mnou doporučený postup je ten zde uvedený. Nejprve je potřeba spustit příkazovou řádku a jít do složky, kde je nainstalováno Visual Studio (alternativou je spustit Visual Studio Command prompt). Ke generování certifikátu slouží program makcert.exe který je instalován v balíčku Visual Studio. Dalším krokem je vytvoření kořenového certifikátu, ten simuluje certifikát certifikační autority. Tento certifikát se vytvoří spuštěním příkazu makecert.exe -r -pe -n "CN=VasProjekt Root CA,O=VasProjekt,C=US" -sky signature -a sha1 -cy authority -sv VasProjektRootCA.pvk VasProjektRootCA.cer Přičemž řetězec znaků VasProjekt doporučuji nahradit jménem vašeho projektu. Následně je již možné vytvořit certifikát, který bude použit k šifrování komunikace. Ten bude podepsán kořenovým certifikátem. Vytvořit ho lze pomocí příkazu makecert -pe -n "CN=www.VasProjekt.com,O=VasProjekt,C=US" -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -ic VasProjektRootCA.cer -iv VasProjektRootCA.pvk -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -sv VasProjektSSL.pvk VasProjektSSL.cer Je potřeba zadat stejné hodnoty jako při vytváření kořenového certifkátu. Hodnota CN (jméno certifikátu) musí být shodná s adresou, na které služba poběží. Posledním krokem je zaheslování certifikátu. To se provede příkazem pvk2pfx -pvk VasProjekt.pvk -spc VasProjekt.cer -pfx VasProjekt.pfx -po heslo Při vybírání hesla je dobré počítat s tím, že uživatel, který bude tento certifikát používat, musí heslo znát. Posledním krokem pak je instalace certifikátu v mobilním telefonu. Pokud vývojář používá pro testování aplikace emulátor, je potřeba počítat s tím, že jsou certifikáty po každém vypnutí emulátoru smazány. Je proto vhodné přidání certifikátu alespoň částečně automatizovat. To jsem udělal tak, že jsem do nastavení (třída SettingsClass) přidal atribut isSetUp. Tento atribut se nastaví na true, jakmile uživatel dokončí úvodní tutoriál, jehož součástí je právě import certifikátu. Je přitom potřeba importovat kořenový certifikát a certifikát zajišťující šifrování komunikace. Importuje se

Stránka | 75

Obrázek 19 – Import certifikátu

kořenový certifikát s koncovkou .cer (nezaheslovaný) a zaheslovaný SSL certifikát (koncovka .pfx). Jiná kombinace opět nefunguje. Import certifikátu jsem provedl tak, že jsem oba certifikáty zabalil do archivu .zip a uložil na web. V aplikaci jsem vytvořil tlačítko, které otevře webový prohlížeč a jako adresu předá adresu archivu.

Archiv lze otevřít bez potřeby nějakých dalších aplikací. Následně uživatel musí dotykem vybrat oba dva certifikáty a zadat heslo. Operační systém mu oznámí, že certifikáty byly přidány. Tlačítkem zpět se pak uživatel dostane zpět do aplikace a může pokračovat v úvodním nastavení. Závěrem bych chtěl podotknout, že jsem šifrovanou komunikaci do produkční aplikace nezahrnul a to především z důvodu nestandardního přidávání certifikátu, které by mohlo ohrozit akceptaci aplikace v Marketplace. Logika ale zůstává v aplikaci implementována ve třídách Settings a ValidatedClient, takže může být znovu použita.

6.2.3.

Navigace mezi stránkami ve Windows Phone 7

V této kapitole se budu věnovat navigaci mezi stránkami (page) ve Windows Phone 7. Navigace (otevření) nové stránky neprobíhá totiž klasickou cestou (např. jako ve WPF aplikaci), tedy vytvořením instance třídy představující stánku. Způsob navigace připomíná spíše navigaci mezi stránkami například HTML. O navigaci se ve Windows Phone 7 stará instance třídy NavigationService (21). Ta ukládá jednotlivé stánky a stará se o to, aby byl uživatel vždy navigován na správnou stránku. To znamená, že například v případě stisku šipky zpět bude vrácen o jeden krok zpět. Navigace přitom může probíhat dvěma směry, vrácení se o jeden krok zpět nebo dopředu (tedy otevření nové stránky). NavigationService se také stará o instance jednotlivých stránek. To znamená, že se v případě první návštěvy (prvního otevření) stránky vytvoří její instanci a naopak v případě návratu na stránku použije již vytvořenou instanci. Navigaci mezi těmito stránkami lze provádět poměrně jednoduše voláním metod Navigate a GoBack třídy

Stránka | 76

NavigationService. V případě, že chceme navigovat uživatele na stránku test, která je umístěna v kořenovém adresáři aplikace, zavoláme metodu s následujícím způsobem: NavigationService.Navigate(new Uri("/test.xaml", UriKind.Relative)); Pokud chceme uživatele navigovat o krok zpět, zavoláme jednoduše NavigationService.GoBack(); Problém ovšem nastává v případě, když chceme právě se otevírající stránce předat nějaké informace, na základě, kterých se pak otevíraná stránka má chovat. Obdobně může být problémem, pokud bychom chtěli po zavření stránky získat informaci o tom, s jakým výsledkem byla stránka uzavřena. Při uzavírání stránky není možnost nastavit žádnou návratovou hodnotu. Tento problém lze řešit dvěma způsoby. Pokud chceme na stránku poslat pouze jednoduchou informaci, lze to provést přidáním parametru k adrese stránky, která se volá. Hodnotu tohoto parametru pak lze na volané stránce snadno přečíst. Tento způsob je využit například u zobrazování detailů přítele. Při zavolání metody pro zobrazení detailu přítele, se na stránku zobrazující jeho detail, pošle ID a dle něj je požadovaný přítel vyhledán a zobrazen. Přidávání parametrů lze také dobře využít, pokud nás zajímá, z jaké stránky uživatel přišel, a chceme na to reagovat. Toto jsem v aplikaci využil, když jsem při návratu na hlavní stránku potřeboval zkontrolovat, zda se uživatel nevrací ze stránky pořízení avataru. V tomto případě jsem chtěl uživatelovu fotku uložit na server. Konkrétní implementace pak vypadá tak, že na stránce tlačítko pro návrat na hlavní stránku zavolá metodu Navigate s parametrem from, jehož hodnota je nastavena na camera: NavigationService.Navigate(new Uri("/PivotPage2.xaml?from=camera", UriKind.Relative)); Na hlavní stránce (PivotPage2) pak v metodě OnNavigatedTo kontroluji, zda je tento parametr přítomen a zda je jeho hodnota nastavena na camera. Využití parametrů dovoluje posílat stránce základní informace, problém ovšem může nastat v případě, že je nutné stránce předat konkrétní instanci nějakého objektu, nebo naopak čekáme, že výstupem práce se stránkou by měl být nějaký objekt, který chceme dále využít. V tomto případě však neexistuje žádná možnost, jak objekt stránce přímo předat. Tento problém jsem vyřešil následujícím způsobem. Uvědomil jsem si totiž, že objekt nemusí být přímo předáván aplikaci, ale spíše je zapotřebí zajistit, aby instance klíčových objektů byly přístupné ze všech částí aplikace. Toto jsem dosáhnul tím, že držím instance tříd v „hlavní“ třídě Application. Ta, jak jsem již zmiňoval výše,

Stránka | 77

představuje samotnou aplikaci. Protože je tato třída (Application) generována při sestavení programu automaticky, vytvořil jsem v projektu partial class App.cs. Partial class přitom umožňuje rozdělit kód do několika tříd a při sestavení jsou tyto partial class složeny dohromady. V této třídě jsou pak drženy objekty představující seznam uživatelových tras, jeho přátele, cesty poblíž uživatele atd. K těmto objektům pak lze z kteréhokoliv místa v aplikaci přistoupit pomocí konstruktu (Application.Current As App).jménoObjektu. Nyní, když jsou všechny objekty přístupné, zbývá vyřešit, jak předat (vybrat) ten správný objekt. Toho lze docílit právě pomocí parametru, který je přidán za jméno stránky při navigaci (viz předchozí odstavec). V tomto parametru musí být předávána proměnná, která jednoznačně identifikuje jeden, popřípadě více záznamů. Příkladem v aplikaci je otevření stánky detailu přítele / trasy / bodu zájmu. Řešení tohoto problému se dá zobecnit do několika základních pravidel, jejichž aplikace umožní simulovat předávání objektů mezi stránkami. Při návrhu a vývoji aplikace je nutné umístit objekty, které chceme používat na více stránkách, do partial class Application. Pokud objekt obsahuje seznam dalších objektů, je nutné, aby bylo možné v seznamu každý objekt identifikovat a také implementovat logiku, která bude vracet jednotlivé objekty právě na základě jejich jednoznačného identifikátoru.

6.2.4.

Asynchronní volání metod v mobilním klientu

V této kapitole se budu věnovat komunikaci mobilního klienta a serveru. Nastíním, s jakými jsem se potýkal problémy a jak jsem je vyřešil. Úvodem této kapitoly bych chtěl uvést, že pro komunikaci klientů se serverem byla použita technologie Windows Communication Foundation (WCF). Tato technologie, která je součástí .NET Framework 3.0, umožňuje vytvářet SOA (Servisně orientované aplikace). V praxi to pak znamená, že aplikace může uveřejnit službu, ke které se lze pomocí klienta připojit a službu konzumovat. Cílem této kapitoly však není detailně popsat WCF, ale zjistit, jak tyto služby co nejlépe konzumovat. Při vývoji mobilního klienta je totiž nutné počítat s tím, že uživatel nebude stále připojen k internetu, připojení může být velmi pomalé, nestabilní a často se může přerušit. Klienta pro připojení k webové službě představuje ve WCF třída, která je tvořena z dvou částí. První z nich je implementace konzumované služby. Tato přidává do třídy metody, které zajišťují předávání informací s webovou službou. Tedy vlastně samotné využití služby.

Druhá

část

implementuje

rozhraní

System.ServiceModel.IClientChannel.

Stránka | 78

Implementace tohoto rozhraní přidává do třídy metody, které se primárně starají o komunikaci, tj. například otevření, ukončení komunikace. Při testování aplikace v reálném provozu jsem díky výše zmíněným faktorům narazil na dva problémy, přičemž oba problémy byly způsobeny nedokončeným voláním webové služby. Prvním, méně závažným problémem bylo, že v případě výjimky při volání služby klient takzvaně spadl. Trvalo mi poměrně dlouhou dobu, než jsem našel správný způsob jak tyto výjimky odchytávat. Pojďme se tedy podívat na úryvek kódu a na něm si objasnit, jak funguje asynchronní volání funkcí a odchytávání výjimek.

Obrázek 20 – Asynchronní volání vzdálené metody

Tento obrázek (Obrázek 20 – Asynchronní volání vzdálené metody) ukazuje kód z třídy TrackControl který stará se o načtení tras uživatele ze serveru. V metodě loadUserTracksFromServer() se vytvoří nová instance klienta. K události dokončení načtení všech tras je přiřazen nový event handler. Ten spustí stanovenou metodu, v tomto případě klient_getTracksAllCompleted, jakmile je jsou vráceny hodnoty po volání metody getTracksAllAsync. Této metodě je pak předána vrácená hodnota

Stránka | 79

v proměnné e. Důležité je vědět, že metoda klient_getTracksAllCompleted je spuštěna i v případě výjimky v „hlavní“ metodě. Nyní se tedy pojďme podívat, jak správně zachytávat výjimky. První try-catch blok zachycující výjimky, který je v metodě loadUserTracksFromServer(), zachytává výjimky, ke kterým dochází již při volání metody (například změna nastavení webové služby). Použití try-catch bloku pro samotné volání asynchronní funkce doporučuji tedy spíše v případě vývoje webové služby i klienta. Pokud se klient připojuje k stabilní webové službě, je možné tento blok vypustit.

O

poznání

důležitější

je

zachytávání

výjimek

v metodě

klient_getTracksAllCompleted. Je nutné vědět, že tato metoda by měla nastat vždy. Vrácená hodnota je v případě úspěchu vrácena uložena v e.Result. V případě, že nastala výjimka, je e.Result null a naopak v atributu Error (e.Error) je uložena chybová hláška. Pokud tedy chceme zjistit, zda bylo volání úspěšné, lze to provést kontrolou přítomnosti e.Error. Druhá možnost je použití try-catch, jak je uvedeno v této ukázce. V tomto případě je nutné upozornit vývojáře na nestandardní chování Visual Studio, které mi způsobilo značné obtíže. V případě, že v bloku try-catch nastane výjimka, Visual Studio zastaví běh programu a zobrazí výjimku. Pokud toto programátor ignoruje a stiskne F5 (Spustit), běh programu pokračuje v pořádku dále a je spuštěn kód obsažený v bloku catch. Nicméně toto chování jsem zaznamenal pouze při vývoji pro Windows Phone, při vývoji webového klienta se Visual Studio chovalo standardně. Nyní se pojďme podívat na druhý, poslední problém, který jsem řešil. Tím byly chyby při komunikaci způsobené spotřebováním velkého množství zdrojů volané služby. Důsledkem tohoto problému pak často byla nedostupnost služby i při pokusu o připojení z jiných klientů (např. webového klienta, druhého telefonu). Při pokusu o připojení byla zobrazena chybová hláška „The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached“. To znamená, že ke službě je připojen maximální počet klientů a další klienty služba již neobslouží. Komunikace se serverem, jak jsem již zmiňoval, probíhá pomocí klienta. Každý klient přitom při připojení ke službě spotřebovává určité zdroje. Při návrhu aplikace je tedy nutné dobře zvážit, jakou zvolit politiku pro vytváření klientů. Jsou zde dva přístupy, prvním z nich je vytvořit pouze jednoho klienta a pomocí něj následně komunikovat se službou. Druhou variantu představuje vytvoření nového klienta při každém požadavku. Pro mobilního klienta je však vhodnější aplikovat druhý způsob, tedy vytvářet nového klienta pro každý požadavek. Pokud bychom totiž vytvořili pouze jednoho klienta, bylo by nutné mít neustále otevřené spojení se serverem. To ale není dost dobře možné,

Stránka | 80

protože jakmile uživatel naviguje z aplikace, spojení je ztraceno, stejně tak se může snadno stát, že telefon ztratí připojení k internetu úplně. Při vytváření nového klienta ke každému požadavku vzniká riziko, že příliš mnoho otevřených spojení (klientů) najednou může spotřebovávat neúměrné množství zdrojů. Je proto nutné po vyřízení požadavku spojení klienta se serverem vždy ukončit. Nyní popíši, jak jsem implementoval správu klientů tak, aby byl ve všech případech klient odpojen od služby a tím bylo zamezeno přílišné spotřebě zdrojů. Vytvořil jsem třídu ValidatedClient, která má atributy představující klienty. Při přístupu k těmto atributům ovšem není vrácen stejný klient, ale vždy se vytvoří nová instance klienta, která je vrácena, zároveň je tato instance uložena do seznamu klientů, který je také držen v této třídě. Odkaz na tohoto klienta je předán v metodě, která k atributu klient přistoupila. Následuje volání metody na klientovi a spuštění metody po dokončení volání (Obrázek 20 – Asynchronní volání vzdálené metody). V této metodě je pak nutné klienta uzavřít. Protože sender představuje odkaz na klienta, který byl použit, přetypujeme ho na typ použitého klienta. Na tomto klientu pak zavoláme metodu closeAsync(). Ta by měla uzavřít spojení, ale není to jisté (když je kanál, spojení v chybovém stavu, není toto volání úspěšné). Zda bylo spojení řádně uzavřeno, již v tuto chvíli netestuji. Protože jsou všichni klienti držení v třídě ValidatedClient, nechávám testování, zda je spojení v pořádku uzavřeno, na později. Toto testování se provádí vždy při vytváření nového klienta (Obrázek 21 – Vytváření klienta) a provádí se tak, že aplikace projde všechny klienty uložené v jejich seznamu a kontroluje jejich atribut State (stav). Pokud je stav klienta Faulted (nastává při chybě v komunikaci a znamená, že klienta již není možno nijak použít, ani uzavřít spojení), je zavolána metoda Abort(). Ta uvolní prostředky, které má klient rezervovány u webové služby. Poslední věc, na kterou bych rád upozornil, je možnost přidávání přihlašovacího jména a hesla, a to v případě, že je použita šifrovaná komunikace. Shrnu-li tedy poslední kapitolu do několika doporučení, je to: vždy uzavírat klienta, kontrolovat, zda byl klient opravdu uzavřen, a kontrolovat jednotlivé instance klientů.

Stránka | 81

Obrázek 21 – Vytváření klienta

6.2.5.

Rozhraní INotifyProperityChanged

V této kapitole se budu věnovat rozhraní INotifyProperityChanged, které jsem v aplikaci často využíval a vyřešil pomocí něj několik problémů. Při správné implementaci rozhraní zajišťuje, že v případě změny atributu třídy, která toto rozhraní implementuje, je vyvolána událost, jejímž argumentem je právě jméno změněného atributu. Nyní odbočím opět ke komunikaci serveru a klienta a upozorním čtenáře, že volání všech metod, které zpřístupňuje klientská třída aplikaci, probíhá asynchronně (podrobněji v kapitole Asynchronní volání metod v mobilním klientu). To kromě jiného znamená, že při volání těchto metod není možné počítat s uživatelsky nastavenou návratovou hodnotou. S tímto je potřeba počítat již při návrhu aplikace. Je tedy jednak nutné uchovávat všechny instance tříd, ke kterým se má v asynchronních metodách přistupovat, viditelné (tedy nejlépe v Application class). Tím zajistíme, že budou moci být měněny z asynchronní metody. Problém nastává v případě, že je potřeba na změnu nějak zareagovat, v tomto případě zobrazit vrácené hodnoty v uživatelském rozhraní. Mým cílem tedy bylo implementovat takovou logiku, která by umožnila jednoduché zobrazování hodnot vrácených při volání webové služby v uživatelském rozhraní. A k tomuto účelu jsem právě využil rozhraní INotifyProperityChanged a techniku bindování atributů objektů. Toto rozhraní jsem implementoval především u modelů jednotlivých objektů (Friend, POI, ale například i v třídě SettingsClass). Nejdřív ukáži, jak rozhraní implementovat a následně jak jeho implementace využít. Nejprve je potřeba deklarovat, že třída

Stránka | 82

implementuje rozhraní INotifyProperityChanged. To jsem zapsal následujícím způsobem (Obrázek 22 – Implementace INotifyProperityChanged):

Obrázek 22 – Implementace INotifyProperityChanged

Rozhraní obecně představuje třídu, ale bez implementace jakéhokoliv kódu. Obsahuje pouze deklarace metod, událostí a indexů (22). Vše, co je deklarováno v rozhraní, pak musí

třída,

která

rozhraní

využívá,

implementovat.

Konkrétně

rozhraní

INotifyProperityChanged deklaruje událost PropertyChanged. Tuto událost je tedy potřeba vytvořit v třídě, která rozhraní implementuje. Dále je potřeba vytvořit metodu, která bude tuto událost volat. Metoda vypadá následovně (Obrázek 23 – RaisePropertyChanges) :

Obrázek 23 – RaisePropertyChanges

Obrázek 24 – Bindování XAML

Tato metoda je volána při změně hodnoty atributu, u které je potřeba zjistit, kdy se její hodnota mění. Díky implementaci tohoto rozhraní pak lze již poměrně snadno přiřadit jednotlivé hodnoty atributů tříd k objektům v uživatelském rozhraní. Toto se nazývá bindování. Ukáži to na následujícím příkladu v souboru PivotPage2.xaml (Obrázek 24 – Bindování XAML), který ukazuje zobrazení přátel na mapě. Aby bylo možné přátele

Stránka | 83

zobrazit, je potřeba k MapItemControl přiřadit konkrétní instanci třídy. To se provede nastavením atributu DataContext (Obrázek 25 – Nastavení DataContext).

Obrázek 25 – Nastavení DataContext

Podívejme se znovu na Obrázek 24 – Bindování XAML. U MapItemControl je nastavený ItemSource na Friends (třída FriendList). To znamená, že MapItemControl bude zobrazovat atribut Friends (třída FriendMode).

Objekty Pushpin, které představují

jednotlivé přátele, mají přiřazené atributy třídy FriendModel, tedy obrázek, místo, kde byla naposledy zaznamenána uživatelova poloha a zda má být kamarád zobrazen na mapě. Tímto způsobem je provedeno přiřazení všech modelů v uživatelském rozhraní. Díky bindování atributů všech objektů, které chceme zobrazovat tedy nemusíme zjišťovat, kdy byla asynchronní část dokončena, protože jakmile se informace vrátí a jsou správným způsobem přiřazeny atributům objektů tříd, jsou ihned zobrazeny v uživatelském rozhraní. Mohou samozřejmě nastat i situace, kdy je potřeba, aby asynchronní volání vrátilo

Obrázek 26 – Třída Settings3

Stránka | 84

nějakou hodnotu a s touto hodnotou dále pracovat. Tento problém jsem vyřešil také pomocí implementace INotifyProperityChanged. Princip řešení je podobný jako v předchozím případě. Spočívá ve vytvoření třídy, která implementuje rozhraní INotifyProperityChanged. Její atribut je v asynchronní metodě změněn a na tuto změnu v programu reaguji. Řešení ukáži na příkladu (Obrázek 26 – Třída Settings3), kdy se uživatel přihlašuje ke svému účtu. Pokud je přihlášení úspěšné, chci uživateli zobrazit možnost pokračovat. V opačném případě chci zobrazit zprávu, že přihlášení nebylo úspěšné. Ve třídě jsem vytvořil metodu, která reaguje na změnu atributu třídy SettingsClass. Argumentem této metody je název atributu, který se v Settings změnil. V metodě je pak nutné zkontrolovat, jaký se měnil atribut a případně na jeho změnu vhodně zareagovat. V případě úspěchu se zobrazí tlačítka pro pokračování a zpráva, že přihlášení bylo úspěšné. V opačném případě je uživatelovi zobrazena zpráva, že přihlášení nebylo úspěšné. V této kapitole jsem obeznámil čtenáře jak využít INotifyProperityChanged, pokud chceme obejít nemožnost použití návratové hodnoty u asynchronního volání.

6.3. Vývoj a zveřejnění aplikace pro Windows Phone 7 V této kapitole popíši, jaká specifika s sebou přináší vývoj aplikace pro platformu Windows Phone 7 a podívám se také, jak probíhá proces zveřejnění aplikace na Marketplace. Nejprve uvedu seznam software, který jsem pro vývoj aplikace používal. Instalaci tohoto software doporučuji čtenářům, kteří si chtějí aplikaci přiloženou v přílohách spustit. 

Windows 7 SP1



Microsoft Visual Studio 2010



Windows Phone SDK 7.1



Microsoft Zune



Microsoft Silverlight 4 SDK



Bing Maps Silverlight Control SDK 1.0

Před samotným vývojem je potřeba vytvořit na stránkách create.msdn.com vývojářský účet. Tento účet přitom může získat každý, kdo má již live účet u Microsoft. Z každého účtu pak lze bezplatně uveřejnit maximálně 100 aplikací. Po získání vývojářského účtu je možné zaregistrovat mobilní telefon jako telefon určený k vývoji aplikací. To se provede pomocí programu Windows Phone Developer Registration, který je součástí Zune balíku. Po

Stránka | 85

odemčení telefonu je umožněno vývojáři nahrávat verze vyvíjeného programu přímo do telefonu. Samotný vývoj pak probíhá ve Visual Studio a vyvíjenou aplikaci je možné testovat buď v emulátoru Windows Phone, který je součástí Windows Phone SDK, nebo přímo v mobilním telefonu. Jakmile se vývoj aplikace dostane do stádia, kdy je potřeba aby ji testovalo více uživatelů, je možnost aplikaci uveřejnit v Marketplace pouze pro uzavřený okruh testerů. Tito testeři pak mohou aplikaci stáhnout kliknutím na odkaz, který je jim doručen v e-mailové zprávě. Pro to, aby byla uveřejněna v testovacím „módu“, musí splňovat pouze několik základních podmínek, kterými jsou přítomnost ikony aplikace, vyplněný popis (Description) aplikace, přítomnost AppResources (který lze použít k překladům textů v aplikaci). Aplikace také musí být zkompilována jako „Release“. Následně stačí odeslat zkompilovaný .xap21 soubor na stránkách create.msdn.com a následně vyplnit několik formulářů typu do jaké kategorie aplikace patří, její popis, název atd. Aplikace je ihned zveřejněna na Marketplace. Jakmile je vývoj aplikace u konce a ta je připravená k zveřejnění, je opět potřeba navštívit stránku create.msdn.com. Zde z uživatelova hlediska probíhá téměř stejný proces jako při zveřejňování. Po uložení aplikace a požádání o její zveřejnění je ale spuštěn proces její certifikace Microsoft a následné zveřejnění. Proces certifikace se přitom skládá z dvou kroků, nejprve automatické testování aplikace a následně testování testery Microsoft. Aplikace přitom musí splňovat poměrně dlouhý seznam požadavků, které jsou kladeny přímo na chování aplikace, na jazyk, který je v aplikaci použit (žádné hrubé výrazy apod.) na zveřejňování reklamy a obsahu v aplikaci. Dále uvedu svou zkušenost s certifikací. Má aplikace byla při prvním pokusu o zařazení do Marketplace odmítnuta, protože nesplňovala některé požadavky Microsoft. Hlavní nedostatky první verze byly, že v dvou případech užití byla aplikace nečekaně ukončena, licenční podmínky (upozornění uživatele, jak budu nakládat s jeho daty) byly zobrazeny pouze při prvním spuštění a z úvodní obrazovky nešlo při prvním spuštění navigovat zpět do aplikace a následně aplikaci ukončit. Na testování Microsoft mne překvapilo, s jakou pečlivostí musely být všechny funkce aplikace otestovány a také jak podrobný report o testování byl vypracován a dostupný na create.msdn.com (v příloze). Poté co jsem všechny nedostatky odstranil, jsem aplikaci nechal znovu certifikovat a na druhý pokus byla aplikace certifikována a uveřejněna na Marketplace. Na závěr bych chtěl uvést, že certifikace trvala v obou případech zhruba týden.

21

Xap – formát pro komprimaci zkompilovaného programu

Stránka | 86

Uveřejněním aplikace na Marketplace končí proces vývoje aplikace. V průběhu dostupnosti aplikace na Marketplace sbírá Microsoft data o počtu stažení aplikace, jejích pádech a také hodnocení aplikace. Všechny tyto informace jsou vlastníkovi aplikace dostupné. V případě updatu je pak možné pomocí příslušného formuláře na create.msdn.com vložit nový .xap soubor a ten je následně certifikován a update zveřejněn. Proces končí stažením aplikace z Marketplace.

Stránka | 87

7. Možné pokračování V této kapitole bych chtěl popsat, jakými kroky by bylo možné aplikaci dále vylepšit a učinit ji atraktivnější pro široké skupiny uživatelů. Přístupy k vylepšení aplikace jsem přitom identifikoval dva. První možností je vylepšit ty funkce, kterými je aplikace unikátní tak, aby se výrazně odlišovala od podobných aplikací a získala tím konkurenční výhodu. Druhým možným přístupem je naopak vylepšení aplikace tak, aby se vyrovnala svým konkurentům v místech, kde v současnosti ztrácí. Nejprve se pokusím nastínit, jakým způsobem by bylo možné vylepšit silné stránky aplikace. Za ty považuji především funkcionalitu spojenou s možností zobrazení průjezdnosti jednotlivých tras a možností upozorňování na důležité body na mapě. Jedním ze směrů, kterým by se budoucí vývoj mohl ubírat, je lepší zobrazení průjezdnosti tras na mapě. V aktuální verzi jsou totiž trasy vykreslovány na mapu v podobě přidané vrstvy zobrazující množiny bodů, ale toto řešení by mohlo mít problémy v případě vykreslování velkého množství různých tras. Bylo by proto vhodné vykreslovat průjezdnost tras přímo do mapových podkladů na serveru a tyto podklady následně zasílat klientovi. S tímto je spojena možnost výběru mapových podkladů (Openstreetmap22 /Bing maps / Google Maps). Dalším směrem, kam by se mohl další případný vývoj ubírat je implementace různých typů oprávnění uživatelů. Pro každou oblast by pak mohl být stanoven nějaký admin / správce, který by spravoval body zájmu a trasy přiřazené v té které oblasti. V případě, že by aplikace obsahovala dostatečný počet uložených tras, bylo by vhodné implementovat i rozšířené vyhledávání cest typu od – do. Naopak, pokud se podívám na ty stránky aplikace, kde je konkurence aplikace lepší, jeví se mi jako největší nevýhoda této aplikace webový klient. Jeho nevýhodou je především vzhled uživatelského rozhraní. Jsou zde použity základní objekty v Silverlight, které nejsou nijak nastylovány. Bylo by proto vhodné předělat uživatelské rozhraní tak, aby stylově odpovídalo rozhraní v mobilním telefonu. Webové rozhraní by také mělo nabízet více funkcí než mobilní klient. Mezi funkce, které by bylo dobré implementovat, je například export tras do GPX23. Jistě by také bylo vhodné, aby aplikace integrovala různé sociální sítě. Pokud bych tedy měl zhodnotit, jakým směrem by se mohl vývoj ubírat v budoucnu a zda má aplikace na trhu šanci, myslím si, že přes nízký počet uživatelů, který aplikace dosud získala, je možné, že by aplikace mohla být úspěšná. Vyžadovalo by to ale dodatečné investice do reklamy, dalšího vývoje, Azure a také například na nákup vlastní domény. Bez těchto investic nejspíše

22 23

Openstreetmap – online mapy GPX – XML schema, které popisuje data GPS data

Stránka | 88

aplikace poběží, bez viditelnějšího zájmu do té doby, než skončí bezplatná zkušební doba na Windows Azure.

Stránka | 89

8. Vyhodnocení V této kapitole zhodnotím cíle tak, jak jsem je definoval v kapitole Popis a cíle aplikace. Nejprve budu vyhodnocovat první skupinu cílů zaměřenou na přínos v průběhu vývoje. Následně vyhodnotím druhou skupinu zaměřenou na cíle spojené s využíváním aplikace. Ze skupiny cílů zaměřených na vývoj aplikace bylo prvním dílčím cílem udělit doporučení pro návrh a vývoj aplikace na platformě Windows Phone 7. Tento cíl jsem se pokusil naplnit v kapitole Struktura programu. Hlavním přínosem obsaženým v této kapitole je především navržená struktura, která je dle mého názoru poměrně univerzální a částečně představuje konkurenci pro model MVVM24. Zároveň jsou zde některé postupy, jejichž implementace může pomoci při vývoji podobných funkčních celků u jiných aplikací (například implementace správy nastavení aplikace). Když se pokusím celkově zhodnotit tento cíl, myslím, že ho mohu označit za splněný. Udělil jsem několik dobrých doporučení a seznámil čtenáře s inovativními návrhy. Přestože jsem při vývoji často využíval známé (již použité) postupy, jejich unikátní kombinace často pomohla návrhu a implementaci aplikačních struktur tak, že tato implementace by mohla znamenat inspiraci pro další vývojáře. Druhým cílem v této skupině bylo popsat řešení problémů, na které jsem narazil. Popis a řešení problémů je uveden v kapitole Problémy a jejich řešení. Tento cíl jsem se rozhodl považovat za splněný v případě, že řešení problémů bude unikátní a zároveň bude toto řešení znovupoužitelné i v dalších případech. Konkrétně jsem se snažil věnovat především komunikaci klienta se serverem a obtížím spojeným s tím. Této problematice se věnují dvě podkapitoly. První z nich ( Zabezpečení komunikace) popisuje problém, jak zprovoznit šifrovanou komunikaci Windows Phone klienta a Azure webové služby. Byl vyřešen problém jak pro komunikaci použít certifikát, který je podepsaný neautorizovanou certifikační autoritou. Řešení problému je, myslím, velkým přínosem, protože v době vypracovávání této práce jsem žádné funkční řešení tohoto problému nenašel. V kapitole Asynchronní volání metod v mobilním klientu je řešen problém správy klientů, kteří se používají pro volání webových služeb. Problém je řešen vytvořením třídy a implementací logiky, která klienty spravuje. Řešení je originální, protože do současné doby nebylo, dle mne známých zdrojů, řešeno jak pracovat s klienty v mobilním zařízení, kde je předpoklad, že bude aplikace spuštěna relativně dlouhou dobu. Problémem, který je řešen v kapitole Navigace mezi stránkami ve Windows Phone 7 je nemožnost předávání složitějších objektů při navigaci mezi stránkami (okny) aplikace. Tento 24

MVVM – Model- View – ViewModel softwarová architektura

Stránka | 90

problém jsem vyřešil umístěním objektů, které mají být dostupné na všech stánkách v třídě představující samotnou aplikaci. V neposlední řadě jsem vyřešil problém s nepřítomností návratové hodnoty při volání metod webové služby. Tento problém jsem vyřešil implementací rozhraní, které upozorňuje na změny hodnot atributů určité třídy. Řešení tohoto problému je přitom užitečné pro vývoj nejen na platformě Windows Phone 7 ale také při vývoji v Silverlight. Myslím tedy, že tento cíl mohu považovat za splněný. Řešení problémů ve výše zmiňovaných kapitolách přinesla buď úplně nové informace, nebo alespoň využila stávající informace originálním způsobem.

Druhou skupinou cílů jsou cíle spojené s využíváním aplikace uživateli. Na začátek je potřeba uvést, že zatímco při plánování cílů jsem počítal s tím, že aplikace bude dostupná po dobu jednoho měsíce, musel jsem nakonec díky prodlevám při zveřejňování aplikace zkrátit tento interval na dobu od 27. března 2012 do 15. dubna 2012, tedy na dobu 20 dní. Úvodem tohoto odstavce bych chtěl uvést, že metriky, které jsem stanovil pro splnění cílů, nebyly téměř v žádném případě splněny. Počítal jsem totiž s tím, že počet stažení aplikace se bude pohybovat okolo 50 stažení během měsíce. Toto číslo však bylo téměř 5x menší a počet stažení za 20 dnů je 12. Z těchto 12 instalací se pouze 10 lidí zaregistrovalo. Během testovacího období byla přitom uložena pouze jedna trasa. Prvním dílčím cílem byl přínos aplikace pro uživatele. Tento cíl má vystihovat užitek uživatelů z aplikace. Aby bylo možné aplikaci využít naplno, je důležité, aby byl počet uživatelů nejméně 50 a zároveň aby každý uživatel ukládal trasy. Proto jsem tedy stanovil minimální počet tras také na 50. Z předchozího tedy vyplývá, že tento cíl splněn nebyl. Zejména pak jeho druhá část, tedy počet tras. Zdá se, že majorita uživatelů aplikaci pouze stáhla, ale rychle vypnula a již znova nespustila. Z tohoto lze vyvodit dva závěry. Buď je uživatelské rozhraní nepřívětivé, uživatel nevěděl jak ukládání trasy spustit, nebo čekal již při prvním spuštění, že mu aplikace nabídne možnost zobrazení průjezdnosti tras v jeho okolí. Dalším cílem bylo zajistit úspěch aplikace. Pro to jsem stanovil opět minimální počet stažení (50) a také hodnocení aplikace na Marketplace jednak průměrné hodnocení podle počtu hvězdiček a také hodnocení získané z komentářů k aplikaci. Bohužel musím konstatovat, že tento cíl rovněž nebyl splněn. Kromě toho, že počet stažení nedosahoval stanovených 50 stažení, počet hodnocení, stejně jako počet komentářů k aplikaci byl nulový. Posledním cílem bylo zajistit kvalitu aplikace. Vyhodnocení toho cíle probíhalo jednak porovnáním stažení aplikace a jejích pádů a dále vyhodnocením komentářů k aplikaci. Protože počet pádů byl jeden a počet stažení

Stránka | 91

12, lze toto kritérium hodnotit jako úspěch. Komentáře u aplikace žádné nebyly, takže tento cíl mohu hodnotit jako splněný. Protože lze z předchozích dat uvažovat o tom, že aplikace nebyla spuštěna po dlouho dobu, takže nestačilo dojít k žádným pádům aplikace, je nutné brát také tento splněný cíl s částečnou rezervou. Souhrn vyhodnocení je vidět v následující tabulce (Tabulka 23 – Vyhodnocení cílů)

Tabulka 23 – Vyhodnocení cílů

Identifikátor C-V01-01

Název cíle Poskytnutí zkušeností

Metriky Udělená doporučení

C-V01-02

Řešení problémů

Kreativně a úspěšně vyřešené problémy

C-A01-01

Přínos aplikace

C-A01-02

Úspěch aplikace

C-A01-02

Kvalita

Min. počet uživatelů:50 Min. počet tras:50 Blízkost tras Min. počet uživatelů:50 Min průměrné hodnocení: 3 Kladné komentáře Pády aplikace/Počet stažení < 1 Zhodnocení komentářů

Skutečný stav Doporučení byla udělena v kapitole Struktura programu Detailně jsem seznámil čtenáře s řešením problémů (kapitola Problémy a jejich řešení) Počet uživatelů: 12 Počet tras: 1

Splněno ANO

Počet uživatelů: 12 Průměrné hodnocení: žádné hodnocení aplikace

NE

Počet pádů / stažení : 1/12 Žádný komentář

ANO

ANO

NE

Celkově myslím, že můžu první skupinu cílů, zaměřenou na vývoj aplikace označit za splněnou, naopak druhá skupina cílů spíše splněna nebyla, protože aplikaci nepoužívá dostatečný počet lidí. Myslím, že pro větší rozšíření aplikace by bylo nutné vylepšit uživatelské rozhraní webového klienta a také aplikaci propagovat na různých sociálních sítích.

Stránka | 92

9. Závěr V této kapitole bych chtěl zhodnotit celou diplomovou práci, podívat se na její přínos a také zhodnotit, kde se nacházejí slabá místa. Práce byla poněkud specifická svým zadáním, tedy tím, že její vypracování bylo navázáno na vypracování jiné diplomové práce. Zároveň byla vypracovávána ve spolupráci s dvěma firmami. Také díky těmto propojením jsem nakonec musel plánovaný termín vypracování práce posunout o jeden semestr. Na druhou stranu pro mě bylo přínosné jak jednání s oběma firmami, tak následný vývoj v týmu. Nyní se pokusím zhodnotit samotnou práci, popsat zda a jaký měla přínos. Myslím, že práce nakonec splnila předem stanovené cíle a je úspěchem, že je dostupná každému, kdo by chtěl využít její služby. Také já jsem při vývoji získal mnoho nových zkušeností, které prostřednictvím této práce předávám. Poněkud problematičtější může být pohled na práci z dlouhodobého pohledu. V době dokončování této práce se objevila informace (23), že nová verze operačního systému Windows Phone má vyjít v říjnu letošního roku a přestože by na této verzi měly jít spustit všechny aplikace z verze současné, jejich vývoj by již měl probíhat za použití jiných nástrojů (a programovacího jazyka). Nabízí se zde otázka, jak dlouho může být tato práce aktuální a informace v ní obsažené užitečné jiným vývojářům. S tímto problémem se ale potýká velká část prací zaměřených na informační technologie a je otázka, jak stanovit časové období, po které by informace obsažené v práci měly být aktuální. Když odhlédnu od platformy, na které aplikace běží, myslím, že celkový koncept anonymního sdílení tras a jejich následného zpracování a zpětného dodání informací uživateli může být velmi prospěšný a úspěšný, tím spíše, že dosud žádná aplikace, která by tuto službu nabízela, nejspíše neexistuje. Proto se budu snažit udržet projekt při životě i po ukončení diplomové práce.

Stránka | 93

Citovaná literatura 1. Nejedlý, Ondřej. Cyklistika v městském a příměstském prostoru. Brno : autor neznámý, 2009. str. 42. 2. Hantová, Jitka. Lidé s tělesným postižením na vozíku a jejich pohled na fyzické a psychické bariéry. 2011. str. 70. 3. Volfová, Kateřina. Bariéry v městě České Budějovice. Brno : autor neznámý, 2011. 4. Fling, Brian. Mobile Platform Marketshare for October 2011. pinch/zoom. [Online] 4. Prosinec 2011. [Citace: 5. Únor 2012.] http://pinchzoom.com/posts/mobile-platform-marketshare-foroctober-2011/mobile-platform-marketshare-for-october-2011. 5. Holan, Karel. Navigační systémy, Analýza trhu technický řešení a ASW. 2007. str. 80. 6. Jarvinen, Jani, DeSalas, Javier a LaMance, Jimmy. Assisted GPS: A Low-Infrastructure Approach. GPS World. [Online] 1. Březen 2002. [Citace: 5. Únor 2012.] http://www.gpsworld.com/gps/assisted-gps-a-low-infrastructure-approach-734. 7. Microsoft. Hardware Specifications for Windows Phone. MSDN. [Online] 15. Listopad 2011. [Citace: 2. Únor 2012.] http://msdn.microsoft.com/en-us/library/ff637514(v=vs.92).aspx. 8. Abrahamsson, Pekk, a další, a další. Agile software development methods. Espoo, Finland : autor neznámý, 2002. 9. Pachal, Peter. Windows Phone Marketplace Passes 50,000 Apps. Mashable. [Online] 28. Listopad 2011. [Citace: 2. Květen 2012.] http://mashable.com/2011/12/27/windows-phonehits-50000-apps/. 10. Herrera, Chris De. Versions of Windows CE / Windows Mobile. Pocket PC FAQ. [Online] 15. Listopad 2009. [Citace: 20. Duben 2012.] http://www.pocketpcfaq.com/wce/versions.htm. 11. Microsoft. Metro Design Language of Windows Phone 7. .toolbox. [Online] 2012. [Citace: 14. Duben 2012.] http://www.microsoft.com/design/toolbox/tutorials/windows-phone7/metro/default.aspx#GuidingPrinciples. 12. Roberts, Chad, Smuga, Michael a Shum, Albert. Windows Phone UI and Design Language. chanell9. [Online] 2012. [Citace: 3. Květen 2012.] http://channel9.msdn.com/events/MIX/MIX10/CL14. 13. Microsoft. Hardware Specifications for Windows Phone. msdn.microsoft.com. [Online] 23. Březen 2012. [Citace: 21. Duben 2012.] http://msdn.microsoft.com/enus/library/ff637514(v=vs.92).aspx. 14. Google. Galaxy Nexus. Android. [Online] [Citace: 20. Duben 2012.] http://www.android.com/devices/detail/galaxy-nexus. 15. Microsoft. Application Tabs (Pivot Control) for Windows Phone. http://msdn.microsoft.com/. [Online] 22. Březen 2012. [Citace: 12. Duben 2012.] http://msdn.microsoft.com/enus/library/hh202890(v=vs.92).aspx.

Stránka | 94

16. —. Interactions and Usability with Windows Phone. msdn.microsoft.com. [Online] 22. Březen 2012. [Citace: 29. Březen 2012.] http://msdn.microsoft.com/enus/library/hh202889(v=vs.92).aspx. 17. Comentsys. Expander Control. CESPage.com Silverlight. [Online] 2010. [Citace: 2. Únor 2012.] http://www.cespage.com/silverlight/wp7tut24.html. 18. Microsoft. msdn.microsoft.com. Idle Detection for Windows Phone. [Online] 23. Leden 2012. [Citace: 24. Březen 2012.] http://msdn.microsoft.com/en-us/library/ff941090(VS.92).aspx. 19. —. Background Agents Overview for Windows Phone. msdn.microsoft.com. [Online] 22. Březen 2012. [Citace: 28. Březen 2012.] http://msdn.microsoft.com/enus/library/hh202942(v=vs.92).aspx. 20. —. Execution Model Overview for Windows Phone. http://msdn.microsoft.com/. [Online] 13. Březen 2012. [Citace: 9. Duben 2012.] http://msdn.microsoft.com/enus/library/ff817008(v=vs.92).aspx. 21. —. NavigationService Class. msdn.microsoft.com. [Online] 2012. [Citace: 10. Duben 2012.] http://msdn.microsoft.com/cs-cz/library/system.windows.navigation.navigationservice.aspx. 22. Mayo, John. The C# Station Tutorial. csharp-station. [Online] 1. Leden 2011. [Citace: 20. Únor 2012.] http://www.csharp-station.com/Tutorials/Lesson13.aspx. 23. Ferson, Paul. Windows Phone 8 will run WP7 apps. Neowin.net. [Online] 30. Leden 2012. [Citace: 2. Březen 2012.] http://www.neowin.net/news/windows-phone-8-will-run-wp7-apps. 24. Microsoft. Windows Phone 7. Prohlídka Marketplace. [Online] 2012. [Citace: 10. Duben 2012.] http://www.microsoft.com/windowsphone/cs-cz/howto/wp7/apps/marketplacehub.aspx. 25. NAVSTAR. Navstar GPS User Equipment Introduction. September 1996. 26. Microsoft. Windows Communication Foundation. .NET Framework Developer Center. [Online] [Citace: 2. Únor 2012.] http://msdn.microsoft.com/en-us/netframework/aa663324. 27. W3C. SOAP Version 1.2 Part 0: Primer (Second Edition). W3C. [Online] 27. Duben 2007. [Citace: 2. Duben 2012.] http://www.w3.org/TR/2007/REC-soap12-part0-20070427/#intro. 28. Sutherland, Jeff a Schwaber, Ken . The Scrum Guide. 2011 : autor neznámý, October 2011. 29. Collins-Sussman, Ben, Fitzpatrick, Brian W. a Pilato, Michael . What Is Subversion? Version Control with Subversion. [Online] 2011. [Citace: 5. Duben 2012.] 30. Microsoft. .NET Framework 4. msdn.microsoft.com. [Online] 2012. [Citace: 24. Únor 2012.] http://www.microsoft.com/net. 31. Framework. docforge. [Online] 24. Srpen 2011. [Citace: 12. Duben 2012.] http://docforge.com/wiki/Framework. 32. Microsoft. Microsoft Silverlight. Microsoft / Web. [Online] [Citace: 12. Duben 2012.] http://www.microsoft.com/cze/web/silverlight/.

Stránka | 95

33. Pai, Yogish. SOA Laws. SOA Blueprint. [Online] [Citace: 13. Duben 2012.] http://soablueprint.com/soa_laws. 34. Hemmendinger, David. operating system (OS). Encyclopædia Britannica. [Online] [Citace: 13. Duben 2012.] http://www.britannica.com/EBchecked/topic/429897/operating-systemOS/. 35. Microsoft. Windows Azure. Windows Azure. [Online] [Citace: 13. Duben 2012.] http://www.microsoft.com/cze/azure/. 36. Jeffery, Joel. Windows 7 Phone, Silverlight and SharePoint 2010. joelblogs. [Online] 04. Březen 2010. [Citace: 19. Březen 2012.] http://joelblogs.co.uk/2010/10/04/windows-phone-7in-7-introducing-windows-phone-7/.

Stránka | 96

Terminologický slovník Termín

Zkratka

Význam [zdroj]

Windows Phone 7

WP7

mobilní operační systém, vyvíjený společností Microsoft (autor)

Marketplace

virtuální obchod společnosti Microsoft, ve kterém naleznete aplikace, hry, hudbu, filmy, televizní pořady a podcasty (24)

Global Positioning

GPS

System

Navstar Global Positioning System je založený na družicích obíhajících po oběžné dráze. Je to systém zajišťující zjišťování polohy pomocí rádiových vln a přenosu časové značky. Systém může poskytovat informace o poloze, rychlosti a času neomezenému množství uživatelů na zemi, na vodě i ve vzduchu (25 stránky 1-1)

Assisted GPS

AGPS

Assisted GPS popisuje systém, v kterém pomáhají externí zdroje GPS přijímači zpracovávat úlohy spojené s určováním polohy (6)

Windows

WCF

součást .NET Framework, která poskytuje programovací

Communication

model pro rychlý vývoj servisně orientovaných aplikací,

Foundation

které komunikují přes web (26)

Simple Object Access

SOAP

bezstavový, jednosměrný systém pro výměnu zpráv (27)

Protocol SCRUM

procesní Framework, který se používá pro řízení vývoje komplexních produktů (28 str. 3)

Subversion

SVN

opensource verzovací systém, to znamená, že spravuje soubory a adresáře a jejich změny (29)

Extensible Application

XAML

Markup Language .NET Framework

značkovací jazyk, používaný k návrhu grafického uživatelského rozhraní aplikací používaný v .NET (autor)

.NET

platforma pro vývoj aplikací, která poskytuje služby, vývoje, nasazení a provoz desktopových, webových a mobilních

Stránka | 97

Termín

Zkratka

Význam [zdroj] aplikací a webových služeb (30)

Bod zájmu

POI

bod, který obsahuje jméno a popis a umístění tyto informace sdílí mezi uživateli (autor)

Framework

softwarový Framework je souhrn kódu a/nebo knihoven, které poskytují svojí funkcionalitu dalším aplikacím (31)

Silverlight

platforma určená pro tvorbu dynamického online obsahu a interaktivní práce s ním. Kombinuje text, vektorovou i bitmapovou grafiku, animace a video. (32). SOA

strategie definující byznys operace tak, aby informace byly poskytovány takovým způsobem, aby sloužili k dosažení cílů; těmito cíli může být zvýšení příjmu, spokojenosti zákazníků nebo zvýšení kvality produktů. Business i IT musí spolupracovat při definování strategie a plánu, jak dosáhnout stanovených cílů (33)

Operační systém

OS

je program, který řídí zdroje počítače, obzvláště jejich přidělování ostatním programů (34)

Microsoft Azure

je operační systém pro služby typu cloud computing, který slouží jako prostředí pro vývoj, hostování a správu služeb na platformě Windows Azure (35)

Stránka | 98

Seznam tabulek Tabulka 1 – Cíle aplikace ............................................................................................................................................. 21 Tabulka 2 – Uživatelské požadavky na klienty ................................................................................................... 26 Tabulka 3 – Use Case Přidávat přátele ................................................................................................................... 29 Tabulka 4 – Use Case Mazat přátele ........................................................................................................................ 30 Tabulka 5 – Use Case Prohlížet přátele ................................................................................................................. 31 Tabulka 6 – Use Case Přidávat trasy ....................................................................................................................... 32 Tabulka 7 – Use Case Zobrazovat trasy ................................................................................................................. 33 Tabulka 8 – Use Case Mazat trasy ............................................................................................................................ 34 Tabulka 9 – Use Case Vytvářet uživatelský účet ................................................................................................ 35 Tabulka 10 – Use Case Získávat informace o průjezdnosti ........................................................................... 36 Tabulka 11 – Use Case Měnit uživatelskou fotografii ...................................................................................... 37 Tabulka 12 – Use Case Přidávat body zájmu ....................................................................................................... 37 Tabulka 13 – Use Case Zobrazovat body zájmu ................................................................................................. 38 Tabulka 14 – Use Case Komentovat body zájmu ............................................................................................... 39 Tabulka 15 – Specifikace procesů Přidání trasy ................................................................................................ 44 Tabulka 16 – Specifikace procesů Načtení trasy................................................................................................ 45 Tabulka 17 – Specifikace procesů Načtení možných tras .............................................................................. 46 Tabulka 18 – Specifikace procesů Přidání POI ................................................................................................... 47 Tabulka 19 – Specifikace procesů Zobrazení POI.............................................................................................. 48 Tabulka 20 – Specifikace procesů Přidání přítele ............................................................................................. 49 Tabulka 21 – Specifikace procesů Zobrazení přítele ....................................................................................... 50 Tabulka 22 – Specifikace procesů Přihlášení uživatele .................................................................................. 51 Tabulka 23 – Vyhodnocení cílů ................................................................................................................................. 92

Stránka | 99

Seznam obrázků Obrázek 1 – Procesní mapa ........................................................................................................................................ 27 Obrázek 2 – Use case diagram ................................................................................................................................... 28 Obrázek 3 – Softwarová architektura .................................................................................................................... 40 Obrázek 4 – Softwarová architektura klienta ..................................................................................................... 42 Obrázek 5 – Proces přidání trasy ............................................................................................................................. 52 Obrázek 6 – Proces načtení trasy ............................................................................................................................. 53 Obrázek 7 – Proces načtení možných tras ............................................................................................................ 54 Obrázek 8 – Proces přidání POI ................................................................................................................................ 55 Obrázek 9 – Proces zobrazení POI ........................................................................................................................... 56 Obrázek 10 – Proces přidání přítele ....................................................................................................................... 57 Obrázek 11 – Zobrazení přátel .................................................................................................................................. 58 Obrázek 12 – Přihlášení uživatele............................................................................................................................ 58 Obrázek 13 – Podíl na trhu mobilních operačních systémů ......................................................................... 61 Obrázek 14 – Windows Phone 7 Model architektury ...................................................................................... 63 Obrázek 15 – Návrhový vzor jedináček ................................................................................................................. 67 Obrázek 16 – PivotControl - Home .......................................................................................................................... 69 Obrázek 17 – Životní cyklus aplikace (20) ........................................................................................................... 72 Obrázek 18 – Nastavení credentials........................................................................................................................ 74 Obrázek 19 – Import certifikátu ............................................................................................................................... 76 Obrázek 20 – Asynchronní volání vzdálené metody ........................................................................................ 79 Obrázek 21 – Vytváření klienta................................................................................................................................. 82 Obrázek 22 – Implementace INotifyProperityChanged .................................................................................. 83 Obrázek 23 – RaisePropertyChanges ..................................................................................................................... 83 Obrázek 24 – Bindování XAML .................................................................................................................................. 83 Obrázek 25 – Nastavení DataContext ..................................................................................................................... 84 Obrázek 26 – Třída Settings3..................................................................................................................................... 84

Stránka | 100

Přílohy 

Elektronické přílohy o Zdrojové kódy aplikace  Windows Phone 7 klient  Silverlight klient – jedná se o projekt serverové částí s Silverlight klientem. Solution vytvořil Bc. Vojtěch Růžička, já jsem zpracoval Silverlight projekt. o Certification Test Results o Video Použití aplikace

Stránka | 101