Studentská tvůrčí a odborná činnost STOČ Petr Čápek

Transkript

1 Studentská tvůrčí a odborná činnost STOČ 2013 Návrh a implementace multiplatformní aplikace s využitím technologie Mono pro platformy ios, Windows Phone a Android Petr Čápek Fakulta aplikované informatiky Univerzity Tomáše Bati ve Zlíně, Nad Stráněmi 4511, Zlín 25. dubna 2013 FAI UTB ve Zlíně

2 Klíčová slova: ios, Android, Windows Phone, Mono,.NET, WCF, DI, IoC, MVVM Anotace: Cílem práce je návrh a implementace multiplatformní aplikace v jazyce C# s využitím technologie Mono. Práce se také zabývá využitím moderních metod tvorby aplikací, jako jsou architektonický vzor Model View ViewModel (MVVM), návrhový vzor Dependency injection (DI) a technika Inversion of Control (IoC). Práce bude obsahovat ukázkovou aplikaci s maximálním využitím sdílení kódu a prostředků napříč platformami. A bude umožňovat plánování osobních rozvrhů studentů Fakulty aplikované informatiky Univerzity Tomáše Bati ve Zlíně (UTB). Dále bude zobrazovat informace o vyučujících a vizualizovat polohu místnosti pro výuku na mapách budovy UTB. Aplikace bude využívat webovou službu vytvořenou pomocí nástrojů Windows Communication Foundation (WCF), která bude napojena na webové služby systému portal.utb.cz a další informační zdroje. 2

3 Obsah 1 Teoretická část Architektura MVVM Návrhový vzor DI Technika IoC Mono MonoTouch a MonoDroid Praktická část Struktura projektu Serverová část CORE část GUI část WP.GUI DROID.GUI IOS.GUI Závěr Literatura

4 1 Teoretická část 1.1 Architektura MVVM MVVM (Model View ViewModel) je architektonický vzor pro tvorbu aplikace. Původně vznikl z dílny Microsoftu jako rozšíření architektonického vzoru MVC (Model View Controller). Klasický model MVC totiž neposkytoval tak striktní oddělení mezi View a Controller. [1] Obrázek 1 MVC architektura [2] Aby se mohla práce na rozsáhlejších projektech lépe rozdělit, byl vytvořen architektonický vzor MVVM, který nabízí striktní oddělení mezi View a Controllerem (označovaným jako ViewModel). Obrázek 2 MVVM architektura Tato architektura byla navržena pro vývoj aplikací v rámci WPF. Pomocí jazyka XAML se definuje View (uživatelské rozhraní). Poté se pomocí Bindování a Commandů vytvoří vazba mezi View a ViewModelem. ViewModel slouží v tomto případě jako převaděč, 4

5 který transformuje data přímo z modelu do objektů, které jsou jednoduše ovladatelné a jednoduše zobrazitelné v rámci View. Tato architektura nám také velice výrazně usnadňuje testování aplikace. Skupina vývojářů zabývající se tvorbou View si může vytvořit testovací ViewModel (mock objekt) a testovat si na něm, zatímco vývojáři zabývající se tvorbou ViewModelu můžou využít klasické Unit testy pro testování. 1.2 Návrhový vzor DI Návrhový vzor DI (Dependency Injection) je založen na tom, že z kódu odstraňuje pevně vytvořené závislosti a vytváří možnost tyto závislosti měnit při kompilaci nebo za chodu programu. Tato technika je velmi důležitá protože odstraněním pevně daným vazeb na závislostech nám velmi usnadňuje testování systému. Při vývoji rovněž můžeme nahradit reálné závislosti nahradit imaginárními a ověřit tak funkčnost systému jako celku. Např. máme systém, který při vzniku nějaké události rozešle všem uživatelům SMS. S využitím DI vytvoříme dva druhy služby, která bude řešit posílání SMS. Jedna služba bude reálna a bude skutečně posílat SMS a druhá bude pouze vypisovat informace do konzole. Při vývoji a testování budeme používat druhou službu, ale ve finálním sestavení použijeme službu reálnou. [3] 5 Obrázek 3 Dependency Injection Dependenci Injection se nejčastěji vyskytuje ve dvou provedeních: Constructor injection závislosti se předávají v konstruktoru dané třídy. Závislosti třídy jsou jasně dané a třida nemůže vzniknout bez daným závislostí. Property injection závislosti se předávají prostřednictvím vlastností dané třídy. Třída je vytvořena bez závislostí a ty jsou dodány až později prostřednictvím setterů. Mezi hlavní výhody použití Dependency Injection patří: Separace kódu Možnost změny implementace za chodu nebo při překladu Vyznačení závislostí dané třidy Lepší možnosti testování Tvorba modulárních systémů Možnost přeložit kód i bez implementovaných závislostí

6 1.3 Technika IoC IoC (Inversion of Control) je technika umožňující sestavení objektů z různých částí podle definovaných pravidel buďto při kompilaci nebo za chodu programu. IoC úzce souvisí s DI a využívá jej. [4] Obrázek 4 IoC Hlavní částí IoC je tzv. IoC kontejner. Tento kontejner nám z dodaných součástí vytváří instance tříd podle daných pravidel. Pokročilé kontejnery umožnují využít i tvz. Intercept, což je vsunutí vlastního kódu před nebo po volané metodě. Princip techniky IoC spočívá v tom, že vytvoříme instanci IoC kontejneru. Do kontejneru poté zaregistrujeme dílčí součásti. Registrace probíhá většinou tak, že k interface registrujeme třídu, která jej implementuje. Poté do kontejneru registrujeme hlavní části, které chceme, aby nám kontejner zkompletoval. U každé registrace si můžeme nastavit životnost objektu. Základní životnosti objektů jsou: Singleton při požadavku o vydání instance typu označeného jako singleton se vytváří vždy pouze jedna instance daného objektu a ta je platná po celou dobu chodu programu. MultiInstance při požadavku o vydání instance typu označeného jako multiinstance je při každé žádosti vydána nová instance daného typu. PerRequest využívá se v rámci WCF. Pro každé nové spojení je vytvořena instance daného typu s životností singleton a při každé žádosti o vydání instance v rámci požadavku se vydává tato stejná instance. PerThread pro každé vlákno je vytvořena nová instance daného typu. Při žádosti o vydání instance v rámci vlákna se vydává vždy stejná instance. Scoped speciální případ. Umožnuje vymezení sekce. Kdykoli se v této sekci vyskytne požadavek na instanci, v rámci sekce je vždy vracena stejná instance. Po registraci všech částí můžeme vyslat požadavek na kontejner, aby nám vydal instanci určitého typu. Kontejner poté vrátí instanci daného s inicializovanými závislostmi. Kontejnery většinou podporují tzv. Lazy Initialization, což znamená, že až při prvním požadavku na daný typ je od tohoto typu vytvořena instance. To umožňuje šetřit paměť a nezatěžuje tolik CPU. Programátor si většinou IoC kontejner neimplementuje sám, ale využívá již kontejner implementovaný od třetí strany. Na trhu jsou dostupné různé implementace IoC kontejnerů pro různé platformy s různými možnostmi. 6

7 Mezi nejznámější z nich (v rámci platformy.net) patří: Unity Ninject Castle Windsor Caliburn MEF Spring.NET V rámci aplikace je použitý IoC kontejner TinyIoC [5], který je kompatibilní se všemi platformami použitými v rámci projektu. 1.4 Mono Mono je open source projekt, který má za cíl vytvořit sadu nástrojů kompatibilních s prostředím.net, které splňují ECMA standart. Mono může fungovat na platformách jako Linux, UNIX, FreeBSD, Mac OS X, Solaris. [6] Aktuální verze Mono je z dubna roku Tato verze částečně poskytuje API z.net Frameworku 2.0, 3.0, 4.0. Cílem projektu Mono je přinést plnou podporu.net 4.0 na všechny platformy kromě některých části jako WPF a WF MonoTouch a MonoDroid MonoTouch a MonoDoid jsou implementace mono od firmy Xamarin pro platformy MacOS a Android. Na rozdíl od Mono jsou tyto implementace komerční a placené. [7] Obrázek 5 MonoTouch a MonoDroid [8] Tyto technologie umožnují pomocí jednoho jazyku (C#) definovat aplikační logiku a tento kód poté sdílet napřič platformami. Nevyužívá se zde nějaký druh universálního GUI, 7

8 ale je potřeba definovat grafické rozhraní pro každou platformu zvlášť. Díky tomu je možné získat aplikace, které vypadají a chovají se zcela nativně v rámci dané platformy. Z hlediska jednotlivých platforem nabízí mono následující: MonoTouch určeno pro MacOS platformu. Obsahuje.NET wrapery pro volání GUI API Cocoa. Taktéž je možné využít již existující kód napsaný v ObjectiveC pomocí binding. Pro kompilaci je však třeba mít počítač vybavený operačním systémem MacOs. Při překladu se využíva AOT kompilace. MonoDroid určeno pro Android platformu. Obsahuje wrapery jak pro nativní android API tak wrapery pro JAVA knihovny. Pomocí binding je možné použít existující JAVA knihovny. Pro kompilaci se využívá JIT kompilace. 8

9 2 Praktická část 2.1 Struktura projektu Projekt byl navržen jako klient server architektura. Serverová část se stará o externí zdroje a pomocí vlastní webové služby poskytuje data dále do klientské části. Klientská část se dělí na 2 úrovně. První úroveň je označená jako CORE a obsahuje sdílený kód mezi platformami. Druhá část se označuje jako GUI a obsahuje implementace uživatelského rozhraní pro danou platformu + implementaci platformě závislých komponent. 2.2 Serverová část 9 Obrázek 6 Struktura projektu Serverová část projektu je založena na technologii WCF (Windows Comunication Foundation). Ta je hostována v rámci IIS na Windows Server Server je virtualizovaný a je umístěn na univerzitní síti pro lepší datovou propustnost a snížení odezvy. Server slouží ke sjednocení zdrojů a poskytuje nad nimi jednotný interface pro jednoduchou konzumaci obsahu. Server využívá následujících externích služeb: Stag services webové služby nad školním portálem STAG. Služba poskytuje informace pomocí protokolu SOAP nebo REST. Aplikace využívá těchto služeb pro získání rozvrhů studentů a vyučujících. Stag webové stránky webová nástavba nad systémem STAG. Protože k získání některých informací neexistují webové služby, bylo třeba tyto informace získat z webových stránek. Stránky se standardně chovají tak, že při spojení vytvoří cookies a mezi některými odkazy vytváří síť přesměrování. Tuto vlastnost bylo třeba obejít pro získání daných informací. Menza webové stránky webové stránky školní jídelny Menza. Z této stránky jsou čerpány informace o dostupných jídlech v jednotlivých jídelnách. Stránka je chráněna nepodepsaným certifikátem SLL a dále obsahuje další bezpečnostní prvky jako např. random key pro přihlášení. Tyto prvky bylo třeba obejít pro získání informací o jídlech a zůstatku peněz na účtu.

10 Server z těchto dílčích služeb získává podstatné informace a ty vystavuje dále prostřednictvím protokolu SOAP (výstupního jazyka XML). Tato služba je pak přímo konzumována samotnou aplikací na telefonu. Jelikož jsem byl požádán, jestli bych neposkytnul webové služby i pro další projekty v rámci univerzity, bylo provedeno vystavení služeb pomocí protokolu REST s jazykem JSON pro snadnou konzumaci obsahu v rámci JavaScriptu. 2.3 CORE část Tato část obsahuje aplikační logiku, která je sdílena přes všechny platformy. Tuto část tvoří ve skutečnosti jeden projekt, který je naklonován do 3 projektů. Každý z těchto 3 projektů obsahuje stejný kód. Projekty jsou vytvořeny pouze kvůli překladači, protože standartě překladač neumí přeložit jeden projekt pro tyto 3 platformy 1. Obrázek 7 Detail struktury CORE části 1 Tento problém řeší PCL (Portable Class Library), což je univerzální.net knihovna konzumovatelná různými platformami. Společnost Xamarin připravuje tuto možnost, která je zatím ve fázi vývoje. 10

11 Core část obsahuje hlavně ViewModely. Každý ViewModel oznamuje své závislosti jako Interface v konstruktoru (Dependency Injection). Jako výstup projektu CORE můžeme považovat abstraktní třídu LocaltorBase (implementace návrhového vzoru VMLocator). Jádrem této třidy je IoC kontejner (implementace TinyIoC). V konstruktoru třídy LocatorBase se volá metoda Install, která registruje platformě nezávislé součásti do IoC kontejneru, a po té provede registraci samotných ViewModelů. Metoda také volá abstraktní metodu CustomInstaller, kterou je třeba přetížit v odvozených třídách a provést registraci platformě závislých součástí. Princip volání CustomInstaller se nazývá NVI (nonvirtual Interface). Třída poté vystavuje jednotlivé ViewModely prostřednictvím read-only vlastností. Při získávání ViewModelů skrze vlastnosti se uplatňuje tzv. Lazy Initialization, což velmi výrazně šetří jak paměťové nároky aplikace, tak dobu jejího startu, protože není třeba vytvářet celý objektový strom. 2.4 GUI část GUI část projektu je zaměřena na implementaci uživatelského rozhraní pro dané platformy. GUI část projektu je rozdělaná do 3 podprojektů. Každý z těchto projektů dědí od třídy LocatorBase a overriduje metodu CustomInstaller tak, aby provedl registraci platformě závislých tříd. Každý dílčí podprojekt obsahuje referenci na odpovídající CORE projekt WP.GUI Tento projekt je cílený pro platformu Windows Phone. Podporuje zařízení s operačním systémem Windows Phone 7.1 a vyšší. Projekt obsahuje definici GUI pomocí jazyka XAML. Jazyk XAML podporuje přímo bindování a Commnandy. Navíc většina grafických komponent podporuje také interface INotifyPropertyChange (interface pro aktualizaci dat), takže implementace GUI pro tuto platformu byla velice jednoduchá. Jediný problém byl v podobě aplikačního panelu, který nepodporuje data binding, tudíž se nemohlo plně využít MVVM architektury (konkrétně plné odstranění code behind ) DROID.GUI Tento projekt je cílený pro platformu android. Podporuje tablety a telefony s androidem a vyšší. Projekt obsahuje definici GUI pomocí axml, což je Androidí rozšíření jazyka XML, a pomocí code behind. Princip tvorby GUI je takový, že se definuje layout a grafické komponenty v axml souboru a poté je tento soubor v kódu načten a jsou doplněna zobrazovaná data a obslužné rutiny pro události jednotlivých komponent. Výhodou Xamarinu je, že podporuje tvorbu axml pomocí grafického návrháře pro GUI přímo ve Visual Studiu. Hlavní problém platformy Adnroid je předávání parametrů v rámci navigace mezi stránkami, potřeba manuálně udržovat referenci na kontext aktuálního okna a také nemožnost provádět některé operace s uživatelským rozhraním v kódu (některé specifické operace je možné provádět jenom v rámci axml souborů) IOS.GUI Tento projekt je cílený na platformu ios. Podporuje zařízení iphone a ipad. Standardně se při tvorbě aplikací na tuto platformu používá vývojové prostředí xcode a pro návrh grafického prostředí se využívají xib soubory (modifikované xml). Xamarin dodává své vlastní vývojové prostředí Xamarin studion, které je možné využít při torbě aplikací a také obsahuje grafický návrhář GUI (zprostředkovaného pomocí xcode). Xamarin však také umožnuje využít pro tvorbu aplikací na tuto platformu plug-in do Visual Studia. Takto je 11

12 možné napsat kompletní aplikaci pro ios v rámci Visual Studia (bez podpory grafického návrháře pro GUI) a využít jiný počítač (na kterém je nainstalován operační systém MacOS a Xamarin.iOS) jako build hosta přes síť. V rámci práce byla využita tato možnost. Jako hlavní problém platformy ios bych označil relativně složité získávání licencí pro debuggování aplikací na reálných zařízeních a netypické API Cocoa. 12

13 3 Závěr Práce obsahuje návrh a implementaci multiplatformní aplikace v jazyce C# s využitím technologie Mono. Projekt byl implementován jako klient server architektura. Serverová část agreguje informace z mnoha zdrojů a pomocí technologie WCF tyto data vystavuje prostřednictvím webových služeb jak pro vlastní projekt, tak pro další nezávislé projekty. Klientská část byla rozdělena do dvou vrstev. První vrstva označovaná jako CORE obsahuje sdílenou část kódu pro všechny platformy. Druhá vrstva označovaná jako GUI obsahuje implementace platformě závislých částí projektu a také obsahuje implementaci uživatelského rozhraní pro danou platformu. Při implementaci řešení byl kladen důraz také na moderní návrhové vzory a technologie. Práce obsahuje implementaci návrhového vzoru MVVM (Model View ModelView), návrhového vzoru DI (Dependency Injection), techniky IoC (Inversion of Control) s využitím IoC kontejneru TinyIoC. Výstupem práce byly získány aplikace pro platformy Windows Phone, iphone, ipad a Adndroid. Z toho se již podařilo aplikaci pro platformu Windows Phone projít certifikačním procesem a umístit ji na Windows Store. Ostatní aplikace se již připravují na proces certifikace. Windows Phone iphone Android Obrázek 8 Srovnání implementace GUI pro jednotlivé platformy 13

14 4 Literatura [1] Microsoft, The Model-View-ViewModel Design Pattern, [Online]. Available: [2] MVC Process, [Online]. Available: [3] Dependency Injection, [Online]. Available: [4] Microsoft, IOC Containers and MVVM, [Online]. Available: [5] TinyIoC, [Online]. Available: [6] Mono, [Online]. Available: [7] Xamarin, MonoTouch&MonoDroid dokumentace, [Online]. Available: [8] Xamarin, Sdílení kódu, [Online]. Available: 14