Univerzita Karlova v Praze Matematicko-fyzikální fakulta Diplomová práce Ondřej Kunc Multiplatformní mobilní aplikace databázového systému Matylda Katedra distribuovaných a spolehlivých systémů Vedoucí diplomové práce: RNDr. Jan Kofroň, Ph.D. Studijní program: Informatika Studijní obor: Softwarové systémy Praha rok 2015
Na tomto místě bych rád poděkoval mému vedoucímu práce RNDr. Janu Kofroňovi, Ph.D., který mi byl vždy k dispozici a poskytnul velmi cenné rady a zkušenosti. Dále bych chtěl poděkovat své rodině a přítelkyni za podporu a všem členům týmu Matylda za skvělou spolupráci na projektu.
Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně a výhradně s použitím citovaných pramenů, literatury a dalších odborných zdrojů. Beru na vědomí, že se na moji práci vztahují práva a povinnost vyplývající ze zákona č. 121/2000 Sb., autorského zákona v platném znění, zejména skutečnost, že Univerzita Karlova v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V.. dne.. podpis
Název práce: Multiplatformní mobilní aplikace databázového systému Matylda Autor: Ondřej Kunc Katedra / Ústav: Katedra distribuovaných a spolehlivých systémů Vedoucí diplomové práce: RNDr. Jan Kofroň, Ph.D. Abstrakt: Systém Matylda vznikl za účelem poskytnutí detailní databáze a webového rozhraní pro vyhledávání, filtrování a porovnávání zboží zoblasti potravin a drogerie. Cílem práce je k tomuto systému vytvořit uživatelsky přívětivou mobilní aplikaci, která bude dostupná na všech hlavních mobilních platformách dneška. Výsledná mobilní aplikace zpřístupňuje hlavní funkcionality již existující webové aplikace a využívá předností mobilních zařízení, jako je použití map nebo zjišťování polohy uživatele. Mezi hlavní funkcionality patří vyhledání detailní informace o produktech, procházení slevových letáků, porovnávání slev, vytváření nákupních seznamů, přihlašování a další. Aplikace tedy může být využita jako chytrý pomocník při nákupu potravin a drogerie, který ušetří uživatelům čas i peníze. Klíčová slova: vývoj mobilní aplikace, Android, ios, Windows Phone, webové služby Title: Multi-platform mobile application of database system Matylda Author: Ondřej Kunc Department / Institute: Department of Distributed and Dependable Systems Supervisor of the master thesis: RNDr. Jan Kofroň, Ph.D. Abstract: System Matylda was created in order to provide a database and web interface which allows sorting, filtering and comparing of products from food and drugstore industry. The goal of this thesis is to create a user friendly mobile application for this system. The application will be available for all today s major mobile platforms. The final application uses main features of the existing web application and also takes advantage of capabilities of modern mobile devices such as maps and user location. Some of the main features are searching for detailed product information, browsing discount leaflets, comparing discounts, creating shopping lists, authentication and more. The application can be used as a smart assistant which helps with shopping for food and drugstore products and can also save both time and money.
Keywords: mobile application development, Android, ios, Windows Phone, web services
Obsah 1 Úvod... 1 1.1 O projektu Matylda... 1 1.2 Požadované cíle... 1 1.3 Struktura diplomové práce... 2 2 Analýza... 3 2.1 Popis existujícího systému... 3 2.2 Specifikace... 4 2.3 Popis jednotlivých platforem... 5 2.3.1 Android... 6 2.3.2 ios... 8 2.3.3 Windows... 9 2.4 Srovnání technologií pro vývoj mobilní aplikace...10 2.4.1 Nativní vývoj...12 2.4.2 PhoneGap...12 2.4.3 Appcelerator Titanium...13 2.4.4 Xamarin...14 2.4.5 Celkové srovnání...15 2.5 Xamarin technologie...16 2.6 Návrhový vzor MVVM a MvvmCross Framework...20 2.7 Podpora různých verzí cílových platforem...23 2.8 Volba lokálního úložiště...26 2.9 Možnosti zobrazení map...27 2.10 Návrh implementace serverové části...30 2.10.1 Začlenění do projektu Matylda...30 2.10.2 Volba technologie...31 3 Implementace...33 3.1 Základní architektura...34 3.1.1 Vrstvy webového klienta...35 3.1.2 Databázová vrstva...36 3.1.3 Vrstva služeb...37
3.1.4 ViewModely...39 3.1.5 Android projekt...42 3.1.6 ios projekt...44 3.1.7 Windows projekt...46 3.2 Platformě specifické UI komponenty...47 3.3 Navigace aplikací...52 3.4 Procházení letáků...54 3.5 Geolokace...57 3.6 Implementace map...57 3.7 Nákupní seznamy a jejich synchronizace...60 3.8 Chybové stavy...62 3.9 Přihlašování...63 3.9.1 Serverová část...64 3.9.2 Klientská část...66 3.10 Testování...67 4 Uživatelská dokumentace...69 4.1 Instalace...69 4.2 Průchod aplikací...71 4.3 Rozbor případů užití...77 5 Podobné aplikace...79 6 Závěr...81 7 Zdroje...82 8 Seznam obrázků...85 9 Seznam zkratek...86 10 Přílohy...87
1 Úvod 1.1 O projektu Matylda Projekt Matylda vznikl v rámci předmětu Softwarový projekt na MFF UK. Hlavním cílem projektu bylo vytvořit univerzální databázový systém pro ukládání produktů z oblasti potravin a drogerie prodávaných na území ČR. K tomuto účelu byla vyvinuta webová aplikace, která uživateli poskytuje široké možnosti filtrování, třídění a preferencí, se zachováním maximální jednoduchosti. Projekt byl v prosinci 2014 úspěšně obhájen a všichni autoři se rozhodli na projektu dále pokračovat a uvést ho do ostrého provozu. Další práce přinesla požadavky na nové funkcionality a vylepšení. Aby bylo dosaženo co největšího počtu uživatelů, byl jeden z těchto požadavků zpřístupnit funkce Matyldy na tzv. chytrých mobilních telefonech, které používá stále více lidí. 1.2 Požadované cíle Hlavním cílem této práce je vyvinout mobilní aplikaci, která zpřístupní funkce webové aplikace a bude maximálně uživatelsky přívětivá. Aplikace bude využívat předností chytrých telefonů, jako jsou mapy, zjišťování polohy uživatele a dotykového ovládání. Bude analyzován trh s chytrými telefony, jejich operačními systémy a podíly jednotlivých platforem na trhu. Výstupem této analýzy bude seznam platforem, pro které se vyplatí vyvinout mobilní aplikaci pro projekt Matylda. Proběhne analýza technologií pro vývoj mobilních aplikací. Dá se očekávat, že cílových platforem bude více, proto je třeba zvážit i různá multiplatformní řešení, kdy lze sdílet kód mezi jednotlivými platformami a tím ušetřit čas při vývoji. Bude navržen a implementován způsob jakým bude komunikovat mobilní aplikace se systémem Matylda včetně popisu napojení do existující architektury systému. 1
1.3 Struktura diplomové práce Diplomová práce začíná popisem již vyvinutého systému a specifikací samotné aplikace. Poté následuje analýza platforem a srovnání technologií pro jejich vývoj. Součástí analýzy je také popis vybrané technologie a analýza řešení samotné aplikace. V kapitole 3, která se zabývá implementací, bude nejprve popsána základní architektura aplikace a poté bude následovat popis řešení jednotlivých problémů jako je např. navigace aplikací, implementace map nebo realizace přihlašování. Součásti kapitoly je i popis způsobu testování aplikace. Kapitola 4 obsahuje uživatelskou dokumentaci, kde je popsán průchod aplikací, realizace různých případů užití a popis instalace. Další kapitola srovná podobné aplikace na trhu a v závěru budou popsána možná rozšíření aplikace a zhodnocení celého řešení. 2
2 Analýza 2.1 Popis existujícího systému Nejprve stručně popíšeme softwarové dílo, které bylo vyvinuto v rámci softwarového projektu, na který tato práce navazuje. Detailní popis tohoto díla byl přiložen ve formě dokumentace při obhajobě projektu a zde bude následovat jen krátký popis pro uvedení čtenáře do problematiky. Systém Matylda je webový projekt založený na technologii ASP.NET MVC, který používá relační databázi MSSQL a NoSQL databázi Apache Solr pro ukládání dat. Hlavním účelem projektu je poskytnout uživatelům detailní databázi potravinářských a drogistických výrobků prodávaných v ČR. Důraz je kladen na ceny produktů a produkty ve slevě, které mohou zajímat velký počet lidí. Pro náročnější uživatele systém navíc umožňuje široké možnosti filtrování produktů. Je možné např. hledat pečivo prodávané v Bille a Albertu v Praze, které neobsahuje lepek a výsledky seřadit podle ceny. Mezi další funkcionality patří procházení slevových letáků, přihlašování, vytváření nákupních košíků, procházení obchodních řetězců, jejich prodejen a další. Web je rozdělen na veřejnou část obsahující výše popsanou funkcionalitu a administrativní část. V této části je možno spravovat téměř veškerá data pomocí webového rozhraní, přičemž největší důraz je kladen na manuální zadávání produktů z letáků. Z každého letáku se získávají údaje o produktech, jejich cenách, hmotnosti a další. Zpracování letáků je časově náročná operace, proto byly implementovány funkcionality, které tento proces urychlí. Jedná se např. o analýzu stránek metodou digitálního zpracování obrazu, které na základě heuristik zkusí rozpoznat opakující se prvky na stránce, jako je název produktu, stará cena a cena ve slevě. Tyto údaje jsou poté předvyplněné a zadávající je pouze kontroluje a upravuje. Databáze produktů v současné době obsahuje přes 20000 unikátních položek a je plněna ručním zpracováním slevových letáků a také importem produktů ze serveru http://www.zdravapotravina.cz/, se kterým máme smlouvu. Zároveň probíhají 3
jednání se samotnými řetězci o poskytování dat ve strojově čitelné formě. Projekt běží v testovacím režimu na adrese http://projekt-matylda.cz/. 2.2 Specifikace Hlavním požadavkem na mobilní aplikaci je zpřístupnit funkce webového portálu s využitím výhod mobilních zařízení. Protože se na vývoji webové části pracuje paralelně s mobilní, mohou vznikat požadavky na nové funkce či změnu stávající funkcionality i v průběhu vývoje, avšak všechny důležité funkcionality jsou definovány již před začátkem implementace. Nyní bude následovat jejich výčet: Prohlížení nejzajímavějších nabídek Uživatel si bude moci zobrazit seznam populárních produktů, které jsou aktuálně ve slevě, seřazené podle velikosti slevy. Tyto produkty by měly být zobrazeny na úvodní stránce. Procházení aktuálních letáků Uživatel bude mít možnost listovat aktuálními slevovými letáky řetězců. Zobrazení informací o produktu U každého produktu bude zobrazena informace o aktuální, průměrné a minimální ceně, složení, ingredience, seznam prodejen kde lze produkt koupit řazeno od nejbližší a poloha těchto prodejen na mapě. Procházení produktů podle kategorií Produkty jsou zařazeny do stromu kategorií a aplikace umožní průchod tímto stromem. Procházení obchodníků Aplikace umožní průchod přes jednotlivé prodejce. U každého prodejce se eviduje seznam jeho produktů, aktuálních letáků, nejbližších prodejen a jejich podčástí (např. Tesco Express je podčástí Tesco). U jednotlivých prodejen bude zobrazena adresa, poloha na mapě a možnost spuštění navigace k dané prodejně. Vyhledávání Uživatel bude moci vyhledávat produkty, kategorie a obchodníky. Volba polohy Aplikace bude používat aktuální polohu telefonu a navíc umožní nastavit aktuální polohu na libovolné město v ČR. 4
Přihlašování Aby mohl uživatel používat nákupní seznamy, musí se nejprve přihlásit. Bude umožněno stejné přihlašování jako ve webové verzi, tedy jménem a heslem nebo přes služby externího poskytovatele, což bude Facebook a Google. Nákupní seznamy Přihlášený uživatel bude mít možnost zakládat nákupní seznamy, přidávat produkty a kategorie do seznamu, editovat seznamy a sdílet seznamy pomocí emailu s jinými uživateli. Seznamy budou synchronizovány s jeho Matylda účtem a musí částečně fungovat i bez připojení k internetu. Tutoriál Při prvním spuštění bude uživatel seznámen s hlavními funkcemi aplikace formou jednoduchého tutoriálu. 2.3 Popis jednotlivých platforem Před vývojem aplikace běžících na chytrých mobilních zařízeních je nejprve nutné zvážit, pro které zařízení je aplikace určená. Dnešní chytré telefony jsou vybaveny různými operačními systémy, které se od sebe můžou poměrně lišit, a pokud se rozhodneme podporovat jeden z těchto systémů, pak port na jiný systém může obnášet vývoj celé aplikace znovu od začátku. Pokud se podíváme na podíly různých operačních systémů na trhu, nejčastěji zde figurují tyto systémy: Android, ios, Windows Phone, Symbian a BlackBerry OS. Celosvětové podíly systémů ve druhém čtvrtletí 2015 srovnává například server IDC [1]. Tabulka 1: Celosvětové podíly - druhé čtvrtletí 2015 [1] Android ios Windows Phone BlackBerry OS Ostatní 82.8 % 13.9 % 2.6 % 0.3 % 0.4 % Server mobilenet.cz [2] přidává srovnání z českého trhu, kde srovnává data od tuzemských operátorů, konkrétně T-Mobile, O2 a Vodafone. Data jsou z ledna 2015 a vypadají následovně: 5
Tabulka 2: Podíly na českém trhu - leden 2015 [2] Android ios Symbian Windows Phone BlackBerry OS Ostatní 71.7 % 10.63 % 9.32 % 6.16 % 1.2 % 0.99 % Kromě procentuálního podílu operačních systémů tu jsou i další faktory pro komerční úspěch aplikace. Např. na Androidu může být těžší zviditelnit aplikaci než např. na Windows Phone. Jiné průzkumy zase ukázaly, že ios uživatelé utratí za aplikace nejvíce peněz. Jenom z tržních podílů můžeme však bezpečně říci, že pokud chceme dosáhnout co největšího počtu uživatelů, měli bychom cílit naši aplikaci minimálně na platformu Android a ios. Protože cílíme na české uživatele, mohl by připadat v úvahu i systém Symbian, avšak telefony s tímto systémem se již nevyrábějí a jejich podíl tedy bude postupně klesat. Posledním systémem, který má nezanedbatelný podíl a vyplatí se pro něj vyvíjet, je systém Windows Phone. Nyní bude následovat stručný popis vybraných systémů. 2.3.1 Android Operační systém Android je založený na jádře Linuxu. Původně byl vyvíjen společností Android Inc., kterou v roce 2005 koupil Google. V roce 2007 bylo vytvořeno uskupení konsorcium Open Handset Alliance, která měla za cíl vytvořit otevřený standard pro mobilní zařízení a jejíž první produkt byl právě Android [3]. Od vydání první verze vychází aktualizace systému, které přidávají do systému nové funkce. Např. verze 3.0 přinesla optimalizaci pro obrazovky tabletů. Poslední vydaná verze 5.1 (Lollipop) vyšla v březnu 2015. Architektura systému se skládá z několika vrstev. Kromě jádra systému a knihoven jádra je zde vrstva Android Runtime. Ta obsahuje virtuální stroj Dalvik, který vytváří běhové prostředí pro Java aplikace. Aplikace se překládá ze zdrojových souborů napsaných v Jave do Java byte kódu. Ten je pomocí Dalvik kompilátoru překompilován do výsledného Dalvik byte kódu, který běží na virtuálním stroji Dalvik. Od verze Androidu 4.4 se ke kompilaci používá mechanismus ART Android Runtime. Jedná se o princip dopředné kompilace a funguje tak, že byte kód 6
Dalviku se při instalaci aplikace přeloží přímo do nativního kódu zařízení. To má za důsledek rychlejší běh aplikací a delší výdrž telefonu. Nejdůležitější vrstvou pro vývojáře aplikací je vrstva Application Framework. Ta zpřístupňuje velké množství služeb, které mohou být použité v samotné aplikaci. Jedná se např. o: View komponenty - Tlačítka, textové pole, atd. Activity manager Stará se o životní cyklus aplikace. Location manager Umožní aplikaci získávat informaci o poloze. Notification manager Umožňuje zobrazit upozornění. Obrázek 1: Architektura Androidu [4] Oficiální vývojové prostředí pro Android je Eclipse, avšak Google prosazuje i Android studio, které koupil v roce 2014. Hlavním aplikačním obchodem je Google Play, ale aplikace mohou být nainstalovány i z jiných zdrojů. Dnes běží Android na více než 20000 zařízeních od 1300 různých značek. 7
2.3.2 ios Systém ios je odlehčenou verzí systému Mac OS X, kterou používá Apple ve svých počítačích. Je to tedy systém UNIXového typu. Hlavní odlišnosti ios oproti Mac OS X je podpora dotykového ovládání. První verze systému vyšla v roce 2007 spolu s vydáním prvního iphonu. Systém byl nejprve znám pod jménem iphone OS. Až roku 2010 byl systém přejmenován na dnešní ios. Aktuální verze je ios 8. Podobně jako Android i ios se dělí na několik vrstev, které poskytují vývojářům základní API a funkcionality. Nejnižší vrstva, na které jsou postaveny ostatní technologie se nazývá Core OS vrstva. Nad touto vrstvou je postavena vrstva Core Services. Ta poskytuje přístup ke službám jako je ochrana dat, SQLite databáze, úložiště icloud a další. Pro vytváření grafických a zvukově propracovaných aplikací slouží vrstva Media. Tu vývojář typicky použije, pokud mu nestačí standartní komponenty systému, které jsou součástí nejvyšší vrstvy a to vrstvy Cocoa Touch [5]. Vrstva Cocoa Touch obsahuje většinu funkcionality, kterou vývojář potřebuje pro vývoj klasické aplikace pro ios. Zahrnuje například: UIKit framework Framework poskytující infrastrukturu pro vývoj standartní grafické aplikace. Obsahuje např. View Controllery (spravují obsah uživatelského rozhraní) nebo standartní UI komponenty. Notifiaction center Framework Umožní přidat notifikace do notifikačního centra. MapKit Poskytuje přístup k mapovým komponentám, které mohou být součástí aplikace. 8
Obrázek 2: Architektura ios [5] Vývoj pro platformu ios probíhá v aplikaci XCode, která je ale dostupná pouze na Mac OS X. Aplikace jsou psané v jazyce C, pokročilejším Objective C nebo nejnovějším jazyku Swift. Kód na ios je překládán do nativního kódu zařízení a není interpretovaný, jako např. bytecode Dalviku na Androidu. Systém ios běží na 12 různých modelech iphonů a 6 modelech tabletů ipadů (novější verze systému nejsou podporovány na starších zařízeních). Výrobce telefonů je jediný a to firma Apple. Aplikace jsou distribuovány pomocí obchodu App Store. 2.3.3 Windows Windows Phone je systém vyvíjený společností Microsoft a je nástupcem systému Windows Mobile. Systém vyšel v roce 2010 a nesl označení Windows Phone 7. Později v roce 2012 vyšel systém Windows Phone 8 založený na architektuře Windows NT, který ale není zpětně kompatibilní s Windows Phone 7 a který používal architekturu Windows CE. Aktuální verze je Windows Phone 8.1 na jejíž popis se zaměříme. Architektura Windows Phone 8.1 se skládá z několika částí. Obsahuje sdílené jádro dělící se na Windows Core a Mobile Core. Nad jádrem je postavené WinRT rozhraní poskytující běhové prostředí Windows Runtime XAML Framework, grafické knihovny, rozhraní pro živé dlaždice, mapy, geolokace a další. 9
Až do verze Windows Phone 8.0 se aplikace pro telefon psaly v tzv. Silverlight API. S verzí 8.1 Microsoft představil rozhraní WinRT, které bylo dříve používáno pro psaní tabletových aplikací ve Windows 8, dříve známé jako metro aplikace. Nad rozhraním WinRT lze psát aplikace v jazyce C# nebo VB.NET s použitím jazyka XAML. Grafické aplikace je možné psát pomocí DirectX v C++. Stejně je možné pro vývoj používat HTML/Javascript [6]. Aplikace pro WinRT lze téměř s minimem změn pustit i na platformě Windows 8.1. Hlavní vývojové prostředí je Visual Studio. Obrázek 3: Windows Runtime Execution model [6] Hlavním dodavatelem telefonů pro systém Windows Phone byla firma Nokia, kterou Microsoft v roce 2013 koupil a nově již telefony s tímto systémem vychází pod značkou Microsoft. Z dalších výrobců je to např. HTC, Samsung, LG a další. Aplikace jsou distribuovány do obchodu Windows Phone Store. 2.4 Srovnání technologií pro vývoj mobilní aplikace V této podkapitole srovnáme technologie, pomocí kterých lze vyvíjet aplikace pro výše uvedené platformy. První z možností je pouze optimalizovat webovou aplikaci pro mobilní zařízení s využitím responsivního designu nebo specializovaného mobilní webu, ke kterému by se přistupovalo na telefonu pomocí webového prohlížeče. Toto řešení má však hned několik nedostatků, jsou jimi například tyto: 10
Aplikace nebude mít platformně specifický vzhled. Aplikace nebude fungovat bez připojení k internetu. Máme přístup jen k těm funkcím telefonu, které zpřístupňuje prohlížeč. Z těchto důvodů nám toto řešení nevyhovuje. Navíc aplikace Matylda již částečně responsivní design používá, a proto se s ním v této práci nebudeme dále zabývat. V úvahu tedy přicházejí dva hlavní způsoby vývoje nativní a multiplatformní. Nativní vývoj zahrnuje použití platformě specifických nástrojů a jazyků pro každý systém. Výsledkem je aplikace, která využívá nativních komponent a tedy má na každé platformě jiný vzhled. Pro lepší názornost platformě specifického vzhledu jsme srovnali oficiální náhledy obrázků z aplikačních obchodů všech uvažovaných systémů aplikace Facebook Messenger. Obrázek 4: Aplikace Facebook Messenger (zleva Android, ios, Windows Phone) Hlavní myšlenkou multiplatformních technologií je to, že většinu nebo celý kód napíšeme jednou a poběží na všech platformách. Podle četnosti výskytu různých technologií jsme vybrali tři nejpopulárnější - Xamarin, PhoneGap, Appcelerator Titanium. Nyní podrobněji o jednotlivých technologiích. 11
2.4.1 Nativní vývoj Pokud bychom se rozhodli použít nativní vývoj, museli bychom pro každou platformu vyvinout aplikaci zvlášť pomocí nativních prostředků. Následující tabulka shrnuje hlavní jazyky a vývojová prostředí: Tabulka 3: Srovnání platforem a prostředí Platforma Jazyky Vývojová prostředí ios Swift, Objective-C Xcode Android Java Android Studio, Eclipse WP8 C# Visual Studio Výhody: Jednoduché využití platformně specifických funkcionalit (GPS, telefonní seznam, atd.). Jednoduché dosažení platformně specifického vzhledu. Nevýhody: Pro každý systém potřebujeme jednu aplikaci. Horší údržba a implementace nových požadavků. Vývojář musí mít znalosti všech platforem, jazyků, prostředí 2.4.2 PhoneGap PhoneGap umožňuje psát aplikace založené na HTML technologiích, které jsou nasazeny a nainstalovány jako nativní aplikace. Celý kód je tedy psán v HTML + JavaScript + CSS a na každé platformě běží ve webové komponentě, která je zabalena do nativní aplikace. PhoneGap zároveň poskytuje společné API, přes které lze přistupovat k mobilním funkcionalitám jako je kamera, adresář atd. [7] PhoneGap aplikace tedy nemají defaultně platformně specifický vzhled a na každé platformě vypadají stejně. 12
Pro vývoj si stačí zvolit jedno prostředí (např. Visual Studio, Eclipse, Xcode) a poté použít online nástroj Adobe PhoneGap Build, kam se pouze nahraje kód, a pro každou platformu dostaneme zkompilovaný balíček. Abychom se zaregistrovali a nastavili certifikát pro vývoj na ios, potřebujeme MAC. Nástroj Adobe PhoneGap Build je zpoplatně částkou $9,99 / měsíc. Pro jednu aplikaci do 50 MB je však zdarma. Výhody: Sdílení až 100 % kódu. Jednoduché nasazení přes PhoneGap Build. Podpora dalších platforem Blackberry, Firefox OS. Teoretické znovupoužití stylů z původního webového projektu. Nevýhody: Ne všechny funkcionality jsou stejně podporovány na všech platformách. Veškerá logika aplikace psaná v JavaScriptu, což se nemusí hodit na větší projekty. Aplikace mají jednotný, ale ne nativní vzhled. Aplikace jsou pomalejší ve srovnání s nativními (běží v prohlížeči). Horší dokumentace 2.4.3 Appcelerator Titanium Appcelerator Titanium poskytuje multiplatformní JavaScriptové prostředí a rozhraní pro mobilní zařízení. Vzniklý kód využívající rozhraní mobilního zařízení je poté přeložen do nativního kódu platformy a business logika zůstane jako JavaScript a za běhu je interpretována platformě specifickým JavaScript enginem. Výsledkem je aplikace, která je hybridem nativní a JavaScriptové aplikace [8]. 13
Aplikace je tedy rychlejší než PhoneGap a má nativní vzhled. Existují však nativní komponenty, které jsou specifické pro systém a nelze je jednoduše sdílet mezi platformami. Nelze tedy sdílet celých 100 % kódu. Aplikace lze vyvíjet v nástroji Titanium Studio, které je založené na prostředí Eclipse, nebo přes nástroje příkazové řádky. Titanium Studio bohužel nemá podporu pro vývoj Windows Phone 8, ale k vývoji lze využít Visual Studio. Pro systém ios je možné v Titanium Studiu vyvíjet pouze na přístrojích s Mac OS od Applu. Základní nástroje jsou zdarma, platí se pouze dodatečné cloudové služby. Výhody: Běží rychle díky částečnému překladu do nativní aplikace. Nativní vzhled. Sdílení velké části kódu. Nevýhody: Řešení platformě specifických komponent. Nelze pro všechny platformy psát v jednom IDE. Slabší dokumentace. Veškerá logika psaná v JavaScriptu, což se nemusí hodit na větší projekty 2.4.4 Xamarin Xamarin [9] je placený nástroj, který umožňuje psát aplikace pro Android, ios a Mac v C# a překládá je do nativního kódu pro danou platformu (aplikace platforem Windows a Windows Phone jsou sami o sobě psané v C#, proto je Xamarin neobsahuje). Udává se, že při použití tohoto nástroje lze bez velkého snažení sdílet 60-70 % kódu mezi platformami. Nadstavbou nad technologií Xamarin je technologie Xamarin.Forms. Jedná se o poměrně nový nástroj, kde se i UI kód napíše v C# a přeloží se do platformě specifických komponent. 14
Xamarin aplikace lze psát v nástroji Xamarin Studio nebo přímo ve Visual Studiu za použití Xamarin pluginu. Pro nasazení aplikace na iphone je třeba mít připojený MAC, sloužící jako build host. Pro vývoj je potřeba jedna licence Xamarin.Android a jedna licence Xamarin.iOS, dohromady za $1998 / rok. Výhody: Sdílení velkého množství kódu mezi platformami, což vede k velké udržovatelnosti projektu. Výsledkem jsou plně nativní aplikace, které běží téměř stejně rychle jako nativní. Výborná podpora a dokumentace. Lze psát ve Visual Studiu jako původní webový projekt a částečně sdílet kód mezi webovým a mobilním projektem. Nevýhody: Cena. Podobně jako u nativního vývoje musí vývojář znát nástroje pro vytváření UI na každé platformě. 2.4.5 Celkové srovnání Následující tabulka shrnuje některé ze základních aspektů: 15
Technologie Nativní aplikace Tabulka 4: Srovnání multiplatformních technologií % sdílení kódu mezi platformami Cena navíc Dokumen tace Prog. jazyk Nativní Ano 0 Zdarma N/A Závisí na plat. Phonegap Ne 100 Zdarma vs. $120 / rok Horší HTML + CSS + Javascript Xamarin Ano 90 $1998 / rok Výborná C# Appcelerator Napůl 90 Zdarma Horší JavaScript Titanium Na základě analýzy těchto technologií a práci na základní úrovni s každou z nich, jsme dospěli k závěru, že jednoznačně nejvhodnější technologií pro naše účely je Xamarin. Zde jsou hlavní důvody pro tuto volbu: Nativní vývoj nepřichází v úvahu, protože nemáme znalosti všech platforem a ukazuje se drahý. PhoneGap může být pomalý a nedosáhneme nativního vzhledu a Appcelerator Titanium je psán v JavasSriptu, což může být časově náročné. Ze všech technologií se při osobním vyzkoušení Xamarin jevil nejjednodušší, s nejlepší dokumentací, podporou a s nejkratším časem potřebného k rozběhnutí jednoduché aplikace. Tím, že většina aplikace je psaná v C#, bude potencionálně jednoduché zapojit i ostatní členy týmu na dílčí úkoly, aniž by museli vědět něco o mobilním vývoji. 2.5 Xamarin technologie Současně s volbou Xamarinu jako hlavního nástroje pro vývoj aplikace musíme zvolit vhodné technologie související s Xamarin vývojem. Xamarin sám o sobě umožňuje psát aplikace pro Android a ios v jazyce C#. Nyní stručně popíšeme, jak je tohoto dosaženo na každé z těchto platforem. Xamarin.Android aplikace běží uvnitř prostředí Mono. To je postaveno nad Linuxovým jádrem a zpřístupňuje implementaci standartních.net knihoven jako je 16
System, System.IO nebo System.Net. Naproti tomu Android knihovny jako Graphics, Audio nebo Telephony jsou přístupné pouze přes prostředí ART. Výsledná aplikace tedy používá obě běhová prostředí a Xamarin poskytuje engine na jejich propojení. Výsledkem překladu je balíček s příponou.apk, který má stejnou strukturu jako balíček přeložený z Javy. Pouze má navíc assembly knihovny aplikace a nativní knihovny obsahující prostředí Mono. Obrázek 5: Xamarin.Android architektura Oproti tomu Xamarin.iOS aplikace je kompilována pomocí dopředné kompilace, která je jednou z funkcionalit prostředí Mono a výsledkem je nativní kód cílového procesoru. Během překladu je použit nástroj zvaný Linker, který má za úkol odstranit nepoužívané části kódu. Samotný.NET Framework je součástí této aplikace, avšak nepoužívaný kód je během kompilace díky nástroji Linker odstraněn. Protože výsledný kód již není interpretovaný, přináší to s sebou několik omezení, např. nemožnost generování kódu za běhu. Všechny limitace lze najít na stránkách Xamarinu [10]. Obě technologie zpřístupňují kompletní rozhraní dané platformy a díky způsobu jejich fungování umožňují, aby výsledná aplikace běžela zhruba stejně rychle jako aplikace napsaná nativně. Např. přeložená Xamarin.iOS aplikace je nerozeznatelná od nativní napsané v Objective C, protože používá stejné nativní rozhraní, ale může mít větší velikost. Zajímavé srovnání můžeme najít např. na serveru magenic.com 17
[11], kde testovaná Xamarin aplikace běžela dokonce rychleji na ios i na Androidu než nativní aplikace. Samotné použití Xamarinu pro vývoj aplikace na Android a ios implicitně nezaručuje, že mezi platformami budeme sdílet nějaký kód. K tomu však slouží další dva koncepty a to Shared Project a Portable Class Library (PCL): Shared Project Umožňuje psát kód, na který se odkazují aplikační projekty. Tento kód je při překladu aplikačního projektu pouze přikompilován ktomuto projektu. Sám o sobě tedy Shared Project nemá žádný výstup ve formě DLL souboru, ale stane se součástí projektu, který se na něj odkazuje. Tím může být např. Xamarin.Android, Xamarin.iOS nebo Windows projekt. Pokud potřebujeme použít kód, který je dostupný jen na jedné z platforem, použijeme direktivy kompilátoru. Např. pokud část kódu je dostupná jen na Androidu, můžeme to vyjádřit takto: #if ANDROID //Android code #endif Obrázek 6: Shared project a dirketivy kompilátoru Portable Class Library Na rozdíl od Shared Project je výstupem přeložený DLL soubor. Problém ale je ten, že různé platformy používají různou podmnožinu.net Base Class Library (BCL). Při vytváření tohoto projektu je proto nutné vybrat platformy, které chceme podporovat. Tato volba se poté přeloží do tzv. identifikátoru profilu, který popisuje, jaké platformy podporujeme. V tomto projektu pak lze používat největší podmnožinu BCL, která je dostupná na všech zvolených platformách. Pro použití platformě specifické funkcionality je zapotřebí jistá míra abstrakce. Např. v PCL projektu definujeme interface, s kterým tu dále pracujeme, a jeho implementace bude definována v aplikačních projektech. 18
Obrázek 7: PCL a výběr platforem Použití těchto konceptů může zaručit, aby velká část kódu byla sdílená. Minimálně však UI kód musíme napsat pro každou platformu zvlášť. Proto Xamarin přišel s další technologií zvanou Xamarin.Forms, která poskytuje abstrakci nad UI komponentami. Vzhled aplikace se tedy definuje pouze jednou a to pomocí předpřipravených komponent a píše se buďto přímo v C# kódu nebo pomocí jazyka XAML. Komponenty jsou poté při překladu namapovány na komponenty cílové platformy a tím je zaručen nativní vzhled i výkon. Hlavní otázka nyní je, zda pro naši aplikaci použít Xamarin.Forms. Na stránkách Xamarinu o Xamarin.Forms [12] se uvádí, kdy je vhodné tuto technologii použít. Podle těchto doporučení jsou Xamarin.Forms vhodné na jednoduché, případně prototypové aplikace, kdy není dáván důraz na platformě specifickou funkcionalitu. Naše aplikace však může být komplexnější a potenciálně může velmi využívat nativní rozhraní, proto se jako bezpečnější volba jeví Xamarin.Forms nepoužívat. Dalším argumentem může být např. fakt, že se jedná o poměrně novou technologii, která není zatím tolik rozšířená. Rozhodnutí tedy je, že Xamarin.Forms nepoužijeme. Přestože nebudeme sdílet UI kód pomocí Xamarin.Forms, stále můžeme sdílet velké množství kódu. K tomu by se nám hodila abstrakce nad rozhraními jednotlivých platforem. Jako příklad uvedeme získávání aktuální pozice uživatele, s kterou chceme dále pracovat (např. spočítat vzdálenost k obchodu). Na každé platformě se tento úkol řeší jinak. Na androidu používáme k získání lokace 19
LocationClient, který udržuje souřadnice v objektu CustomLocation. Na ios je CLLocationManager se souřadnicemi uložených v CLLocation a podobně na Windows najdeme Geolocator s Geocoordinate. Nám by se však hodilo pracovat jen s jedním typem objektů, který by tyto zastřešoval. Toho můžeme docílit tak, že si nad těmito objekty vytvoříme interface, jehož implementace bude v aplikačních projektech. Protože tato funkcionalita je poměrně častá, můžeme využít již existující řešení. Nejrozšířenější knihovnou je open source framework MvvmCross [13]. Ten nejenže zastřešuje funkcionality jako geolokace, práce s obrázky nebo s barvami, ale i navigaci mezi obrazovkami. Je založen na návrhovém vzoru MVVM, umožňující oddělit business logiku aplikace od vzhledu. Rozhodli jsme se tedy použít MvvmCross Framework využívající návrhový vzor MVVM, který bude popsán v následující kapitole. 2.6 Návrhový vzor MVVM a MvvmCross Framework MVVM (Model View ViewModel) [14] je návrhorvý vzor pocházející od firmy Microsoft. Má za cíl lépe oddělit vzhled aplikace od ostatních vrstev. Vznikl jako variace na vzor Presentation Model [15] od Martina Fowlera a je inspirován vzorem MVC (Model View Controller) [16]. Vzor MVVM rozděluje architekturu aplikace na tyto části: Model Označuje doménový model, který obsahuje data i tzv. business logiku aplikace. View Odpovídá uživatelskému rozhraní. ViewModel Vrstva abstrahující uživatelské rozhraní pomocí výčtu vlastností a akcí. Poskytuje přístup k datům z modelu a zajišťuje interakční logiku aplikace. Binder Spojuje data a akce z View s ViewModelem pomocí tzv. Data Bindingu. V kontextu Microsoft technologií tomu odpovídá jazyk XAML a je tedy implicitní součástí aplikace. 20
Obrázek 8: Návrhový vzor MVVM Pokud bychom srovnávali tento vzor se vzorem MVC, pak vrstvy View a Model jsou totožné. Místo kontroleru, který řídí komunikaci mezi View a Modelem, je zde ViewModel a Data Binding. Hlavním přínosem MVVM je způsob oddělení UI kódu takovým způsobem, že není třeba psát explicitní kód na propojení View s daty ve ViewModelu o to se stará Data Binding. ViewModel tedy neví nic o View který ho používá, ale změny v něm jsou propagovány pomocí bindingu do View. Stejně jsou změny ve View přeneseny do ViewModelu. Původně byl tento návrhový vzor využíván pouze v technologii WPF, později se začal používat v dalších technologiích od Microsoftu využívajících XAML jako např. Silverlight nebo WinRT (včetně vývoje pro Windows Phone). Nyní se používá např. i v JavaScript frameworku KnockoutJS. Na ios je doporučeno vyvíjet aplikace pomocí vzoru MVC, který má širokou podporu v systému a jeho komponentách. Na Androidu není přesně dané, o jaký návrhový vzor se jedná a záleží, jak budeme chápat koncept tzv. aktivity, který má odpovídat jedné aktivitě uživatele. Z návrhového vzoru MVVM vychází i námi zvolený MvvmCross Framework [13]. Cílem tohoto frameworku je umožnit psát pomocí MVVM i na platformách Xamarin.Android a Xamarin.iOS, které MVVM standardně nepodporují. Jedná se o open source Framework vyvíjený především vývojářem jménem Stuart Lodge. Využívá techniku sdílených PCL projektů a umožňuje strukturovat aplikaci takovým způsobem, aby velká část logiky aplikace byla v tomto projektu. Hlavní myšlenka je taková, že obrazovky jednotlivých platforem si víceméně odpovídají obsahem a logikou, která je s nimi spojená a liší se hlavně ve vzhledu. Budeme mít tedy pro každou obrazovku jeden ViewModel, který může být součástí PCL. Na každé plaformě pak pouze naimplementujeme odpovídající View a 21
pomocí bindingu, který taktéž implementuje MvvmCross, napojíme tyto View do ViewModelu. Sám autor MvvmCross o tomto konceptu mluví jako o vylepšeném vzoru MVVM a pojmenovává ho zkratkou MVX Mvvm Cross Platform. Obrázek 9: Vzor MVX MvvmCross tedy nabízí nástroje pro psaní multiplatformních ViewModelů. Dále poskytuje nástroje pro vytvoření základní infrastruktury aplikace jako je společná inicializace při startu aplikace nebo možnost používat princip tzv. Dependency Injection. Jedná se o způsob programování, kdy si objekty sami nevytvářejí závislosti mezi sebou, ale předávají si je (např. pomocí konstruktoru). S tím souvisí pojem IoC Container, což je objekt, který se stará právě o vytváření objektů a jehož vlastní implementaci MvvmCross poskytuje. Důležitou součástí MvvmCross je mechanismus pluginů. Myšlenka je taková, že uživatel nemusí v každé aplikaci chtít pracovat např. s geolokací nebo obrázky. Proto jsou tyto jednotlivé funkcionality oddělené od hlavního projektu pomocí pluginové architektury. Tato architektura je podobná jako architektura samotného projektu a skládá se ze sdílených PCL projektů obsahující abstrakce a knihoven implementující tyto abstrakce na jednotlivých platformách. Pokud bychom chtěli naimplementovat vlastní plugin, musíme dodat PCL, která abstrahuje funkcionalitu tohoto pluginu pomocí interfaců a abstraktních tříd a pro každou platformu musíme dodat jednu knihovnu implementující tuto funkcionalitu na dané platformě. Uživatelova aplikace 22
se typicky bude skládat také z jednoho PCL projektu a několika projektů cílových platforem odkazujících se na jeho PCL. Použití je pak takové, že uživatel si přidá odkaz na PCL pluginu obsahující abstrakce do svého PCL projektu a navíc si přidá odkaz z každého projektu platformy na platformě specifickou knihovnu pluginu. Výhodou je, že uživatel pak s touto funkcionalitou pracuje ve formě abstrakce již jen ve svém PCL projektu a dosáhne většího množství sdílení kódu. Kromě Xamarin.Android a Xamarin.iOS podporuje MvvmCross i platformu Mac, Windows Phone, Windows a částečně i WPF. Framework není přímo závislý na technologii Xamarin, která je potřeba, jen pokud chceme podporovat Android nebo ios. 2.7 Podpora různých verzí cílových platforem Dalším faktorem ovlivňující vývoj aplikace je volba verzí operačních systémů, které budeme podporovat. Novější verze operačních systémů přinášejí nová rozhraní, která nemusí být podporovaná na starých verzích. Další problém, který je třeba vzít v úvahu, je podpora tabletů. Naše aplikace je primárně určena pro chytré telefony, ale rozdíly mezi tablety a telefony se postupně smazávají a jediným rozdílem může být velikost displeje. Naše rozhodnutí je podporovat aplikaci i na tabletových zařízeních, ale nebudeme věnovat větší snahu jejich optimalizaci. Co se týče verzí, nejhorší je situace na Androidu. Různí výrobci telefonů používají vlastní upravené verze Androidu, a pokud vyjde nový Android, jsou uživatelé závislí na výrobci, zda jim doručí update s touto verzí, což může být se zpožděním nebo vůbec. Na stránkách developer.android.com [17] je tabulka ukazující rozložení verzí v dubnu 2015 z dat získaných z obchodu Google Play. 23
Obrázek 10: Rozložení Android verzí (duben 2015) [17] Z těchto dat je patrné, že nejnižší verze, kterou má smysl podporovat je Gingerbread. Avšak i podíl této verze každým měsícem klesá. Proto jsme se rozhodli podporovat primárně verzi IceCream a výše, přičemž po uvedení aplikace do obchodu Google Play můžeme znovu zvážit pracnost podpory verze Gingerbread a případně ji doplnit. Android má podporu tabletů již od API level 11, tudíž naše aplikace by měla běžet i na všech tabletech. Na Androidu je zpětná kompatibilita řešena především pomocí tzv. Support Libraries. Ty umožňují používat funkcionalitu dostupnou v novějších verzích Androidu i ve starších verzích. Navíc se můžeme za běhu zeptat na aktuální verzi Androidu a podle toho volat kód specifický pro danou verzi. Na ios je situace jednodušší. Apple umožňuje většině svých modelů přechod na nejnovější verzi. Nejnižší iphone podporující nejnovější verzi 8 je iphone 4S a co se týče tabletů, podporu nejnovější verze dostaly všechny tablety ipad 2 a výše. Přikládáme graf opět z dubna znázorňující rozložení verzí ios z dat v App Store na stránkách Applu [18]. 24
Obrázek 11 - Rozložení ios verzí (duben 2015) [18] Z grafu nám vyplývá, že má smysl podporovat verzi ios 7 a výše. Opět máme možnost v kódu kontrolovat aktuální verzi. Při vývoji aplikace navíc máme možnost určit, zda je aplikace určená i pro tablety. My tuto možnost povolíme. Na Windows je díky volbě WinRT rozhraní volba jednoduchá. Jediná verze mobilního systému, který běží na tomto rozhraní je Windows Phone 8.1. Ten díky automatickému upgradu z Windows Phone 8.0 běží na většině telefonů. Komplikovanější je situace s tablety. Tabletům odpovídají zařízení běžící na Windows 8.1, aplikace tedy půjde pustit i na desktopových Windows. Tam ale nemusí být podpora pro dotykové ovládání, avšak většina komponent umí fungovat i bez toho. Pokud chceme vyvíjet i pro Windows 8.1, Visual Studio nabízí způsob, jak jednoduše sdílet většinu kódu aplikace. Jedná se o použití sdíleného projektu popsaném v kapitole 2.5. Ten umožňuje sdílet i View ve formě XAML kódu. Bohužel ne všechny komponenty existují na obou platformách. Protože na tablety je kladen menší důraz, budeme kód psát do sdíleného projektu, ale View s platformě specifickými komponentami budeme definovat jenom ve Windows Phone 8.1. Takto bez jakékoliv námahy získáme projekt spustitelný i na klasickém PC, který ale nebude kompletní a může sloužit k rychlému testování aplikace. Dalším důvodem, proč neudržovat kompletní Windows 8.1 aplikaci, je způsob, jakým bude řešen přechod na budoucí Windows 10. Tam bude celá aplikace jen v jednom projektu, jehož rozhraní má být více podobné současnému Windows Phone 8.1 a tedy bychom stejně komponenty z Windows 8.1 projektu nepoužili. 25
Rozhodnutí tedy je podporovat primárně Windows Phone 8.1, udržovat projekt Windows 8.1 jen pro testování a v budoucnu podporovat tablety až s příchodem Windows 10. 2.8 Volba lokálního úložiště Jedním z typických požadavků na aplikaci je persistence lokálních dat při vypnutí aplikace. Tento problém se týká i naší aplikace a přímo ze specifikace vyplývá, že budeme muset uchovávat alespoň tyto data: Nákupní seznamy Musí fungovat částečně bez připojení, tedy musíme si ukládat celé seznamy se všemi položkami včetně informací jako je počet kusů, zda je položka koupená atd. Zobrazení tutoriálu Tutoriál se má ukázat při prvním spuštění, proto si musíme někde pamatovat, zda již uživateli tutoriál příště neukazovat. Přihlašovací údaje Pokud bychom nutili uživatele přihlašovat se při každém spuštění aplikace, pak by používání aplikace bylo značně nepohodlné. Lokace a filtry Uživatel si může zvolit, kde nakupuje a jaké položky ho zajímají (např. jen ve slevě). Toto nastavení musí být také uloženo lokálně na telefonu. Každá z platforem má přístup k lokálnímu souborovému systému, který přidělí aplikaci místo, kam může číst a zapisovat. Protože ukládání dat je častá operace, poskytuje každá platforma vestavěný mechanismus na ukládání dat ve formě klíč-hodnota. Konkrétně na Androidu jsou k dispozici tzv. SharedPreferences, na ios existuje NSUserDefaults a na Windows je to ApplicationDataContainer. Druhou možností jak ukládat data je použít lokální SQLite databázi [19]. Jedná se o minimalistickou knihovnu ukládající data do jednoho souboru. Vyžaduje nulovou kofiguraci, implementuje téměř celý standard SQL-92 a je implementovaná na všech platformách. 26
Další možností je ukládat si data přímo do souboru a spravovat je ručně. To se může hodit např. pro ukládání strukturovaných dat ve formě XML nebo JSON nebo pro ukládání obrázků. Při volbě první varianty bychom se nechtěli zabývat implementačními detaily vyjmenovaných úložišť a můžeme například použít Settings Plugin pro Xamarin [20] zastřešující implementace na všech platformách pod jedním rozhraním. Při použití SQLite můžeme použít knihovnu sqlite-net [21], která taktéž poskytuje multiplatformní rozhraní. Pro jednotnou práci se se soubory můžeme použít File Plugin pro MvvmCross nad kterým je postaven DownloadCache plugin, který poskytuje logiku cachování stažených dat, hlavně obrázků. Ke každé volbě úložiště tedy existuje multiplatformní řešení, a proto by mělo být jejich použití jednoduché. Otázkou zůstává, který typ úložiště je nejvhodnější pro naši aplikaci. Pro jednoduchá data, jako právě informace, zda uživateli ukazovat tutoriál, by bylo nejvhodnější vestavěné úložiště. Na druhou stranu potřebujeme ukládat nákupní seznamy spolu sjejich položkami a na to nám struktura klíč-hodnota nestačí a pro tento účel by byla nejvhodnější SQLite databáze. Ukládání do souboru se jeví jako velmi pracné, může být však vhodné pro cachování obrázků. Bylo by však nepraktické, ukládat část informací do databáze a část do nastavení, proto jsme se rozhodli, ukládat veškerá data kromě obrázků do SQLite databáze a tedy spravovat pouze jedno úložiště. Pro cachování obrázků použijeme DownloadCache MvvmCross plugin, které používá ukládání do souborů, avšak správa těchto souborů je součástí implementace pluginu, proto nebudeme muset se soubory explicitně pracovat. 2.9 Možnosti zobrazení map Další z požadavků je dát uživateli možnost zobrazit si nejbližší prodejny na mapě a spustit navigaci k dané prodejně. Právě použití map je jednou z klíčových funkcionalit, které odlišují mobilní zařízení od desktopových počítačů, kde není 27
kladen takový důraz na aktuální polohu uživatele. Z tohoto důvodu má každý ze systémů v sobě zabudovaný mechanismus pro práci s mapami. V případě map musíme také učinit několik rozhodnutí. První otázkou je, zda pro zobrazení prodejen na mapě použijeme externí aplikaci nebo přidáme mapy přímo do aplikace. Na každé platformě však nemusí být dostupné jenom jedny mapy, např na ios můžeme použít vestavěné mapy od Applu nebo použít Google mapy. Druhou otázkou tedy je, jaké mapy použijeme na konkrétních systémech. Nyní podrobněji probereme jednotlivé možnosti. Pokud bychom chtěli mapy zobrazit v externí aplikaci, pak všechny tři systémy tuto funkcionalitu poskytují. Typicky stačí zavolat systémovou metodu se specifickým URL obsahující informace, které chceme zobrazit v mapové aplikaci. Tento přístup má však několik nevýhod. Jedním problémem je malá možnost konfigurace map. Externí aplikace umí často zobrazit jen jeden bod nebo naplánovat cestu mezi dvěma body. Dalším problémem je samotný fakt, že uživatel je přesměrován do externí aplikace a to může odvést jeho pozornost od naší aplikace. Naopak vestavěné mapy můžeme umístit přímo do naší aplikace a pomocí mapových rozhraní máme možnost jejich široké konfigurace. Můžeme např. přepínat mezi nočním a denním režimem, přepnout na satelitní mapu a především můžeme vykreslit libovolný počet bodů na mapě. Pro naši aplikaci je tedy výhodné, pokud zobrazíme obchody spolu s naší pozicí na mapě, která bude uvnitř naší aplikace. Samotnou navigaci k prodejně ovšem provedeme pomocí externí aplikace, která má již navigaci mezi dvěma body implementovanou. Co se týče dostupnosti jednotlivých mapových technologií na jednotlivých platformách, situace je následující. Na Androidu se nejčastěji používají Google Maps. Ty jsou předinstalované jako aplikace na téměř všech Android zařízeních. Mapy můžeme používat pomocí rozhraní, které je dostupné pomocí platformy Google Play Services. Tato platforma je také dostupná na téměř všech telefonech a stačí ji přilinkovat do naší aplikace. Poté máme Google Mapy dostupné jako komponentu v naší aplikaci. Na stránkách 28
s dokumentací k Xamarinu [22] je detailně popsané, jak používat Google Maps na platformě Xamarin.Android. Popis zahrnuje například získání unikátního klíče pro fungování map, který se získá registrací na Googlu. Na serveru Android Central [23] jsou vypsané alternativy ke Google Maps, mezi něž patří např. HERE mapy s vlastním SDK pro Android. Avšak uživatelé Androidu jsou nejvíce zvyklí na Google Maps a díky jejich velké integraci do systému nemá smysl uvažovat nad alternativou. Na ios se až do roku 2012 používaly výhradně Google Maps. S příchodem ios 6 ovšem Apple představil vlastní technologii Apple Maps. Na tu se zpočátku snesla vlna kritiky kvůli nepřesnostem, pomalé odezvě nebo špatné navigaci. Tyto problémy však již nejsou v novějších verzích tak časté a Apple Maps jsou plnohodnotnou alternativou k mapám od Googlu. Výhodou Apple Maps je především fakt, jsou dostupné pomocí knihovny Map Kit, která je přímo součástí systému. Navíc Apple mapy jsou předinstalované na nových zařízeních a uživatelé jsou na ně více zvyklí. Z tohoto důvodu a kvůli lepší integraci do systému jsme se rozhodli na ios použít mapy přímo od Applu. Při použití map na Windows Phone 8.1 jsou mapy dostupné pomocí komponenty Map Control, která odpovídá Bing mapám. Ty jsou zabudované v samotném SDK pro Windows Phone 8.1. Je zde i možnost použít např. Google mapy, které se ovšem musí používat přes komponentu prohlížeče a kód na konfiguraci map psát v JavaScriptu. Větší smysl dává tedy použít nativní komponentu Map Control. Tato komponenta je jednou z komponent, které nejsou dostupné na desktopových Windows 8.1, proto je budeme implementovat pouze ve verzi pro Windows Phone 8.1. Na každé platformě jsme tedy zvolili nativní mapy. Problém je, že rozhraní těchto map jsou tak rozdílné, že nelze jednoduše vytvořit abstrakci, která zastřeší celkovou práci smapami. Pokud budeme chtít tedy na mapě zobrazit kolekci několika obchodů, pak si budeme muset napsat vlastní mechanismus, který se bude starat o zobrazování těchto bodů na každé platformě. To bude odpovídat implementaci Binderu popsaném v kapitole 2.6 o MVVM. 29
2.10 Návrh implementace serverové části Stěžejní funkcionalitou aplikace je komunikace se serverovou částí. Musíme vymyslet a naimplementovat způsob, jakým bude serverová část předávat data mobilnímu klientu. V této kapitole bude nejprve popsána architektura existujícího webového projektu a bude popsán způsob, jakým začleníme tuto část do existující architektury projektu. Následně vybereme technologii, pomocí které budeme novou část projektu implementovat. Samotná implementace většiny serverové části však bude ponechána na jiného člena týmu a nebude součástí odevzdaného řešení. 2.10.1 Začlenění do projektu Matylda Nejprve stručně popíšeme architekturu původního webového projektu, která se od odevzdání projektu téměř nezměnila a je zobrazena na následujícím diagramu. Obrázek 12: Architektura systému Matylda Architektura se dělí na několik vrstev, přičemž každá vrstva může komunikovat s vrstvami pod sebou, jak znázorňují šipky. Nejnižší vrstva obsahuje relační databázi MS SQL a NoSQL databázi Solr. Nad databází je vrstva Domain zajišťující mapování databázových entit z relační databáze do doménových modelů. Podobně SolrLib zajišťuje komunikaci s databázi Solr. Nad těmito vrstvami je postavená 30