UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Vývoj mobilních aplikací pro více různých platforem Autor BP: Tomáš Oplatek Vedoucí BP: Mgr. Pavel Zeman 2016 Praha
Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Vývoj mobilních aplikací pro více různých platforem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne 8. 1. 2016. Tomáš Oplatek
Poděkování Děkuji vedoucímu bakalářské práce Mgr. Pavlu Zemanovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
Vývoj mobilních aplikací pro více různých platforem Cross-platform mobile application development 6
Abstrakt Tato práce se zabývá schopnostmi frameworků umožňujících multiplatformní vývoj aplikací pro mobilní zařízení. To nám může značně ušetřit náklady na vývoj, jelikož tím opadne vývoj pro každou platformu zvlášť. Jeden z těchto frameworků poté zvolím a budu v něm vyvíjet aplikaci, abych plně otestoval jeho možnosti. V teoretické části se nejdříve zabývám situací na trhu s mobilními zařízeními a poměrem jednotlivých platforem na trhu. Po ní následuje popis a analýza možností tří frameworků: Xamarin, IBM MobileFirst a Apache Cordova. V praktické části jsem testoval schopnosti frameworku Xamarin. Vytvořil jsem v něm vlastní aplikaci, jejímž cílem je převést již existující dobrodružnou textovou hru s názvem Lone Wolf do elektronické podoby tak, aby hráč nemusel ke hraní využívat žádných dalších nástrojů. Výsledná aplikace psaná v jednom jazyce je plně funkční na platformách Android, ios a Windows Phone s více než 98% sdíleného kódu, čímž jsou potvrzeny udávané schopnosti frameworku. Klíčová slova: Xamarin, MobileFirst, Cordova, Lone Wolf, Android, ios, Windows Phone 7
Abstract The purpose of this thesis is to analyze the functionality of cross-platform development frameworks for mobile smart devices. This approach can reduce development costs, because we don t have to develop each app separately. I will then choose one of the frameworks and use it to develop an app to test its abilities. In the theoretical part I first analyze the situation on the smart mobile devices market and the percentage share of each platform. Then I describe these three frameworks in detail: Xamarin, IBM MobileFirst and Apache Cordova. In the practical part I focused on the abilities of framework Xamarin. I used it to create my own app, the purpose of which was to transfer an existing text gamebook called Lone Wolf into an electronic version, so that the player does not have to use any other tools to play it. The resulting app was written in only one language and is fully functional on platforms Android, ios and Windows Phone with more than 98% shared code. This confirms the proclaimed abilities of the framework. Key words: Xamarin, MobileFirst, Cordova, Lone Wolf, Android, ios, Windows Phone 8
Obsah Úvod... 12 1 Trh s chytrými zařízeními... 13 1.1 Vznik trhu... 13 1.2 Zastoupení platforem na trhu... 13 1.2.1 Smartphony... 14 1.2.2 Tablety... 14 1.2.3 Shrnutí... 15 2 Srovnání Platforem... 15 2.1 Android... 15 2.1.1 Technická specifikace... 16 2.2 ios... 16 2.2.1 Technická specifikace... 18 2.3 Windows Phone... 18 2.3.1 Technická specifikace... 19 3 Srovnání frameworků... 20 3.1 IBM MobileFirst (IBM Worklight)... 20 3.1.1 Přístup k vývoji aplikací... 21 3.1.2 Vývojářské prostředí... 22 3.1.3 Vývoj hybridní aplikace... 23 3.1.4 Ostatní služby platformy MobileFirst... 25 3.2 Apache Cordova (PhoneGap)... 27 3.2.1 Přístup k vývoji aplikace... 28 3.2.2 Vývoj pomocí CLI... 30 3.3 Xamarin... 33 3.3.1 Přistup k vývoji aplikací... 33 3.3.2 Vývojářské prostředí... 34 3.3.3 Možnosti sdílení kódu... 34 3.3.4 Xamarin.Forms... 36 3.3.5 Produkty... 37 3.4 Shrnutí... 37 4 Návrh aplikace... 39 4.1 Obecný popis gamebooků a motivace... 39 9
4.2 Gamebook sága Lone Wolf... 40 4.3 Pravidla gamebooku... 40 4.3.1 Vlastnosti postavy... 42 4.3.2 Dovednosti postavy... 43 4.3.3 Předměty... 43 4.3.4 Souboje... 44 4.4 Popis aplikace... 46 4.5 Návrh GUI... 46 4.5.1 Úvodní obrazovka (Title Page)... 47 4.5.2 Obrazovka Sekce (Section Page)... 48 4.5.3 Obrazovka Vlastnosti (Stats Page)... 50 4.5.4 Obrazovka Předměty (Items Page)... 51 4.5.5 Obrazovka Souboj (Fight Page)... 52 4.5.6 Obrazovka Zvolení předmětů (Choose Items Page)... 53 4.5.7 Navigace... 54 4.6 Načtení informací o knize... 54 4.6.1 Struktura HTML souboru... 54 4.6.2 Syntaktická analýza... 56 4.7 Datová struktura... 58 5 Implementace aplikace... 59 5.1 Struktura aplikace... 60 5.1.1 Vrstvy... 60 5.2 Práce s databází... 60 5.2.1 Načtení databáze... 61 5.2.2 ORM... 61 5.2.3 SQLite na WP... 62 5.3 Navigace... 62 5.3.1 Nová hlavní obrazovka... 62 5.3.2 Zachování zásobníku... 62 5.4 Práce se soubory... 63 5.5 Vytvoření sekce... 63 5.5.1 Obecný HTML parser... 64 5.5.2 Unikátní sekce... 64 5.6 Srovnání GUI na platformách... 65 10
5.6.1 Testovací zařízení... 65 5.6.2 Úvodní obrazovka... 66 5.6.3 Obrazovka Vytváření postavy... 67 5.6.4 Obrazovka Sekce... 68 5.6.5 Obrazovka Vlastnosti... 70 5.6.6 Obrazovka Předměty... 71 5.6.7 Obrazovka Souboj... 72 5.6.8 Obrazovka Hádanka... 73 5.6.9 Vyskakovací okna... 74 5.7 Kód specifický pro platformu... 75 5.7.1 Dlouhý text tlačítka... 75 5.7.2 Chyba při odebírání předmětu na WP... 76 5.7.3 Mezera u horního okraje obrazovky... 77 5.8 Shrnutí implementace... 77 Závěr... 78 Seznam zdrojů... 79 Tabulky... 83 Obrázky... 84 Přílohy... 85 Příloha A... 86 11
Úvod Vývoj aplikací pro smartphony a tablety je dnes oblast, která se velice rychle rozvíjí. I přesto, že tyto mobilní zařízení jsou již nějakou dobu na trhu, se stále jedná o relativně nové a lukrativní odvětví ve vývoji aplikací. Na trhu mobilních zařízení není dominantní pouze jedna platforma, ale spotřebitelé mohou vybírat z mnoha možností. Jedná se např. o platformy Android od firmy Google, ios od firmy Apple a Windows Phone od firmy Microsoft. Standardně je nutné pro každý operační systém vyvíjet stejnou aplikaci zvlášť, v jiných programovacích jazycích a s minimální možností sdílení kódu mezi jednotlivými platformami. zvyšuje náklady na vývoj aplikace. To samozřejmě Proto dnes vznikají tzv. frameworky (český překlad je aplikační rámec, ale v praxi se příliš nepoužívá), které umožňují vývoj aplikace na několik platforem najednou, ve stejném jazyce. Zároveň umožní sdílení většiny aplikační logiky. Zaujala mě proto možnost otestovat jejich funkčnost a přístup k vývoji takovéto multiplatformní aplikace. Teoretická část této práce je zaměřena na přístup tří zvolených frameworků k vývoji aplikace, jejich možnosti a pro koho jsou vhodné. Konkrétně se jedná o tyto tři frameworky: Xamarin, IBM Worklight a Apache Cordova. Praktická část práce se bude zabývat vývojem aplikace ve frameworku Xamarin, na které předvedu práci s tímto frameworkem. Poté otestuji aplikaci na zvolených platformách a ukáži případné rozdíly ve funkčnosti a vzhledu. Pro definování platforem, na kterých bude má aplikace funkční, nejdříve zjistím nynější zastoupení jednotlivých platforem na trhu. K tomu využiji výzkumy trhu od americké společnosti International Data Corporation (IDC). Na základě těchto dat zvolím 3 platformy s největším zastoupením. Aplikace bude umožňovat hraní jednoho dílu tzv. gamebooku dobrodružné hry v knižní formě. Konkrétně se jedná o gamebook od autora Joe Devera s názvem Voyage of the Moonstone, k němuž jsou uvolněna autorská práva. Gamebook má určitá pravidla, která bude tato aplikace implementovat, a umožní uživateli gamebook hrát bez pomoci tužky a papíru, které jsou jinak nezbytnou součástí. V rámci práce popíšu pravidla tohoto gamebooku a návrh jejich implementace ve své aplikaci. 12
1 Trh s chytrými zařízeními 1.1 Vznik trhu Když se v dnešní době bavíme o chytrých zařízeních, myslíme tím většinou smartphony a tablety, tedy mobilní dotyková zařízení. Tento pojem se však používá i pro další elektronická zařízení, např. lednice, která je schopná sama objednat jídlo. V této práci se budu zabývat pouze mobilními dotykovými zařízeními. Když Apple ještě pod vedením Steva Jobse vydal v roce 2007 svůj první smartphone s názvem iphone, naprosto tím změnil celý trh s mobilními zařízeními. Do té doby standardní ovládání tlačítky bylo nahrazeno dotykovým ovládáním. V následujících letech proběhla kompletní transformace trhu na tento typ zařízení, na což se některým společnostem nepodařilo zareagovat. To se týkalo hlavně firmy Nokia, která byla do té doby dominantním výrobcem na trhu s mobilními zařízeními. Té se od roku 2007 do roku 2013 propadl podíl na trhu z 50% až na 3%. [1] Zároveň to ale umožnilo raketový vzestup nových, převážně asijských značek, např. Samsung, HTC, LG, Xiaomi. Tato změna na trhu zároveň způsobila razantní změnu ve vývoji aplikací pro mobilní zařízení. Hlavní změna spočívala v samotném ovládání aplikace a vzniku nových ovládacích prvků, např. hardwarová klávesnice byla odstraněna a zůstala pouze klávesnice softwarová, posouvání je řešeno posunem prstu po obrazovce nebo tzv. multi-touch (česky vícedotykové ovládání ), které umožňuje zařízení reagovat na více dotyků najednou. Rovněž se velmi výrazně zvětšila úhlopříčka displejů. Další z chytrých zařízení opět uvedl Apple, a to v roce 2010. Jednalo se o první komerčně úspěšný tablet, nazvaný ipad. I toto zařízení zaznamenalo podobný úspěch jako iphone a vytvořilo do té doby prakticky neexistující trh s tablety. Jednalo se o zařízení velice podobné iphonu s podobnými vlastnostmi, pouze s větší úhlopříčkou a bez funkcí telefonu, zaměřené hlavně na konzumaci obsahu. Nejrychleji na tuto změnu trhu zareagovala firma Google, která v roce 2008 přišla s první verzí svého systému Android, a firma Microsoft s upgradem svého systému Windows Mobile 6.1 pro dotykové displeje. 1.2 Zastoupení platforem na trhu Pro účely této práce je důležité nejdříve zjistit zastoupení jednotlivých platforem na trhu, jestli je vyvíjení pro danou platformu v současnosti perspektivní a jaké jsou výhledy do budoucna. 13
1.2.1 Smartphony Celkový trh se smartphony již od svého vzniku roste, a rok 2015 v tomto trendu stále pokračuje, jelikož se meziročně zvětšil o 13%. Ve druhém kvartálu roku 2015 se prodalo 341,5 milionů zařízení. [2] Jak můžeme vidět v tabulce 1, na trhu se smartphony čím dál více dominuje operační systém Android. Velký podíl na tomto počtu zařízení mají zařízení v levnější kategorii pod 200$. Na trhu s tímto operačním systémem dosud dominovala značka Samsung, jejíž podíl nyní klesá na úkor nových čínských značek, hlavně značky Xiaomi. [2] ios v celkovém podílu na trhu meziročně vzrostl, což je dáno hlavně úspěchem nových modelů iphone 6s a iphone6s Plus, které jdou na odbyt velmi dobře. Systému Windows Phone se po akvizici firmy Nokia podařilo v roce 2013 zvýšit svůj podíl na trhu, meziročně pak v roce 2014 opět klesl a v roce 2015 stále nedosahuje ani pětiny podílu ios, což je pro Microsoft problém. Navíc některé značky, které se rozhodly dát tomuto systému šanci, od něj nyní opouštějí a soustředí se na telefony pro Android, jelikož se jim nedaří na telefonech s Windows Phone generovat zisk. Hlavním problémem systému je nedostatek aplikací třetích stran, jelikož výrobci se soustředí hlavně na ios a Android, které používá daleko větší procento uživatelů. Firma BlackBerry je jednou z posledních firem, která ještě vyrábí smartphony s klasickou QWERTY hardwarovou klávesnicí i dotykovým ovládáním. Jak ale můžeme vidět v tabulce 1, její podíl na trhu se dramaticky snižuje, firma je navíc populární hlavně v USA, takže vyvíjet aplikace pro evropský trh se nejeví jako moc perspektivní. Mezi ostatní OS patří např. Firefox OS nebo Ubuntu Touch OS. Jejich podíl na trhu je naprosto zanedbatelný, ačkoliv se v obou případech nejedná o vysloveně špatný systém. Hlavní problém těchto zařízení je v nedostatku aplikací pro telefon, což je u smartphonů dnes jedna z nejdůležitějších vlastností. Ostatně tímto problémem trpí i Windows Phone, ačkoliv v menší míře. Tabulka 1: Vývoj trhu se smartphony dle OS [2] Období Android ios Windows Phone BlackBerry OS Ostatní 2015Q2 82.8% 13.9% 2.6% 0.3% 0.4% 2014Q2 84.8% 11.6% 2.5% 0.5% 0.7% 2013Q2 79.8% 12.9% 3.4% 2.8% 1.2% 2012Q2 69.3% 16.6% 3.1% 4.9% 6.1% 1.2.2 Tablety Trh s tablety ještě mezi lety 2013 a 2014 rostl, ale o poznání menším tempem než v minulých letech, meziroční nárůst byl 11,5 procenta při 53,8 milionech kusů. 14
V meziročním srovnání let 2014 a 2015 se prodej tabletů dokonce snížil o 12,6 procent při 48,7 milionech prodaných zařízení. [3] Z tabulky 2 je patrné, že Apple se svými tablety ipad již dlouho nemá dominantní postavení na trhu, to postupně ztratil na úkor Androidu. Uživatelé často dávají přednost levnějším zařízením, která ani v tomto segmentu Apple nenabízí. Některé firmy prodávají tablety s upravenou verzí Androidu, např. firma Amazon vydává vlastní řadu úspěšných tabletů Kindle Fire s upraveným systémem Fire OS. Mírný narůst zažívá operační systém Windows Phone, ale jeho problémy zůstávají stejné jako na trhu smartphonů, tedy nedostatek aplikací, popřípadě jejich vydání s velkým odstupem po ostatních platformách. Odhadovaná situace pro rok 2015 počítá s mírným nárůstem Windows Phone na úkor Androidu a ios. Tabulka 2: Vývoj trhu s tablety dle OS Období Android ios Windows Phone 2015 66% 23.5% 8.4% 2014 67.3% 27.6% 5.1% 2013 62.36% 33.93% 3.5% Zdroj: http://www.statista.com/statistics/272446/global-market-share-held-by-tabletoperating-systems/ 1.2.3 Shrnutí Na základě těchto zjištění se budu soustředit na platformy Android, ios a Windows Phone, jelikož všechny tři platformy mají dostatečnou uživatelskou základnu a při současné podobě trhu je nutné předpokládat, že zadavatel vývoje aplikace bude chtít mít aplikaci funkční na všech těchto platformách. 2 Srovnání Platforem Nyní se zaměřím na popis jednotlivých platforem, jejich stručnou historii a technologické specifikace. 2.1 Android Původní firma Android byla založena v roce 2003 Andy Rubinem, Richem Minerem a Nickem Searsem. V roce 2005 jí odkoupila firma Google a pod jejím vedením nejdříve v roce 2007 vznikla tzv. Open Handset Alliance, která sdružuje další firmy, jako např. HTC, Sony, Intel, Samsung a LG. Toto konsorcium se soustředí na vývoj otevřených standardů pro mobilní zařízení a v roce 2008 vydalo operační systém Android. [4] 15
Android je open source platforma, jedná se tedy o otevřený software a ten je, na rozdíl od ios, používán mnoha výrobci mobilních telefonů, z nichž si ho většina ještě nějakým způsobem sama upraví. Tento přístup má velký podíl na tom, že platforma je dnes nejrozšířenější na světě, jak jsem ukázal v minulé kapitole, a díky tomu je pro ni k dispozici nejvíce aplikací. Má to ale i své nevýhody, a to hlavně pro vývojáře aplikací, kteří musí brát v úvahu obrovské množství zařízení, na kterých musí aplikace být funkční. Platforma umožňuje zpětnou kompatibilitu. Na stránkách pro vývojáře je k dispozici procentuální zastoupení aktuálně používaných verzí a obecně bývá doporučeno, aby aplikace podporovala 90 procent aktivních zařízení při používání nejnovější verze platformy. [5] Od vzniku platformy vyšlo již několik verzí, každá verze operačního systému má zvláštní název, dle sloganu platformy: Jelikož zařízení s platformou Android dělají naše životy tak sladké, je každá verze pojmenována podle dezertu. Např. první verze Android 1.6 se tedy jmenovala Donut (česky kobliha ). Zatím poslední verze systému Android 6.0 se jmenuje Marshmallow. 2.1.1 Technická specifikace Platforma je založena na linuxovém jádře. Jádro Androidu je navrženo tak, aby bylo funkční na různých typech zařízení s různým výkonem, velikostí obrazovky a rozlišením. Nativním jazykem této platformy je jazyk Java a oficiálně podporované vývojářské prostředí je Android Studio, ale je možné použít také IDE Eclipse. Aplikace jsou vyvíjeny pomocí Android SDK, který obsahuje množství nástrojů pro efektivní vývoj aplikací, např. vlastní nástroj pro odladění aplikace, softwarové knihovny, dokumentaci, ukázkové kódy a další. Aplikace se instalují pomocí souborů s koncovkou APK, většinou přes některý obchod s aplikacemi, který umožní přehledné stahování, instalování a odinstalování aplikace. Oficiální obchod Androidu se jmenuje Google Play Store a, na rozdíl od obou dalších platforem zmiňovaných v této práci, do něj může jakýkoliv vývojář nahrát svou aplikaci a to zcela zdarma. Android zařízení využívají hardwarová nebo softwarová tlačítka pro návrat o krok zpět a návrat na domovskou obrazovku, která jsou esenciální pro ovládání telefonu. 2.2 ios Systém ios od firmy Apple má ve světě mobilních zařízení své speciální místo. Ačkoliv Apple nebyl první, kdo se pokusil vyrábět mobilní zařízení s dotykovým ovládáním, tak až 16
jemu se podařilo tato zařízení nabídnout v dostatečně atraktivní a funkční formě, aby oslovila dostatečné množství zákazníků. První verze systému ios ještě neměla spoustu dnes již samozřejmých věcí (např. multitasking, kopírování a vkládání textů, obchod s aplikacemi, nepodporovala 3G sítě). Obsahovala ale již od počátku dotykové ovládání, ke kterému nebyl potřeba stylus. Firmě Apple se podařilo vytvořit ovládání, které je velice intuitivní, jednoduché, a zároveň dobře použitelné pro správu celého telefonu. Každý iphone obsahuje pouze 5 hardwarových tlačítek (z toho jsou 3 na ovládání hlasitosti, 1 na vypnutí/zapnutí telefonu a 1 na návrat na domovskou stránku), vše ostatní je možné ovládat pouze pomocí dotykového displeje. Dvě nejznámější součásti dotykového ovládání, se kterými se můžeme dnes setkat prakticky u všech dotykových zařízení, jsou tzv. Pinch-to-zoom a Inertial scrolling. V prvním případě se jedná o dotykové gesto dvěma prsty, při kterém zvětšujeme nebo zmenšujeme daný objekt. Ve druhém případě se jedná o setrvačné posouvání, kdy se při použití gesta posun obrazovky postupně zpomaluje. Systému ios vyšlo do dnešního dne mnoho verzí, jejichž detailní popis by byl nad rámec této práce, proto v následujících odstavcích zmíním pouze některé důležité milníky ve vývoji. Hned druhá verze ios 2 přinesla dvě důležité nové součásti: obchod s aplikacemi App Store a první verzi ios SDK pro vývojáře aplikací. V dalších verzích postupně přibylo kopírování a vkládání textu a multitasking. V roce 2010 vyšla spolu s vydáním prvního tabletu od firmy Apple (ipad) verze ios 3.2. Ta přinesla řadu funkčností určených přímo pro tablet, např. podporu vyšších rozlišení, speciální vzhled některých aplikací a ergonomičtější softwarovou klávesnici. Ve verzi ios 5 přibyla hlasová asistentka Siri. [6] Až do roku 2013 zůstal design uživatelského prostředí ios prakticky beze změny. V tomto roce vyšla verze ios 7, a s ní přišla první větší změna vzhledu prostředí, přinášející nové ikony, větší barevnost, průhlednost některých prvků a zcela nové Control Center. Control Center umožňuje rychlý přístup k často používaným funkcím telefonu, jako jsou zapnutí/vypnutí Wi-Fi nebo zapnutí/vypnutí baterky, a je možné ho zobrazit přejetím ze spodní části obrazovky směrem nahoru. [6] Zatím poslední verzí je ios 9 z roku 2015, která se soustředí hlavně na vylepšení stávajících aplikací a přidává nové funkce na ipad, např. Split View, umožňující zobrazit dvě obrazovky vedle sebe. 17
2.2.1 Technická specifikace Operační systém ios vychází z operačního systému OS X pro počítače Mac. Systém má hybridní jádro XNU. Všechna zařízení, na kterých běží ios, vyrábí Apple sám. Ve srovnání s ostatními výrobci tak Apple nemusí řešit funkčnost operačního systému na velkém množství zařízení. Systém je proto navržen přímo pro hardware zařízení od Applu. Nativními jazyky pro vývoj aplikací jsou Swift a Objective-C. Stejně jako u ostatních platforem je k dispozici SDK, obsahující nástroje pro vývoj aplikací. Prostředí pro vývoj aplikací je u této platformy Xcode. Obchod s aplikacemi se jmenuje App Store. Celý ekosystém u firmy Apple je velice uzavřený, distribuce aplikací je možná pouze přes App Store. Aby vývojář mohl aplikaci do App Storu nahrát, musí být členem Apple Developer Program, což stojí 99$ ročně. Aplikace musí před nahráním do App Storu projít schvalovacím procesem. [7] Aplikace je možné kompilovat pouze na zařízení s operačním systémem OS X, což znamená, že i při multiplatformním vývoji je nutné toto zařízení mít k dispozici. 2.3 Windows Phone Platforma Windows Phone (WP) byla založena firmou Microsoft (MS) v roce 2010. První verze systému byla verze Windows Phone 7, která byla následovníkem předchozí platformy od MS Windows Mobile. Platforma Windows Mobile byla zaměřena hlavně na firemní sféru, proto obsahovala hlavně nástroje pro usnadnění práce zaměstnancům, např. balíček kancelářských aplikací MS Office. Oproti Windows Mobile se WP7 již nezaměřují pouze na firemní sféru, ale jsou určeny jako operační systém pro co nejširší množství zákazníků. MS se tímto systémem snaží srovnat krok s Androidem a ios. WP7 jsou plně přizpůsobeny dotykovému ovládání bez stylusu. Na rozdíl od Androidu, který se při vytváření uživatelského rozhraní nechal inspirovat ios, přichází MS s vlastním řešením uživatelského rozhraní. Jedná se o rozhraní Metro, které je založeno na konceptu tzv. živých dlaždic. Hlavní obrazovka na telefonu je složena z těchto dlaždic, které mají formát obdélníku nebo čtverce. Dlaždice mohou být pouze ikona s neměnným obsahem, nebo mohou dynamicky zobrazovat aktuální informace, např. počasí nebo poslední přijatou zprávu. MS se tímto výrazně odlišil od konkurence a telefon opravdu působil jinak než ostatní. Styl nového operačního systému byl přijat relativně dobře, systém získal v roce 2011 několik ocenění na soutěži International Design Excellence Awards. [8] Na uživatele zvyklé na ostatní operační systémy ale tento styl často působil 18
jako nepřehledný a zmatený. [9] V první verzi systému také chyběly některé podstatné funkčnosti, např. kopírování a vkládání textu, což podstatně komplikovalo práci s jinak dobře zpracovanou MS Office aplikací. V roce 2012 vyšla nová generace operačního systému, Windows Phone 8 (WP8). Tato generace přinesla mnoho změn, z nichž nejpodstatnější byla změna architektury systému. To ale bohužel znamenalo, že uživatelé starších verzí WP nemohli přejít na novější verzi, a to ani ti, kteří měli top model telefonu s výkonným hardwarem. Nový systém umožnil používání SD karet, zvětšil maximální rozlišení obrazovky a přinesl i změny v uživatelském rozhraní. Dlaždice bylo nově možné zvětšovat a zmenšovat (k dispozici jsou 3 velikosti malá, střední a velká), přibyly nové barvy pro celkový vzhled systému a nové typy dlaždic. Dlaždice mohou nyní obsahovat informace na přední i zadní straně a systém pak dlaždici sám v pravidelných intervalech obrací. [9] Verze Windows Phone 8.1 (WP8.1) z roku 2014 byla zpětně kompatibilní s předchozí verzí a byla k dispozici všem uživatelům WP8. Přinesla další změny uživatelského rozhraní, např. možnost nastavit průhlednost dlaždic, přidání třetího sloupce dlaždic na hlavní obrazovku a hlasovou asistentku s názvem Cortana. Zatím poslední verzí tohoto operačního systému je systém Windows 10 Mobile. V této verzi systému se MS snaží o co nejužší propojení svých zařízení (mobilů, tabletů, herních konzolí XBOX a PC), a to formou Universal Windows Platform (UWP) aplikace. Tato platforma je založena na myšlence, že kód aplikace bude stejný na všech zařízeních, pouze se bude měnit způsob ovládání aplikace dle zařízení, na kterém je nainstalována. MS rovněž připravuje nástroje, díky kterým bude možné snadno převést aplikaci pro i OS na UWP. Tímto krokem by se Microsoft mohl vypořádat s problémem, který trápí tento WP již několik let, a tím je nedostatek aplikací (či jejich funkčností) ve srovnání s konkurenčními systémy. [10] 2.3.1 Technická specifikace Verze WP7 měla jádro operačního systému založené na Windows Embedded Compact 7, ale od verze WP8 má systém jádro typu Windows NT, což je stejné jádro, které používají operační systémy Windows pro PC. Aplikace je možné vyvíjet v jazycích C#, Visual Basic a C++, pro definici UI se používá jazyk XAML. K dispozici je Windows Phone SDK, které obsahuje všechny potřebné nástroje pro vývoj aplikace a emulátory pro testování aplikace. Oficiální prostředí pro vývoj aplikací je Microsoft Visual Studio. 19
Aplikace se instalují pomocí souborů s koncovkou XAP nebo APPX. Obchod s aplikacemi od MS se jmenuje Windows Store. Pro nahrání aplikace je nutné mít MS Developer účet, který je zpoplatněn, a aplikace musí být před nahráním schválena. Všechny verze WP mají ve spodní části telefonu 3 hardwarová tlačítka: tlačítko Zpět (návrat o jednu stránku), tlačítko Start (návrat na hlavní stránku) a tlačítko Vyhledat. 3 Srovnání frameworků 3.1 IBM MobileFirst (IBM Worklight) Platforma pro multiplatformní vývoj aplikací od přední světové IT společnosti IBM se jmenuje IBM MobileFirst Platform Foundation a je založena na webových technologiích. Firma IBM framework zakoupila od izraelské společnosti Worklight v roce 2012. [11] Framework se původně jmenoval IBM Worklight a byl součástí platformy MobileFirst, která obsahuje i další nástroje pro podporu a vývoj mobilních aplikací. Platforma MobileFirst není pouze framework pro vývoj aplikací, ale je to balíček nástrojů pro podporu managementu, bezpečnosti a analýzy aplikací. Hlavní tři součásti platformy jsou: IBM MobileFirst Platform Foundation obsahuje samotný framework a další nástroje pro vývoj hybridních či nativních aplikací pro mobilní zařízení a jejich testování a správu IBM MobileFirst Platform Application Scanning nástroje pro prověření bezpečnosti aplikace, nalezení případných zranitelností a jejich včasné odstranění IBM MobileFirst Platform Quality Assurance nástroje pro efektivní testování a analýzu chování aplikace, obsahuje hlavně automatické reporty při selhání aplikace a jejich analýzu, možnost odeslat chybové hlášení přímo z aplikace a nástroje pro analýzu reakcí uživatelů (ať už přímo z aplikace nebo získanou z obchodů s aplikacemi) V této práci se budu soustředit hlavně na IBM MobileFirst Platform Foundation a na přístup k vývoji multiplatformních (hybridních) aplikací. Tu je možné získat ve třech edicích. Pouze první z nich, s názvem IBM MobileFirst Platform Foundation Developer Edition, je k dispozici zdarma. Obsahuje pouze vývojářské nástroje. Při stažení je sice uváděno, že se jedná o trial verzi, ale dle dokumentace je tato edice zcela zdarma. [12] [13] 20
Další dvě edice, IBM MobileFirst Platform Foundation Consumer Edition a IBM MobileFirst Platform Foundation Application Pattern Consumer Edition, obsahují další nástroje a podporu od IBM. Cena za tyto edice není fixní, a pro její získání je nutné kontaktovat přímo IBM. Z dostupných informací jsem ale zjistil, že cena pouze za IBM MobileFirst Platform Foundation je přes 36000 $ za rok pro jednoho vývojáře. [14] Framework v této edici je tedy zcela jasně cílen hlavně na větší společnosti. 3.1.1 Přístup k vývoji aplikací U tohoto frameworku jsou k dispozici čtyři přístupy k vývoji mobilní aplikace (obrázek 1). Obrázek 1 - IBM MobileFirst typy aplikací [15 str. 20] Webová aplikace běží na serveru a je přístupná přes webový prohlížeč, je pouze optimalizovaná pro zobrazení na mobilu. Hybridní aplikace je vytvářena za pomocí webových technologií, ale funguje jako aplikace a má přístup k API zařízení. Nativní aplikace je psaná v nativním kódu daného zařízení, ale stále může využívat serverové API MobileFirst a další nástroje. Hybridní aplikace mix je kombinace předchozích dvou přístupů, umožňující část kódu psát v nativním jazyce platformy a část pomocí webových technologií. MobileFirst používá technologie založené na standardech pro integraci přímo s SDK jednotlivých platforem, díky čemuž není nutný překlad kódu, interpret ani některý z méně známých skriptovacích jazyků. [15 str. 20] 21
Pro účely této práce je důležitý hlavně hybridní přístup, díky kterému je možné psát aplikaci pouze za pomocí webových technologií a není nutné znát nativní kód platformy. To znamená, že pro vývoj používáme jazyky HTML5, CCS3 a JavaScript. Zpočátku byl tento přístup k vývoji aplikací preferovaný, ale v průběhu psaní této práce se situace změnila. Od verze 6.3 jsou součástí frameworku vylepšené nativní API pro tři hlavní platformy (WP, Android a ios) a mnoho společností využívající MobileFirst se dnes přiklání spíše k tomuto typu vývoje. [16] Zde bych ještě rád zmínil, že některé funkčnosti frameworku pro zobrazení nativních prvků na jednotlivých platformách (např. nativní alert box při zavolání javascript funkce alert ), využívají ve skutečnosti framework Apache Cordova [17], který bude popsán v následující kapitole. 3.1.2 Vývojářské prostředí Pro vývoj aplikace je možné použít IDE MobileFirst Studio, které je k dispozici formou pluginu do populárního IDE Eclipse. Tento plugin obsahuje vše potřebné pro vývoj, testování aplikací a komunikaci s MobileFirst serverem. Pro uživatele, kteří jsou již zvyklí na práci v některém z jiných IDE nebo textových editorů, je k dispozici CLI ( Command- Line Interface ), díky němuž mohou využívat většiny standardních funkcí pomocí příkazové řádky. Aktuální verze IDE je 7.1.0, nicméně v době psaní této práce obsahuje plugin chybu, a je nutné nainstalovat starší verzi 7.0.0 a tu poté upgradovat. [18] 22
3.1.3 Vývoj hybridní aplikace Vytvoření nové hybridní aplikace v MobileFirst Studiu je jednoduché, pouze vytvoříme nový projekt typu hybridní aplikace, do kterého můžeme v rámci vytváření přidat volitelné knihovny jquery mobile, Dojo Toolkit a Sensa Touch. Tím získáme základ pro vývoj aplikace a složku common pro sdílený kód, jak můžeme vidět na obrázku 2. Obrázek 2: Nově vytvořený projekt Zdroj: Vlastní zpracování Nyní musíme zvolit platformy, na kterých chceme, aby aplikace fungovala. Vytvoříme tedy nový MobileFirst artefakt typu MobileFirst Environment. U mobilních aplikací máme na výběr ze všech nejpoužívanějších platforem, včetně systému Blackberry, jak můžeme vidět na obrázku 3. 23
Obrázek 3: Dostupné platformy Zdroj: Vlastní zpracování Pro každou zvolenou platformu jsou vytvořeny složky se soubory (obrázek 4), které mají přednost před soubory ze složky common, takže jejich pomocí můžeme měnit vzhled a chování aplikace na jednotlivých platformách. 24
Obrázek 4: Složky platforem Zdroj: Vlastní zpracování Aplikaci můžeme odlaďovat přes standardní emulátory dostupné s SDK jednotlivých platforem, nebo přes webové rozhraní služby MobileFirst Application Center. 3.1.4 Ostatní služby platformy MobileFirst Platforma MobileFirst neslouží pouze k vývoji hybridních aplikací. Obsahuje ještě další nástroje, které jsou používány v průběhu celého životního cyklu aplikace. Pět klíčových komponent platformy MobileFirst je znázorněno na obrázku 5 (v knize je framework veden ještě pod starým názvem Worklight). 25
Obrázek 5: Pět MobileFirst komponent [15 str. 21] MobileFirst Server MobileFirst Server je podstatnou součástí celé platformy. Funguje jako škálovatelná gateway (česky brána ) mezi mobilní aplikací a externími službami nebo servery. Díky tomuto serveru je umožněna např. šifrovaná komunikace mezi mobilní aplikací a servery, autentizace aplikace, manipulace s daty a automatický sběr údajů o používání aplikace. Na serveru může být umístěná webová část aplikace. Komunikace s externími službami a aplikacemi probíhá pomocí adaptérů na straně serveru. Tyto adaptéry mohou být typu JMS, SAP, SQL, Cast Iron nebo HTTP. Adaptér se vytváří pomocí MobileFirst Studio a poté je nahrán na MobileFirst Server. Každý adaptér obsahuje XML soubor, ve kterém jsou parametry připojení a deklarace procedur, a JavaScript soubor. Ten obsahuje definici procedur a vlastní logiku adaptéru. Data získaná adaptérem jsou aplikaci vracena jako JSON objekt. 26
MobileFirst Console Tento nástroj slouží ke správě MobileFirst serveru. Jedná se o webové uživatelské rozhraní, přes které můžeme spravovat všechny v současnosti nasazené aplikace a adaptéry. Mezi další klíčové vlastnosti konzole patří: [15 str. 26] Správa push notifikací odeslání notifikace uživatelům aplikace Správa více verzí stejné aplikace je možné vzdáleně ukončit aplikaci v závislosti na verzi aplikace nebo operačního systému Zobrazení statistik používání aplikace MobileFirst Application Center Application Center je vlastní obchod s aplikacemi, pomocí kterého je možné efektivně distribuovat aplikace v rámci společnosti. Obchod je přístupný přes webové rozhraní a uživatelé pomocí něho mohou instalovat dostupné aplikace. Je možné použít případné již existující frameworky pro autentizaci a na jejich základě zobrazit skupinám/uživatelům pouze aplikace, které jsou pro ně určené. Obchod obsahuje i prvky známé z klasických veřejných obchodů s aplikacemi, jako jsou hodnocení aplikace a komentáře. Aplikační centrum umožňuje spravovat pouze aplikace na platformy Android, ios a BlackBerry. [15 str. 25] 3.2 Apache Cordova (PhoneGap) Apache Cordova (AC) je multiplatformní open source framework založený na webových technologiích a je poskytován zdarma v rámci licence Apache License firmou Adobe Systems. Framework od doby svého vzniku prošel několika změnami názvů, z nichž ten původní, PhoneGap, dnes Adobe používá pro jiný framework, který je pouze nadstavbou nad AC. Situace bude jasnější, když se podíváme na historii AC. Původní framework s názvem PhoneGap byl založen firmou Nitobi již v roce 2008 za účelem usnadnění vývoje multiplatformních aplikací. Nejdříve byla dostupná platforma ios, poté Android a Blackberry. S přidáním dalších platforem si framework získával stále větší oblibu a v roce 2009 vyhrál dokonce ocenění na soutěži Web 2.0 Expo v San Franciscu. [19] Firmu Nitobi v roce 2011 koupila firma Adobe a ta následně vydala framework jako open source produkt, nejdříve s původním názvem PhoneGap, poté krátce s názvem Apache Callback, a nakonec (od verze 1.4) jako Apache Cordova. [20 str. 4] 27
3.2.1 Přístup k vývoji aplikace AC je založený na webových technologiích, aplikace tedy vyvíjíme pomocí HTML5, CSS3 a JavaScriptu. Vytváříme v zásadě standardní webovou aplikaci pomocí libovolného IDE. Aplikace může obsahovat i některé z populárních dostupných frameworků pro CSS nebo JavaScript. AC se poté samo postará o spuštění této aplikace na jednotlivých platformách. U většiny platforem to znamená, že je vytvořena nativní aplikace, která obsahuje jedno nativní WebView (komponenta pro zobrazení webového obsahu). To zaplní celou dostupnou plochu zařízení a zobrazí naší webovou aplikaci. Výjimku tvoří např. platforma Firefox OS, ve které je nativní aplikace totožná s webovou aplikací, a není tedy nutné žádné WebView, webová aplikace je spuštěna přímo na zařízení. [20 str. 3] Aplikace tedy funguje jako webová, není ale dostupná přes webový prohlížeč. Místo toho může být distribuována typickým způsobem, většinou přes některý z veřejných obchodů s aplikacemi pro danou platformu. To však není jediná věc, co nám AC umožňuje. Další jeho podstatnou součástí je JavaScript API, které nám umožní přístup k nativním API zařízení. Naše aplikace tedy bude moci např. získat přístup k fotoaparátu, seznamu kontaktů, stavu baterie a mnoha dalším funkcím. Tyto API jsou k dispozici pomocí pluginů do AC. Pro všechny funkčnosti jsou samostatné pluginy, které můžeme mezi sebou libovolně kombinovat. Od verze 3.0 neobsahuje AC projekt po vytvoření žádné, ani základní pluginy, a všechny tedy musíme manuálně přidat. [21] Schéma aplikace a pluginů je znázorněno na obrázku 6. 28
Obrázek 6: Schéma pluginů [20 str. 6] Co se týče postupu při vývoji aplikace, umožňuje nám AC tyto dva: [21] Cross-platform (CLI) sdílený kód pro velké množství platforem, žádný vývoj v nativním kódu platformy, použití pomocí utility Cordova přístupné přes příkazovou řádku Platform-centered pokud je aplikace zaměřena na menší množství platforem, kombinace nativního kódu a webových technologií Pro účely této práce je podstatný hlavně první ze zmíněných postupů, jelikož nám umožňuje sdílet nejvíce kódu, nemusíme znát nativní jazyky pro danou platformu a pomocí utility Cordova můžeme aplikaci spravovat centrálně pro všechny platformy. 29
3.2.2 Vývoj pomocí CLI AC neobsahuje žádné vlastní IDE, veškerá práce s projektem je realizována pomocí příkazové řádky a některého ze standardních textových editorů pro vývoj webových aplikací. Rovněž je k dispozici spousta rozšíření do existujících IDE, např. Tools for Apache Cordova pro Visual Studio. [22] Před instalací samotného CLI je nutné mít v počítači nainstalován JavaScript framework Node.js a verzovací systém Git. Poté můžeme na systému Windows nainstalovat AC přes příkazovou řádku tímto příkazem (díky parametru g bude Cordova přístupná globálně, ne pouze z aktuální složky): C:\>npm install -g cordova Po úspěšné instalaci můžeme z příkazové řádky používat utilitu Cordova. Pro ukázku jsem vytvořil vlastní projekt s názvem BPTest, a to pomocí příkazu create s následujícími argumenty: C:\>cordova create bp cz.test.bp BPTest Argumenty jsou dobře popsány v dokumentaci frameworku. [23] První argument bp je název hlavního adresáře projektu, který utilita vytvoří. Druhý argument je reversované doménové jméno projektu (nepovinný). Třetí argument obsahuje název naší aplikace (rovněž nepovinný). Tímto příkazem je vytvořen základ projektu, konkrétní složky můžeme vidět na obrázku 7 a 8. 30
Obrázek 7: Složka bp Zdroj: Vlastní zpracování Obrázek 8: Složka www Zdroj: Vlastní zpracování Soubor config.xml je konfigurační soubor projektu, obsahuje údaje jako jsou název aplikace, revertované doménové jméno nebo zda má aplikace reagovat na změnu orientace zařízení. Složka www obsahuje webovou aplikaci s předvytvořenými složkami pro umístění CSS, JavaScript souborů a obrázků. Dále v ní najdeme domovskou stránku aplikace index.html. Složky platforms a plugins jsou po vytvoření projektu prázdné, platformy a pluginy je nutné přidat manuálně. V době psaní této práce jsou u CLI podporovány následující platformy: [24] ios (Mac) Amazon Fire OS (Mac, Linux, Windows) Android (Mac, Linux, Windows) BlackBerry 10 (Mac, Linux, Windows) Windows Phone 8 (Windows) Windows 8.0, 8.1, 10 + Windows Phone 8.1 (Windows) Firefox OS (Mac, Linux, Windows) Ubuntu (Linux distribuce Ubuntu) Jak můžeme vidět, ani u tohoto frameworku není možné vyvíjet aplikace pro všechny podporované platformy z prostředí jednoho operačního systému. Navíc je stále nutné manuálně nainstalovat SDK pro každou platformu, pro kterou chceme vyvíjet, AC tuto činnost na rozdíl od frameworku Xamarin za nás nevykoná. Svou ukázkovou aplikaci 31
jsem vytvořil v prostředí Windows 10 s nainstalovaným Android SDK, nyní tedy mohu přidat platformy Android, WP8 a Windows do projektu pomocí příkazů: C:\bp>cordova platform add wp8 C:\bp>cordova platform add windows C:\bp>cordova platform add android Díky těmto příkazům se nám ve složce platforms vytvořila složka s nativními aplikacemi pro každou platformu. Každá složka obsahuje svojí verzi sdílené složky www, je však třeba mít na paměti, že obsah této složky je utilitou Cordova často přepisován. Proto veškeré změny musíme provést nad sdílenou složkou www. [23] Nyní již je naše aplikace připravená, stačí pouze provést příkaz build a poté aplikaci spustit na emulátoru nebo na připojeném zařízení. Pro ukázku jsem zvolil spuštění aplikace na telefonu HTC One S pomocí následujících příkazů: C:\bp>cordova build android C:\bp>cordova run android Výsledek můžeme vidět na obrázku 9. 32
Obrázek 9: Nainstalovaná AC aplikace Zdroj: Vlastní zpracování 3.3 Xamarin Firma Xamarin byla založena v květnu 2011 a nyní sídlí v San Francisku. Firma vydává několik produktů umožňujících multiplatformní vývoj aplikací. Platforma Xamarin je založená na open source projektu Mono, který založil pan Miguel de Icaza (rovněž jeden ze spoluzakladatelů firmy Xamarin) hned po vzniku platformy.net v roce 2000. Projekt Mono umožňuje funkčnost platformy.net i na ostatních platformách, je tedy funkční např. na Androidu, linuxových distribucích, OS X a Solarisu. Rovněž obsahuje vlastní C# kompilátor. [25] 3.3.1 Přistup k vývoji aplikací Přístup frameworku Xamarin není založen na webových technologiích, ale vychází z jazyka C#. Pro vývoj mobilních aplikací v Xamarinu totiž stačí pouze znalost tohoto programovacího jazyka. To je umožněno díky již zmíněnému projektu Mono. 33
Pro Windows Phone není nutné žádné speciální kompilování, jelikož je C# nativní jazyk této platformy. Pro ostatní platformy je ale nutné speciální kompilování. Pro Android je k dispozici produkt Xamarin.Android. Aplikace je nejdříve zkompilována kompilátorem Xamarinu do mezijazyku (anglicky intermediate language), který je poté Just-in-Time (akronym JIT, volně přeloženo právě včas ) přeložen do nativního kódu při spuštění aplikace. Pro ios je to produkt Xamarin.iOS, který naopak využívá přístup Ahead-of-Time (akronym AOT, volně přeloženo předem ) kompilace ios aplikace do nativního kódu. [26] Výsledkem kompilace je balíček aplikace, který je stejný jako při vytváření aplikace v nativním jazyce platformy. Pro Android je to soubor s koncovkou APK. Zkompilovanou aplikaci je možné spustit v některém z emulátorů nebo přímo v připojeném zařízení. Jednou z velkých výhod tohoto přístupu je, že je možné přistupovat přímo k SDK pro danou platformu a tu poté využívat s C# syntaxí. K SDK se dá jednoduše přistoupit přes namespace. Pro Android je to namespace Android a pro ios se jedná o namespace MonoTouch. [27 str. 4] 3.3.2 Vývojářské prostředí Vývoj aplikace je možný buďto v Xamarin Studiu, což je vlastní vývojové prostředí Xamarinu, nebo je možné využít integraci do Microsoft Visual Studia. Xamarin Studio funguje na Macu i PC. Projekty vytvořené v Xamarin Studiu jsou kompatibilní s projekty vytvořenými ve Visual Studiu. [28] Pokud chceme vyvíjet aplikaci pro ios, je nutné mít k dispozici Mac zařízení. Poté máme dvě možnosti. První je vyvíjet aplikaci přímo na Macu v Xamarin Studiu. Druhou možností je nainstalovat na Mac zařízení program Xamarin ios tools, který po správné konfiguraci umožní vývoj a build ios aplikací i na PC s Visual Studiem. Na PC je nutné mít nainstalovaný program Xamarin Bonjour Service. Poté již jen stačí, aby ve stejné síti, ve které je připojeno PC, bylo připojeno Mac zařízení s tímto programem. 3.3.3 Možnosti sdílení kódu Xamarin nabízí dvě možnosti sdílení kódu napříč platformami. První je vytvořit shared project (česky sdílený projekt ) a druhou je vytvořit Portable Class Library (akronym PCL, česky přenosné knihovny tříd ). [29] Při obou těchto metodách je dle firmy možné dosáhnout až 90procentní znovupoužitelnosti kódu. [30] 34
3.3.3.1 Shared Project Jedná se nejjednodušší přístup ke sdílení kódu. V rámci solution se vytvoří tři projekty (pro Android, pro ios a pro Windows Phone) a zároveň se vytvoří ještě jeden projekt, nazvaný Shared (česky sdílený ). V adresáři shared se nachází sdílený kód, který je využitelný na všech platformách. Změny provedené v tomto projektu se projeví na všech platformách. Kód ve sdíleném adresáři je dále možné větvit pomocí #if příkazů pro kompilátor. Někdy totiž potřebujeme i ve sdíleném adresáři zjistit na jaké kód běží platformě, např. když chceme zjistit cestu k souboru databáze. Kód pak vypadá takto: #if ANDROID string documentspath = Environment.GetFolderPath (Environment.SpecialFolder.Personal); Celý sdílený projekt je hezky znázorněn na obrázku 10. Obrázek 10: Diagram sdíleného projektu [29] Tento přístup se nejvíce hodí použít tam, kde bude sdílený kód využíván pouze uvnitř aplikace a ne sdílený mezi více projekty. 35
3.3.3.2 Portable Class Library PCL je naopak dobré využít tam, kde chceme sdílený kód sdílet nejen v rámci aplikace, ale v rámci několika projektů. Nevýhodou je, že nemůžeme využívat příkazy pro kompilátor a také nemůžeme využívat celý.net Framework, ale pouze jeho část. Diagram PCL je na obrázku 11. Obrázek 11: Diagram PCL [29] 3.3.4 Xamarin.Forms Framework Xamarin nabízí ještě jednu velice zajímavou možnost vyvíjení aplikací, která ve výsledku může umožnit sdílet ještě více kódu. Xamarin.Forms je framework, který umožní vytváření nativního uživatelského rozhraní pro danou platformu v rámci sdíleného projektu. Jedná se o další abstrakci uživatelského rozhraní, které je poté vytvořeno. Obsahuje jednotnou API (Application Programming Interface) pro vytváření uživatelského rozhraní. V něm nalezneme prvky controls a layouts. Tyto prvky jsou poté při běhu programu převedeny na příslušné nativní prvky platformy. Tento přístup dovede ušetřit opravdu velké množství kódu, zvláště u jednodušších aplikací. Jelikož aplikace, kterou budu vytvářet já, sestává hlavně z naprosto základních ovládacích prvků, rozhodl jsem se pro svou práci využít tento Framework. To mi umožní 36
vyzkoušet kolik kódu lze reálně sdílet a aplikace také bude obsahovat nativní ovládací prvky na všech platformách. 3.3.5 Produkty 3.3.5.1 Xamarin Platform Xamarin je komerční produkt a je dostupný v několika variantách. Základní verze je zdarma, ale aplikace má omezenou velikost a nesmí využívat knihovny třetích stran. Další varianty jsou od 25$ měsíčně za Indie edici do 158$ měsíčně za edici Enterprise. Dále je možné využít trial Enterprise verzi na jeden měsíc zdarma a vyzkoušet tak plné možnosti frameworku. Každý build aplikace je v této verzi funkční pouze 24 hodin. Nově je také možné zažádat o studentskou licenci, která umožní využívat Business edici na jeden rok zcela zdarma. 3.3.5.2 Xamarin Test Cloud Trh se smartphony a tablety je dnes tak obrovský, že je pro jednotlivce nemožné vyzkoušet aplikace na všech typech zařízení. Hlavně operační systém Android se dnes používá v nepřeberném množství zařízení. Z tohoto důvodu vznikl Xamarin Test Cloud, který umožňuje aplikace testovat na stovkách zařízení v Cloudu. Je možné vytvořit vlastní automatizované testy, které se poté spustí na vybraných zařízeních a uživatel obdrží detailní informace o průběhu testů, včetně analýzy výkonu aplikace. 3.3.5.3 Xamarin Insights Tento produkt umožňuje monitorování selhání a výjimek aplikace. Můžeme v reálném čase sledovat, jak uživatel aplikaci využívá a se kterými problémy se setkal. To je velice užitečné při odstraňování případných chyb. Insights používá vlastní algoritmus pro seřazení incidentů podle závažnosti, četnosti a počtu ovlivněných uživatelů. Vše můžeme sledovat v přehledných grafech a tabulkách. 3.3.5.4 Xamarin University Xamarin nabízí velmi dobrou základní podporu, tutoriály a dokumentaci. Firma však zároveň nabízí službu University, která zprostředkovává výukové kurzy vedené vývojáři z firmy. Služba je poskytována za poplatek 1995$ za rok. 3.4 Shrnutí Výsledky mého srovnání frameworků jsou znázorněny v tabulce 3. 37
Výkon aplikací vytvořených pomocí jednotlivých frameworků je rozdílný hlavně díky přístupu k vývoji. Zde jasně dominuje framework Xamarin jehož výkon je srovnatelný s čistě nativními aplikacemi. Naopak u aplikací zobrazovaných pomocí WebView může být výkon aplikace až 6x pomalejší v porovnání s nativní. [31] Co se týče distribuce aplikace, pouze framework MobileFirst obsahuje vlastní webový obchod s aplikacemi, u ostatních musíme využít některého z veřejných obchodů. To znamená, že aplikace musí splňovat podmínky zadané vlastníkem daného obchodu. Zde může nastat problém u aplikací využívajících WebView, jelikož podmínky pro umožnění nahrání aplikace do obchodu u firmy Apple jsou velmi striktní. Pokud naše aplikace pouze zobrazuje v rámci WebView webovou aplikaci umístěnou na serveru (bez přidané funkčnosti), Apple s největší pravděpodobností naši žádost zamítne. Pokud tedy chceme zvýšit naše šance, měla by aplikace běžet lokálně a v ideálním případě zároveň využívat některé nativní možnosti ios. Tabulka 3: Srovnání frameworků IBM MobileFirst Apache Cordova Xamarin Programovací jazyk HTML, CSS, Javascript HTML, CSS, Javascript C# Typ výsledné aplikace Webová, nativní s Webová, nativní s Nativní WebView WebView Grafický vzhled prvků Webový Webový Nativní Možnosti ladění MobileFirst Console, prohlížeč (Safari, prohlížeč (Safari, Chrome), externí Přímo ve Visual Studiu nebo Xamarin Studiu Chrome), externí nástroje (Weinre) nástroje (Ripple, Weinre) Možnosti ladění - Fyzické zařízení i Fyzické zařízení i Fyzické zařízení i zařízení simulátor simulátor Přístup k nativním API Přes Apache Cordova Pomocí pluginů (JS interface zapouzdřující nativní kód platformy) Ošetření různých velikostí displejů Podporované platformy Podpora Android Widget Podpore WP živých dlaždic Dostupné pro platformy Přes responzivní design (možno použít frameworky, např. Bootstrap) ios, Android, Blackberry 10, WP 8, Windows Přes responzivní design (možno použít frameworky, např. Bootstrap) ios, Amazon Fire OS, Android, BlackBerry 10, WP 8, Windows, Firefox OS Ne Ne Ano Ne Ano pomocí pluginu Ano 38 simulátor Plný přístup (jako při nativním vývoji) Stejně jako u nativních aplikací, u Xamarin.Forms pomocí layouts ios, Android, WP 8, Windows ios, Windows ios, Windows, Linux ios, Windows
Současná cena (7. 1. 2016) Dle edice (Developer zdarma, Consumer/Application na míru (cca 36000 $ za rok za vývojáře)) Zdarma Dle licence (Indie 25$ za měsíc, Business 999$ za rok, Enterprise 1899$ za rok) Studentská licence Ne - Ano Business edice Současná verze (7. 1. 2016) Vhodné pro IDE MobileFirst Studio Plugin do IDE Eclipse Ne, pouze příkazová řádka zdarma na 1 rok Xamarin Studio nebo plugin do IDE Visual Studio 7.1 5.4.0 Xamarin.Android 6.0, Xamarin.iOS 9.4, Xamarin.Forms 2.0.0.6490 Webové vývojáře (malé projekty nebo velké projekty a firmy dle edice) Webové vývojáře (menší a středně velké projekty) Zdroj: Vlastní zpracování C# vývojáře (všechny typy projektů) 4 Návrh aplikace V této kapitole se zaměřím na návrh mé vlastní aplikace s názvem Lone Wolf New Order. Bude se jednat o textovou hru, zpracování tzv. gamebooku dobrodružné hry v knižní formě, pro mobilní zařízení. 4.1 Obecný popis gamebooků a motivace Gamebooky byly velmi populární v době, kdy ještě nebyly běžně v domácnosti počítače a žádná chytrá přenosná zařízení ještě neexistovala. Základní myšlenka spočívala v tom, že v knize bylo několik desítek až stovek číselně označených sekcí, mezi kterými se čtenář mohl pohybovat na základě daných instrukcí. Začal tedy na sekci jedna a účelem bylo se dostat až do finální sekce. Na konci každé sekce měl hráč na výběr, na kterou další sekci se chce přesunout. Zároveň hra měla určitá pravidla, většinou ve formě kolik má hráč životů, jak dobře je schopen bojovat, kolik může unést předmětů atp. Ve hře pak hráč často musel bojovat, řešit hádanky a používat předměty tak, aby se bezpečně dostal až na konec hry. Ke hře bylo většinou nutné mít tužku a gumu, aby si hráč mohl zapisovat a aktualizovat do knihy své údaje, a velice často bylo také nutné mít šesti - či desetihrannou kostku, pomocí které si hráč určil počáteční hodnoty životů, nebo se používala při vyhodnocování soubojů. Celý tento princip vycházel z populární stolní hry Dungeons & Dragons. Jelikož jsem v dospívání tyto gamebooky často hrával, zaujala mě myšlenka přenést tuto formu hraní do dnešních moderních chytrých zařízení. Hráč by již nemusel 39
zaznamenávat údaje na papír, vše by bylo uloženo v databázi aplikace a o hody kostkou by se staral náhodný generátor čísel. Několik aplikací převádějících gamebook do elektronické podoby již vzniklo, ale gamebook, který chci zpracovat já, zatím na žádné platformě k dispozici není. 4.2 Gamebook sága Lone Wolf Sága gamebooků Lone Wolf obsahuje 28 knih, jejichž autorem je Joe Dever. Sága je rozdělena do 4 částí, z nichž první tři (série Kai, Magnakai a Grand Master) jsou velice úzce propojeny, protože všechny obsahují stejného hlavního hrdinu se jménem Lone Wolf. Mezi těmito sériemi je možné přenášet předměty do dalších knih v rámci série a hráč rovněž za každou úspěšně dokončenou knihu získává výhody v knize následující. Knih v těchto třech sériích je dohromady 20. Čtvrtá část série s názvem New Order je samostatná, není tedy možné do ní přenést žádné předměty z předchozích knih. Tato série obsahuje 8 knih, jejichž hlavním hrdinou již není postava Lone Wolf, ale jeden z jeho učňů. Ve své práci se zaměřím výhradně na tuto poslední část ságy. Sága je z 80. let 20. století a během svojí existence si vybudovala početnou základnu fanoušků, byla přeložena do mnoha jazyků a prodalo se jí více než 9 milionů kopií. [32] Sága si svoji popularitu udržela až dodnes, hlavně díky tomu, že Joe Dever v roce 1999 uvolnil práva ke všem knihám, což umožnilo stále aktivní základně fanoušků gamebooky předělat do HTML formátu a nahrát je na internet. [33] Tento fanouškovský projekt se jmenuje Project AON a jeho HTML verze knih využívám i já ve své práci. Další obnovení popularity ságy přišlo v roce 2007, kdy společnost Mongoose Publishing dostala od autora práva opět vydávat tištěnou verzi ságy (práva poskytovat elektronickou verzi zdarma ale zrušena nebyla). Nakonec společnost vydala pouze knihy 1-17. Poté se autor rozhodl práva společnosti odebrat a předal je společnosti Mantikore-Verlag, která má v plánu vydat zbývající knihy v průběhu roku 2015 a 2016. [34] V českém překladu bohužel vyšly pouze knihy 1-15, žádný překlad ostatních knih zatím neexistuje, což je jeden z důvodů, proč bude aplikace dostupná pouze v anglickém jazyce. [35] Gamebook, který chci z této ságy zpracovat, se jmenuje Voyage of the Moonstone, a je první knihou v sérii New Order. Aplikaci je možné v budoucnu rozšířit o další díly série. 4.3 Pravidla gamebooku Každý gamebook v sérii New Order obsahuje 350 číslovaných sekcí. Hráč začíná na sekci 1. Na konci každé sekce je odkaz na jednu nebo několik navazujících sekcí, na které 40
může uživatel v rámci pravidel přejít. Výjimku tvoří poslední sekce (350), po které hra končí, a sekce, ve kterých hráčova postava zemře. V rámci sekce je často možné vykonat nějakou akci (sebrat předmět, zúčastnit se souboje). Některé jsou povinné, jiné volitelné. Zároveň série obsahuje systém pravidel, kterými by se měl hráč řídit. V rámci tištěné verze si uživatel všechny údaje zaznamenával sám a bylo tedy jen na něm, zda se pravidly bude řídit doslova, nebo zda si je nějakým způsobem upraví. V rámci mé aplikace se bude o dodržování pravidel starat aplikace sama a žádná úprava nebude možná. Základ celého gamebooku tvoří hráčova postava. Tu si vytvoří na začátku hry dle daných pravidel. Některé vlastnosti postavy jsou určeny hodem kostkou, většinu si jich ale hráč může zvolit strategicky sám z předem definovaného seznamu. Tradičně si hráč všechny tyto údaje zaznamenával tužkou přímo do knihy, do speciální sekce nazvané Action Chart (v původním českém překladu Průvodní listina ), jejíž náhled ze série Magnakai můžeme vidět na obrázku 12. Všechny tyto informace bude nyní spravovat aplikace sama. 41
Obrázek 12: Ukázka průvodní listiny Zdroj: http://www.magnamund.org/risingsun/may2000/actchart.gif 4.3.1 Vlastnosti postavy Hlavní vlastnosti postavy jsou dvě: a. COMBAT SKILL (akronym CS, v původním českém překladu UMĚNÍ BOJE ) Tato vlastnost reprezentuje schopnost postavy bojovat, využívá se při soubojích, kdy se hodnota CS postavy porovná s hodnotou CS nepřítele. Hodnotu CS postavy určíme tak, že získáme náhodné číslo 0-9 a k němu přičteme 25. 42
b. ENDURANCE (akronym END, v původním českém překladu KONDICE ) Vlastnost END udává schopnost postavy vydržet zranění, pokud v průběhu hry klesne na nulu, hra končí. Její hodnotu určíme získáním náhodného čísla 0-9, ke kterému přičteme 30. 4.3.2 Dovednosti postavy Dovednosti (původní český překlad z anglického Disciplines ) jsou jednou z nejdůležitějších složek hry. Díky nim získává hráč různé benefity, které ovlivňující jednotlivé složky hry. Většina z nich se projevuje tak, že umožní hráči přechod na sekci, ke které by jinak neměl přístup. Některé ovšem přímo ovlivňují vlastnosti postavy a souboje. Detailní popis dovedností je k dispozici v rámci hry při vytváření postavy. Dovedností je celkem k dispozici 16, ovšem hráč na začátku musí zvolit pouze 4, které bude jeho postava ovládat. V rámci série je možné za každou dohranou knihu přidat jednu další dovednost. Tuto situaci moje aplikace zatím neřeší, jelikož je možné hrát pouze první knihu. 4.3.3 Předměty V rámci hry má hráč přístup k mnoha předmětům, které mu můžou usnadnit další postup. Ty jsou rozděleny do 4 kategorií: a. Zbraně (z anglického Weapons ) Tento typ předmětu je používán v soubojích. Maximální počet zbraní postavy je 2. Zbraň může měnit vlastnosti postavy. Během souboje je nutné zvolit jednu zbraň, kterou chce hráč použít. Zbraní je k dispozici 10 typů (např. meč, dýka, sekyra). Speciálním typem zbraně je luk, který se nedá použít v souboji, ale pouze v rámci sekcí, ve kterých je jeho použití umožněno. K jeho použití je rovněž potřeba toulec s alespoň jedním šípem (viz bod c. Speciální předměty). b. Předměty v batohu (z anglického Backpack Items ) Maximální počet předmětů v batohu je 10. Díky předmětům je někdy usnadněn postup hrou (např. s předmětem provaz můžeme překonat překážku ve hře a posunout se na další sekci). Speciálním typem předmětu je předmět jídlo, který musí hráč při vyzvání v sekci zkonzumovat, jinak ztratí 3 body END. Další speciální typ, předmět lektvar, je možné použít kdykoliv mimo souboj. Tento typ mění vlastnosti postavy, buďto pouze v rámci sekce, nebo pro celý zbytek dobrodružství. c. Speciální předměty (z anglického Special Items ) 43
Maximální počet speciálních předmětů je 12. Při obdržení speciálního předmětu je hráč v rámci sekce obeznámen s jeho použitím. Speciálním typem tohoto předmětu je předmět toulec, který umožňuje hráči nosit šípy (do jednoho toulce se jich vejde 6). Druhým speciálním typem předmětu je Kai zbraň. Tento předmět funguje stejným způsobem jako předmět typu Zbraň, ale je možné ho nosit i v případě, že již máme 2 předměty typu Zbraň. Tento speciální předmět je možné získat pouze na začátku dobrodružství, k dispozici je 10 variant předmětu. Při použití v boji zvyšuje tento předmět CS o 5. d. Zlaté koruny (z anglického Gold Crowns ) Maximální počet zlatých korun je 50. Používají se jako univerzální platidlo během dobrodružství. 4.3.4 Souboje Poslední důležitou složkou jsou souboje. Boj pak probíhá v několika kolech, ve kterých se určí bojový koeficient (z anglického Combat Ratio ). Ten získáme jako rozdíl CS postavy a CS nepřítele. Dále potřebujeme tabulku výsledků boje (z anglického Combat Results Table ), jejíž náhled můžeme vidět na obrázku 13. 44
Obrázek 13: Tabulka výsledků boje Zdroj: http://www.projectaon.org/en/xhtml/lw/21votm/crtable.htm Každé políčko znázorňuje ztrátu END postavy a nepřítele. Správné políčko vybereme dle náhodného čísla 0-9 a bojového koeficientu. Ten, jehož kondice klesne v průběhu boje na 0, souboj prohrává. V průběhu boje může nastat změna CS postavy nebo nepřítele, v takovém případě se znovu vypočítá bojový koeficient. Z boje je někdy možné utéct, ovšem pouze v případě, že to sekce výslovně dovoluje. Pokud ano, při útěku se provede ještě jedno poslední kolo, během kterého ztratí END pouze postava. Průběh celého souboje je znázorněn na obrázku 14. 45
Obrázek 14: Diagram souboje BPEL SampleBPELProcess EA 12.0 Unregistered Odečtení bodů Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Získání aktuální Trial Version EA 12.0 Unre kondice hodnoty umění EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version Začátek boje EA 12.0 Unregistered Trial Version EA 12.0 Unre souboje EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unre Získání náhodného Kolo souboje Získání hodnoty EA 12.0 Unregistered Trial Version čísla EA 12.0 Unregistered Trial Version EA 12.0 Unregistered bojového Trial Version EA 12.0 Unre koeficientu Oba EA 12.0 Unregistered účastnící Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unre ne naživu? ano ne EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unre EA 12.0 Unregistered Trial Version EA 12.0 Unregistered ne Trial Version EA 12.0 anounregistered Trial Version EA 12.0 Unre Smrt Možnost Změna Úprava EA 12.0 nepřítele? Unregistered Trial Version a úmysl EA 12.0 Unregistered Trial Version hodnot EA 12.0 Unregistered hodnoty Trial Version EA 12.0 Unre ano ne utéct? umění umění boje ano EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version boje? EA 12.0 Unregistered Trial Version EA 12.0 Unre EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unre Výhra Prohra Útěk EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unregistered Trial Version EA 12.0 Unre Zdroj: Vlastní zpracování 4.4 Popis aplikace Aplikace musí být funkční na třech platformách, konkrétně se jedná o ios, Android a WP. Aplikace bude nasazena přímo na koncovém zařízení a nebude komunikovat s žádnými servery třetích stran. Veškerá potřebná data budou přímo součástí aplikace. Data o průchodu hrou budou v průběhu ukládána do databáze, odkud budou při opětovném spuštění aplikace načtena. 4.5 Návrh GUI GUI (graphical user interface, český překlad grafické uživatelské rozhraní ) aplikace jsem se snažil navrhnout tak, aby bylo co nejintuitivnější na používání. Tím pádem by uživatel zvyklý na ovládání mobilních aplikací mohl ihned začít hrát a nemusel by trávit čas zkoumáním ovládání aplikace. 46
4.5.1 Úvodní obrazovka (Title Page) Obrázek 15: Úvodní obrazovka Zdroj: Vlastní zpracování Po zapnutí aplikace se uživateli zobrazí úvodní obrazovka (viz obrázek 15). V horní části je umístěn nadpis s názvem aplikace. Uživateli je zobrazen seznam dostupných profilů (postav) s jejich jménem a s informací o tom, na které sekci se postava zrovna nachází. Pokud žádný profil dosud nebyl vytvořen, nebo chce uživatel vytvořit nový, může použít tlačítko Create New Profile. To mu zobrazí sekvenci obrazovek, ve kterých si vytvoří novou postavu a zároveň se dozví základní informace o světě hry, příběhu a pravidlech. Tato sekvence obrazovek je poměrně rozsáhlá, proto ji v psané části své práce zmiňuji pouze slovně bez ilustrací. Uživatel si postupně zvolí jméno postavy, její vlastnosti, dovednosti a počáteční předměty. 47
4.5.2 Obrazovka Sekce (Section Page) Obrázek 16: Sekce s možnostmi a povinnou akcí Zdroj: Vlastní zpracování Toto bude hlavní obrazovka při hraní hry. Zobrazí se po načtení nebo vytvoření profilu. Akcí na této obrazovce může být více druhů, rozložení ale bude vždy stejné. V horní části obrazovky budou umístěna tato 3 tlačítka: Stats (Vlastnosti) zobrazí novou navigační stránku s přehledem vlastností a dovedností postavy Items (Předměty) zobrazí novou navigační stránku pro přehled a editaci předmětů ve vlastnictví postavy Menu v základní verzi umožňuje pouze návrat do hlavního menu 48
Pod těmito tlačítky bude umístěn text a číslo sekce, na které se hráč právě nachází. Některé sekce mohou obsahovat ilustraci, v takovém případě se ilustrace zobrazí před textem samotné sekce. Dle typu sekce budou pod textem zobrazena tlačítka, která umožní hráči provést určitou akci. Zde může nastat několik případů: a. Uživatel může pouze zvolit přesun na další sekci. Buďto může zvolit pouze jednu možnost, nebo má na výběr z několika (viz obrázek 16 obrazovka vlevo). Přesun na další sekci může být podmíněn např. vlastnictvím určitého předmětu, současným stavem vlastností postavy nebo disciplínami, které postava ovládá. V takovém případě hra zkontroluje, zda postava splňuje podmínky. Pokud ne, nebude na tlačítko možné kliknout. b. Uživatel musí před přesunem na další sekci vykonat určitou akci. Akce může být povinná (např. ztráta END, odstranění předmětu) nebo volitelná (např. nákup předmětů, použití luku). Pokud je akce povinná, hra neumožní před jejím vykonáním postup na další sekci (viz obrázek 16 obrazovka vpravo). Pokud akce není povinná, může ji uživatel přeskočit přechodem na další sekci. c. Sekce končí smrtí postavy. Tento typ sekce nemá žádný další odkaz a po jejím přechodu na ní je hráči zobrazeno vyskakovací okno oznamující konec hry. Následuje návrat na hlavní menu a smazání postavy. d. Poslední sekce knihy. Zde je situace podobná jako u bodu c., uživateli bude zobrazeno vyskakovací okno oznamující úspěšné dokončení hry. Postava zůstane zachována do dalších dílů série. Celá tato část bude posouvatelná, jelikož text sekce s tlačítky a případným obrázkem může být (zvláště na zařízeních s menší úhlopříčkou) delší, než je dostupná plocha na zařízení. Horní 3 tlačítka zůstávají při posunutí na svém místě. 49
4.5.3 Obrazovka Vlastnosti (Stats Page) Obrázek 17: Obrazovka s vlastnostmi postavy Zdroj: Vlastní zpracování Zde budou zobrazeny všechny údaje o vlastnostech postavy (viz obrázek 17). V horní části jsou to aktuální hodnoty CS a END, následované dvěma seznamy. V prvním z nich bude seznam hráčem zvolených disciplín. Druhý seznam se bude zobrazovat pouze v případě, pokud byla hráčem zvolena dovednost Grand Weaponmastery, a bude obsahovat zbraň, kterou postava dokonale ovládá v rámci této disciplíny. V rámci první knihy má sice hráč možnost zvolit pouze jednu zbraň, v případném budoucím rozšíření o další knihy je ale možné zvolit zbraně další, proto bude zbraň zobrazována v seznamu. Na platformách, které tuto komponentu podporují, bude v záhlaví zobrazena lišta s nadpisem stránky a tlačítkem pro návrat zpět. 50
4.5.4 Obrazovka Předměty (Items Page) Obrázek 18: Obrazovka se seznamy předmětů Zdroj: Vlastní zpracování Na obrazovce s předměty (viz obrázek 18) bude v horní části přehled o počtu zlatých korun a šípů, které má postava k dispozici. Tyto hodnoty nejsou editovatelné, mají pouze informační hodnotu. Hráč zde také může zobrazit mapu (ta byla standardně součástí knihy), která se otevře přes celou obrazovku na nové navigační stránce. Následují 3 seznamy pro každou z kategorií předmětů. U každé položky seznamu bude jedno či více tlačítek umožňujících provést s předmětem akci. Každý předmět je možné zahodit, čímž dojde k jeho smazání. U zbraní bude možné zvolit jednu právě používanou zbraň. U lektvarů bude možné je použít, čímž dojde ke smazání předmětu a aplikaci jeho efektu na vlastnosti postavy. Záhlaví bude stejné, jako u obrazovky Vlastnosti. 51
4.5.5 Obrazovka Souboj (Fight Page) Obrázek 19: Obrazovka se soubojem Zdroj: Vlastní zpracování Tato obrazovka (viz obrázek 19) umožní hráči provést souboj s nepřítelem v rámci pravidel daných hrou. Z této stránky není možné se vrátit zpět, dokud hráč souboj nedokončí. V horní polovině stránky jsou hráči k dispozici aktuální údaje o vlastnostech postavy a nepřítele. Pod nimi je zobrazen přepínač, který umožní hráči použít dovednost Kai-surge v případě, že to souboj dovoluje (v opačném případě bude tlačítko vypnuté). Na základě tohoto tlačítka se bude dynamicky měnit hodnota CS postavy a tím pádem i hodnota CR zobrazená pod přepínačem. 52
K vykonání jednoho kola souboje slouží tlačítko Execute Round. Po jeho stisknutí se zobrazí v dolní části obrazovky výsledek daného kola. Hráč pokračuje ve vykonávání kol souboje tak dlouho, dokud hodnota END postavy nebo nepřítele neklesne na hodnotu 0. Poté souboj končí a hráči je buďto umožněn návrat na sekci nebo je hra ukončena. Pokud to souboj dovoluje, je možné po vykonání daného počtu kol ze souboje utéci. Hráč tak může učinit stiskem tlačítka Evade Fight. 4.5.6 Obrazovka Zvolení předmětů (Choose Items Page) Obrázek 20: - Zvolení předmětů Zdroj: Vlastní zpracování Tato obrazovka se bude používat v několika variantách, vždy ale bude obsahovat seznam předmětů, akci, kterou je s nimi možno provést, a tlačítko pro návrat zpět. Obrazovka může sloužit pro: 53
Nákup/Prodej předmětů je možný návrat zpět, tlačítko obsahuje údaj o ceně předmětu a v případě nákupu je aktivní, pokud má uživatel dostatek peněz Odebrání předmětů návrat zpět není možný, dokud hráč neodebere předem definovaný počet předmětů, stisknutím tlačítka hráč předmět odebere Sebrání předmětů návrat zpět je možný kdykoliv, stisknutím tlačítka hráč předmět získá 4.5.7 Navigace U struktury navigace v GUI je třeba mít na paměti, že hráči není vždy umožněn návrat zpět na předchozí obrazovku. Dle pravidel hry není možné se vrátit o krok zpět na předchozí sekci, opustit souboj v jeho průběhu nebo v některých případech opustit obrazovku Zvolení předmětů. Jak jsem již zmiňoval u technických specifikací jednotlivých platforem, mají některá zařízení hardwarová tlačítka Zpět. Na zmíněných obrazovkách bude tedy nutné funkčnost těchto tlačítek zakázat. 4.6 Načtení informací o knize Mnou zpracovávaný díl knihy je k dispozici online v html formátu na již zmíněných stránkách Project AON. [33] Knihu je možné stáhnout jako ZIP soubor, který obsahuje html soubor pro každou ze sekcí knihy a samostatné soubory s ilustracemi. Názvy souborů sekcí jsou ve formátu sect{číslo sekce}.htm. Hlavním úkolem mé aplikace bude tento soubor s informacemi o sekci načíst a na základě něho vytvořit layout a potřebná tlačítka pro akce nebo přechod na další sekce. 4.6.1 Struktura HTML souboru HTML soubor se sekcí knihy je poměrně dobře strukturovaný a obsahuje tagy, kterých budu moci využít při parsování (syntaktické analýze) souboru. Na obrázku 21 je ukázka sekce zobrazené ve webovém prohlížeči. Strukturu HTML souboru můžeme vidět na obrázku 22. 54
Obrázek 21: Sekce zobrazená v prohlížeči Zdroj: Vlastní zpracování 55
Obrázek 22: Ukázka HTML kódu sekce Zdroj: Vlastní zpracování Pro účely mé aplikace nás budou zajímat pouze elementy uvnitř tagu <div class= maintext >. Uvnitř tagu <h3> nalezneme číslo sekce, na které se právě nacházíme. V tagu <p> se nachází text samotné sekce. V tagu <p class= choice > je text zobrazovaný u přechodu na další sekci. Tag zároveň obsahuje odkaz na následující sekci. Tento nejjednodušší typ sekce nebude problém na základě HTML tagů obecně parsovat. 4.6.2 Syntaktická analýza Zdaleka ne všechny sekce mají ovšem takto jednoduchou strukturu. Proto jsem v rámci návrhu provedl kompletní analýzu všech sekcí, abych zjistil, které bude možné parsovat 56
automaticky, a které bude nutné vytvořit manuálně. Ke každé sekci jsem si nejdříve poznamenal, jaké akce a podmínky obsahuje. Poté jsem vyhodnotil, jestli je možné pro tyto akce a podmínky vytvořit obecný parser, který by na základě jejich znění sám vytvořil potřebné prvky na obrazovce. Dle mé prvotní analýzy jsem dospěl k závěru, že obecné parsování bude funkční pro přibližně 280 z 350 sekcí. Pro ostatní bude nutné layout obrazovky vytvořit manuálně. Sekce, které je dle analýzy možné parsovat obecně, obsahují tyto akce a podmínky: Postava se musí najíst vždy stejná syntaxe v podobě textu eat a Meal Postava získává/ztrácí END syntaxe lose/restore {číslo} ENDURANCE Generování náhodného čísla syntaxe Random Number Table Postava zemřela syntaxe your life and your quest end here Souboj HTML tag obsahuje třídu combat, některé souboje obsahují speciální parametry, které je nutné zpracovat manuálně Zda postava ovládá disciplínu syntaxe If you possess {název disciplíny} Postava může zaplatit syntaxe wish to pay {číslo}, netýká se sekcí, kde postava zaplatit musí, ty mají zpravidla jinou (neopakující se) syntaxi U ostatních sekcí se jako hlavní problém ukázalo to, že autor často nepoužívá pro akce a podmínky jednotnou syntaxi. Zde jsou některé příklady: Postava získává předmět mnoho typů syntaxe, název předmětu může být jedno nebo více slov, bez jednoznačného ohraničení Hádanka postava musí zodpovědět hádanku, různá syntaxe Postava musí zaplatit různá syntaxe, hodnota peněz k zaplacení uváděna jako číslovka i jako textový zápis Zda postava vlastní předmět podobné jako u získání předmětu, není možné získat název předmětu Získání peněz stejné situace jako u povinného placení Kombinace podmínek a unikátní situace kombinace podmínek nemají jednotnou syntaxi, unikátní situace není možné obecně ošetřit 57
4.7 Datová struktura Obrázek 23: Datový model class Logic Model EA 12.1 Unregistered «enumeration» Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V GrandWeaponmastery EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version Axe EA 12.1 Unregistered Trial V 0..* EA 12.1 Unregistered KaiScreen Trial Version EA 12.1 Unregistered Trial Version ShortSword EA 12.1 Unregistered Trial V EA 12.1 Unregistered MagiMagic Broadsword Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V Herbmastery +masteredweaponsblobbed EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V EA 12.1 Unregistered Trial Version 0..* EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V EA 12.1 Unregistered Trial Version EA 12.1 +FK_Item_Character Unregistered *pfk Trial id: INTEGER Version EA 12.1 Unregistered Trial V Character EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial itemstatus: Version INTEGER EA 12.1 Unregistered Trial V «column» *PK id: INTEGER changeend: INTEGER EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V * name: TEXT * combatskillbase: INTEGER * endurancebase: INTEGER +PK_Character EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V * combatskillcurrent: INTEGER * endurancecurrent: INTEGER * disciplinesblobbed: TEXT EA 12.1 * Unregistered masteredweaponsblobbed: Trial TEXT Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V * coins: INTEGER * arrows: INTEGER + PK_Item(INTEGER) EA 12.1 Unregistered equippedweaponid: Trial INTEGER Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V * currentsection: INTEGER * curedpoints: INTEGER EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V «PK» + PK_Character(INTEGER) EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V EA 12.1 Unregistered Trial (id = id) Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V Fight EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial «enumerati... Version EA 12.1 Unregistered Trial V «column» *pfk id: INTEGER Disciplines AnimalMastery Deliverance Assimilance GrandHuntmastery GrandPathsmanship KaiSurge GrandNexus Telegnosis KaiAlchemy Astrology Elementalism Bardsmanship +disciplinesblobbed EA 12.1 Unregistered * enemyname: Trial TEXTVersion EA 12.1 Unregistered Trial Version EA 12.1 SpecialUnregistered Trial V * charactercs: INTEGER * characterend: INTEGER EA 12.1 Unregistered * enemycs: Trial INTEGERVersion EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V * enemyend: INTEGER * rounds: INTEGER * immunity: INTEGER EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V «FK» + FK_Fight_Character(INTEGER) EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V «index» + IXFK_Fight_Character(INTEGER) «PK» EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V + PK_Fight(INTEGER) 1 +PK_Character 1 «FK» +FK_Fight_Character 0..* 1 1 EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial Version EA 12.1 Unregistered Trial V EA 12.1 Unregistered Trial Version Zdroj: EA 12.1 Vlastní Unregistered zpracování Trial Version EA 12.1 Unregistered Trial V 58 0..* (id = id) «FK» «column» Item * name: TEXT * storagetype: INTEGER * weightless: INTEGER changecs: INTEGER price: INTEGER weapontype: INTEGER «FK» + FK_Item_Character(INTEGER) «index» + IXFK_Item_Character(INTEGER) «PK» ItemStatus Use Equip «enumerati... WeaponType Dagger Mace Warhammer Quarterstaff Spear Bow Sword +itemstatus 0..1 +weapontype 1 0..1 1 1 1 +storagetype «enumerati... StorageType Weapon Backpack
Datová struktura byla navržena podle průvodní listiny postavy. Můžeme ji vidět na obrázku X. Obsahuje všechny údaje, které jsou potřeba k hraní hry. Do databáze se budou ukládat tři tabulky. Hlavní tabulka má název Character a obsahuje údaje o hráčově postavě (vlastnosti, dovednosti, předměty a údaje o soubojích). Každá postava může vlastnit 0 až n předmětů. Ty jsou reprezentovány druhou s názvem Item. Třetí tabulka se jmenuje Fight a shromažďuje údaje o soubojích, kterých se postava účastnila, a jejich výsledky. Vazba mezi postavou a soubojem je rovněž 0 až n. Tyto tabulky budou sloužit pro zachycení stavu hry při přechodu na další sekci. Změny v aplikaci tedy nebudou do databáze zapisovány ihned, ale až po úspěšném dokončení sekce. Je to z toho důvodu, že akce na zobrazené sekci vykonává uživatel stisknutím tlačítka, které po vykonání akce není možné znovu použít. Pokud ale v tuto chvíli uživatel aplikaci vypne a znovu zapne, tlačítka budou opět aktivní, čímž by došlo k narušení funkčnosti aplikace. V rámci datové struktury budou ještě využívány 4 datové typy Enumeration (zkráceně Enum, česky výčtový typ ), které nebudou ukládány do databáze, ale budou definovány uvnitř aplikace. Tento přístup jsem zvolil z důvodu, že pravidla hry jsou naprosto stejná pro celou sérii knih, nikdy tedy nedojde k jejich změně, a proto není nutné pro ně vytvářet samostatné tabulky. Jedná se o Enum Disciplines (seznam všech disciplín), Enum WeaponType (typy zbraní), Enum ItemStatus (zda je možné použít předmět) a Enum StorageType (do jaké kategorie patří předmět). 5 Implementace aplikace Jak již jsem zmiňoval v průběhu práce, zvolil jsem vývoj aplikace ve frameworku Xamarin, jelikož s jazykem C# mám největší zkušenosti a zároveň se mi s frameworkem dobře pracovalo. Jelikož se jedná o komerční produkt, využíval jsem během vývoje trial verzi frameworku. Po vypršení trial verze programu jsem si zažádal o studentskou licenci, čímž jsem získal plnohodnotnou Xamarin Business edici na jeden rok. Ta obsahuje nadstavbu Xamarin.Forms (XF), kterou chci pro vývoj využít. Zvolil jsem XF, protože moje aplikace bude dynamicky vytvářet UI u jednotlivých sekcí, což by bez XF bylo nutné dělat pro každou platformu zvlášť. S XF je možné i tento kód sdílet. Dalším důvodem bylo to, že má aplikace dle dokumentace odpovídá typu aplikace, která by měla být přes XF zpracována. [36] Nepotřebuji totiž prakticky žádnou funkčnost specifickou pro jednotlivou 59
platformu a UI na jednotlivých platformách by mělo být co nejvíce podobné. XF používám ve verzi 1.5.0.6447. Aplikaci budu testovat na všech třech platformách a budu porovnávat vzhled a funkčnost aplikace. V rámci textové práci popisuji pouze vybrané části aplikace a ukazuji, jak jsem využil možností XF, případně na které problémy jsem narazil a jak jsem je vyřešil. Snažil jsem se aplikaci vyvíjet tak, abych mohl co nejlépe otestovat tvrzení firmy Xamarin, že je při vývoji aplikace možné sdílet více než 90 procent kódu. [30] Proto jsem používal co nejvíce prvků dostupných přes XF, které jsem upravoval pro danou platformu pouze v případech, kdy prvek neplnil na platformě bez úpravy svojí funkčnost. 5.1 Struktura aplikace Po vytvoření sdílené XF aplikace framework vytvoří 4 projekty 3 nativní projekty pro každou ze tří platforem a 1 sdílený. Veškerý sdílený kód musí být umístěn ve sdíleném projektu, nativní projekty upravujeme pouze ve chvíli, kdy chceme upravit UI nebo funkčnost jen pro danou platformu. Po vytvoření obsahuje sdílený projekt pouze třídu App.cs, která je hlavní třídou celé aplikace. Můžeme v ní nastavit hlavní obrazovku aplikace. 5.1.1 Vrstvy Při vytváření vrstev aplikace jsem se řídil doporučeními uváděnými firmou Xamarin pro vývoj multiplatformních aplikací. [37] a. DL (Data Layer) - Obsahuje třídu s databází aplikace b. DAL (Data Access Layer) Obsahuje třídu pro přístup a manipulaci s daty (ta je realizována pomocí návrhového vzoru Singleton) c. BL (Business Layer) Obsahuje definice objektů a logiku aplikace d. UIL (User Interface Layer) Obsahuje jednotlivé obrazovky a vizuální prvky 5.2 Práce s databází Při výběru databáze bylo hlavním požadavekem, aby s databází bylo možno pracovat na všech třech platformách. Zvolil jsem databázi SQLite, což je relační databázový systém, který je k dispozici ve formě knihovny. Má malou velikost a celá databáze je obsažena v jednom souboru na disku. [38] Databáze funguje na všech třech platformách, na WP je ale potřeba přidat rozšíření, které bude popsáno v další části. Pro základní verzi databáze je možné pouze přidat knihovnu do projektu. Ve své práci jsem ovšem chtěl využít ORM 60
(object-relational mapping, česky objektově relační mapování ), proto jsem využil následujících dvou rozšíření: SQLite.Net-PCL vylepšená verze SQLite knihovny s využitím PCL SQLite-Net Extensions-PCL rozšiřuje SQLite knihovnu o ORM, podporuje vztahy s kardinalitou 1:1, 1:N a N:M 5.2.1 Načtení databáze Pro načtení souboru s databází musíme před zavoláním konstruktoru specifikovat platformu a cestu k souboru, k čemuž využijeme #if příkazů pro kompilátor. V mé aplikaci se o tuto funkčnost stará třída LoneWolfDatabase.cs. Platformu (pro příklad uvedena pouze platforma Android) získáme tímto kódem: #if ANDROID var platform = new SQLite.Net.Platform.XamarinAndroid.SQLitePlatformAndroid(); #else A cestu k souboru tímto: var sqlitefilename = "LWDB.db3"; #if ANDROID string documentspath = Environment.GetFolderPath (Environment.SpecialFolder.Personal); // Documents folder var path = Path.Combine(documentsPath, sqlitefilename); #else 5.2.2 ORM Naše ORM rozšíření se automaticky postará o konverzi dat mezi databází a C# objektem, nad kterým stačí pouze definovat atributy. Pro ukázku použiji třídu Character.cs a Item.cs, mezi kterými je vazba 1:N. Na straně třídy Character definujeme její primární klíč a seznam předmětů: public class Character { [PrimaryKey, AutoIncrement] public int Id { get; set; } [OneToMany] public List<Item> Items { get; set; } objektu: A na straně třídy Item definujeme primární klíč a cizí klíč, u kterého uvedeme typ public class Item { [PrimaryKey, AutoIncrement] public int Id { get; set; } [ForeignKey(typeof(Character))] public int CharId { get; set; } // Specify the foreign key 61
Díky tomuto rozšíření nemusíme např. při získání všech předmětů postavy psát databázový dotaz, ale můžeme získat postavu včetně jejích předmětů pomocí příkazu: db.getwithchildren<character>(id); 5.2.3 SQLite na WP Databáze SQLite je na platformách Android a ios funkční bez problémů, na platformě WP je nutné nejdříve stáhnout VSIX balíček pro danou platformu. Po jeho instalaci můžeme do WP projektu přidat referenci a poté bude chování SQLite na WP totožné s ostatními platformami. [39] 5.3 Navigace Základní navigace mezi obrazovkami v XF funguje na principu vrstvení. Po vytvoření hlavní stránky je každá další zobrazená stránka vložena do zásobníku (princip FIFO). Při návratu zpět se jen odebere první stránka ze zásobníku a zobrazí se stránka předchozí. V mé aplikaci je ale vyžadováno, aby se hráč po načtení profilu nemohl vrátit o krok zpátky. Rovněž v rámci jednotlivých sekcí není možný návrat zpět. Pro řešení tohoto problému jsem ve své aplikaci využil dvou možností. Nutno ještě poznamenat, že možnosti navigace, které popisuji, jsou k dispozici až od verze XF 1.3.0. [40] 5.3.1 Nová hlavní obrazovka Po vytvoření aplikace se jako hlavní obrazovka nastaví obrazovka pro zvolení/vytvoření profilu (třída ProfileSelectionPage.cs ). MainPage = new NavigationPage(new ProfileSelectionPage()); Po zvolení/vytvoření profilu se uživatel nemůže vrátit o krok zpět, toho je docíleno přepsáním hlavní obrazovky, čímž je vytvořen nový zásobník s obrazovkou pro sekci ( SectionPage.cs ) jako hlavní obrazovkou. Application.Current.MainPage = new NavigationPage(new SectionPage(selectedCharacter.CurrentSection)); 5.3.2 Zachování zásobníku Předchozí řešení vymaže zásobník stránek, což by bylo problematické např. u obrazovky se soubojem ( FightPage.cs ) nebo u obrazovky s povinným odebráním předmětů ( ItemRemovalPage.cs ). Zde se totiž hráč nemůže vrátit o krok zpátky, dokud nedokončí danou akci. Po jejím dokončení se ale vrací na předchozí obrazovku sekce. Zde se nám tedy princip zásobníku hodí. Pro zachování zásobníku tedy vykonávám následující kroky: 62
1. Obrazovku zavoláme metodou PushModalAsync tím je stránka zobrazena na platformách ios a Android bez navigačního tlačítka zpět Navigation.PushModalAsync(itemRemovalPage); 2. Nyní musíme ještě zrušit funkčnost HW tlačítka pro krok zpět na platformách Android a WP přetížením této metody obrazovky: protected override bool OnBackButtonPressed() { return true; } 3. Po dokončení úkonů na obrazovce odebereme současnou obrazovku ze zásobníku a vrátíme se na obrazovku předchozí: Navigation.PopModalAsync(); 5.4 Práce se soubory Všechny externí soubory, se kterými aplikace pracuje, jsou umístěny ve sdíleném projektu. Při buildu aplikace se XF postará o to, aby byl součástí každého nativního projektu jako tzv. Embedded Resource. V rámci sdíleného kódu k nim můžeme přistoupit pomocí #if příkazů pro kompilátor a zvolením správné platformy. V aplikaci využívám soubory ve složce Sections, která obsahuje všech 350 sekcí + 5 stránek týkajících se pravidel a vytváření postavy. Složka Images obsahuje ilustrace k vybraným sekcím. 5.5 Vytvoření sekce UI pro každou sekci se vytváří ve třídě SectionPage.cs na základě korespondujícího HTML souboru. Pro načtení a parsování HTML souborů využívám zdarma dostupnou knihovnu s názvem Html Agility Pack (HAP), kterou je možné stáhnout na adrese https://htmlagilitypack.codeplex.com. Pro použití na všech platformách využívám její PCL verzi, dostupnou na adrese https://www.nuget.org/packages/htmlagilitypack-pcl. Všechny akce a podmínky ve hře jsou dle návrhu řešeny pomocí tlačítek XF třídy Button, nebo jejích dědiců. Každé tlačítko má přiřazenou metodu, ve které dojde k vykonání akce. Pokud uživatel nesplňuje podmínky pro danou akci, nebude na tlačítko možné kliknout. 63
5.5.1 Obecný HTML parser Pomocí HAP a LINQ dotazu nejdříve získám obsah HTML tagu <div> se třídou maintext : HtmlNode maintext = doc.documentnode.descendantsandself().first(x => x.name == "div" && x.attributes["class"]!= null && x.attributes["class"].value == "maintext"); Následně proběhne cyklus pro všechny elementy typu <p> v maintext. Pro každý odstavec je pomocí regulárních výrazů zkontrolováno, zda neobsahuje syntaxi určenou v analýze aplikace. Pokud ano, jsou vytvořeny korespondující UI elementy a nastaveny jejich vlastnosti. Celá metoda je poměrně rozsáhlá, proto pro ilustraci ukážu pouze parsování sekce, ve které se uživatel musí najíst: if (Regex.Match(p.InnerText, @"eat a Meal").Success) { CanClickNext = false; sectiontext.text += p.innertext + "\n"; mealb = new Button() { Text = "EAT A MEAL" + "\n" }; mealb.clicked += MealClicked; } Pokud se v současné sekci vyskytuje syntaxe eat a Meal, znamená to, že se postava musí najíst. Dokud tak neučiní, není možné pokračovat. To je reprezentováno vlastností CanClickNext, která je nastavena na hodnotu false. Poté se přidá text sekce, který zůstává beze změny, a vytvoří se tlačítko, díky němuž může hráč akci vykonat. List<string> buttons = new List<string>(); if (cha.disciplines.exists(d => d == Disciplines.GrandHuntmastery)) buttons.add("use Grand Huntmastery to get a meal"); if (cha.items.exists(item => item.name == "Meal")) buttons.add("eat a meal from backpack"); var action = await DisplayActionSheet("Eat a meal:", "Lose 3 Endurance points", null, buttons.toarray()); if (action == null) return; if (action == "Lose 3 Endurance points") LoseEndurance(3); if (action == "Eat a meal from backpack") cha.removeitem("meal", StorageType.Backpack); V metodě MealClicked dochází k ověření možností vykonání této akce. Hráči je zobrazen výběr pro něj dostupných možností řešení této situace pomocí asynchronní XF metody DisplayActionSheet. Po zvolení možnosti hráčem jsou provedeny změny související s danou volbou a hra může pokračovat dál. 5.5.2 Unikátní sekce Oproti mojí prvotní analýze sekcí se mírně zvýšil počet sekcí, pro které není možné UI vytvořit obecným parsovaním. Finální počet těchto sekcí je 91, což značí nárůst o 21 sekcí 64
oproti analýze. I u některých sekcí s opakující se syntaxí akcí a podmínek se totiž vyskytly komplexnější podmínky a jejich kombinace, které není možné z textu získat bez znalostí dalších souvislostí. Stále se ale jedná o rozdíl pouhých 6% z celkového počtu sekcí navíc, což považuji za dobrý výsledek. Čísla těchto sekcí jsou uvedena v listu s názvem SpecialSections. Pro každou sekci existuje metoda, ve které je manuálně vytvořeno UI pro danou sekci. Metoda má název ve formátu: ParseSection{číslo sekce}. Předáme jí list HTML tagů obsahujících text sekce a hlavní layout stránky, do kterého se text a UI prvky vloží. Metoda je dynamicky volána pomocí reflexe: private void ParseSpecialSection(int sectionnumber, IEnumerable<HtmlNode> enumerable, StackLayout sectionarea) { this.gettype().getmethod(string.format("parsesection{0}", sectionnumber), BindingFlags.NonPublic BindingFlags.Instance).Invoke(this, new object[] { enumerable, sectionarea }); } 5.6 Srovnání GUI na platformách Obrazovky jsou v XF řešeny třídou ContentPage, do které pak vkládáme naše vizuální prvky (popis typů prvků je popsán v kapitole o frameworku Xamarin). Pokud chceme vytvořit vlastní stránku, stačí pouze vytvořit novou třídu a dědit od třídy ContentPage. Layout a UI stránky je možné zadávat v jazyce XAML (do samostatného souboru) nebo je můžeme vytvořit přímo v dané třídě v kódu. Jelikož moje obrazovka jednotlivé sekce hry nebude vždy stejná, musel jsem zvolit vytváření UI v kódu, abych mohl na základě parsování dynamicky přidat prvky na obrazovku. Tento přístup sice funguje dobře, ale značně nám kvůli němu naroste počet řádků v kódu. Rovněž je zhoršena přehlednost kódu. Při vytváření obrazovek jsem vycházel z mého návrhu aplikace. Každá obrazovka v návrhu je v aplikaci realizována pomocí samostatné třídy. 5.6.1 Testovací zařízení Pro posouzení výsledné podoby aplikace vytvořené v XF bylo nutné ji otestovat na všech třech platformách. Testování aplikace jsem prováděl na různých typech mobilů i tabletů, ať už přímo na zařízení, nebo pomocí emulátoru. U grafického srovnání v této kapitole byl okruh zařízení zúžen na jedno pro každou platformu. Pro ukázku GUI na platformě Android jsem využil svůj telefon HTC One S. Pro WP jsem použil emulátor dodávaný jako součást SDK, konkrétně emulátor WP 8.1 WVGA 4 inch. U platformy ios jsem použil MacBook Pro, na kterém byl spuštěný iphone 65
6s simulátor. Zvolil jsem tento typ iphonu, protože je momentálně s 30% zastoupením mezi iphony nejrozšířenější. [41] 5.6.2 Úvodní obrazovka Obrázek 24: Srovnání Úvodní obrazovka Zdroj: Vlastní zpracování Úvodní obrazovka je reprezentována třídou ProfileSelectionPage.cs. Po zapnutí aplikace se načtou dostupné profily z databáze a zobrazí se jejich název spolu se sekcí, kde se právě postava nachází. Pod dostupnými profily je tlačítko pro vytvoření profilu nového. Na obrázku 24 můžeme vidět některé rozdíly mezi GUI jednotlivých platforem, které budou patrné i na dalších obrazovkách. Díky rozdílům můžeme krásně vidět, jak XF opravdu vytváří pro každou platformu daný prvek tak, aby působil nativně. U ios tlačítka (XF prvek s názvem Button ) nejsou ohraničena a mají text v modré barvě. U WP ohraničena jsou, ale mají stejnou barvu pozadí, jako celá obrazovka. U platformy Android jsou ohraničena a mají šedou barvu pozadí. Aplikace díky tomu nemá jednotné GUI, díky čemuž působí jako by byla vyvíjena přímo pro danou platformu. Další rozdíl je v horní navigační liště s nadpisem, která na WP není dostupná, je proto zobrazena pouze u Androidu a ios. 66
5.6.3 Obrazovka Vytváření postavy Obrázek 25: Srovnání Vytváření postavy Zdroj: Vlastní zpracování Na obrázku 25 můžeme vidět jednu z úvodních obrazovek zobrazených postupně při vytváření postavy (třída CharacterCreationPage.cs ). Popis pravidel je zanechán v původním znění, pro určení náhodného čísla je přidáno tlačítko. Po jeho stisknutí se vygeneruje náhodné číslo, tlačítko se deaktivuje a zobrazí výsledek CS postavy. 67
5.6.4 Obrazovka Sekce Obrázek 26: Srovnání Sekce s předmětem Zdroj: Vlastní zpracování Ukázkovou obrazovku s textem sekce a jednou akcí můžeme vidět na obrázku 26. V horní části jsou tlačítka pro zobrazení předmětů, vlastností a pro návrat do hlavního menu (výběru profilu). U této sekce je možné získat předmět s názvem Siyen Crown. Uživatel tak může učinit pomocí souvisejícího tlačítka. Na WP obrazovce již uživatel předmět získal, a proto je tlačítko deaktivováno. Tlačítka pro přesun na další sekci jsou pro hráče snadno odlišitelná, jelikož vždy končí číslem sekce. 68
Obrázek 27: Srovnání Sekce s náhodným číslem Zdroj: Vlastní zpracování Na obrázku 27 je příklad dalšího z mnoha typů sekcí. V tomto typu sekce se uživatel nemůže sám rozhodnout o přesunu na další sekci, ale o výsledku rozhoduje náhoda. Uživatel nejdříve vygeneruje náhodné číslo pomocí tlačítka (Android obrazovka) a na základě výsledného čísla se mu zpřístupní tlačítko pro přechod na další sekci. Výsledné číslo můžou ovlivňovat i další faktory, jak můžeme vidět na WP obrazovce. Zde hráčova postava díky disciplíně dokonale ovládá střelbu z luku, proto je výsledné číslo zvýšeno o 3. Tento výsledek je zobrazen v kulatých závorkách. 69
5.6.5 Obrazovka Vlastnosti Obrázek 28: Srovnání Vlastnosti Zdroj: Vlastní zpracování U obrazovky s vlastnostmi (viz obrázek 28) a dovednostmi postavy, znázorněné na obrázku X, jsou pro zobrazení disciplín a ovládaných zbraní využity 2 XF prvky typu ListView. Tomuto prvku stačí pouze předat datový zdroj a on se sám postará o jejich zobrazení. Pokud obrazovka není dostatečně veliká, bude možné se v listu posouvat, což můžeme vidět u Android obrazovky, na které je vidět posun vůči položkám listu u ios. V horní části můžeme vidět informace o aktuálních stavech CS a END postavy. 70
5.6.6 Obrazovka Předměty Obrázek 29: Srovnání Předměty Zdroj: Vlastní zpracování Obrázek 29 znázorňuje podobu obrazovky s předměty postavy. Obrazovka je posouvatelná, postupně jsou zobrazovány předměty z jednotlivých kategorií. V horní části se rovněž nachází tlačítko pro zobrazení mapy hry. Co se týče rozdílů mezi platformami, můžeme si všimnout, že u ios verze je barevně odlišeno tlačítko pro zahození předmětu (tlačítko Drop ). Bez ohraničení totiž dvě tlačítka se stejnou barvou působila jednolitě, proto jsem tlačítko odlišil změnou barvy. U ostatních platforem jsem zachoval defaultní vzhled. Každý předmět je v listu reprezentován vlastní buňkou, reprezentovanou třídou ItemCell.cs. Ta dědí od XF třídy ViewCell a umožňuje nám vytvořit vlastní vzhled jednotlivých řádků listu. Díky tomu je možné vytvořit tlačítka dle typu předmětu. Např. předmět typu zbraň je možné nastavit jako aktivní (tlačítko Equip ) a předmět typu lektvar je možné použít (tlačítko Use ). Po stisknutí tlačítka se aplikace sama postará o úpravy vlastností postavy. 71
5.6.7 Obrazovka Souboj Obrázek 30: Srovnání Souboj Zdroj: Vlastní zpracování Obrazovka umožňující vykonání souboje neobsahuje navigační lištu a zároveň blokuje funkci HW tlačítek pro krok zpět, aby nebylo možné souboj opustit bez dokončení. Na obrázku 30 je vidět, že layout obrazovky je na WP ve srovnání s ostatními platformami hůře uspořádán. Zde má XF trochu problémy, jelikož prvek Switch, který se používá jako přepínač, je na WP defaultně větší. I po jeho zmenšení je mu ale rezervován stále stejně velký prostor. Pomocí přepínačů může hráč používat disciplíny (pokud je ovládá) pro zvýšení CS. Při jejich vypnutí/zapnutí se automaticky mění zobrazovaná hodnota CS a CR. Po vykonání kola souboje tlačítkem Execute round se vygeneruje náhodné číslo a zobrazí se výsledné hodnoty END obou soupeřů, změna END je zobrazena v závorkách. Tlačítko Evade fight slouží pro útěk ze souboje a je aktivní pouze v některých soubojích po určitém počtu kol. Na ios obrazovce můžeme vidět, že z tohoto souboje je možné utéci po třech kolech. 72
5.6.8 Obrazovka Hádanka Obrázek 31: Srovnání Hádanka na čas Zdroj: Vlastní zpracování Zajímavou obrazovkou je obrazovka s hádankou, kterou musí hráč vyřešit za daný čas. Její ukázku můžeme vidět na obrázku X. Layout je jednoduchý, na stránce je zobrazeno zadání hádanky, pod ním odpočet času a nakonec místo pro zadání odpovědi. Pro zadání odpovědí je využíván XF prvek Entry. Ten na každé platformě zobrazí nativní prvek pro zadávání textu. Po jeho zvolení se zobrazí softwarová klávesnice. V mém případě jsem prvek upravil tak, aby bylo možné zadávat pouze čísla 1-350, jelikož odpovědí je vždy číslo sekce. U implementace odpočtu času nebylo kvůli zajištění funkčnosti na všech platformách možné využít standardní třídu System.Threading.Timer, ale stejné funkčnosti bylo docíleno pomocí XF třídy Device a metody StartTimer. Té předáme interval, po kterém se vždy zavolá námi definovaná metoda. Dokud tato metoda vrací hodnotu true, bude se volání v intervalech opakovat. Pokud vrátí false, další volání již neproběhne. Device.StartTimer(new TimeSpan(0, 0, 1), OnTimedEvent); Zobrazení zbývajícího času jsem implementoval tak, že se při vytvoření stránky vytvoří proměnná s počtem vteřin na splnění hádanky. Metoda OnTimedEvent je 73
volána každou vteřinu a uvnitř ní je proměnná snížena o 1. Výsledná hodnota je následně zobrazena na obrazovce. private bool OnTimedEvent() { Counter--; CounterLabel.Text = Counter.ToString(); 5.6.9 Vyskakovací okna Nedílnou součástí dobrého GUI mobilní aplikace jsou i vyskakovací okna. V XF jsou k dispozici dva typy, které oba ve své práci využívám. Obrázek 32: Srovnání Vyskakovací okno 1 Zdroj: Vlastní zpracování První z nich je pouze základní okno s nadpisem, upozorněním a tlačítkem pro potvrzení. Ve své aplikaci ho využívám např. když uživatel chce sebrat předmět, na který již nemá místo (viz obrázek 32). Je možné ho použít i asynchronně a pozdržet další vykonávání kódu, dokud na něj uživatel nezareaguje. Vyskakovací okno je na každé platformě zobrazeno pomocí nativní komponenty. await DisplayAlert("Not enough space", "You are carrying the maximum number of weapons (2)", "OK"); 74
Obrázek 33: Srovnání Vyskakovací okno 2 Zdroj: Vlastní zpracování Druhý typem je vyskakovací okno s výčtem možností (viz obrázek 33). Metodě předáme nadpis, tlačítko pro zrušení a seznam možností k zobrazení. V aplikaci je použito např. u výběru Kai zbraně. I zde je využíván asynchronní přístup. Hráčem zvolená možnost je uložena do proměnné a na základě její hodnoty můžeme provést akci. U zmíněného výběru zbraně přidáme zvolenou zbraň mezi hráčovy předměty a nastavím ji jako právě používanou. var action = await DisplayActionSheet("Choose Kai Weapon", "Cancel", null, kaiweapons.select(it => it.name + " " + it.weapontype).toarray()); if (action == "Cancel" action == null) { return; } 5.7 Kód specifický pro platformu V průběhu vývoje a testování jsem narazil jen na velice málo situací, kdy bych musel upravit chování aplikace na základě platformy, na které je spuštěna. V této kapitole budou uvedeny ty nejvýznamnější z nich. 5.7.1 Dlouhý text tlačítka Pokud je text tlačítka delší, než je šířka obrazovky, vykazují jednotlivé platformy rozdílné chování. Na platformě Android je text zalamován tak, aby byl zobrazen celý, a velikost 75