UNICORN COLLEGE. Katedra informačních technologií

Transkript

1 UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Návrh architektury Windows 10 UWP aplikace znovupoužitelný pro ASP.NET MVC aplikaci Autor BP: Tomáš Sieger Vedoucí BP: Ing. David Hartman Ph.D Praha

2

3

4 Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Návrh architektury Windows 10 UWP aplikace znovupoužitelný pro ASP.NET MVC aplikaci 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. dne (Tomáš Sieger)

5 Poděkování Děkuji vedoucímu bakalářské práce Ing. Davidu Hartmanovi Ph.D. za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

6 Návrh architektury Windows 10 UWP aplikace znovupoužitelný pro ASP.NET MVC aplikaci Designing Windows 10 UWP app architecture reusable for ASP.NET application 6

7 Abstrakt Předmětem této bakalářské práce je analýza, návrh a ověření vhodné architektury Windows 10 Universal Windows Platform (UWP) aplikace, která umožní co největší znovupoužitelnost kódu při vývoji webové ASP.NET MVC aplikace, za předpokladu, že obě nabízejí stejné funkčnosti a využívají společný datový zdroj hostovaný v cloudu Microsoft Azure. Stěžejní část práce je zaměřena na podrobný rozbor aplikační platformy Windows 10 UWP Apps a architektonického vzoru MVVM. Jeho aplikací lze docílit důsledného oddělení prezentační vrstvy aplikace od zbývajících částí tak, aby jejich výsledný kód byl přenositelný i na další platformy. Práce se proto především velmi detailně věnuje konkrétním metodám, rozhraním a postupům, které je při vývoji aplikace pomocí MVVM vhodné použít a dodržet. Všechna teoretická východiska jsou následně ověřena v praktické části práce, která má tři části. Nejprve je vytvořen samotný datový backend v MS Azure. Na něm je postavena prototypová UWP aplikace, která aplikuje pravidla a prvky vzoru MVVM. Ve třetí části jsou její logická a datová vrstva napojeny na webovou MVC aplikaci a ověřena celková funkčnost. Závěr práce shrnuje všechny poznatky získané během tvorby návrhu, vyhodnocuje průběh jednotlivých částí realizace a hledá možnosti, kde by se dala navržená architektura prakticky využít. Klíčová slova: Windows 10, UWP aplikace, Universal Windows Platform, ASP.NET, MVC, univerzální aplikace, MVVM, sdílení kódu, přenositelnost kódu, Microsoft Azure. 7

8 Abstract The objective of this bachelor thesis is the analysis, design and verification of suitable Windows 10 Universal Windows Platform (UWP) Apps architecture, which allows the greatest code reusability possible for developing ASP.NET MVC Web application, provided that both offer the same features, and both use a common data source hosted in the cloud Microsoft Azure. The main part is focused on a detailed description of Windows 10 UWP Apps application model and the software architecture MVVM pattern. Using this pattern facilitates full separation of the application s GUI layer from the rest of application so the resulting code can be made compatible with the other app models. For that reason there is a very thorough analysis of the specific methods, interfaces and procedures, which are important to use and follow when developing a MVVM compatible application. All theoretical conclusions are verified in the practical part of the work, which is separated into three sections. First is about establishing the application s data backend in the MS Azure. Second deals with building the UWP application using the aforementioned MVVM pattern. And the third connects the loosely coupled logic and data layers of the UWP application to the Web MVC application and checks the overall functionality. The conclusion summarizes all the knowledge acquired in the course of this work, evaluates the process of implementation, and examines the possibilities of using the offered solution in the real world environment. Keywords: Windows 10, UWP apps, Universal Windows Platform, ASP.NET, MVC, MVVM, universal apps, MVVM, code sharing, code reusability, Microsoft Azure. 8

9 Obsah Úvod Operační systém Windows Problematický předchůdce Nový začátek Programování pro Windows Framework.NET zblízka Vývojářské nástroje Přenositelnost kódu UWP Aplikace Universal Windows Platform XAML Layout prvky Inicializace uživatelského prostředí Práce s daty Architektura MVVM Data binding Value Converter Observable objekty Commandy (Příkazy) v MVVM Návrhový vzor Dependency Injection Návrhový vzor Factory (Továrna) Service Locator IoC kontejner Služby (Services) v MVVM MVVM frameworky

10 5 Architektura MVC Http protokol ASP.NET MVC Routování View Engine Seznámení s návrhem Ověřovací aplikace Solution aplikace Použité technologie Backend aplikace DTO třídy Swagger anotace REST Client Windows 10 UWP Aplikace Architektura aplikace Vzhled aplikace Navigace Předávání parametrů Validace ASP.NET MVC aplikace Architektura aplikace Převod UWP prvků Konečná podoba aplikace Závěr Conclusion Seznam použitých zdrojů Seznam obrázků Seznam příloh

11 Úvod Prostředí UWP aplikací koncepčně vychází ze svých předchůdců, moderních, resp. univerzálních, aplikací pro Windows 8. Nabízí plně adaptivní design schopný se dynamicky přizpůsobit různým druhům cílových zařízení, plnohodnotné dotekové ovládání a schopnost přímo využívat celou řadu periférií, standardně dostupných v mobilních telefonech a tabletech. Zároveň ale naštěstí opouští některá striktní omezení na filozofii ovládání a chování, které značně omezovalo využití Windows 8 aplikací na desktopu a představovalo jeden z důvodů, proč se systém i samotné aplikace setkaly s odmítavým přijetím. Největším problémem UWP aplikací je jejich nulová zpětná kompatibilita s předchozími operačními systémy, a to především se stále bezkonkurenčně nejpoužívanějšími Windows 7. Čísla z prvního roku prodeje Windows 10 jsou sice optimistická, ale to se týká jen desktopu, kde uživatelé nemají velké důvody na UWP aplikace přecházet. V mobilním segmentu, kde by se dal předpokládat největší zájem, zůstává situace kritická. Poslední známá data dokonce mluví o poklesu podílu prodeje telefonů se systémem Windows 10 pod jedno procento. Nové vedení společnosti navíc mobilní Windows 10 nebere jako prioritu a propagaci telefonů omezuje na naprosté minimum, takže se dokonce objevují spekulace, že se Microsoft chystá mobilní segment úplně opustit. [1] Cíl práce Vše výše uvedené znamená, že většina vývojářů vlastně ani nemá důvod UWP aplikace vytvářet, a pokud zákazník požaduje řešení v podobě mobilní dotykové aplikace, raději se rozhodne pro technologie konkurence. Tak se bohužel uzavírá začarovaný kruh v podobě nedostatku atraktivních aplikací, který nemotivuje uživatele k přechodu na nový systém, jehož malá rozšířenost zas odrazuje vývojáře, a tak stále dokola. Hlavním cílem této práce je pokusit se tento kruh rozetnout a přijít z řešením, které by učinilo vývoj UWP aplikací zajímavým i v současné situaci. To spočívá v nabídnutí plnohodnotné náhrady, kterou je možné použít všude tam, kde ještě není k dispozici systém Windows 10. Vývojář tak může na jednu stranu nabídnout klientovi plnohodnotnou UWP aplikaci, ale ten se zas může svobodně rozhodnout, na jakém procentu zařízení se mu její nasazení vyplatí; a kde se spokojí třeba s hůře vypadající a nedotykovou, ale přesto funkčně plně odpovídající variantou. Klíčové je, že data a logika, nad kterými budou obě varianty postavené, zůstanou zcela totožné, lišit se bude jen vlastní uživatelské rozhraní. 11

12 Samozřejmě, aby takové řešení bylo průchodné, musí představovat co nejméně práce navíc. Teoretická část práce je proto věnována především rozboru softwarové architektury UWP aplikace a využití jejích možností k tomu, aby maximální část kódu aplikace zůstala platformově nezávislá, tudíž znovupoužitelná i pro náhradní variantu. Obrázek 1: schéma navrženého řešení Zdroj: Vlastní zpracování Základní schéma navrženého řešení je na Obrázku 1. Východiskem je důsledná aplikace návrhového vzoru MVVM (Model-View-ViewModel), který popisuje postupy a metody, jak uživatelské rozhraní aplikace rozdělit na vlastní grafický návrh s jednotlivými prvky uživatelského prostředí (View), a řídící logiku (ViewModel). ViewModel poté přebírá zodpovědnost za veškerou interakční logiku grafického prostředí aplikace a zprostředkovává výměnu dat mezi uživatelem a dalšími komponentami. Využitím těchto pravidel lze výrazně redukovat přímé závislosti mezi grafickým prostředím a ViewModelem, jehož kód lze poté sdílet i s náhradní aplikací; tou je v tomto případě standardní ASP.NET MVC webová aplikace dostupná z libovolného webového prohlížeče. Ta ve výsledku funguje v podstatě jako webové rozhraní původní UWP aplikace. 12

13 Jako perzistentní vrstva je použita MS SQL databáze hostovaná v cloudu Microsoft Azure. Tam je zároveň umístěna i jednoduchá Azure APP API aplikace fungující jako REST API backend, ze kterého obě řešení čerpají svá data. Struktura práce Text práce je rozdělen do devíti kapitol. První kapitola se věnuje seznámení se systémem Windows 10 a přibližuje důvody, které Microsoft přiměly k jeho urychlenému vydání. Další část je zaměřena na programování v systémech Windows obecně, zejména pak na rozbor technologie.net Framework a možnosti, které jeho použití otevírá pro přenositelnost již jednou napsaného kódu na další projekty. Stěžejní kapitoly se zaměřují na podrobný rozbor aplikační platformy Windows 10 UWP Apps a architektonického vzoru MVVM. Začátek je věnován samotným UWP aplikacím, jejich klíčovým vlastnostem a nejdůležitějším prvkům, jejichž znalost je nezbytná pro vývoj. Poté následuje detailní analýza samotného návrhového vzoru MVVM a jeho základních technik, jako jsou datové vazby a commandy. Závěrečným prvkem analýzy je seznámení s principy Dependency Injection a Inversion Of Control, kterými lze dále rozvolnit vazby mezi jednotlivými vrstvami MVVM aplikace a získat tzv. loosely coupled architekturu. Každá část přitom obsahuje jak teoretický základ, tak praktickou implementaci, a to včetně ukázkového kódu. Závěr teoretické části je věnován návrhovému vzoru MVC a na něm postavené aplikační platformě ASP.NET MVC. Ta je sama o sobě tak komplexní, že by ji mohla být věnována samostatná práce, proto se text zaměřuje pouze na klíčové rozdíly oproti MVVM, resp. UWP aplikaci. Všechna teoretická východiska výsledného návrhu jsou ověřena v praktické části práce, která má tři části. Nejprve je vytvořen samotný datový backend v MS Azure. Na něm je postavena prototypová UWP aplikace, která aplikuje pravidla a prvky vzoru MVVM. Ve třetí části jsou datová a logická vrstva UWP aplikace napojeny na webovou MVC aplikaci a ověřena celková funkčnost. Závěr práce shrnuje všechny poznatky získané během tvorby návrhu, vyhodnocuje průběh jednotlivých částí realizace a hledá možnosti, kde by se dala navržená architektura prakticky využít. 13

14 1 Operační systém Windows 10 Windows 10 jsou nový operační systém společnosti Microsoft, který byl uveden na trh v červenci roku Jedná se o prozatímní vyvrcholení dlouhodobé snahy společnosti nabídnout jeden univerzální operační systém pro všechna zařízení schopná provozovat Windows; od tradičních PC, přes tablety a mobilní telefony, až po nové typy zařízení, jako jsou herní konzole řady Xbox, nebo produkty spadající do rodiny tzv. internetu věcí (Internet Of Things). Součástí systému je také nové aplikační prostředí Universal Windows Platform (UWP), které umožňuje jednotný vývoj aplikací pro Windows 10 bez ohledu na cílovou platformu. Všechna zařízení rodiny Windows 10 nyní sdílejí jedno společné jádro, se kterým jsou aplikace UWP schopné přímo komunikovat a volat jeho systémové prostředky. [2, s. 2-5] V praxi to znamená, že při vývoji aplikace již není nutné myslet na to, pro jaký typ zařízení je určena, pouze při volání některých platformově specifických funkčností je potřeba ověřit, zda zařízení, na kterém aplikace právě běží, tuto funkčnost podporuje. Další důležité novinky systému, se kterými je možné pomocí UWP pracovat, jsou aktivní dlaždice, notifikační centrum a hlasová asistentka Cortana, která ale zatím není dostupná v české mutaci. Notifikační centrum se nechalo inspirovat mobilními systémy a jeho cílem je do jednoho místa systému sjednotit všechny důležité informace, které jednotlivé aplikace i systém samotný potřebují předat uživatelům. UWP aplikace jsou schopné velmi jednoduše tyto notifikace generovat, a to přímo voláním příslušného API. Trochu jinou funkci mají aktivní dlaždice, které připomínají reklamní banner aplikace snažící se přimět uživatele k jejímu spuštění. S Windows 10 přichází významná změna v tom, že už netlačí dlaždice tolik dopředu a uživatel je dokonce může z nabídky Start úplně odstranit. Zároveň jsou ale mnohem lépe integrované do systému, takže např. reagují na pravý klik nebo je možné je přesouvat myší. 1.1 Problematický předchůdce Windows 10 jsou třetím pokusem Microsoftu přijít se systémem, který vhodně skloubí požadavky tradičních desktopových uživatelů s požadavky uživatelů moderních dotekových zařízení, jako jsou tablety a mobily. Koncepčně proto v mnoha ohledech navazuje na systém Win- 14

15 dows 8, který byl uveden na trh v roce Ten poprvé představil nové plně dotykové uživatelské prostředí, tehdy nazývané Metro, a přišel s řadou nových ovládacích prvků a změnou uživatelské filozofie, která šla proti léta zavedeným zvyklostem ovládání Windows. Bohužel se ukázalo, že šlo o systém přinejmenším neodladěný a šitý horkou jehlou, kde sice všechno fungovalo, ale pocit uživatelské přívětivosti a všeobecné promyšlenosti a provázanosti chyběl. Problém navíc umocňovalo nepovedené a místy až arogantní PR společnosti, které naprosto odmítalo připustit jakékoli připomínky ze strany uživatelů. Kolem systému se díky tomu postupně vytvořila značně negativní atmosféra, která velmi připomínala reakci uživatelů na uvedení Windows Vista o několik let dříve. Pravdou je, že Windows 8 byly do značné míry panickou reakcí. Vedení Microsoftu si dlouho odmítalo připustit, že nová kategorie mobilních dotekových zařízení, která razantně vstoupila na trh roku 2007 s uvedením prvního telefonu Apple iphone, představuje ohrožení jeho dominantního postavení ve světě počítačů. Jenže relativně drahé a exkluzivní telefony brzy následovaly tablety a po nich i celá lavina různých čínských noname a OEM výrobků se systémem Android. Dotykový mobil nebo tablet si náhle mohl dovolit doslova každý, takže tržní prostředí se během několika let zcela změnilo. Microsoft sice stále dominoval svému tradičnímu segmentu, ale vedle něj tu náhle začal prudce růst i segment nový, a brzy dokonce mnohokrát větší. Řada odborníků začala mluvit o nástupu tzv. postpc období [3] a zejména mladší generace náhle začala zjišťovat, že PC vlastně vůbec nepotřebuje. Pro budoucnost společnosti to představovalo hrozbu, na kterou musela reagovat, takže prohlásila mobilitu a dotykové ovládání za absolutní prioritu. Bohužel přitom zcela opomenula tradiční uživatele na desktopech, kteří se s novým směrováním odmítali smířit. Výsledkem, který měl uspokojit obě skupiny, byl právě Windows 8. Podivná kombinace tradičního a nového, kde část systému fungovala na novém jádru WinRT určeném pro moderní aplikace dotekových zařízení, zatímco druhá se držela jádra Win32 určeného pro klasické programy. Pod společnou slupkou se tak ocitly dva nepříliš kompatibilní systémy s velmi odlišnou filozofií ovládání a zaměřené na rozdílné typy uživatelů. Pokud by dokázal Microsoft obě části sladit, nemusel by to být problém. Jenže k tomu nedošlo. Aplikace pro desktop nebylo možné v dotekové části ani detekovat, shodné vlastnosti systému se v různých částech nastavovaly rozdílně a nové moderní aplikace nesmyslně nutily desktopové uživatele k práci v režimu celé obrazovky, i když ti byli po léta zvyklí využívat všech výhod multitaskingu a jednoduchého přepínání mezi okny. 15

16 Trvalo necelý rok od uvedení systému na trh, než Microsoft konečně akceptoval, že tentokrát ani jeho drtivá tržní síla nepostačí k tomu, aby nový systém prosadil. Následoval ještě pokus s uvedením systému Windows 8.1, který odstranil řadu nejvíce problematických omezení. Reputace systému už ale byla natolik poškozená, že ani to jeho většímu rozšíření výrazněji nepomohlo. 1.2 Nový začátek Microsoft kombinací mizerného PR a arogantního přístupu ztratil několik klíčových let, kdy ještě měl reálnou šanci výrazněji se prosadit i v mobilním segmentu. Namísto toho ale přišel opak a musel si začít pokládat otázku, co se stane se všemi momentálně naštvanými uživateli s klávesnicí a myší, co zatím stále používají Windows 7, ale přechod na Windows 8 odmítají. Vedení společnosti se proto rozhodlo k radikálním změnám. Z čela společnosti bylo postupně odvoláno několik kritizovaných top manažerů, včetně samotného CEO Stevea Balmera, a její přístup k uživatelům i médiím prodělal obrat. Windows 10 tak nejsou jen další systém v řadě, ale symbolický nový začátek a zároveň i velká omluva, která znovu vrací tradičního uživatele do středu zájmu. Zmizela vynucená celoobrazovková startovací obrazovka, kde byl desktop degradován jen do pozice jedné z dlaždic. Zmizela nemožnost spouštět dotekové aplikace v okně a snadno je vypnout nebo přizpůsobit jejich velikost. Zmizela nucená uniformovanost a grafická strohost. Také ovládací a správcovskou schizofrenii se podařilo potlačit na minimum. Některé kontrolní prvky sice zůstaly zdvojené a občas se stále stává, že z nabídky vyskočí menu, jehož font a použité ovládací prvky dávají najevo svůj odlišný původ. Pro většinu nastavení už ale není nutné přeskakovat z jedné podoby do druhé, takže to uživatele výrazněji neobtěžuje. Dotekové aplikace se povedlo mnohem hlouběji integrovat do prostředí desktopu a filozofie práce s nimi se z velké části přestala lišit od toho, na co jsou uživatelé zvyklí při práci s tradičními programy. Samozřejmě to neznamená, že je systém dokonalý. Mnoha pokročilejším uživatelům se příliš nelíbí množství různých sledovacích a cloudových funkcí nově přidaných do systému, které odesílají do Microsoftu značné množství nikde nedokumentovaných informací o chování a preferencích uživatele. Naštěstí je lze zatím vypnout. Podobně kontroverzně se jeví i nově povinný Windows Update, který navíc ani nelze běžným způsobem vypnout. 16

17 Microsoft sice toto rozhodnutí obhajuje snahou udržet uživatelův systém bezpečný a aktuální, pravým důvodem je ale zřejmě spíše snaha udržet si kontrolu na celým životním cyklem systému a jeho klíčovými komponenty. Toto je další novinka, protože vedení Microsoftu otevřeně prohlašuje, že Windows 10 nejsou jen jednou hotový a dokončený operační systém, ale služba, která se bude v pravidelných intervalech vylepšovat a aktualizovat. [4] Dokonce nechybí spekulace, že jde o poslední tradičně distribuovaný a prodávaný systém Windows vůbec. V každém případě je systém zatím úspěšný. Na březnové vývojářské konferenci Build 2016 Microsoft oznámil, že Windows 10 za necelý rok od uvedení už používá více jak 270 miliónů zařízení, což je o 145 % více, než za stejnou dobu dosáhly Windows 7. [5] Zbývá otázka, jak se k systému postaví velké firmy a především jejich administrátoři, kteří jsou většinou velmi opatrní a mnohde teprve nedávno dokončili přechod na Windows 7. Teprve pokud se podaří přesvědčit i je, může společnost naplnit svůj ambiciózní cíl a dosáhnout počtu biliónu aktivních zařízení s Windows 10 v příštích několika letech. 17

18 2 Programování pro Windows Existují v zásadě dva základní přístupy, jak pro Windows programovat. První je tradiční a systém jej nabízí už od počátku; spočívá v přímém volání funkcí jádra systému na nejnižší úrovni. Systém k tomu nabízí specializované Windows API, resp. celou jejich skupinu, která postupně narůstá, jak systém prochází časem. Nejznámější z nich je Win32api, které nabízí přímý přístup k funkcím typu diskové operace, paměťové operace, vykreslování oken a prvků uživatelského rozhraní, práce s grafikou a multimédii, bezpečnost, systémové služby a další. Podmínkou je znalost jazyka C/C++, hluboká orientace v principech samotného systému, trpělivost a pečlivost, protože programování na tak nízké úrovni znamená, že i pouhé zobrazení dialogového okna představuje napsání několika desítek řádek kódu a jakékoliv opomenutí pád systému. [6, s ] Přímé volání přenechává veškerou zodpovědnost na vývojáři a každou chybu tvrdě trestá. Hlavní výhodou je rychlost. Protože program je psán v nativním kódu systému, který se po kompilaci ihned převádí do strojového kódu procesoru, nabíhá okamžitě po spuštění a jednotlivé funkce API jsou volány přímo. Přímé volání dnes využívají především hry a sám Microsoft, který takto programuje své klíčové produkty řady Office a vývojářské nástroje. Jedná se ale o natolik odlišnou a rozsáhlou oblast, že se jí ve své práci už nebudu dále zabývat. Mnohem běžnějším a pro vývoj standardních aplikací doporučovaným přístupem je využití programovacího frameworku. Ten zařídí odstínění vývojáře od řešení problémů spolupráce se samotným systémem a provede za něj některé klíčové činnosti typu alokace paměti nebo garbage collection, takže se může plně soustředit jen na programování vlastní aplikace. Ve světě Windows se tento framework nazývá.net (dot net) a jeho první verze byla představena již roku [6, s ] Nejnázorněji se dá představit jako speciální vrstva složená z velkého množství vzájemně integrovaných komponent, která sedí nad operačním systémem a umožňuje snadno vyvíjet, spouštět a spravovat aplikace. Aktuálně poslední verze frameworku, představená současně s Windows 10, je verze.net 2015, jejíž složení je možné vidět na Obrázku 2. 18

19 Obrázek 2: Framework.NET 2015 Zdroj: MSDN.microsoft.com Oproti předchozím verzím došlo k zásadní změně v tom, že pod nový souhrnný název nyní spadá jednak klasický framework.net, aktuálně ve verzi 4.6, tak i nový framework.net Core 5 přinášející mimo jiné i podporu vývoje UWP aplikací. Framework.NET má i nadále sloužit k vývoji standardních nativních aplikací pro Windows, zatímco.net Core představuje kompletně přepracovanou a pro multiplatformní použití upravenou sadu knihoven původního frameworku, která je nově šířena jako opensource. 2.1 Framework.NET zblízka Zatímco aplikace využívající přímé volání Windows API jsou psané v nativním jazyce systému a dají se po zkompilování ihned spustit, aplikace založené na.net frameworku jsou nejprve zkompilované do tzv. managed kódu. To znamená, že nemohou být spouštěné přímo, ale pouze ve speciálním běhovém prostředí frameworku, v podstatě ve virtuálním stroji, který pro aplikaci zařídí základní potřeby typu alokace zdrojů, přístup k systémovým prostředkům, správu paměti, apod. Toto prostředí se nazývá Common Language Runtime (CLR) a dává frameworku několik důležitých vlastností; především je vícejazyčný. CLR totiž na vstupu nepracuje se strojovým kódem, ani kódem přímo v některém z programovacích jazyků, ale s již zmíněným managed kódem ve speciálním jazyce Intermediate Language (IL). Převod vlastního kódu apli- 19

20 kace do jazyka IL má na starost kompilační platforma nazývaná Roslyn, která funguje jako univerzální převaděč. Pokud Roslyn umí kód aplikace zkompilovat do podoby IL, není pro další komponenty.net už problém následně jej zpracovat a spustit. Nativním programovacím jazykem frameworku je C#, který kombinuje vlastnosti jazyka C++ a Java a byl vyvinut přímo Microsoftem pro programování ve Windows. Dalšími.NET přímo podporovanými programovacími jazyky jsou Visual Basic, C++ a F#. Kromě toho ale existují i převaděče pro další jazyky jako Fortran nebo Pascal, obě vyvinuté třetími stranami. Base Class Library Základem frameworku je sada několika binárních knihoven označovaná Base Class Library (BCL), která obsahuje definice datových typů, tříd, rozhraní a dalších prvků společných pro celý framework. Ty jsou dále uspořádané do větších logických celků zvaných namespace (jmenný prostor), jejichž struktura je snadno průchozí pomocí tečkové konvence. BCL jednak tvoří jádro samotného frameworku, tak umožňuje všem aplikacím nad frameworkem snadno implementovat mnoho stovek funkčností od spolupráce s Windows API, přes I/O operace, internetové funkce, zpracování XML, práci s daty a mnoho dalších. Assembly Další klíčovou vlastností frameworku je podpora snadného skládání aplikace pomocí již existujících balíčků prvků a komponent. K tomu slouží speciální binární typ zvaný assembly, jehož obsahem je právě zkompilovaný kód v jazyce IL. Navenek se poznají jako dobře známé soubory s přílohou DLL (knihovna) nebo EXE (spustitelný soubor). Interně se skládají ze dvou hlavních částí: a) Vlastní kód jedná se o vlastní kód aplikace překompilovaný do jazyka IL; b) Metadata obsahují informace o obsahu balíčku, tedy o jeho datových typech, metodách, vlastnostech, třídách apod. Právě metadata jsou klíčová, protože díky nim je možné do vyvíjené aplikace přidat hotové knihovny třetích stran a poté volat jejich funkčnosti, aniž by bylo nutné sdílet přímo jejich kód. Vývojář má tedy možnost importované knihovny využít, ale do jejich fungování nevidí, ani je nemůže pozměnit. Knihovny jsou navíc už zkompilované do jazyka IL, takže je možné kombinovat i balíčky původně psané různými jazyky. 20

21 JIT kompilátor Binární kód uložený v souborech assembly je v jazyce IL, proto se musí před spuštěním znovu zkompilovat do strojového kódu. Toto je úkolem JIT (Just In Time) kompilátoru, který se spouští bezprostředně po startu aplikace. Aktuální verze.net používá novou verzi nazvanou RyuJIT. Protože kompilace nějakou dobu trvá, JIT pro omezení času startu nekompiluje celou aplikaci najednou, ale zaměřuje se pouze na počáteční kód, odkud pak stromovou metodou nabaluje i všechny další metody bezprostředně potřebné pro spuštění. Jakmile jsou všechny zkompilovány, aplikace se spustí. Pokud následně dojde k zavolání ještě nezkompilované metody, dokompiluje se až za běhu aplikace. [7] JIT kromě toho disponuje i pomocnou pamětí cache, do které si ukládá zkompilovaný kód všech metod volaných po spuštění. Ke kompilaci tak dochází pouze při prvním zavolání, v dalším chodu aplikace se již používají zkompilované verze uložené v paměti. Celý princip JIT kompilace a využití cache je zobrazen na Obrázku 3. Obrázek 3: princip JIT kompilace Zdroj: telerik.com 21

22 Nutno dodat, že výše popsané platí především pro tradiční Windows aplikace. UWP aplikace psané v jazycích C# nebo Visual Basic mohou využít i kompilaci pomocí.net Native, což je nový kompilátor představený ve verzi 2015, který umožňuje převést kód aplikace přímo do strojového kódu zařízení ještě před spuštěním aplikace. Dle Microsoftu tak lze zkombinovat všechny výhody vývoje pomocí.net a zároveň dosáhnout výkonu srovnatelného s aplikací psanou v nativním jazyce C++. [8] 2.2 Vývojářské nástroje Základním nástrojem k vývoji aplikací pro Windows je Visual Studio (VS), aktuálně ve verzi Visual Studio je pravidelně upgradované a velmi bohaté vývojářské prostředí (IDE), jehož zevrubný popis by vydal na samostatnou práci. Následuje proto jen stručný souhrn pojmů a vlastností, které se budou v dalším textu vyskytovat: a) Solution (řešení) kontejner zahrnující všechny komponenty vyvíjené aplikace, který umožňuje jejich společný vývoj a testování; b) Project (projekt) komponenta aplikace v rámci Solution, která má svůj jasně daný typ a účel. Jednoduché aplikace mohou mít pouze jeden projekt, u složitých to může být i několik desítek; c) Reference aby komponenta mohla využívat kód a logiku jiné komponenty nebo už hotové knihovny třetí strany, musí na ni mít referenci. Je možné vytvářet reference pouze na takové komponenty, které jsou vzájemně kompatibilní; d) Intellisense pokročilý systém kontextové nápovědy VS, která pro každý prvek kódu napovídá, jaké další možnosti jsou možné a okamžitě vyznačuje případné chyby, bránící kompilaci; e) Build sestavení a zkompilování aplikace do spustitelné podoby; f) GitHub centralizovaný online depozitář dostupných systémových knihoven a knihoven třetích stran, které je možné stáhnout a přidat do projektu, pokud to umožňuje příslušná licence; g) Version Control nástroj pro správu verzí aplikace a teamovou práci. Ve VS je integrovaný jednak Git, oblíbený v opensource komunitě, tak Visual Studio Team Services (VSTS), které je možné využívat zdarma pro neomezený počet projektů, a to až do počti pěti lidí pracujících na projektu. 22

23 Pokud grafický návrh aplikace využívá XAML, lze její vzhled přibližně navrhnout přímo ve VS, ale mnohem více možnosti nabízí další nástroj Blend, který je přímo určený pro profesionální designéry XAML aplikací. Blend je pokusem o WYSIWYG (zkrátka sousloví What You See Is What You Get; obvykle překládaná jako co vidíš, to dostaneš ) editor XAML kódu, který je přizpůsobený pro lidi neznalé programování. Proto se v něm mnohem snadněji tvoří různé pokročilé prvky typu animací, přechodů nebo celkových skinů, které až do hloubky přepisují defaultní styly všech prvků. Program zároveň zpřístupňuje i řadu vlastností zejména vestavěných prvků aplikace, ke kterým se ve standardním XAML editoru VS nelze dostat. 2.3 Přenositelnost kódu Přenositelnost kódu je nejen téma této práce, ale také stále častější potřeba vývojářů, protože se neustále rozšiřuje množství zařízení a platforem, na které je potřeba aplikaci zacílit. Velká výhoda frameworku.net je právě to, že většina na něm postavených platforem má společný základ, takže není důvod stejnou věc programovat dvakrát. Sdílet se přitom dá buď přímo kód, nebo už zkompilované knihovny. Linked Files Použití linked files znamená jednoduché vytvoření odkazu na již jednou existující soubor programu v rámci solution VS. Namísto, aby se soubor s kódem zkopíroval, takže je pak nutné držet jeho podobu shodnou na více místech současně, existuje soubor pouze jednou a na všechna další místa se vkládá pouze odkaz na jeho originální umístění. Ten se přitom navenek tváří úplně stejně jako fyzický soubor, pouze je označen speciálním příznakem. Otvírat i měnit soubor je možné odkudkoli, změna se vždy projeví všude. Linked files působí jako dobrá myšlenka, bohužel v praxi je jejich využití omezené, protože fyzicky se skutečně jedná o odkaz přímo na soubor, ne přímo definici třídy. Důsledkem toho nelze vytvářet linked files, které se vyskytují v jiném jmenném prostoru než originální soubor. Conditional Compilation Tato možnost je vhodná pro případy, kdy kód souboru, který potřebujeme sdílet, není úplně stejný, ale odlišuje se jen v maličkostech, např. ve volání nějaké metody, kterou jedna platforma podporuje a druhá ne. Podmínečná kompilace využívá klíčových slov if, else, 23

24 end-if ke stanovaní podmínky, za které má kompilátor určité platformy vymezený kód použít. Nevýhodou je nutnost podpory podmínek na všech platformách, kde chceme výsledný kód použít, a rostoucí nepřehlednost zdrojového souboru, proto je potřeba podmínky využívat rozumně. Class Library (Knihovna tříd) Pokud chceme implementovat nějakou ucelenou funkčnost a dál ji sdílet, nejlepší je všechny její třídy, rozhraní a soubory umístit do zvláštního projektu. Po zkompilování se vytvoří samostatná binární knihovna (soubor DLL), kterou je možné přímo používat, nebo sdílet se třetími stranami. Nevýhodou standardní knihovny je, že je určená vždy pro jednu konkrétní aplikační platformu a při pokusu vytvořit na ní referenci z jiného typu aplikace, to VS odmítne. VS totiž z binárního souboru knihovny už nemá jak zjistit, zda třeba neobsahuje nějaký kód, který je s cílovou platformou nekompatibilní. Autor knihovny to ale samozřejmě ví, proto řada vývojářů řeší problém tak, že z jednoho zdroje udělá několik funkčně shodných knihoven tříd pro různé platformy, které pak používá nebo šíří dál. Portable Class Library (Knihovna přenosných tříd) Roku 2009 přišlo VS s novým typem projektu zvaným Portable Class, který umožňuje vytvářet knihovny, které jsou multiplatformní. [9] Daní za to je omezení metod a funkcí.net, které je možné ve třídě použít, a to tím více, čím více platforem chceme zacílit. Ty se jednoduše vyberou pomocí dialogu při vytváření knihovny, jehož ukázka je na Obrázku 4. Na jeho základě VS určí, na jaké knihovny z BCL knihoven.net může mít projekt reference. 24

25 Obrázek 4: výběr cílové platformy Portable Class Zdroj: MSDN.com Při pokusu přidat reference na další knihovny VS oznámí, že projekt přestane být kompatibilní. Po zkompilování pak VS dovolí vložit referenci na knihovnu přenosných tříd do projektů jakékoli platformy, která byla při vytvoření knihovny vybrána jako cílová. 25

26 3 UWP Aplikace UWP aplikace představují další evoluční krok tzv. moderních a univerzálních aplikací, které se Microsoft snaží zpopularizovat od uvedení Windows 8. Oproti nim ale mnohem víc berou ohled i na standardní desktop a dávají mnohem větší svobodu vývojáři přizpůsobit jejich vzhled a chování individuálním potřebám. Původní velmi striktní designová omezení se změnila na doporučení a aplikace je nyní mnohem snazší navrhnout tak, aby byly nejen funkční, ale také atraktivní. Princip návrhu uživatelsky příjemné UWP aplikace má hodně společného s návrhem responzivní webové aplikace. I tady jsou základem jednotlivé stránky. I tady je nutné navrhnout layout aplikace tak, aby se snadno přizpůsobil aktuálním rozměrům zařízení, na kterém právě běží. I tady se jako základní způsob navigace používají odkazy na jednotlivé stránky s možností rychle se pohybovat tam a zpět v rámci historie. UWP aplikace mají dva základní módy zobrazení, desktopový nebo tabletový, který se určuje v závislosti na typu zařízení. [2, s. 6-8] Desktopový mód se přitom oproti svým předchůdcům snaží vypadat velmi podobně jako běžné programy Windows. To klade další nároky na adaptabilitu designu, protože UWP aplikace už se nemusí přizpůsobovat jen konkrétním rozměrům displeje spuštěného zařízení, ale také konkrétní velikosti okna aplikace. 3.1 Universal Windows Platform Jednou z klíčových vlastností systému Windows 10 je jeho univerzálnost. Může za to nové jádro a aplikační platforma Universal Windows Platform (UWP), které jsou nyní společné pro všechna zařízení používající Windows 10. Tato platforma nabízí unifikovanou sadu univerzálních UWP API, kterými je možné volat funkce systému bez ohledu na konkrétní typ právě používaného zařízení. Windows 10 UWP aplikace se tak už necílí na konkrétní zařízení ani systém, ale pouze platformu. [2, s ] Microsoft se o něco podobného pokoušel už od Windows 8, které přinesly výrazné sjednocení na úrovni kernelu systému. Další výrazný pokrok přišel s Windows 8.1, kde se sjednocení posunulo na aplikační úroveň a vývojáři mohli poprvé použít tzv. ShareProject, který fungoval jako společná kódová základna aplikace pro desktop i telefon. Po společném vývoji ale stále následovalo konečné cílení na konkrétní systém a nutnost zkompilovat vzájemně nekompatibilní verzi aplikace pro každý z nich. 26

27 Velký problém navíc nastal, pokud ve sdíleném kódu aplikace bylo potřeba zavolat nějakou funkci, kterou podporovalo jen jedno cílové zařízení (např. GPS lokace u telefonu). U Windows 8.1 aplikací nezbylo, než vložit do kódu kompilační výjimku, díky které kompilátor věděl, že pro dané zařízení má volání přeskočit. Pokud takových platformově specifických volání bylo víc, kód se stával nepřehledným, nebo přestalo být technicky možné volání nějak rozumně vymezit. U UWP aplikací všechny podobné starosti odpadají, protože k přesnému cílení a přizpůsobení aplikace konkrétnímu typu zařízení dochází až po spuštění. S každým typem, který Windows 10 podporuje, přichází i speciální přídavné API sloužící k volání jeho platformově specifických funkcí. UWP nabízí celou řadu metod, jejichž voláním se může aplikace kdykoli za běhu systému otázat, zda zařízení, na kterém aplikace právě běží, toto přídavné API podporuje. Pak už je jen na autorovi aplikace, aby takto získanou informací správně ošetřil a patřičně přizpůsobil její vzhled a chování. Toto testování může probíhat opakovaně a při mnoha různých událostech, takže aplikace se může okamžitě adaptovat na případnou změnu. Přímo v kódu nebo definici vzhledu aplikace je k tomu účelu možné určit řadu triggerů, po jejichž aktivaci má aplikace zareagovat a například změnit aktivní layout. Všechny UWP aplikace na desktopu navíc fungují v okně, takže je to sám uživatel, kdo rozhoduje, zda si aplikaci roztáhne na celou obrazovku, nebo se spokojí kupříkladu jen s úzkým pruhem u kraje. Životní cyklus Okno UWP aplikací na desktopu nově obsahuje klasická tlačítka pro ukončení, minimalizaci a maximalizaci, která se ale chová trochu jinak než u běžných programů. Zatímco u nich zůstává i minimalizovaný program běžet a jeho vypnutí je nutno explicitně vyžádat, životní cyklus UWP aplikací vychází z mobilních zařízení a je optimalizován pro maximální úsporu systémových prostředků. Pracuje se třemi základními stavy, jejichž vzájemná závislost je názorně zobrazena na Obrázku 5: a) Aplikace běží (Running) aplikace je spuštěná a není minimalizována, má alokovanou paměť a běžící procesy. b) Aplikace je pozastavena (Suspended) aplikace nemá žádné běžící procesy, ale obsah alokované paměti zůstal netknutý, takže po obnovení se vrátí do shodného stavu před pozastavením. UWP aplikace se na mobilu pozastaví, jakmile uživatel přepne na jinou aplikaci. Na desktopu dojde k pozastavení minimalizací, nebo přepnutím na jiné aktivní okno (dá se překonfigurovat). 27

28 c) Aplikace neběží (Not Running) aplikace je kompletně odstraněna z paměti a nemá žádné běžící procesy. Po aktivaci začne nabíhat od začátku. Obrázek 5: životní cyklus UWP aplikace Zdroj: Real Windows 10 Development Ne vždy je ale vhodné, aby se minimalizovaná aplikace také pozastavila. Příkladem je např. hudební přehrávač. UWP aplikace proto umožňují vytvářet tzv. Background Tasks. Ty představují určitou formu kontraktu mezi aplikací a Windows 10, kterým aplikace žádá o provedení nebo dokončení určité úlohy, i když sama již není aktivní. Pokud aplikace využívá Background Tasks, musí to být jasně deklarované v manifestu aplikace, o kterém bude ještě řeč dále. Aby se přesto nemohlo stát, že na pozadí běžící úlohy začnou alokovat příliš prostředků a zpomalovat chod systému, jsou spouštěny v odděleném prostředí a mají povoleno čerpat maximálně 10 % dostupného výkonu procesoru. Omezení přístupu UWP aplikace jsou navržené jako sandboxové, tzn., že bez implicitního povolení mají jen velmi omezený rozsah možností, které mohou provádět mimo svou vymezenou oblast. Toto bývá zdrojem nemalé frustrace vývojářů klasických aplikací, kteří jsou zvyklí, že mají okamžitě k dispozici veškeré prostředky systému. UWP aplikace si oproti tomu musí každý nadstandardní přístup vyžádat a uživatel jej musí odsouhlasit při instalaci aplikace. S tím také souvisí nový způsob práce se souborovým systémem. UWP aplikace je po instalaci rozbalena na tzv. Package Install Location, která je vytvořena současně s aplikací 28

29 a obsahuje její soubory. [2, s ] Odtud aplikace může načítat případná konfigurační data, textové soubory, apod. Nevýhodou je, že obsah tohoto vymezeného prostoru se přepisuje s každým updatem nebo reinstalací aplikace, je tedy velmi nestálý. Aplikace proto umožňuje přístup ještě k další speciální lokaci, kterou je Isolated Storage Area. [2, s ] Jak napovídá název, jedná se o izolovaný prostor na disku dedikovaný UWP aplikaci, ve kterém si může volně ukládat a načítat data. Klíčové je, že se tento prostor nepřepisuje ani při updatech, takže se dá použít pro ukládání dat dlouhodobější povahy. Instalace Další důležitou změnou, kterou Microsoft prosazuje od uvedení Windows 8, je přechod od individuální distribuce a instalace aplikací k centralizovanému repozitáři Windows Store. Vývojář, který chce zveřejnit svou aplikaci na Store, se musí nejprve zaregistrovat a jeho aplikace projít příslušným schvalovacím procesem. Sjednotil se také formát instalačních souborů. Všechny UWP aplikace se nyní distribuují pomocí tzv. aplikačních balíčků (App Packages), které je možné vytvořit přímo pomocí Visual Studia. Oproti klasickým Win32 programům není už součástí instalace žádný spustitelný instalátor, ale instalace i deinstalace se dějí na systémové úrovni pouze zavoláním příslušných PowerShell příkazů. Každý aplikační balíček obsahuje 3 klíčové části: a) Vlastní soubory aplikace; b) Instalační PowerShell skripty; c) App Manifest. App Manifest (manifest aplikace) je klíčový soubor, který slouží k identifikaci samotné aplikace a popisuje její nejdůležitější vlastnosti a požadavky, pokud jde např. o požadovaná práva k systému, podporované funkčnosti, přizpůsobení designu aplikace různých formátům, apod. Fyzicky se jedná o XML soubor, který je uložen v rootu aplikace. [2, s ] Naštěstí ho ale není nutné vytvářet ručně, protože po jeho otevření se automaticky zobrazí formulář, ve kterém je možné vyplnit většinu hodnot; VS je automaticky převede do odpovídajících XML tagů. Aplikační balíčky se nejčastěji distribuují v zkomprimované podobě pomocí tzv. AppX balíčků, jejichž instalaci buď automaticky obstará systém, nebo je možné ji vynutit pomocí PowerShell příkazů. Pokud ale chceme instalovat vlastní nebo cizí balíčky, které nepochází 29

30 z Windows Store, je nutné nejprve povolit jejich instalaci, a to přepnutím systému do tzv. Developer Mode. 3.2 XAML XAML je speciální podoba jazyka XML, která se v UWP používá k definici vzhledu uživatelského rozhraní jednotlivých stránek aplikace. Oproti automaticky generovanému kódu, který používá např. designér Windows Forms, je jeho zápis plně strukturovaný, takže už zanořením jednotlivých tagů do sebe lze velice názorně určit, jak zhruba bude aplikace vypadat. Klíčové je, že XAML je pomůcka, jejíž životnost končí zkompilováním. Jeho tagy jsou jen jiný syntaktický způsob, jak velmi rychle vytvořit instance tříd jednotlivých prvků a nastavit jim vlastnosti. Z toho vyplývá, že všechno, co lze udělat pomocí XAML, lze i normálně naprogramovat v code-behind. Je to ale velice nepraktické, protože dokud se aplikace nespustí, nemá Visual Studio co zobrazit. Oproti tomu tagy XAML dávají Visual Studiu dostatek informací, aby dokázalo sestavit přibližnou podobu stránky už při návrhu. [6, s ] Obrázek 6: srovnání XAML a C# syntaxe Zdroj: Vlastní zpracování 30

31 Velkou předností XAML je automatizace. Zatímco syntaxe C# je velmi striktní, protože požadavek programu může být takřka jakýkoli a kompilátor musí být schopen přesně určit další požadovaný krok, při návrhu uživatelského rozhraní se většinou řeší jen omezené množství požadavků, které se často opakují. Použití XAML tak dává VS informaci, aby se soustředil jen na tuto omezenou skupinu, takže určité rutinní úkoly si je schopno domyslet a doplnit automaticky. Názorně je to vidět na Obrázku 6, který ukazuje srovnání XAML syntaxe a standardní syntaxe C#, kde výsledkem je totožná akce zobrazení tlačítka v mřížce. Default Properties XAML používá několik základních syntaktických zkratek, které umožňují výrazně zkrátit jeho zápis oproti běžné C# syntaxi. Tou nejdůležitější jsou tzv. Default Properties, které má definované každý prvek uživatelského rozhraní. Jedná se o jednu klíčovou vlastnost rodičovského objektu, kterému je automaticky přiřazen obsah mezi jeho otevíracím a zavíracím tagem. Dobře je to vidět na příkladu výše, kde v C# definici stránky je na posledním řádku vložen nově vytvořený prvek Button do kolekce Children prvku Grid. Podobně prvek Button má popisek nastavený pomocí vlastnosti Content. V případě XAML to ale není ani v jednom případě nutné, protože kolekce Children je nastavená jako defaultní vlastnost prvku Grid a vlastnost Content je zas defaultní pro prvek Button. VS tedy jen na základě vnoření jednotlivých tagů do sebe dokáže určit, jaký obsah má které vlastnosti přiřadit. Complex Properties Řada vlastností je natolik složitých, že je nelze nastavit pouhým přiřazením požadované hodnoty. V takovém případě má i vlastnost svůj vlastní otvírací a zavírací tag, v jehož rámci jsou pak nastavené požadované parametry, takže definici vlastnosti představuje celý obsah tagu. Na Obrázku 7 je jako příklad nastavení komplexní vlastnosti Background prvku Button v případě, že tlačítko nemá mít jednu barvu, ale použít barevný přechod. Komplexní formát využívá k popisu vlastnosti tečkové konvence, která vždy definuje nejprve rodičovský prvek a za tečkou příslušnou vlastnost. Komplexní formát zápisu přitom funguje, i když mezi tagy vložíme pouze jednoduchou hodnotu, v uvedeném příkladu např. jednu konkrétní barvu. 31

32 Obrázek 7: nastavení komplexní vlastnosti Zdroj: Vlastní zpracování Schema V XAML hlavičce každé stránky je několik řádek, které definují tzv. schema. Jedná se o předpis, na základě kterého se VS dozví, že uvedený XML kód představuje XAML syntaxi. Každé schema je označené pomocí fiktivního URL, které slouží jako jeho jedinečný identifikátor. Zároveň má přiřazený unikátní jmenný prostor, aby bylo možné určit, v rámci jakého schema hledat definici jednotlivých prvků a vlastností. Definice jmenného prostoru je v hlavičce uvozena klíčovým slovem xmlns, za nímž následuje dvojtečka a klíč, pod kterým je dostupný ve zbytku stránky. Vedle defaultních schemat je přitom možné stejným způsobem ukládat pod klíče i jmenné prostory vlastní aplikace. Prvky uživatelského rozhraní Prvky uživatelského rozhraní slouží k interakci s uživatelem. UWP aplikace obsahují bohatou řadu vestavěných prvků, které z velké většiny svou funkčnosti odpovídají formulářovým prvkům známým z jiných aplikačních frameworků Windows, a proto není nutné je detailněji popisovat. Důležité je, že ve všech případech se jedná o samostatné třídy, které jsou odvozené z třídy UIElement a většinou je jejich defaultní vlastností Content. Při inicializaci dochází postupně k vytváření instancí jednotlivých prvků v XAML kódu stránky, a pokud mají přidělené jméno, je k nim poté možné přistupovat z code-behind stránky. Vedle vestavěných prvků je možné vytvářet i prvky vlastní. Základním a bezpečným způsobem je použít vestavěné šablony pro tvorbu nových prvků, která do projektu vloží nový custom prvek dědící z třídy UserControl. Ten se podobně jako stránka dělí na XAML definici a část code-behind. Nový custom prvek se poskládá z existujících prvků, nastaví se mu chování, a poté funguje jako obálka umožňující pracovat s jeho obsahem jako jedním prvkem. 32

33 Složitější způsob tvorby vlastních prvků je vytvoření tzv. TemplateControl, což je opět samostatný objekt dědící z třídy Control. Hlavní odlišností template prvku je možnost oddělit styl definující vzhled prvku od jeho funkce. Styl prvku se v tomto případě vydělí do samostatného souboru generic.xaml, který se po vložení prvku automaticky vytvoří do adresáře Themes, kde je ho možné upravit dle potřeby. [2, s ] Styl je vložen do tzv. ResourceDictionary, jedná se tedy o slovník, kde je možné každému stylu přiřadit unikátní klíč, na základě kterého dojde k provázání s vlastním template prvkem. Oproti prvku UserControl, kde každý požadavek na úpravu vzhledu znamená celý custom prvek znovu upravit, template control může mít celou řadu vzhledů, které se změní jen přiřazením klíče stylu příslušného vzhledu. Výchozí vzhled vybraných prvků určuje defaultní styl, který je definován v rámci schema. Jeho použití má zaručit, že všechny UWP aplikace budou dodržovat základní designová pravidla a ovládat se podobným způsobem. Také tento vzhled lze změnit, a to opět použitím ResourceDictionary, do kterého se vybalí definice defaultního stylu, kde je poté možné ji upravit. 3.3 Layout prvky Layout prvky jsou speciální prvky uživatelského rozhraní, které slouží k rozvrstvení vzhledu aplikace. Nejdůležitější layout prvky jsou Grid a StackPanel, novinkou UWP aplikací jsou nové prvky RelativePanel a SplitView. Zatímco běžné prvky mají defaultní vlastnost Content, která umožňuje vložení pouze jednoho podřízeného objektu, defaultní vlastností většiny layout prvků je Children a je typu UIElementCollection, takže umožňuje vložení neomezeného množství objektů. Jakýkoli objekt umístěný mezi tagy layout prvku se automaticky stává součástí jeho Children kolekce. Jednotlivé layout prvky lze přitom dále vnořovat do sebe, čímž lze vytvářet i velmi složitý design. Grid Grid je v podstatě tabulka, ve které je možné nastavit počty řádků a sloupců, a následně určit, v jaké buňce gridu se má zobrazit každý z prvků jeho kolekce. [2, s ] Návrh layoutu se tak hodně podobá principům tabulkového designu, který se často používal při tvorbě webových HTML stránek předtím, než se standardem stalo CSS pozicování. Oproti HTML tabulkám je zápis přehlednější v tom, že jednotlivé prvky není nutné v rámci XAML kódu umisťovat přímo mezi tagy vymezující příslušnou buňku. Namísto toho se 33

34 přímo na pozicovaném prvku zadá číslo sloupce a řádky tabulky, kde se má prvek objevit. Slouží k tomu další specializovaný typ vlastnosti, tzv. Attached Properties, které umožňují nastavit hodnotu vlastnosti nějakého prvku i v rámci jiného prvku. Praktická ukázka pozicování pomocí gridu je na Obrázku 8 ukazující XAML kód a výsledný layout tabulky, která obsahuje 3 různobarevné obdélníky. Důležité je, že pozicování v rámci gridu je absolutní a prvky ve stejné buňce se překryjí, nikoli vloží do řady za sebou. Číslování řádků a sloupců probíhá od nuly, přičemž pokud nejsou zadány jiné souřadnice, prvek se automaticky umístí do buňky vlevo nahoře (souřadnice 0,0). Obrázek 8: XAML syntaxe Grid Zdroj: Vlastní zpracování Velikost layout tabulky i jednotlivých řádků a sloupců je kromě absolutní hodnoty v pixelech možno zadat i relativně, takže se skutečné rozměry určí až v závislosti na aktuální velikosti okna aplikace. K tomu UWP aplikace využívají tzv. hvězdičkovou konvenci, kde je výsledný layout určen poměrem jeho jednotlivých částí. Ukázka výše toho využívá a velikost sloupců tabulky určuje poměrem 3:1:2. Celková šířka tabulky je tedy nejprve rozdělena na 6 dílů, které jsou pak v tomto poměru přiděleny jednotlivým sloupcům. Relative Panel RelativePanel umožňuje vytvářet dynamický layout, který oproti stack panelu nemá jasnou lineární strukturu. Principem je možnost nastavit pozici jednotlivých prvků v rámci relative panelu na základě pozice samotného panelu nebo jiných prvků. [2, s ] K tomu je 34

35 k dispozici celá řada attached properties typu Zarovnat vršek s panelem, Zarovnat spodek s jiným prvkem, Umístit nad jiný prvek, apod. Za jiný prvek lze přitom doplnit jméno libovolného dalšího prvku, který je součástí kolekce prvků relative panelu. Stack Panel StackPanel je jednoduchý layout prvek, který vezme všechny objekty ze své kolekce a podle nastavení vlastnosti Orientation je zobrazí buď za sebou, nebo pod sebou, v tom pořadí, v jakém byly vloženy. [2, s ] Rozměry stack panelu se automaticky přizpůsobují velikosti prvků, které obsahuje. Stack panely se často vnořují do sebe, nebo se kombinují s Gridem, jak je možné vidět v ukázce na Obrázku 9. Obrázek 9: XAML syntaxe StackPanel Zdroj: Vlastní zpracování SplitView SplitView slouží k vytvoření aktuálně velmi moderního typu layoutu, kde je možné část obsahu jakoby vysunout a poté opět zasunout zpět. [2, s ] Split view definuje dvě komplexní vlastnosti, které jeho obsah dělí na dvě části. Část Pane je vyšupovací, zatímco část Content je trvale viditelná a v závislosti na nastavení vlastnosti DisplayMode může být po aktivaci Pane buď překryta, nebo odsunuta stranou. Vysunutí a zasunutí panelu je určeno pomocí vlastnosti IsPaneOpen, jejíž počáteční hodnota je false. Další zajímavou vlastností split view je CompactPaneLength, která 35

36 umožňuje nastavit, jak velká část panelu Pane má být viditelná, i když je panel zasunutý. To je mimo jiné i doporučovaný postup, jak v UWP vytvořit standardní hamburger navigaci. Vlastnosti Pane i Content nejsou kolekce, takže akceptují pouze jeden prvek. Není ale problém, aby tímto prvkem byl např. StackPanel, do jehož kolekce je pak možné naskládat všechny prvky, které je potřeba zobrazit. Praktická ukázka takového layoutu je na Obrázku 10, včetně výsledné podoby v zavřeném a otevřeném stavu. Obrázek 10: XAML syntaxe SplitView Zdroj: Vlastní zpracování 3.4 Inicializace uživatelského prostředí Aby se uživateli zobrazilo okno aplikace a nějaká stránka, musí dojít k inicializaci několika klíčových objektů. To má na starost kód v souboru App.xaml.cs, který inicializacuje třídu App, potomka třídy Application, která funguje jako vstupní bod aplikace. Kód souboru je automaticky vygenerován při vytvoření projektu a u jednoduchých aplikací do něj není nutné výrazněji zasahovat. Pro pochopení, co se v jeho průběhu děje, je potřeba znát funkci především následujících objektů: Window Třída Window představuje UWP obdobu klasického okna aplikace s tlačítky pro zavření, minimalizaci a maximalizaci, jak jsou na ně uživatelé zvyklí z Win32 aplikací. Jeho zobrazení je proto omezené na desktopový mód. Při inicializaci aplikace je nejprve s pomocí sta- 36

37 tické vlastnosti Current třídy Window získána její aktuální instance a té je následně nastavena vlastnost Content na konkrétní prvek odvozený z třídy UIElement, který se má v okně zobrazit. Poslední důležitou operací je zavolání metody Activate, která provede aktivaci okna. [2, s ] Frame Třída Frame je speciální prvek UWP aplikace, která nemá reálný grafický obsah, ale slouží jako kontejner, v rámci nějž jsou zobrazované jednotlivé stránky aplikace. Jejím hlavním úkolem je zprostředkovat navigaci, k čemuž slouží klíčová metoda Navigate, které lze jako parametr předat typ stránky, která se má zobrazit, případně libovolný objekt, který je potřeba zobrazované stránce předat. Rámec funguje velmi podobně oknu prohlížeče, protože si ukládá celou historii a pořadí zobrazených stránek. Pomocí volání dalších důležitých metod třídy, GoBack a GoForward, lze tak snadno implementovat chování tlačítek Zpět a Vpřed. [2, s ] Na Obrázku 11 je příklad jednoduché inicializace uživatelského prostředí; od nastavení aktivního okna až po navigaci na MainPage aplikace. Vše probíhá v rámci přetížené metody OnLaunched třídy App v soboru App.xaml.cs. Obrázek 11: inicializace uživatelského prostředí aplikace Zdroj: Vlastní zpracování Frame patří mezi potomky třídy UIElement, takže s ním lze pracovat jako s kterýmkoli jiným prvkem uživatelského rozhraní. Je ho tak možné umístit přímo do nějaké stránky a další stránky pak zobrazovat pouze v rámci tohoto vnořeného rámce. Stránka MainPage tak např. může obsahovat navigační menu a další společné prvky layoutu společně s dalším rámcem, ve kterém se bude zobrazovat vlastní obsah. 37

38 Page Stránka je základní prvek uživatelského rozhraní, který umožňuje prezentovat obsah aplikace uživatelům. Každou stránku aplikace tvoří samostatná třída dědící ze třídy Page. Vlastní obsah stránky je dostupný pomocí vlastnosti Content. Při zavolání stránky, např. pomocí metody Navigate zmíněné výše, dochází automaticky k vytvoření nové instance třídy dané stránky, která je následně zobrazena uživateli. [2, s ] V code-behind stránky je možné přetížit metody OnNavigatedFrom a OnNavigatedTo, čímž se lze se dostat k obsahu stránky před jejím zobrazením, resp. před odchodem na jinou stránku. To se hodí zejména, pokud chceme ve stránce zobrazit obsah nějakého objektu, který jí byl předán jako parametr pomocí metody Navigate, zavolaný z předchozí stránky. Další důležitou částí stránky je komplexní vlastnost Resources. Ta je typu ResourceDictionary, takže funguje jako slovník, do kterého je možné pod klíčem vložit jakýkoli prvek, ke kterému chceme na stránce přistupovat Na Obrázku 12 je možné vidět, jak to funguje. Nejprve je na řádce 10 pod klíčem mvvm zpřístupněno namespace Infrastructure a následně je na řádce 10 jako zdroj stránky pod klíčem Locator nastaven objekt ViewModelLocator z tohoto namespace. Zároveň je vidět, že základem každé stránky je vždy nějaký layout prvek, v rámci kterého se teprve vytváří vlastní design. Je to proto, že defaultní vlastnost Page je Content; tedy umožňuje nastavit pouze jeden objekt. Obrázek 12: použití Page Resources Zdroj: Vlastní zpracování 38

39 3.5 Práce s daty Pokud mají prvky stránky zobrazit nějaká data, existují dvě základní možnosti. Ta úplně základní spočívá v prostém nastavení příslušných vlastností jednotlivých prvků v code-behind. Druhá využívá vlastnost DataContext, které je možné při inicializaci stránky předat nějaký objekt, který pak zůstává k dispozici všem dalším prvkům stránky, jež k němu mohou pomocí techniky datových vazeb přistupovat přímo v rámci XAML kódu. Fungování datových vazeb se bude podrobně věnovat další kapitola, proto je na Obrázku 13 jen uvedena jednoduchá názorná ukázka. Na řádku 11 je nejprve jako zdroj dat stránky nastaven objekt BookItem, čímž se prvkům TextBlock zpřístupní hodnota jeho vlastností BoookAuthor a BookTitle. Výsledkem je, že aplikace po spuštění zobrazí autora a název nějaké knihy. Obrázek 13: nastavení DataContext stránky Zdroj: Vlastní zpracování Zajímavější je situace, kdy je potřeba souhrnně prezentovat celý seznam. UWP aplikace k tomu používají především prvky GridView a ListView, které se liší hlavně v tom, v jakém formátu výsledný seznam prezentují. Jak napovídá jméno, základem GridView je tabulka, do které se všechny položky seznamu postupně poskládají jako knihy do knihovny. Šířka tabulky přitom může být pevně daná nebo se dynamicky přizpůsobovat velikosti rodičovského prvku, resp. okna aplikace. [2, s ] Oproti tomu ListView skládá položky pod sebe. Názorný příklad ukazující základní podobu zobrazení obou prvků je na Obrázku

40 Obrázek 14: srovnání GridView a ListView Zdroj: Vlastní zpracování K nastavení zdroje dat pro oba seznamy slouží vlastnost ItemsSource, která akceptuje libovolnou kolekci. Samotná data se zobrazují pomocí objektu DataTemplate, což je šablona definující, v jaké grafické podobě se mají zobrazit data každé položky seznamu. K připojení šablony k seznamu slouží komplexní vlastnost ItemTemplate. Šablony je možné používat buď jednorázově, pak se obvykle definují přímo mezi tagy vlastnosti ItemTemplate, nebo opakovaně, kde je výhodné celou šablonu vložit do slovníku Resources stránky nebo aplikace. Jednoduchý příklad, jak vytvořit seznam knih typu list view z příkladu výše, je uveden na Obrázku 15. Obrázek 15: vytvoření seznamu ListView Zdroj: Vlastní zpracování Pro generování jednotlivých položek seznamu se opět využívá datových vazeb. Jako data context stránky slouží objekt BookSource, jehož vlastnost GetBooks vrací požadovaný 40

41 seznam knih. ListView tímto seznamem postupně iteruje a pro každou knihu v seznamu generuje grafickou podobu odpovídající šabloně DataTemplate. Všechny položky přitom zůstávají provázány s původním objektem, takže pokud v seznamu nějakou položku označíme, je možné původní objekt znovu získat. Slouží k tomu vlastnost SelectedItem, resp. SelectedItems, pokud je dovoleno označovat více položek najednou. 41

42 4 Architektura MVVM Návrh uživatelského rozhraní většiny aplikačních modelů Microsoftu se drží velmi podobné šablony, kde je základem nějaký skupinový vizuální objekt (stránka, formulář) opatřený prvky komunikace s uživatelem (texbox, tlačítko, apod.), na který je následně navázaná související logika definovaná v code-behind. Část grafická a část s kódem přitom reálně tvoří jednu třídu jen pomocí klíčového slova partial rozdělenou do dvou souborů. Postup návrhu takové stránky se proto zpravidla sestává ze 3 kroků: a) V grafické části stránky se z jednotlivých prvků sestaví její přibližná podoba a pojmenují se jednotlivé prvky, aby k nim bylo možné přistupovat z codebehind. b) U prvků, kde je požadováno nějaké chování, se doplní handlery příslušných eventů, nebo se se vygeneruje jejich šablona. c) K jednotlivým handlerům v codebehind se dopíše, co konkrétně má aplikace v reakci na jejich aktivaci dělat. Pro jednoduché aplikace to většinou postačuje a umožňuje velmi rychle stvořit základní funkční kostru. Jak se ale aplikace začne rozrůstat, začnou se také množit požadavky na to, že nějakou část logiky definovanou u jednoho objektu by bylo výhodné znovu použít u dalších, aplikaci je nutné opakovaně testovat, a požadavky uživatelů se vyvíjí, čemuž se musí přizpůsobovat také chování aplikace. Pokud je nějaká logika potřeba u 10 různých formulářů a pokaždé je napsána samostatně v code-behind dané stránky, nastává velký problém udržet celou aplikaci konzistentní. Standardním řešením, které pomáhá tento chaos řešit, je proto využití návrhových vzorů, které s pomocí abstraktních tříd a rozhraní umožňují více vymezit zodpovědnost jednotlivých vrstev aplikace. Jedním z těchto vzorů je MVVM (Model-View-ViewModel), který vychází z obecnějšího prezentačního vzoru Model-View-Presenter, resp. Model-View-Controller, kterému se budu podrobněji věnovat v další kapitole. Vzor MVVM byl původně představen architektem WPF a Silverlight aplikací Johnem Gossmanem [10] a většinu jeho principů následně převzaly i moderní, resp. UWP aplikace. Jeho cílem je separovat prezentační vrstvu do 3 oddělených částí. První z nich je samostatné grafické prostředí aplikace, tedy jednotlivé stránky. Druhou je navazující ovládací logika, která obsluhuje reakce na události, které se odehrají na stránce. A poslední je obecná business logika zbytku aplikace. 42

43 Jak tato separace vypadá schematicky je znázorněno na Obrázku 16, přičemž zodpovědnost jednotlivých prvků je následující: a) Model obsahuje vlastní datový objekt, se kterým stránka nějak pracuje, případně přímo související business logiku, např. validace. b) View představuje vlastní objekt uživatelského rozhraní, který vidí uživatel. Ideální view v MVVM je takové, které nemá vůbec žádnou ovládací ani business logiku v code-behind, tedy je úplně hloupé. c) ViewModel funguje jako prostředník mezi Modelem a View, kterému obstarává data modelu a zároveň za něj vykonává veškerou ovládací logiku. Zatímco komunikace mezi ViewModelem a Modelem probíhá standardně pomocí volání příslušných metod, ve vztahu mezi ViewModelem a View platí, že o sobě nesmí vědět. Všechna data a logiku, které View potřebuje, nabízí ViewModel pomocí veřejných vlastností, na které se View napojuje pomocí commandů a datových vazeb, o kterých bude pojednáno v dalším textu. Obrázek 16: MVVM architekura Zdroj: Data binding Data binding (datové vazby) jsou klíčová funkce MVVM architektury, díky které se View může propojit s ViewModelem a získat hodnoty přidružených vlastností. Základní koncept je jednoduchý. Při načtení View se automaticky instancuje k němu přidružený ViewModel, čímž se View zpřístupní i všechny veřejně vystavené vlastnosti ViewModelu. Data binding umožňuje navázat tyto vlastnosti na pro ně kompatibilní vlastnosti jednotlivých prvků View, takže tato nastavení převezmou, čímž v podstatě určí jejich výslednou podobu. [11] Názorně je průběh vazby zobrazen na Obrázku

44 Obrázek 17: princip datových vazeb Zdroj: blog.scottlogic.com Aby vazba mezi vlastnostmi fungovala, musí být vlastnost cílového prvku typu DependencyProperty. Definice DependenceProperty má dvě části. První je registrace vlastnosti v podobě slovníkového záznamu klíč/type do k tomu určené služby DependencyService a druhá vlastní zpřístupnění vlastnosti pomocí getteru a setteru, díky kterým se vlastnost navenek nijak neliší od běžné vlastnosti definované lokálně. Naštěstí většina vlastností vystavených defaultními kontrolními prvky UWP aplikací jsou právě typu dependency property, takže jejich definici je třeba řešit hlavně při vytváření vlastních kontrolních prvků. Existují 3 způsoby, jak je možné datové vazby nastavit: a) One-Time jednorázová jednosměrná datová vazba, při které se při načtení View natáhnou hodnoty z ViewModelu, ale další změny jsou ignorovány. Vhodné pro statické hodnoty typu popisků, nadpisů, apod. b) One-Way jednosměrná vazba, která sleduje případné změny ViewModelu a přenáší je na View, ale ne obráceně. Vhodné pro zobrazení dat, která jsou pouze pro čtení. c) Two-Way oboustranná vazba, kdy se sledují změny na obou stranách a View a ViewModel se mezi sebou při každé změně synchronizují. Datové vazby se nejčastěji vytváří v podobě XAML syntaxe, která se přímo v definici View navazuje na setter nastavované vlastnosti. Na Obrázku 18 je možné vidět ukázkovou implementaci v kódu UWP aplikace, která nejprve nastavuje WelcomePageViewModel jako zdroj pro WelcomePage View a následně vytváří vazbu vlastnosti Content prvku Button na vlastnost Text ViewModelu. 44

45 Obrázek 18: XAML Data binding Zdroj: Vlastní zpracování Klíčové jsou následující 3 části kódu: 1) Řádek 8 představuje vytvoření jmenného prostoru vm: na který je pomocí klíčového slova using navázán adresář ViewModels ukázkové aplikace. 2) Řádky nastavují vlastnost DataContext na konkrétní ViewModel. 3) Řádek 17 provádí samotný data binding, tedy nastaví popis tlačítka na hodnotu, která je shodná s textem stanoveným vlastností Text ViewModelu. V základní syntaxi datových vazeb se vždy vyskytují 3 prvky: 1) Cílový objekt v příkladu prvek Button prvek uživatelského rozhraní, který je potřeba z ViewModelu nějak nastavit. 2) Cílová vlastnost v příkladu Content konkrétní vlastnost cílového objektu, která se nastavuje. 3) Zdrojová vlastnost v příkladu Text vlastnost ViewModelu, se kterou má cílová vlastnost provázat a převzít její hodnoty. 4.2 Value Converter Problém nastává, pokud vlastnost jako hodnotu očekává nějakou konkrétní třídu nebo výčet, nikoli jen obecný datový typ. Teoreticky je sice možné i tuto vlastnost nastavit přímo z ViewModelu, jenže ten se pak stane použitelný jen pro aplikaci jednoho konkrétního typu. Jedno z doporučení MVVM přitom říká, že ViewModely by měly být, pokud možno, platformově nezávislé; toto doporučení se mění v nezbytnost, pokud má ViewModel fungovat jako zdroj dat pro vice uživatelských rozhraní současně, jak vyžaduje tato práce. 45

46 Pro řešení podobných nekompatibilit proto v MVVM existuje rozhraní IValueConverter, které předepisuje dvě metody, Convert a ConvertBack, jejichž implementací lze dosáhnout oboustranné kompatibility. [2, s. 49] Konvertor se tedy přidává na straně View a jeho úkolem je obstarat překlad hodnoty obecného typu získaný z ViewModelu do hodnoty jiného typu, kterou očekává vlastnost prvku, se kterým má vlastnost ViewModelu datovou vazbu. Na Obrázku 19 je ukázka takové implementace, která umožňuje propojení vlastnosti Visibility nějakého prvku UWP aplikace s obecnou vlastností typu bool. Jediný parametr metody Convert, který nás zajímá, je value. Ten je v rámci metody nejprve ověřen, že odpovídá očekávanému typu, a poté přetypován pro zjištění konkrétní hodnoty, které je možné přiřadit ekvivalent, kterému rozumí prvek View. Metoda ConvertBack funguje přesně opačně a umožňuje realizovat oboustrannou vazbu. Obrázek 19: implementace IValueConverter Zdroj: Vlastní zpracování Na Obrázku 20 je vidět napojení vytvořeného konvertoru na View v XAML stránky. Odkaz na VisibilityConvertor je nejprve přidán ke zdrojům stránky. Zdroje fungují jako slovník, proto je konvertoru nutné zároveň nastavit klíč VC, pod kterým lze konvertor později zavolat. Což se děje v klíčové řádce 25, pomocí parametru Converter, kterému je nastavena statická datová vazba na příslušný klíč knihovny Resources stránky. 46

47 Obrázek 20: přiřazení konvertoru k vlastnosti Zdroj: Vlastní zpracování Kompilovaný binding Datové vazby ani používání konvertorů nejsou zadarmo a při velkém množství vazeb se mohou projevit na výkonu. Z toho důvodu UWP aplikace vedle tradičních datových vazeb, využívajících syntaxi {Binding}, umožňují také použití nové techniky {x:bind}, která je též označovaná jako kompilovaný binding. Zatímco standardní datové vazby jsou založené na reflexi prováděné za běhu aplikace, kompilovaný binding odvede většinu práce už při kompilaci, což může přinést značné zvýšení výkonu. [12] Zároveň to ale znamená, že v okamžiku kompilace už musí příslušné instance tříd existovat a musí být znám jejich typ. Při použití {x:bind} se proto nepoužívá deklarace ViewModelu pomocí vlastnosti DataContext v XAML, ale instance ViewModelu se inicializuje současně s inicializací stránky, a poté vystaví jako její veřejná vlastnost. Bohužel {x:bind} zatím jen omezeně podporují design data, tedy provázání vlastnosti prvku na ViewModel už v okamžiku návrhu. To je přitom velký problém, protože nesprávně definované datové vazby se oproti běžnému kódu při kompilaci nijak neprojeví. Design data tak představují jednu z mála možností, jak si v průběhu návrhu ověřit, že vytvořená vazba funguje. Starší metoda {Binding} je kromě toho bohatě zdokumentovaná i v dalších typech aplikací využívajících XAML. Proto se tato práce bude spíše držet této metody a {x:bind} využije jen tam, kde to bude výhodné. 47

48 4.3 Observable objekty Pokud MVVM označuje nějaké objekty jako observable, v podstatě to znamená, že je framework aplikace monitoruje a případnou změnu reportuje dál. Jedná se o klíčovou techniku datových vazeb, která umožňuje synchronizovat případné změny mezi View a ViewModelem. Rozhraní INotifyPropertyChanged Aby vlastnost ViewModelu byla observable, musí ViewModel nebo jeho rodič implementovat rozhraní INotifyPropertyChanged. To předepisuje event PropertyChanged, což je delegát metody, která jako parametr přijímá jméno vlastnosti, jejíž jméno se změnilo. Následně se vytvoří pomocná metoda pro vyvolání události, která nejprve otestuje, jestli události někdo naslouchá; pokud ano, umožní vyvolání události s příslušným jménem. Samotná pomocná metoda se nejčastěji volá v setteru vlastnosti, jejíž změnu chceme reportovat, proto není možné používat zkrácený zápis. [6, s ] Na Obrázku 21 je ukázka takové implementace pro oboustrannou vazbu vlastnosti UserName. V praktické implementaci se ale většinou používá společná bázová třída, která rozhraní implementuje a ostatní ViewModely z ní dědí. Obrázek 21: implementace IPropertyNotifyChanged Zdroj: Vlastní zpracování 48

49 Kolekce Vedle jednotlivývh vlastností je ale možné sledovat i celé kolekce. K tomu MVVM nabízí rozhraní INotifyCollectionChanged. Toto rozhraní je v.net již implementované v kolekci typu ObservableCollection<T>, která představuje observable podobu třídy Collection<T>. Pokud je observable kolekce navázána na některý z prvků sloužících k zobrazení seznamu, jako jsou GridView nebo ListView, obsah se automaticky aktualizuje kdykoli, když dojde ke změně kolekce (nikoli ale ke změně jejich jednotlivých prvků). 4.4 Commandy (Příkazy) v MVVM Reakce na události vyvolané jednotlivými prvky daného View jsou druhou nejdůležitější skupinou problémů, které je v rámci MVVM nutné řešit. Otázka zní, jak informovat ViewModel, že k nějaké události došlo, když View dle pravidel MVVM nemá mít žádné úzké vazby se zbytkem aplikace, a tudíž nemůže zavolat metodu představující tuto reakci, ať už je implementována na ViewModelu, nebo kdekoli jinde v struktuře aplikace. Návrhový vzor Command Řešením je právě využití objektů Command (Příkaz), které vychází z návrhového vzoru stejného jména. Základní charakteristika říká, že zabalí metodu do objektu, takže s ní pak lze pracovat jako s běžným objektem. To umožňuje dynamickou výměnu používaných metod za běhu programu a optimalizaci přizpůsobení programu požadavkům uživatele. [13] Zjednodušeně se dá říct, že z nějaké metody se vytvoří třída, která danou metodu zastupuje, aniž by zájemci o její spuštění tušili, o jakou konkrétní metodu se jedná a odkud pochází. Pokud se reálná metoda schovaná pod zástupcem změní, zájemce nic nepozná. A protože se metoda chová jako objekt, je také možné požadavky na její spuštění řadit do fronty, různě přehazovat dle požadavků, nebo naopak se vracet frontou požadavků v čase zpět. 49

50 Obrázek 22: návrhový vzor Command (Příkaz) Zdroj: Rahul Rajat Singh's blog Na Obrázku 22 je zobrazené ULM schéma návrhového vzoru Command a základních prvků. Jednotlivé objekty mají následující funkci: a) Invoker využívá objekt Commandu k provedení akce; b) Command interface ICommand předepisující podobu Concrete- Command; c) Receiver objekt, který skutečně realizuje akci, kterou Invoker požaduje provést; d) Client realizuje interface ICommand v objektu ConcreteCommand a určuje Receiver, kterému bude předán požadavek na provedení akce; e) ConcreteCommand implementace ICommand, která představuje vazbu mezi Invokerem a Receiverem. Zodpovídá za to, že pověřený Receiver požadovanou akci vykoná. Využití v MVVM Pro zjištění, jaké konkrétní využití má vzor v MVVM, si stačí za obecné pojmy Invoker a Client dosadit prvek View, ze kterého pochází událost a ViewModel, který obsahuje implementaci commandu, který se má s View propojit. Jako Receiver pak může fungovat jak samotný ViewModel, tak i kterákoli jiná třída nebo třídy, na kterých je reálně implementována metoda, která se má po aktivaci Commandu provést. [14] 50

51 Zbývá tedy vytvořit samotný Command, pro které už má.net připravený příslušný interface ICommand. Ten předepisuje dvě metody a jeden event. Hlavní z této trojice je metoda Execute, která má za úkol vykonat akci, kterou Command představuje. Další pomocná metoda CanExecute prování kontrolu, zda je spuštění vůbec možné a event CanExecuteChanged upozorňuje, pokud se stav CanExecute změnil. Výsledkem je objekt Command, který zapouzdřuje chování, které se má provést jako reakce na událost. Ten je pak možné vystavit jako vlastnost daného ViewModelu a pomocí datových vazeb standardně navázat na příslušný prvek View. Na Obrázku 23 a Obrázku 24 je vidět jednoduchá implementace Commandu a jeho následné vytvoření a publikování jako třídy ViewModelu. Cílem implementace je vytvořit událost prvku Button, která v reakci na stisknutí vymaže prvky formuláře. Pro zjednodušení je zahrnuta pouze hlavní metoda Execute. Základem je definice delegáta ResetOperation, který zastupuje vlastní metodu Reset- Form, jež provádí vynulování všech prvků formuláře. Vytvořený delegát je předán jako parametr nově vytvořené instanci třídy ResetCommand, která je následně vystavena jako veřejná vlastnost ResetThisForm ViewModelu. Samotné View, které na ukázce není, pak už jen používá standardní datovou vazbu této vlastnosti na vlastnost Command příslušného tlačítka. Obrázek 23: implementace ICommand Zdroj: Vlastní zpracování 51

52 Obrázek 24: zveřejnění instance ResetCommand jako vlastnosti Zdroj: Vlastní zpracování Bohužel, pouze omezené množství prvků uživatelského rozhraní má podporu commandů přímo vestavěnou, nebo umožňují navázat pouze nejčastější události. Proto UWP aplikace umožňují využit i tzv. Blend behaviors, které výrazně rozšiřují možnosti commandů. Jedná se v podstatě o XAML podobu populárního ITTT (zkratka sousloví If This, Then That, překládaného jako když toto, pak tamto ), která navzdory svému názvu nepotřebuje program Blend a nabízí mimo jiné i prvek EventToTrigger, který umožňuje provázat command s libovolným eventem. Jedinou nutností je přidat do referencí aplikace odkaz na knihovnu System.Windows.Interactivity.dll. Hlavní nevýhodou commandů je jejich relativní složitost, kdy i pro akci, kterou lze normálně vyřešit několika řádky v code-behind, je nutné vytvářet speciální objekt. Proto se v praxi často volí kompromis, kdy vlastní chování je sice definováno na ViewModelu, obsluha události se ale řeší klasicky v code-behind, odkud se následně pouze volá příslušná metoda. Stačí k tomu odchycení aktuální instance ViewModelu, což je relativně snadné, i pokud je iniciován automaticky v rámci XAML definice stránky. Konkrétně v UWP lze využít v minulé kapitole zmíněné metody OnNavigatedTo, která se spouští až ve chvíli, kdy už je instance ViewModelu vytvořená. Další zajímavou možností, jak si ušetřit práci, nabízí kompilovaný binding, kde je za určitých podmínek možné vytvořit přímou vazbu události na metodu. 4.5 Návrhový vzor Dependency Injection Dependency Injection (předávání závislostí) je dalším návrhovým vzorem, který je výhodné využít při návrhu MVVM aplikace. Za obtížně přeložitelným názvem (lze narazit například na otrocký překlad závislostní vstřikování ) se skrývá princip předání odpovědnosti za vytváření 52

53 závislostí nějakého nově tvořeného objektu dalšímu objektu a pouze převzetí konečného výsledku. Dependency injection je velmi jednoduchý princip, který navíc většina programátorů začne používat téměř intuitivně, protože jinak se jim bude výsledný kód velmi špatně spravovat a testovat. Obrovskou výhodou je, že jen změnou nějaké závislosti lze dosáhnout změny konečného objektu, aniž by se do něj muselo jakkoli zasahovat. U MVVM tak typicky existuje ViewModel, který má za úkol předávat View data o nějakém objektu databáze. Pokud se databáze nevolá přímo, ale spojení na ní je definováno jako závislost, může se snadno změnit např. její typ nebo reálné umístění, aniž by bylo nutné jakkoli měnit kód ViewModelu. Obrázek 25: možnosti Dependency Injection Zdroj: Vlastní zpracování 53

54 Na Obrázku 25 jsou uvedené vzorové implementace čtyřech možností možností, jakými lze závislost na objektu nastavit. [15] Jsou to: a) Constructor Injection Všechny závislosti jsou dodané jako parametry v konstruktoru objektu, takže bez nich objekt nelze vytvořit. Hlavní předností této metody je její transparentnost, protože závislosti jsou jasně patrné. b) Setter Injection Objekt je nejprve vytvořen, a poté pomocí zavolání k tomu určené metody předána závislost. c) Property Injection Funkčně stejné jako přechozí možnost, ale závislost je nastavena pomocí k tomu určené veřejné vlastnosti. d) Interface Injection Podobné jako setter injection, ale závislost je definována už na úrovni interface jako metoda, kterou musí realizovat konkrétní odvozený objekt. Při popisu dependency injection se pro závislosti často používá honosnější označení Service (služba), protože přesně o to se z pohledu vytvářeného objektu jedná. Je to ale matoucí označení, protože to vzbuzuje dojem další komplikované komponenty, ačkoli se často jedná jen o jednoduchý objekt. 4.6 Návrhový vzor Factory (Továrna) Při snaze využít v MVVM pravidla Dependency Injection (DI), popsané v minulé kapitole, lze rychle dojít k tomu, že standardní workflow, kdy se nejprve zavolá nějaké View, a to následně iniciuje příslušející ViewModel, přestane vyhovovat. Jednak je problém závislosti vůbec předat, protože standardní XAML inicializace přes DataContext si poradí jen s ViewModelem bez argumentů, jednak je potřeba závislost nějakým způsobem vyrobit. Proto je potřeba se seznámit s dalším návrhovým vzorem Factory (Továrna), který umožní centralizovat do jednoho místa (objektu) získávání a správu instancí objektů, se kterými má aplikace pracovat. Pokud je v návrhu použita továrna, ohromně se tím zpřehlední fungování aplikace, protože vytvoří místo, odkud je možné získávat instance všech potřebných objektů. Kdekoli jinde bude daný objekt potřeba, pouze se zavolá továrna. Továrna navíc není omezená jen na vlastní tvorbu objektů, ale může obsahovat i logiku, která na základě parametrů rovnou vrací instanci požadovaného typu. Vyráběné objekty pak nemusí být pouze instance jedné třídy, ale i instance příbuzných tříd implementujících stejné rozhraní. 54

55 Obrázek 26: návrhový vzor Factory (Továrna) Zdroj: Rahul Rajat Singh's blog Na Obrázku 26 je zobrazené ULM schéma návrhového vzoru factory a základních prvků. Jednotlivé objekty mají následující funkci: [16] a) Product Určuje předpis (interface) objektů, které továrna produkuje. b) ConcreteProduct Představuje konkrétní implementaci interface. c) Creator Interface nebo abstraktní třída továrny, která předepisuje metodu FactoryMethod, vracející objekt typu Product. d) ConcreteCreator Konkrétní implementace Creator. Obrázek 27 ukazuje jednoduchou implementaci vzoru Factory na příkladu továrny, která vrací objekty konkrétních světelných zdrojů LEDLight a LightBulb. Ty realizují společné interface ILightSource a pro úspornost nejsou na příkladu zahrnuté. Klíčová je hlavně metoda CreateSource třídy LightFactoryExample, ve které se děje vlastní výroba. Metodě je nejprve pomocí enum parametru source řečeno, jaký typ světla má vytvořit a poté vrátí příslušnou nově vytvořenou instanci. 55

56 Obrázek 27: implementace vzoru Factory Zdroj: Vlastní zpracování 4.7 Service Locator V kapitole věnované dependency injection byl zmíněn pojem služby, což jsou v podstatě objekty, na nichž je závislá třída, kterou je potřeba inicializovat. Názorně je to znázorněné na Obrázku 28. Obrázek 28: závislost třídy na službách Zdroj: msdn.microsoft.com 56

57 Toto řešení není moc výhodné, protože jakákoli změna některé ze služeb znamená i nutnost přepsání závislé třídy. Většina rozsáhlejších aplikací se navíc skládá z modulů, které jsou vyvíjeny zvlášť, přičemž základním požadavkem je, aby změna nebo výměna jednoho modulu za jiný neznamenala i nutnost předělávat zbytek aplikace. Cílem ServiceLocator vzoru je proto oddělit proces lokalizace jednotlivých běžících služeb od samotné inicializace tak, aby existovalo jedno centralizované místo, kam se může závislá třída obrátit a své služby si vyžádat. [17] Jak takové řešení může vypadat, je uvedené na Obrázku 29. Obrázek 29: využití ServiceLocator Zdroj: msdn.microsoft.com V praxi se jedná o kontejner, kde se do paměti aplikace ukládají instance jednotlivých spuštěných služeb. Samotný vzor sice neříká nic o tom, kde se tyto instance berou, většinou je ale ServiceLocator kombinovaný s továrnou, takže není nutné služby iniciovat jinde. Pokud na ServiceLocator přijde požadavek na nějakou službu, nejprve se prověří obsah kontejneru, zda už neobsahuje jeho instanci. Pokud ne, Locator ji vytvoří a uloží její odkaz do kontejneru. Pokud ne, nová už se nevytváří, ale Locator vrátí tento odkaz. Na Obrázku 30 je ukázka jednoduché implementace ServiceLocatoru, která nepracuje s parametry. [18] Jako kontejner slouží Dictionary (slovník), který jako klíč používá jméno ukládaného objektu a jako hodnotu samotný nový objekt přetypovaný jako object. Díky tomu lze do slovníku uložit instanci libovolného typu. Na výstupu je získaný objekt přetypován zpátky. 57

58 Obrázek 30: implementace ServiceLocator Zdroj: Vlastní zpracování (na základě Rahul Rajat Singh's blog) 4.8 IoC kontejner Pokročilejší z komponent, které představují implementaci Dependency Injection v rámci MVVM, je IoC kontejner. Jedná se o zkratku slov Inversion Of Control, někdy překládanou jako obrácené řízení, což je návrhový vzor, který jakoby předává získávání potřebných závislostí frameworku namísto toho, aby si je klasicky generovaly přímo příslušné třídy. [16] Vzor lze také chápat jako automatizaci konstructor injection, kdy iniciaci a dodání závislostí už nemá na starosti nějaká nadřazená třída, ale IoC kontejner. Obrovskou výhodou je variabilita a centralizace jakýchkoli změn. Zatímco normálně jakákoli změna závislosti znamená přepsat i všechny navázané objekty, IoC kontejner provádí vstřikování na úrovni rozhraní, takže na konkrétní implementaci nezáleží. Jako příklad je možné uvést např. ladění aplikace, která jako službu využívá náročné cloudové zdroje. Pokud je služba abstrahována pomocí rozhraní a poté vytvořena testovací 58

59 atrapa, která toto rozhraní realizuje, lze pomocí IoC kontejneru snadno přepínat obě služby pouhým zaregistrováním aktuálně požadované implementace. Není tak nutno jakkoli měnit kód ostatních částí aplikace, případně dokonce složitě dohledávat, kde všude danou službu voláme. Z hlediska nabízených funkčností je IoC kontejner možné přirovnat k ServiceLocatoru, který má ale zároveň vestavěnou továrnu, případně i řadu dalších funkcí. Jejich rozsah se liší v závislosti na konkrétní implementaci, nicméně v. NET aplikacích je základem realizace rozhraní IServiceLocator, které kontejner umožní nastavit jako ServiceLocatorProvider, čímž se stane univerzálně dostupný přímo pomocí frameworku. Protože ukázka kódu implementace už by byla příliš dlouhá a nepřehledná, je na Obrázku 31 uvedena jen ukázka využití hotového kontejneru SimpleIoC, který je k dispozici v rámci frameworku GalaSoft MVVM Light. Obrázek 31: využití IoC kontejneru GalaSoft Light Zdroj: Vlastní zpracování 59

60 Jak napovídá slovo kontejner, základem je opět slovník, do kterého se pomocí metody Register uloží jednotlivé injektované služby a jejich abstraktní předpis v podobě rozhraní. K tomu dochází na řádce 47, kde je třída DataService1 zaregistrovaná jako konkrétní poskytovatel služby IDataService. Následně je zaregistrovaná i třída ViewModel1. Ta je klíčová tím, že v konstruktoru na řádce 31 požaduje injektovat poskytovatele služby IDataService. Bez využití IoC by pro získání instance musela existovat ještě nějaká nadřazená třída, která službu nastaví a iniciuje. IoC kontejner ale toto zařídí automaticky, takže pokud je instance pomocí vlastnosti MainViewModel na řádce 54 vyžádána, kontejner prohledá zaregistrované služby, iniciuje službu DataService1 a následně její instanci injektuje do závislé třídy ViewModel1. [20] Možností IoC kontejneru jsou ale mnohem širší. Konkrétně ukázkový typ SimpleIoC např. umožňuje určit, zda se má iniciovaná instance uložit do paměti aplikace a fungovat jako singleton, nebo se při každém požadavku iniciovat znovu. Je také možné iniciované instance stejné třídy odlišit pomocí klíče, nebo přikázat, aby k prvotní iniciaci došlo ihned při registraci a nikoli až po obdržení prvního požadavku. Využití IoC se neomezuje jen na MVVM, ale právě tam je opravdu užitečné. Prakticky každý ViewModel je totiž závislý přinejmenším na nějaké datové službě, navigační službě, messengeru, případně dalších službách. Navíc se o iniciaci ViewModelu většinou stará přímo příslušné View, ale v XAML kódu je injektování závislostí nemožné a v code-behind zas velmi nepraktické. IoC kontejner tak představuje vítanou možnost, jak metody dependency injection v MVVM prakticky nasadit. 4.9 Služby (Services) v MVVM Poslední důležitou součástí MVVM, kterou je důležité zmínit, jsou služby, které je většinou nezbytné při návrhu aplikace využít. Přesunutím ovládací logiky do ViewModelu totiž dochází k omezení použití některých technik, které je možné volat pouze z code-behind příslušného View. Proto je potřeba tyto možnosti nějakým způsobem nahradit. Navigační servis V kapitole UWP bylo popsáno, že navigace mezi stránkami probíhá pomocí metody Navigate a jejich odvozenin, které jsou implementovány na třídě Frame, která je jedním z prvků uživatelského rozhraní. To je problém, protože jde o nativní objekt UWP aplikace, který nelze 60

61 ve ViewModelu použít. Přitom struktura aplikace velmi často předpokládá, že např. po úspěšném splnění nějakého úkolu po stisknutí tlačítka dojde k přesunu na jinou stránku, která zobrazí výsledek. Navigační servis řeší tenhle problém tím, že zastřešuje vlastní objekt Frame, provádějící navigaci, a prostřednictvím ServiceLocatoru nabízí jeho služby všem zaregistrovaným objektům aplikace. Principem je odchycení aktivní instance Frame, ke kterému dojde v rámci kódu souboru app.xaml.cs při inicializaci aplikace. Navigační služba tuto instanci následně obalí vlastními metodami, které je pak možné volat přímo z jednotlivých ViewModelů. [21] Toto zabalení je důležité, protože metoda Navigate jako navigační parametr používá nativní UWP typy cílových View, které opět nejsou ve ViewModelech standardně dostupné. Proto si navigační servis pomáhá dalším trikem, kdy je pro každé cílové View nejprve potřeba zaregistrovat nějaký unikátní klíč, který se pak používá jako označení cíle. Výsledkem je, že pokud ViewModel zavolá navigační servis, ten si podle zadaného klíče dohledá příslušný typ View a následně ho použije jako cílový parametr samotné metody Navigate. Názorná ukázka možné implementace navigační služby je na Obrázku 32. Obrázek 32: implementace Navigation Service Zdroj: Vlastní zpracování 61

62 Z popisu služby vyplývá jedna důležitá věc - není multiplatformní. I když k ní ViewModely nepřistupují přímo, navigace stále probíhá prostřednictvím nativní třídy Frame UWP aplikace. To není problém, pokud mají být ViewModely použité jen v rámci tohoto frameworku. Pokud je ale chceme používat univerzálně, jak předpokládá tato práce, je nutné nějak ošetřit, aby každá z cílových platforem měla k dispozici kompatibilní navigační servis, případně jej vůbec nepoužít, pokud daná platforma řeší navigaci radikálně odlišně. Naštěstí lze opět využít dependency injection a IoC kontejner. Zobecněním navigační služby do rozhraní INavigationService je totiž možné pro různé aplikační platformy vytvořit různé typy navigačních služeb implementujících toto rozhraní a do IoC kontejneru zaregistrovat tu aktuálně potřebnou. Přímo z ViewModelu se pak volají pouze metody tohoto rozhraní, takže není potřeba řešit, jak konkrétně navigace probíhá. Více komplikovaná je situace, pokud navigační servis není potřeba. Jednou z možností je zaregistrovat jen fasádu služby, která reálně nic nevykonává. Další pak využít některé z dalších metod IoC kontejneru pro ošetření kódu aplikace tak, že k zavolání kódu navigační služby dojde jen tehdy, pokud je v kontejneru zaregistrována. Messenger servis Další komplikací, která nastává při použití MVVM a dependency injection, je vykonání nějaké logiky nebo zobrazení nějaké správy v reakci na činnost vykonanou na jiném ViewModelu. Při běžném návrhu, který vytváří novou instanci ViewModelu při každém načtení View, by se dalo využít konstruktoru. IoC kontejner ale standardně každý vytvořený ViewModel ukládá do paměti a při opětném načtení stránky ho z ní pouze vyvolá. Proto je opět potřeba nějaká externí služba, která se postará o zprostředkování komunikace. Základní úkol Messenger služby je zřejmý už z názvu. ViewModely, které si přejí odebírat informace, se zaregistrují, vyberou typ zprávy, které je zajímají, a poté čekají. Jiný ViewModel, který chce nějakou zprávu poslat, naopak vybere její typ, případně i přesného adresáta, a prostřednictvím služby ji odešle. Pokud typ a adresát souhlasí, cílový ViewModel zprávu zachytí a vykoná navázanou logiku. Implementaci podobně jako u IoC kontejneru není třeba řešit, protože služba je v nějaké podobě součástí většiny MVVM frameworků. Stačí ji tedy pouze využít. Na Obrázku 33 je proto uvedena ukázka, jak prakticky vypadá volání a poslání zprávy služby Messaging, která je součástí frameworku GalaSoft MVVM Light. 62

63 Obrázek 33: využití GalaSoft Messaging Service Zdroj: Vlastní zpracování Vlastní zpráva se vytvoří jednoduše poděděním z připravené třídy MessageBase a následným zavoláním jejího konstruktoru. Pak už se jen pomocí metody Send vytvoří a odešle příslušná zpráva. Zajímavější je příjmová strana, kde metoda Register očekává delegáta metody, která se má vykonat při obdržení zprávy. V ukázkovém příkladu jde o anonymní metodu přímo v těle delegáta, které je předán obsah zprávy a na jeho základě rozhodnuto o dalším postupu MVVM frameworky Z předcházejícího textu je zřejmě, že implementace MVVM není úplně triviální a vyžaduje velké přípravy ještě předtím, než je možné se jakkoli věnovat samotným funkčnostem aplikace. To samozřejmě představuje otevřenou příležitost pro nasazení specializovaných frameworků, které vývojáře odstíní od většiny infrastrukturních požadavků a umožní se soustředit jen na samotná View, ViewModely a logiku aplikace. Problém nastává, pokud má být framework využit i jinak, než předpokládají jeho tvůrci, protože pak může být přílišná automatizace na obtíž. To je i případ této práce, proto nebylo snadné rozhodnout, zda nějaký framework vůbec využít. 63

64 V následujícím srovnání jsou proto uvedeny 3 známé a populární frameworky pro vývoj MVVM aplikací, jejichž užití bylo zvažováno: PRISM Jedná se o oficiální open source projekt Microsoftu, který zahrnuje jak samotný framework, tak celou řadu doporučení a vzorů pro návrh WPF, Silverlight, Windows 8.1, UWP a nejnověji i Xamarin aplikací. Základ frameworku je distribuován jako Portable Class Library, takže je ho snadné propojit s více projekty současně. Zároveň se ale jedná o komplexní a spíše pro enterprise sféru určený nástroj, který poskytuje celou řadu služeb formou magického kódu, který produkuje výsledek, ale bez podrobné znalosti dokumentace není snadné říct proč. Framework je výborně zdokumentovaný a má silnou online podporu, která je ale zaměřená především na vývoj profesionálních WPF aplikací pro desktopová Windows. Caliburn Micro Jedná se o často doporučovaný framework, který při prvním ohmatání působí jako dobrý kompromis mezi robustností a srozumitelností. Základ frameworku je opět distribuován jako Portable Class Library, kde jsou k dispozici ty nejpoužívanější služby. Caliburn se hodně snaží držet pravidla Convention over Configuration, takže při dodržení doporučených konvencí je schopen plno věcí zařídit automaticky. Na druhou stranu tím opět dochází k odstínění autora od infrastruktury aplikace, což při experimentech může způsobovat problémy. MVVM Light Toolkit Spíše než o framework se jedná o sadu klíčových knihoven zjednodušujících implementaci základních služeb pro podporu MVVM. Dokumentace přímo na stránkách projektu není úplně aktuální, ale naštěstí existuje dostatek blogpostů zaměřených i přímo na UWP aplikace. Framework je možné stáhnout buď čistě jako knihovny, nebo včetně implementace klíčových tříd. Díky své jednoduchosti je univerzální, takže knihovny MVVM Light lze snadno použít buď v rámci Portable Class Library, nebo přímo přidat referenci do většiny typů.net aplikací včetně MVC. Pokud by cílem této práce byla reálná aplikace s nějakými vyššími ambicemi, pravděpodobně by jako nejvhodnější varianta vyšel Caliburn. Protože je ale cílem postavit prototyp, na kterém lze otestovat funkčnost navrženého konceptu, ukázal se jako vhodnější MVVM Light, a to ještě ve verzi pouhých knihoven, kde je nutné větší část infrastruktury implementovat ručně. 64

65 5 Architektura MVC Základní úlohou architektury MVC je stejně jako u MVVM rozdělit prezentační vrstvu aplikace do několika komponent, které mají úžeji vymezený úkol, čímž lze usnadnit její testování, údržbu a další vývoj. Architektura je založena na jednom z nejstarších návrhových vzorů, který se používal k návrhu uživatelských rozhraní v době, kdy ještě neexistovala Windows, a znovu získal na popularitě s příchodem třívrstvých webových aplikací. MVC inspiroval další vzory uživatelského rozhraní, jako je MVP (Model-View-Presenter), na kterém je založena architektura frameworku WindowsForms, a samozřejmě MVVM, který platí za současný standard. Schematické porovnání všech tří vzorů se vzájemnými závislostmi jejich komponent je na Obrázku 34. Obrázek 34: architektura prezentačních vzorů Zdroj: Zjednodušeně se dá říct, že komponenty Model a View jsou u všech vzorů stejné, takže se liší jen ta část, která zprostředkovává komunikaci mezi nimi. V případě MVC je touto komponentou Controller, který přejímá požadavky z View, předává je dále Modelu ke zpracování a rozhoduje na jaké View pošle výsledek. Právě pasivita View je přitom klíčový rozdíl oproti MVVM, kde díky datovým vazbám funguje neustálá oboustranná synchronizace mezi ním a ViewModelem. U MVC tato zpětná linka chybí, protože View ve standardní podobě nemá žádné techniky, jak událost z Controlleru přijmout a zpracovat. 65

66 Z toho vyplývá, že MVVM architektura je mnohem pokročilejší a umožňuje mnohem vyšší dynamiku rozhraní a uživatelský komfort. Bohužel je omezená tím, že všechny tři komponenty musí být reálně součástí jedné fyzické aplikace. Proto se také používá ve všech současných standardech desktopových a mobilních aplikací, které se instalují přímo na klientské zařízení. Standardem webových aplikací je naopak třívrstvá architektura, kde komponenty Model a Controller jsou provozované na serveru, zatímco jednotlivá View představují HTML stránky, zobrazované uživateli prostřednictvím webového prohlížeče. Spojení mezi prohlížečem a serverem probíhá prostřednictvím internetu, resp. protokolu http, který má jen omezené možnosti a je bezestavový, takže každá stránka se musí při každém požadavku znovu načíst a nepamatuje si nic o svém předchozím stavu. V praxi to znamená, že zatímco v lokálně instalované aplikaci není problém se dozvědět a nějakým způsobem okamžitě zareagovat na jakoukoli akci, kterou uživatel udělá, ve webové aplikaci server neví o ničem, dokud uživatel neodešle nějaký požadavek, který zároveň znamená znovu načtení stránky, nebo přechod jinam. Existuje mnoho technik, které se tento problém snaží řešit, či spíše maskovat tak, aby uživatel ani nevěděl, že k nějakému obnovování stránek dochází. Ty ale zase znamenají další speciální vrstvy na klientské i serverové straně, které navíc často používající úplně jiný jazyk a technologie, čímž se aplikace stává méně a méně přehledná. Využití MVC pomáhá vnést do této změti pořádek a prostřednictvím kontrolerů jasně určit, jaká činnost se má vykonat v reakci na každý konkrétní obdržený požadavek. 5.1 Http protokol Protokol http (Hyper State Transfer Protocol) představuje úzké hrdlo mezi serverem a uživatelem, jehož principy a omezení mají značný vliv na konečný návrh aplikace. Jedná se bezestavový protokol, který je založen na standardní klient/server architektuře, kde klient zasílá požadavek (Request) na určité unikátní URL, a server na základě tohoto URL požadavek zpracuje a vrátí odpověď (Response), která se zobrazí na klientovi. Základní schéma architektury je na Obrázku 35. Zatímco server je standardně jeden, klientů může být teoreticky nekonečně mnoho. Pokud tedy dojde k tomu, že se současně sejde více požadavků, server je seřadí do fronty a vyřizuje postupně v tom pořadí, v jakém přijdou. 66

67 Obrázek 35: architektura client/server Zdroj: Důležité je, že spojení pro každý požadavek a odpověď se navazuje pokaždé znovu a ihned po odeslání zaniká. Tzn., že neexistuje žádná otevřená linka, kde by si server a klient mohly izolovaně vyměňovat data po celou dobu, kdy má uživatel např. otevřené okno nějakého webu. Každý požadavek a odpověď je zabalen do tzv. http message, která jej pomáhá lépe identifikovat. Ta má dvě základní části: a) Header (Hlavička) obsahuje řídící informace požadavku a metadata popisující přenášený obsah; b) Body (Tělo) je volitelná a představuje vlastní přenášená data; Protokol http je univerzální, takže umožňuje přenášet různé typy dat, od html stránek, přes různá strukturovaná data, až po binární soubory. Konkrétní typ se určuje pomocí vlastnosti content-type, která je součástí hlavičky. Další důležitou vlastností je status-code, což je třímístný číselný kód, kterým server může popsat výsledek zpracování požadavku nebo identifikovat případnou chybu, která v průběhu zpracování nastala. Aby se nějak odlišilo, jaký typ požadavku klient zasílá, http protokol rozeznává čtyři základní metody: a) GET požadavek na získání existujících dat z nějakého URL. Server tato data vyhledá a zašle jako odpověď. b) POST požadavek na uložení dat, zaslaných standardně pomocí webového formuláře. Server zajistí jejich uložení na určené místo a vygeneruje URL, kde je možné je vyžádat. c) PUT požadavek na přepis existujících dat. Funguje podobně jako POST, ale součástí požadavku je existující URL, jehož obsah se nahradí. d) DELETE požadavek na smazání dat určeného URL. 67

68 U MVC aplikací se většinou využívají pouze první dvě metody, protože zbývající lze snadněji odlišit podle tvaru URL požadavku. Kontroler umožňující zpracování všech čtyř operací se často označuje jako CRUD kontroler, což je zkratka slov Create, Read, Update, Delete. Pro jakoukoli interakci uživatele s MVC aplikací platí, že je nutné ji přetransformovat do některé z těchto metod a přidělit jí URL na kterém čeká příslušná metoda určeného kontroleru, který je schopen požadavek zpracovat a zaslat odpověď. 5.2 ASP.NET MVC ASP.NET MVC je ve své současné verzi pokročilý framework, který se snaží držet hesla convention over configuration, což znamená, že čistý projekt inicializovaný ve VS je ihned připraven ke spuštění a pokud se programátor drží doporučených postupů, není potřeba žádné komplikované nastavení. Nejdůležitějším prvkem frameworku jsou kontrolery. Každý kontroler představuje samostatnou třídu, které je odvozená z třídy Controller a jeho název (bez slova Controller) standardně představuje i odpovídající část URL, na které může klient zasílat http požadavky. Pro vyřízení každého požadavku je automaticky vytvářena nová instance kontroleru, které po jeho vyřízení zaniká. [22] Životní cyklus http požadavku v MVC Každý http požadavek, který web server předá MVC aplikaci, musí nejprve projít procesem routování, což je pokus najít na základě obdrženého URL existující kontroler a metodu, které jsou tomuto URL přiřazeny. K tomu slouží jednoduchá routovací tabulka, která se automaticky iniciuje při prvním startu aplikace. Pokud je hledání úspěšné, MVC framework se postará o vytvoření instance příslušného kontroleru a zavolá požadovanou metodu. Metody kontroleru pro práci s http požadavky se v MVC označují jako Akce. Ty fungují jako zprostředkovatel mezi klientem a vlastní logikou aplikace a zároveň mají na starost zpětné zobrazení zpracovaného výsledku, přesměrování na jiný kontroler, apod. Akce reagující na požadavek typu POST nebo UPDATE mají jako parametr objekt, který očekávají na vstupu. Proto ještě před jejich zavoláním musí dojít k procesu zvanému model binding, což je pokus propojit obsah prvků formuláře obdržených jako obsah požadavku s konkrétními vlastnostmi modelu, který očekává Akce. Ten může být dvojího druhu. Buď se jedná o obecný objekt FormCollection, nebo přímo o konkrétní model aplikace. 68

69 Jakmile je požadavek zpracován, akce vrátí objekt typu ActionResult, který nejčastěji zahájí generování příslušné html stránky. K renderování samotných stránek slouží zvláštní komponenta ViewEngine, které bude věnována další podkapitola. Celý životní cyklus požadavku je zachycen na Obrázku 36. Obrázek 36: životní cyklus http požadavku v MVC aplikaci Zdroj: The Digital Thoughts Chetan Vihite blog Protože základní kostra kontrolerů se neustále opakuje, je v MVC možné využít tzv. scaffolding, který ji vygeneruje automaticky. Lze vygenerovat jak čistý kontroler, který není navázán na žádný model, nebo už pro konkrétní model určený kontroler. Výhodou druhého přístupu je, že na základě vlastností modelu zároveň vygeneruje i funkční kostry navazujících stránek pro provádění CRUD operací nad tímto modelem, čímž lze velice rychle získat funkční základ aplikace. Přímé předávání dat Standardní MVC architektura je bezestavová, takže nepoužívá žádné formy uchovávání klientských dat na serveru mezi požadavky. V praktickém provozu ale není úplně praktické, když se i případná konfigurační a stavová data aplikace s každým požadavkem přesouvají mezi serverem a klientem, proto ASP.NET MVC používá speciální objekt TempData, který umožňuje přímé předání dat mezi akcemi a kontrolery. Ten funguje jako slovník, do kterého se data pod klíčem dočasně uloží a poté v jiné akci opět vyzvednou. [23, s ] 69

70 Standardní životnost dat v TempData je pouze mezi dvěma http požadavky, takže se typicky používá k předání informací při přesměrování jedné akce na jinou. Pokud je potřeba data uchovat déle, je lepší využít objekt Session, který funguje podobně, ale data zůstávají uchovaná až do konce klientské session nebo vypršení volitelného timeoutu. Konfigurace aplikace K inicializaci služeb na aplikační úrovni slouží speciální soubor Global.asax, který funguje jako vstupní bod aplikace. Soubor obsahuje třídu MvcApplication, odvozenou z třídy HttpApplication, jejíž instance se vytváří vždy při zahájení nové klientské session. Proto funguje trochu jako sandbox, oddělující požadavky různých klientů aplikace. Názorně je to zobrazeno na Obrázku 37. Obrázek 37: instancování HttpApplication domain Zdroj: msdn.microsoft.com 70

71 Soubor Global.asax je společný pro všechny aplikační modely založené na ASP.NET a kvůli zpětné kompatibilitě se chová trochu nestandardně, na což je třeba pamatovat. I když se jeho obsah instancuje, zároveň obsahuje speciální metody ApplicationStart a ApplicationEnd, které se spouští pouze jednou při startu, resp. ukončení aplikace. Naopak umožňuje vložit řadu dalších speciálních metod, které se nezapisují jako přetížené, ale kterými je přesto možné přímo navázat nějakou logiku na události v životním cyklu každé instance. 5.3 Routování Routování je proces mapování serverem obdrženého URL na jednotlivé kontrolery, akce a jejich parametry v rámci MVC aplikace. Provádí se pomocí tzv. routovací tabulky, která se vytváří voláním metody RegisterRoutes ve třídě RouteConfig, iniciované prostřednictvím výše zmíněné metody ApplicationStart v souboru Global.asax. Každá routa je textový řetězec, který funguje jako maska očekávaného tvaru URL. V něm jsou pomocí složených závorek definované jednotlivé části, které jsou poté převedeny na odpovídající atributy. [23, s ] Každá nově vytvořená MVC aplikace už má registrovaný defaultní tvar routy pro základní CRUD operace, který je možné začít ihned používat, nebo upravit dle potřeby. Jeho defaultní podoba je na Obrázku 38. Obrázek 38: registrace defaultní routy v MVC Zdroj: Vlastní zpracování Nevýhodou definice pomocí RouteConfig je, že jakákoliv takto vytvořená routa platí globálně pro celou aplikaci. Proto s MVC5 přišla ještě možnost využít tzv. attribute routing, který umožňuje nastavit tvar routy samostatně pro každý kontroler nebo akci. Routa se v tomto případě zapisuje ve formě atributu a je automaticky upřednostněna před globální routou, takže oba způsoby lze v rámci aplikace kombinovat. 71

72 Oproti globálně definovaným routám umožňují routy v atributech mnohem přímější propojení s akcemi, ke kterým patří. Je tak možné např. omezit, na jaký typ objektu se má daná část URL pokusit namapovat, určit zda jde o povinný nebo volitelný parametr, nastavit parametru defaultní hodnotu, apod. [24] Na Obrázku 39 je příklad routy definované pomocí atributu, která slouží k předání filtračních parametrů pro výpis hardware. Vedle povinné proměnné active, může být součástí URL i volitelný parametr cat, který určuje číslo kategorie, podle které se má výpis filtrovat. Aby akce věděla, co má dělat v případě, že hodnota parametru v URL chybí, je pro každý volitelný parametr nutné určit jeho defaultní hodnotu. Obrázek 39: definice routy pomocí atributu Zdroj: Vlastní zpracování Ne vždy je ale nutné k vykonání akce využít routy. Často je naopak potřeba, aby jedna akce kontroleru přímo spustila akci na jiném kontroleru, případně jí předala nějaké parametry, které by normálně přišly jako součást URL. Pro tento případ nabízí MVC speciální metody RedirectToAction and RedirectToRoute, které standardní proces routování obchází a buď přímo zavolají určenou akci, nebo routu, pokud má přidělené jméno. 5.4 View Engine ViewEngine je speciální komponenta ASP.NET aplikace, která je zodpovědná za genervání HTML stránek, které jsou odeslané zpět na klienta. Zpravidla funguje tak, že vezme nějakou počáteční statickou HTML šablonu a do té pomocí speciální syntaxe doplní data, případně další prvky, které jsou předané kontrolerem. Původní ViewEngine ASP.NET MVC frameworku byl společný se sesterským frameworkem ASP.NET WebForms, nicméně od verze MVC3 je defaultním ViewEnginem Razor. Ten je velmi úsporný na zápis a lehký na učení, protože používá jen minimum speciální syntaxe a namísto toho jen kombinuje standardní HTML tagy s jazykem C#. 72

73 K odlišení C# syntaxe od HTML používá Razor magický Ten může uvozovat buď proměnnou, funkci, nebo celý delší blok kódu, tzv. code nugget, který se vloží mezi složené závorky. Razor je přitom natolik inteligentní, že i v rámci takového bloku je pořád schopen rozlišit, pokud narazí na HTML tag a ten do výsledné stránky správně vložit. [23, s ] Nejvýhodnější způsob předávání dat pro ViewEngine je pomocí modelů. Ty je možné definovat pomocí speciálního kterému se přiřadí typ modelu, se kterým chceme ve View pracovat. Kromě toho existují ještě speciální objekty ViewBag a ViewData, které slouží k předávání libovolného obsahu mezi kontrolerem a ViewEnginem. ViewData fungují podobně jako TempData a jedná se o slovník objektů, které je možné zpětně vyvolat pomocí klíče. Naopak ViewBag je speciální prvek, který skutečně funguje jako batoh, do kterého lze vložit jakýkoli objekt. Každý nový prvek se totiž přidá jako nová, dynamicky typovaná vlastnost. Oproti ViewData to znamená, že ani u složitějších objektů není nutné řešit jejich typ a zpětné přetypování, protože ten se dynamicky doplní přímo při vytvoření vlastnosti. Zároveň je ale potřeba zvýšená opatrnost, protože VS nijak neupozorní, pokud předávané typy nesedí a vše se projeví až pádem při chodu aplikace. Vedle práce se samotnými daty má Razor několik speciálních příkazů, které slouží k tvorbě layoutu. Ten funguje jako HTML šablona, do které se na určených místech použitím vkládají další hotové části HTML kódu, čímž je poskládána výsledná stránka. Zatímco první z nich slouží k vložení různých opakujících se částí typu menu, druhý vkládá hlavní unikátní obsahovou část stránky. Posledním často užívaným prvkem ViewEngine jsou tzv. Helpery. Ty umožňují rychle vložit do stránky nejpoužívanější HTML tagy a nastavit jejich parametry pomocí vlastností zobrazovaného modelu, proměnné, apod. Jde ale jen o pomůcku, kterou v žádném případě nelze zaměňovat s datovými vazbami MVVM. Každý helper je v podstatě do objektu zapouzdřená HTML šablona, která na určených místech vloží hodnoty vlastností přiřazeného objektu, a pak pomocí metody Render vytvoří výsledný HTML tag. [23, s ] Po odeslání stránky už neexistuje žádná zpětná vazba a tag vytvořený pomocí Helperů se nijak neliší od tagů zapsaných ručně. 73

74 6 Seznámení s návrhem Cílem této a následující kapitoly je provést praktické ověření teoretických předpokladů, ze kterých vychází tato práce a kterým byly věnovány předchozí kapitoly. Ověření bude provedeno pomocí vývoje reálné prototypové aplikace, resp. celého řešení (Solution) Visual Studia, které bude zahrnovat několik projektů. Jeho základní principy a idea byly představeny již v úvodu, tato kapitola proto představí modelový scénář, ze kterého vychází ověřovací aplikace, a pak i jednotlivé projekty. V další kapitole poté dojde k jejich naplnění konkrétním obsahem. 6.1 Ověřovací aplikace Problémová doména aplikace je evidence HW nějaké středně velké firmy. Tu má velmi často na práci samotné IT oddělení, které ji řeší buď pomocí specializovaného programu, který je často postavený ještě na platformě WinForms, nebo jen s využitím excelovské tabulky. V obou případech platí, že jde o řešení primárně desktopové, zatímco pro rychlou a efektivní práci by se naopak hodila mobilní aplikace, kterou by měl správce okamžitě po ruce. HW je totiž často špatně dostupný, rozmístěný po mnoha místech budovy, a různé dočasné zapisování evidenčních nebo výrobních čísel a jejich dodatečné dohledávání v kanceláři značně zdržuje. Na druhou stranu je občas nutné aplikaci naplnit daty, a proto se lépe hodí klasická klávesnice a velký monitor. Pokud by firma už měla za sebou migraci na Windows 10, daly by se oba požadavky skloubit vývojem takové UWP aplikace, kterou lze dobře používat i na desktopu. Jenže firma neplánuje přechod až do roku Situaci navíc komplikuje, že firma má více poboček, mezi kterými správce nepravidelně cestuje, takže nemá ani stálou kancelář. Scénář byl úmyslně zvolen tak, aby šlo dobře ověřit hlavní cíl prototypu, kterým je možnost využití již napsaných MVVM ViewModelů UWP aplikace pro MVC webovou aplikaci. Naopak, co projekt v této fázi neřeší, je otázka zabezpečení, autorizace a autentifikace, stejně jako případné práce více uživatelů. Výsledná aplikace bude umožňovat následující funkčnosti, a to bez ohledu na to, zda je spuštěná na mobilu nebo v prohlížeči: a) Evidence (CRUD operace) jednotlivého HW; b) Evidence (CRUD operace) uživatelů tohoto HW; c) Možnost rozdělovat uživatele do oddělení a HW do kategorií; 74

75 d) Možnost oddělení a kategorie vytvářet a mazat; e) Validace zadávaných dat; f) Zablokovat a zobrazit upozornění ve chvíli, kdy se pokusí smazat kategorii nebo oddělení, která nejsou správná; g) Zobrazení detailu uživatele s výpisem HW, který má přiřazen; h) Možnost tento HW uživateli přidat a odebrat; i) Filtrování výpisu uživatelů podle oddělení; j) Filtrování výpisu HW podle dat; k) Vyhledávání v datech podle uživatele a inventárního čísla HW Z nefunkčních požadavků je základním požadavkem mobilita, neustálá dostupnost a konzistence dat v obou verzích. Jak mobilní, tak webová verze proto budou sdílet společný datový backend hostovaný v MS Azure, kde bude zároveň hostována i samotná webová aplikace. Jediným prvkem instalovaným lokálně tak bude klientská část UWP aplikace. 6.2 Solution aplikace Veškeré projekty tvořící obě aplikace budou soustředěné v rámci jednoho Solution Visual Studia, jehož podoba je logicky rozvržena tak, aby jedinou částí, kterou je potřeba programovat pro každou aplikaci samostatně, je uživatelské rozhraní. Všechny prvky včetně databáze a vzájemných vlastností jsou na Obrázku 40. Základem řešení jsou dvě knihovny přenosných tříd (Portable Class Library), jejichž princip byl popsán v kapitole popisující vývoj aplikací ve Windows. Do první z nich jsou soustředěné ViewModely a navazující logika UWP aplikace, zatímco druhá funguje jako REST klient pro webové REST API rozhraní, prostřednictvím kterého si aplikace vyměňuje data s cloudovou databází. Rozhraní REST je samostatný projekt, který nemá žádné reference na žádné části Solution. Díky tomu lze výhodně využít novou službu Azure APP Api pro hostování backendu aplikací v MS Azure. Samotná UWP aplikace je postavena na frameworku.net Core Universal Windows, zatímco MVC webová aplikace na tradičním.net Framework 4.5. Každá z aplikací proto mají 75

76 svůj nativní projekt, ve kterém je soustředěno jejich jádro a všechen zbývající kód, který není možné umístit do knihoven přenosných tříd. Poslední částí řešení je cloudová SQL databáze. Její zprovoznění spočívá ve třech krocích. Založení a spuštění cloudového serveru MS SQL 2012, založení prázdné databáze a naplnění této databáze daty. Obrázek 40: rozdělení projektů aplikace Zdroj: Vlastní zpracování Jelikož je řešení téměř výhradně cloudové, proběhne finální nasazení aplikace využitím funkce Publish Visual Studia. Ta umožňuje vzdálené nahrání hotové aplikace do připraveného běhového prostředí Azure a automatické vytvoření veřejného URL, pod kterým k ní lze na internetu přistupovat. Výjimkou je frontend UWP aplikace, který bude testován nejprve pomocí emulátoru Windows 10 zařízení ve VS, a poté i na mém vlastním telefonu s Windows 10. Obě podoby aplikace se tak dočkají i testování v reálných podmínkách. 6.3 Použité technologie Z textu výše vyplývá, že projekt zahrnuje i některé další technologie, kterým nebyl v teoretické části věnován prostor, protože nejsou klíčové pro cíl této práce. Následující text se je pokusí alespoň stručně představit: 76

77 Microsoft Azure Neustále se rozšiřující sada integrovaných cloudových služeb podporující širokou škálu operačních systémů, programovacích jazyků a technologií. Druhá nejpopulárnější cloudová služba na světě po Amazon Web Services (AWS), která pro společnost představuje nejvyšší prioritu. Služby Azure jsou proto stále více integrovány do dalších vývojářských nástrojů Microsoftu, jako jsou Visual Studio, Team Services apod. Služby Azure nejsou zadarmo a k jejich čerpání je nutné nejprve založit Microsoft Account. Nicméně účtuje se po vteřinách, a to až při překročení určitého základního limitu na množství čerpaných služeb a jejich výkon. Ty jsou poměrně benevolentní, nebo je možné využít řady speciálních programů. Pro účely testování nebo studentské pokusy je tak většinou možné se vejít do limitu zdarma. REST API Jedná se o zkratku slov Representatonal State Transfer, což není název technologie, ale sady architektonických rad a doporučení pro návrh určitého druhu API. API, které doporučení dodržuje, se poté často nazývá RESTful API, oba názvy se ale často zaměňují. V současné době se jedná o asi nejpopulárnější typ rozhraní, pokud jde o výměnu dat mezi zařízeními na internetu, resp. prostřednictvím protokolu http. Základní požadavky kladené na RESTful API jsou: a) Konzistence napříč celým API. b) Bezestavovost tj. žádné uchovávání klientských session na serveru mezi požadavky. Session zůstávají na klientovi, odkud si je server v případě potřeby vyžádá. c) Využívání http status kódů a metod k bližšímu určení požadavků. d) Struktura URL tvořících API logicky odpovídající struktuře dat, které API sdílí. Základní schéma API je na Obrázku 41, ze kterého je také zřejmá podobnost s fungováním MVC webové aplikace. Každý příchozí http požadavek obsluhuje na serveru konkrétní metoda nějakého kontroleru, který vyžádá dále z nitra aplikace potřebná data a následně připraví http odpověď. Klíčový rozdíl je, že tato odpověď obsahuje data ve strukturované podobě dobře čitelné jinému zařízení. 77

78 Obrázek 41: princip REST API Zdroj: restful-api-design.readthedocs.io Praktická podoba REST API v navrhovaném řešení je založená na ASP.NET Web API 2. Od běžné webové MVC aplikace se liší především třídou ApiController, od které jsou odvozené všechny kontrolery. Samotná data jsou předávána pomocí formátu JSON (JavaScript Object Notation), který umožňuje převádět objektová data do strukturované textové podoby a jejich zpětnou rekonstrukci. Oproti XML sice nemá tolik možností, ale je velmi úsporný na zápis a jeho syntaxe je snadno pochopitelná a čitelná, což usnadňuje kontrolu. Proces převodu mezi objektovými daty a formátem JSON se nazývá serializace a deserializace. V dřívějších verzích ASP.NET se nejednalo o úplně triviální záležitost, protože přenášené objekty musely mít určitou podobu a jejich vlastnosti bylo potřeba opatřit speciální anotací. V aktuální verzi je využíváno služeb externí knihovny NewtonSoft.Json, která se při vytvoření projektu automaticky stáhne pomocí GitHubu. Ta už je natolik pokročilá, že objekt pouze stačí vložit jako požadovanou odpověď metody kontrolleru, vše další proběhne automaticky. Samotný REST klient je založen na nativní komponentě.net frameworku 4.5 HttpClient, která slouží k zasílání a přijímání http požadavků a odpovědí. Požadavek se jednoduše poskládá, nastaví cílové URL, kam se má poslat, a poté zpracuje odpověď. HttpClient je nedávno uvedená komponenta, která je primárně určená právě pro vytváření aplikací, jejichž backend komunikuje prostřednictvím REST API. Oproti dříve používané komponentě WebClient pracuje asynchronně, je univerzálně použitelná a jedna instance současně zvládá vyřizovat více požadavků, takže práce s ní je mnohem komfortnější. 78

79 Databázový systém MS SQL Základem vrstvy perzistence dat je databázový systém MS SQL Server 2014, rovněž provozovaný v Azure. Jedná se o jeden z nejvyužívanějších systémů relační databáze, který v základní verzi Express nabízí společnost zdarma, takže jej mohou využívat i jednotlivci. Základní práce s databází spočívá ve formulaci čtyř základních typů příkazů: a) DML slouží k manipulaci přímo s vlastními daty databáze; b) DDL slouží k definici struktury databáze a jednotlivých tabulek; c) DCL - slouží k přidělování práv; d) TCL slouží k řízení transakčního zpracování. Pro komfortnější práci je možné využít programu SQL Management Studio, který je rovněž zdarma a umožňuje spravovat databázi a její pokročilejší funkce pomocí grafického rozhraní. Management studio umožňuje připojení k libovolné MS SQL databázi, pokud k ní má uživatel práva, a to bez ohledu na to, zda běží lokálně, nebo vzdáleně. V případě připojení cloudové databáze Azure jsou ale jeho možnosti omezené jen na spouštění DDL a DML skriptů, proto je výhodnější databázi nejprve vyvinout někde stranou lokálně a na cloud přenést, až když je hotová. Další možností je navrhnout si datový model v některém ze specializovaných programů, který má funkci automatického převodu modelu do podoby zakládacích skriptů. Entity Framework 6 Jedná se o nativní součást tzv. ADO.NET komponenty frameworku.net, která slouží k objektově relačnímu mapování; tedy převádění objektů do podoby prvků (tabulek a jednotlivých záznamů) relační databáze, případně naopak. Entity Framework (EF) umožňuje vytvořit v aplikaci speciální objekt typu DbContext, který představuje vstupní bod databáze, a namapovat jednotlivé tabulky a jejich obsah na kolekce odpovídajících entit typu DbSet. Klíčové je, že namapování probíhá včetně všech relací, takže v místech cizích klíčů dojde k napojení na objekty navazujících tabulek a výsledná data lze pak pomocí tečkové konvence snadno procházet. Vytvoření DBContextu je možné pomocí jednoduchého průvodce, na jehož konci dojde k vygenerování speciálního connection stringu, který EF říká, kde reálně se databáze nachází. Připojení cloudové verze se přitom výrazně neliší od připojení lokální databáze. 79

80 7 Backend aplikace Vývoji finální verze aplikace předcházelo několik testů, takže panovala poměrně jasná představa, jaká data by měl backend aplikace poskytovat. Proto byla zvolena metoda data-first a navržen nejprve datový model, který je na Obrázku 42. Následovalo zprovoznění serveru MS SQL v cloudu Azure a převod modelu do podoby databáze. Obrázek 42: datový model aplikace Zdroj: vlastní zpracování Dalším úkolem bylo vybrat vhodnou Azure službu, na kterém bude běžet REST API aplikace. Právě tady se situace od prvních testů změnila pravděpodobně nejvíce, protože ty ještě využívaly službu Mobile App, na kterou byla následně portována standardní ASP.NET MVC aplikace založená na šabloně Web API. Mezitím ale cloud Azure přišel s novou službu API Apps, která je přímo určená pro provozování cloudových API. Její podpora byla integrována do Update2 poslední verze Visual Studia a po prvním rychlém projití webového tutoriálu vzorové aplikace jsem se rozhodl převést projekt na ni. 80

81 7.1 DTO třídy Následovalo připojení databáze k projektu pomocí Entity Framework, tím i vygenerování příslušného kontextu databáze a modelů jednotlivých tabulek, resp. objektů. U malých projektů, jako je tento, se často stává, že databázové entity a vlastní modely aplikace se shodují, což vede k tomu je i tak využít. Tím se ale velmi komplikují další změny a rozvoj modelu. Případné změny EF modelu totiž mají přímý vliv na celý zbytek aplikace, zatímco pokud se EF entity nejprve přemapují na samostatné objekty, zůstávají změny izolované na jednu vrstvu. Je tedy až na vývojáři, jak a kdy je pustí dále do aplikace. V případě webového API je také dobré myslet na to, že řada ViewModelů bude reálně zobrazovat data z více entit současně, ale komunikace s API byla měla proběhnout ideálně v rámci jednoho dotazu. Proto aplikace využívá speciální DTO (Data Transfer Object) třídy, které slouží výhradně k přenosu dat mezi API a klientem a jsou navržené tak, aby minimalizovaly datové nároky při chodu aplikace. Na straně API tedy nejprve dochází k mapování entit EF na DTO třídy, ty jsou prostřednictvím http protokolu přenášeny na klienta, kde jsou znovu transformovány na modely aplikace. Aby se s DTO objekty lépe pracovalo, předepisuje schopnost transformace z EF entit a opačně rozhraní IHasDTOConverter. Rozhraní předepisuje metody ConvertFrom a ConvertTo, které všechny DTO objekty musí implementovat. Obrázek 43: převod EF kolekcí na DTO kolekce Zdroj: Vlastní zpracování Jako konvertor kolekcí slouží třída DataTranform, která je schopná transformovat kompletní DbSet do odpovídající kolekce DTO objektů. Základem je statická třída Activator, jež 81

82 s pomocí metody CreateInstance umožňuje přímo vytvářet instance objektů typu, který je předaný jako první z parametrů metody. Implementace třídy je na Obrázku Swagger anotace Samotné API je tvořené standardními kontrolery ASP.NET založenými na třídě ApiController, které vrací objekty realizující rozhraní IHttpActionResult. Ty umožňují přímo specifikovat status kód vracené http odpovědi a zároveň do těla této odpovědi vložit objekt, který je automaticky serializován do formátu JSON. Zásadní předností využívaného projektu Azure APP Api je technologie Swagger, která pomocí anotací jednotlivých metod kontroleru umožňuje specifikovat typy odpovědi a objektu, které metoda odesílá. Na základě této anotace se po spuštění projektu automaticky vygeneruje přehledné webové rozhraní, kde je možné všechny metody API vyzkoušet. Zároveň je i vytvořen speciální swagger popis celého rozhraní, který plně automatizuje následné vytvoření klienta. Obrázek 44: využití swagger anotace k popisu API Zdroj: Vlastní zpracování Na Obrázku 44 je ukázka kódu swagger anotace, která popisuje metodu Get kontroleru HWUsersController, vracející buď http status kód 200 Ok a kolekci prvků DTO_UserSimple, nebo http status kód 503 Service Unavailable. Na Obrázku 45 je potom výsledná podoba webového rozhraní hotového REST API aplikace vygenerovaného pomocí Swagger, a to po jeho nahrání na cloud Azure. 82

83 Obrázek 45: webové rozhraní REST API aplikace Zdroj: Vlastní zpracování Z rozhraní jsou jasně zřejmé jednotlivé logické části, metody a požadovaný tvar URL, kterým se lze k datům API dostat. Každou z metod lze přitom dále rozbalit a podívat se, s jakými status kódy a případně JSON objektem metoda pracuje. 7.3 REST Client Na klientské straně s API komunikuje klient, jehož kód je prostřednictvím knihovny přenosných tříd sdílen jak s UWP, tak MVC aplikací. Ten byl z velké části vygenerován automaticky prostřednictvím technologie Swagger, zmíněné výše. Pro přidání nového API popsaného pomocí Swagger stačí ve Visual Studiu v podmenu Add vybrat položku REST Client. Následně se otevře průvodce, kde je možné vybrat buď existující Azure projekt, nebo přímo URL, na kterém se nachází Swagger popis připojovaného rozhraní. Výsledkem je kompletní sada automaticky vygenerovaných metod pro všechna popsaná volání REST API a přenesené DTO objekty, umožňující serializaci i deserializaci přenášených objektů. Bohužel, v případě této práce generování neproběhlo zcela hladce, protože bylo potřeba nejprve ručně doplnit mezi reference externí knihovnu NewtonSoft.Json, která se z nějakého důvodu odmítala stáhnout automaticky. A další obtíže přineslo vložení vygenerovaného klienta do knihovny přenosných tříd, kdy se začal nestandardně chovat proprietární objekt Rest.ClientRuntime. 83

84 Naštěstí, ten většinu svých funkcí dědí ze standardní třídy HttpClient frameworku.net, takže se obtíže povedlo vyřešit nahrazením touto třídou, aniž by bylo nutno rozhraní nějak výrazněji upravovat. Jeho konečná vygenerovaná podoba je na Obrázku 46. Obrázek 46: výsledek generování REST klienta Zdroj: Vlastní zpracování 84

85 8 Windows 10 UWP Aplikace Úkolem této části bylo vytvořit funkční prototyp UWP aplikace, která bude postavena na MVVM architektuře a v další části umožní pokud možno bezproblémové napojení vytvořených ViewModelů na kontrolery a HTML stránky MVC aplikace. Výsledný design je primárně směřován na mobilní telefony, čemuž je přizpůsobena i logika ovládání a počet a prvky jednotlivých View, resp. ViewModelů aplikace. 8.1 Architektura aplikace Základem MVVM architektury testovací aplikace jsou bázové knihovny frameworku GalaSoft MVVM Light Toolkit, které jsou doplněné jak do nativního projektu UWP aplikace, tak do projektu SharedLibrary, kde jsou umístěné ViewModely a další sdílená logika aplikace. Návrh vychází z principů Dependency Injection a Inversion Of Control, které byly podrobně popsány v předchozích kapitolách. Obrázek 47: MVVM architektura testovací aplikace Zdroj: Vlastní zpracování 85

86 Základní schéma architektury je na Obrázku 47. Instancování všech služeb probíhá pomocí objektu ViewModelLocator, který se iniciuje při spuštění aplikace. Při jeho inicializaci současně dochází k nastavení GalaSoft SimpleIoC kontejneru jako ServiceLocator providera aplikace a jsou zaregistrované rozhraní nebo přímo typy všech využívaných služeb. ViewModelLocator obsahuje veřejné vlastnosti pro všechny zaregistrované objekty. Ty fungují jako prostředník, jehož prostřednictvím je možné získat z kontejneru jejich aktuální instanci. Všechny zaregistrované ViewModely fungují jako singleton, jejichž instance je vygenerována ve chvíli, kdy uživatel poprvé vstoupí na odpovídající stránku, a poté již zůstávají v paměti. Naopak služby AzureDataService a NavigationMenu jsou inicializované ihned při startu aplikace. Zvláštním případem je služba NavigationService, která musí být součástí nativního projektu aplikace a nelze ji zaregistrovat přímo. Proto vedle obecného ViewModelLocator existuje ještě odvozený UWPViewModelLocator, který v konstruktoru nejprve iniciuje obecný lokátor a poté rozšiřuje registrace v IoC kontejneru o služby specifické pro UWP aplikaci. Praktické provedení je na Obrázku 48. Obrázek 48: iniciace UWPViewModelLocator Zdroj: Vlastní zpracování Služba AzureDataService realizuje rozhraní IDataService, který předepisuje funkce REST klienta. Toho lze s výhodou využít zejména při návrhu designu aplikace, kdy je možné jako zdroj používat jakoukoli jinou službu, která realizuje stejné rozhraní, ale nepoužívá cloud, ale jen statická data. 86

87 Jednotlivá View přistupují k ViewModelům pomocí instance UWPViewModelLocatoru, který je nastaven jako Application.Resource vstupního souboru aplikace App.xaml.cs. Jako společný předek všech ViewModelů slouží třída CommonViewModel, která rozšiřuje funkce bázové třídy ViewModelBase z frameworku MVVM Light. Ve všech ViewModelech je tak možné okamžitě používat pro datové vazby klíčovou událost RaisePropertyChanged a služby GalaSoft Messaging. 8.2 Vzhled aplikace Při návrhu vzhledu bylo cílem, aby aplikace byla funkční, ale strohá, proto jsou použité hlavně základní prvky, popsané v kapitole 3. Aplikace používá pro zobrazení stránek dva prvky Frame. Rámec MainFrame funguje jako obálka aplikace, ve kterém je umístěna stránka Main- Page, která definuje základní layout a pomocí prvku RelativePanel umožňuje zobrazit hlavní překryvné menu. Druhý rámec ContentFrame slouží k zobrazování jednotlivých obsahových stránek aplikace a je využíván k navigaci. Základní layout aplikace je na Obrázku 49. Obrázek 49: základní layout aplikace Zdroj: Vlastní zpracování 87

88 Protože standardní služba NavigationService, která je součástí knihoven MVVM Light neumožňuje změnu prvku Frame používaného k navigaci, aplikace implementuje vlastní službu CustomNavigationService. Ta nejprve realizuje rozhraní INavigationService a poté jej rozšiřuje o další metody. K nastavení aktivního Frame dochází pří spuštění aplikace v rámci kódu souboru App.xaml.cs, jehož část je na Obrázku 50. Obrázek 50: nastavení ContentFrame aplikace Zdroj: Vlastní zpracování Nejprve je pomocí vlastnosti Content hlavního rámce rootframe získán objekt stránky MainPage, na kterém je pomocí veřejné vlastnosti MainPageFrame zpřístupněn prvek customframe. Následuje využití služby ServiceLocator, resp. IoC kontejner, pro získání platné instance služby CustomNavigationService. Protože metoda SetMainFrame není definována přímo na rozhraní INavigationService, je potřeba přetypovat objekt získaný z kontejneru zpět na původní typ. Pak už je možné metodu zavolat a nastavit instanci customframe jako nový hlavní Frame pro navigační servis. Poslední řádka využívá takto překonfigurované služby a spouští navigaci na stránku, která se zobrazí jako obsah customframe při startu. 8.3 Navigace Navigace mezi View je řešena pomocí navigační služby CustomNavigationService, která zapouzdřuje nativní funkce Navigate a GoBack prvku Frame. K inicializaci a konfiguraci služby dochází v rámci třídy UWPViewModelLocator při startu aplikace. 88

89 Obrázek 51: konfigurace klíčů pro NavigationService Zdroj: Vlastní zpracování Aby byla navigace maximálně intuitivní, jsou jako klíče každého View využívána plná jména odpovídajících ViewModelů. Ukázka konfigurace služby je na Obrázku 51. Na třídě CustomViewModel jsou zároveň definované metody, které umožňují volání navigační služby přímým předáním typu ViewModelu. Protože způsob navigace v MVC aplikaci je radikálně odlišný a využití navigačního servisu není možné, jsou všechna volání služby podmíněná, a to pomocí vlastnosti IsNavigationAvailable. Její definice je na Obrázku 52. Vlastnost zapouzdřuje výsledek volání metody IsRegistered na kontejneru SimpleIoC, kterou je možné ověřit registraci libovolné služby. Obrázek 52: ověření registrace INavigationService Zdroj: Vlastní zpracování 8.4 Předávání parametrů Předávání parametrů mezi ViewModely je řešeno dvěma způsoby. Jednak využitím služby Messenger frameworku MVVM Light, která již byla popsána v teoretické části, tak předáváním parametrů pomocí metody Navigate navigační služby. V tomto případě tedy dochází k využití code-behind, ve kterém je předávaný parametr v rámci metody OnNavigatedTo odchycen, otestován, přetypován na správný typ a vložen jako hodnota odpovídající vlastnosti ViewModelu. Praktická ukázka, která slouží k nastavení filtrace uživatelů dle oddělení pomocí jeho ID je na Obrázku

90 Obrázek 53: předání parametrů pomocí code-behind Zdroj: Vlastní zpracování Toto řešení bylo zvoleno, protože jinak šlo jen špatně spolehlivě zajistit, že k předání parametru dojde i v případě, že na stránku adresáta uživatel vstupuje poprvé. Pro využití messengeru je totiž nutné, aby se adresát nejdříve zaregistroval, jenže to je možné nejdříve při inicializaci objektu. Naopak SimpleIoC kontejner nevytvoří instanci zaregistrovaného objektu dříve, než si ji někdo poprvé vyžádá. Existuje sice i možnost nastavit kontejner tak, aby všechny služby automaticky inicioval už při startu, ale tato možnost zas komplikuje start aplikace. Některé ViewModely při inicializaci stahují různé úvodní seznamy a jinak komunikují s backendem aplikace. Pokud by k jejich startu došlo najednou, start aplikace by se neúnosně prodloužil. 8.5 Validace Všechny validace aplikace využívají speciálního prvku ValidationTextBox, který je součástí kolekce různých hotových prvků vzhledu aplikace WinUX UWP Toolkit. Autorem kolekce je James Croft a je k dispozici v rámci MIT licence na GitHubu. Prvek umožňuje provádět všechny základní typy validací typu délka stringu, ověření numerického vstupu, platný tvar u, regulární výrazy, apod. Jeho velkou výhodou je, že požadované validace se dají nastavit jak přímo v rámci XAML definice stránky, tak využít i validační objekty, které tvoří jejich pozadí. Ty nemají žádnou závislost na nativní třídy UWP aplikace, takže je možné zavolat je přímo z ViewModelu a tím získat univerzální validační řešení, které je funkční jak pro UWP, tak MVC aplikaci. 90

91 9 ASP.NET MVC aplikace Cílem poslední části práce bylo převést existující ViewModely a další logiku UWP aplikace do podoby ASP.NET MVC aplikace. Protože hlavní myšlenka za celou prací je umožnit, aby vývoj této náhradní aplikace byl co nejjednodušší, záměrně bylo maximálně využíváno defaultních šablon, nastavení, scaffoldingu, a další technik frameworku, které mají vývoj co nejvíce ulehčit. Následující text se proto věnuje jen těm oblastem, které se liší od standardního návrhu. 9.1 Architektura aplikace MVC aplikace využívá k vytváření instancí jednotlivých objektů framework Microsoft Unity, což je v podstatě varianta IoC kontejneru určená pro MVC. Ačkoli není problém využívat přímo původní SimpleIoC kontejner ze sdíleného projektu, ten není určen pro webové aplikace a jednotlivé registrované objekty jsou proto instancované jen na úrovni aplikace. Naopak Unity má celou řadu vestavěných tzv. time managerů, postavených na společné bázové třídě LifetimeManager, které umožňují blíže nastavit životnost instance v kontejneru. Defaultně kontejner využívá TransientLifetimeManager, který instance registrovaných objektů neukládá a při každém požadavku vytváří novou. Opačný extrém je ContainerControlledLifetimeManager, který instance drží po dobu životnosti kontejneru, takže uložené objekty se chovají jako sigleton. Problém s převodem ViewModelů, jejichž logika počítá s životností po dobu běhu aplikace je v tom, že v MVVM existuje jen jeden uživatel, který ji zapne a také ukončí. Naopak webová aplikace může běžet na serveru neomezeně dlouho a sdílet ji současně mnoho uživatelů. Pokud ViewModel uchovává stav jednoho uživatele, není možné ten samý ViewModel zobrazit dalšímu uživateli. Proto aplikace využívá svůj vlastní SessionLifeTimeManager, který zaregistrované objekty uchovává po dobu životnosti Session přihlášeného uživatele. Konkrétní implementace třídy je na Obrázku 54. Třída přetěžuje původní metody bázové třídy TimeManager a využívá standardní prvek Session jako dočasné úložiště. Jako klíče je přitom z výhodou využíváno plné jméno ukládaného objektu. 91

92 Obrázek 54: vytvoření SessionLifeTimeManager Zdroj: Vlastní zpracování Nastavení a registrace objektů do Unity kontejneru probíhá ve třídě UnityConfig, jejíž obsah se automaticky vygeneruje při vložení frameworku Unity do projektu. Podobně jako u IoC je možné zaregistrovat buď přímo existující instance, konkrétní typy, nebo jen rozhraní. Současná podoba frameworku je už velmi pokročilá, takže není nutné registrovat samotné kontrolery. 9.2 Převod UWP prvků Následující text je souhrnem zkušeností a poznatku získaných při převodu prvků UWP aplikace na ViewModely. Určitě není kompletní a zkušenější programátoři by bezpochyby byli schopní navrhnout efektivnější řešení, nicméně i tak je možné jej brát jako odhad toho, kolik práce navíc transformace jednoho typu na druhý představuje. ViewModely Použití existujících MVVM ViewModelů UWP aplikace jako modelů v MVC aplikaci je relativně bezproblémové, až na výjimky typu volání navigační služby, která v MVC nemá žádný přímo použitelný ekvivalent. Problém představuje volání různých inicializačních metod přímo v konstruktoru ViewModelu. Zatímco UWP aplikace takový seznam zobrazí a drží v paměti, bez ohledu na to, kolik dalších funkcí uživatel z příslušné stránky zavolá, MVC bude danou metodu volat znovu a znovu při každém http požadavku, který uživatel zašle na kontroler. 92

93 Je proto lepší zavolat danou metodu přímo z akce, ve které je její výsledek opravdu potřeba, nebo použít řešení s pomocí IoC kontejneru a dependence injection, které bylo představené v předchozí podkapitole. Commandy Volání funkcí, které v UWP uživatel iniciuje pomocí commandů, je nejrychlejší ošetřit přímo zavoláním metody, kterou daný command zabaluje. Metody ale musí být napsané tak, aby se jejich provedení dalo dobře převést na vyřízení jednoho http požadavku. Zároveň musí vždy jasně sdělit svůj výsledek, na základě kterého je pak možné v akci kontroleru rozhodnout, jaká akce má následovat dál. Hodnoty různých mezivýpočtů, které se v UWP dynamicky zobrazují uživatelům, je možné odchytit z veřejných vlastností, které prvky UWP stránek používají pro datové vazby. U běžných CRUD kontrolerů ale nemá moc smysl, používat celý ViewModel i jako model pro generování View. Pokud je např. potřeba zobrazit seznam prvků nějaké entity, plus pár doprovodných vlastností, je jednodušší postavit View přímo na modelu entity a doprovodné vlastnosti pak dodat přes ViewBag nebo ViewData. Navigační servis V MVC není žádný ekvivalent, který by se mohl jednoduše použít jako MVC realizace rozhraní INavigationService. Všechna volání navigační služby je proto nutné izolovat, aby nezpůsobovala pád aplikace a navigaci mezi stránkami vyřešit pomocí standardních metod MVC aplikace. Volání funkcí z View Zde je situace podobná. UWP aplikace používá k volání funkcí ViewModelu datové vazby, napojené na příslušný command, který zabaluje volanou metodu. Oproti tomu v MVC se zavolání funkce rovná odeslání http požadavku. Pro každé takové volání tedy musí být na MVC aplikaci připravená routa, která jej identifikuje a předá příslušnému kontroleru a akci. Ta pak v rámci svého těla zavolá metodu, kterou původně zabaloval command. Existuje i pokročilejší řešení v podobě různých klientských nástaveb typu frameworku MVC Knouckout, které umožňují simulovat některé vlastnosti MVVM stránek i ve webovém prostředí. Jedná ale o další nadstavbu, která celou transformaci zbytečně zesložiťuje a jde tak proti zadání této práce. 93

94 Messenger Service Samotný messaging funguje v obou typech aplikací. Ve standardní podobě MVC aplikace se ale jen málokdy stane, že se objekty adresáta i odesílatele stihnou zaregistrovat dříve, než dojde k vyřízení http požadavku a jejich životnost skončí. Naopak při využití dependency injection a nastavení držení instancí na delší dobu, je třeba pamatovat na to, aby se nezdvojovalo případné volání funkcí, které jsou reakcí na obdrženou zprávu a funkcí spouštěných přímo z akce kontroleru. Protože ale spolehlivost zpráv nelze zaručit, je vždy lepší přímá metoda. Zvláštním případem jsou parametry, které se v UWP aplikaci předávají pomocí metody Navigate a poté v code-behind cílové stránky vkládají do instance ViewModelu. Ty je nutné předat buď přímo, např. pomocí prvku TempData, nebo přes routovací parametry. Asynchronní volání Všechny metody na rozhraní IDataService jsou definované jako asynchronní, takže jejich návratová hodnota je vždy zpracovávaná úloha Task a nikoli výsledný objekt, resp. nic, pokud se jedná o metodu typu void. Pokud je v dalším kroku potřeba pracovat s výsledkem asynchronního volání, je nutné použít speciální příkaz await, který po dobu čekání na výsledek operace předává aktivitu jinému vláknu aplikace. Asynchronní volání mají tu vlastnost, že se šíří aplikací podobně jako lavina, protože každá metoda, obsahující aspoň jedno asynchronní volání, musí být označena příznakem async, takže i případná nadřazená metoda musí být async, a tak stále dokola. Problém nastává, pokud k nějakému asynchronnímu volání dochází v konstruktoru ViewModelu, který async být nemůže. Obrázek 55: zapouzdření asynchronní metody v kontruktoru Zdroj: Vlastní zpracování 94

95 Jedná se o jediný případ, kdy je připuštěno použít jako návratovou hodnotu async metody void. V UWP aplikaci to není problém, protože výsledek úlohy se do View doplní dodatečně, až se dopočítá výsledek. Pokud se ale takto neošetřený ViewModel použije v kontroleru MVC aplikace, ten nepozná, že spuštěná úloha ještě nemá výsledek, a pokračuje až ke generování html stránky. To buď skončí chybou, protože hodnota předaného modelu je nulová, nebo vygeneruje prázdný formulář, seznam, apod. Proto je nejlepší se volání asynchronních metod v konstruktoru úplně vyhnout a používat v MVC jen metody, které vrací řádné Task. Pokud je ale opravdu nezbytné metodu zavolat, je možné ji zapouzdřit do další úlohy, která se nakonfiguruje tak, aby čekala na svůj výsledek, resp. na výsledek úlohy spuštěné uvnitř ní. Ukázka takového konstruktoru se zapouzdřenou úlohou je na Obrázku

96 10 Konečná podoba aplikace Následující stránky obsahují srovnání vybraných stránek obou verzí finální podoby aplikace. Úvodní menu a vyhledávání Seznam oddělení 96

97 Seznam uživatelů s možností filtrace Editace uživatele 97

98 Přehled hardware uživatele Statistika databáze 98