Část 2 – Architektura

Klíčovou zásadou vytváření multiplatformních aplikací je vytvoření architektury, která se hodí k maximalizaci sdílení kódu napříč platformami. Dodržování následujících principů objektově orientovaného programování pomáhá vytvářet dobře navrženou aplikaci:

• Zapouzdření – Zajištění, aby třídy a dokonce i vrstvy architektury zpřístupnilo pouze minimální rozhraní API, které provádí požadované funkce, a skryje podrobnosti implementace. Na úrovni třídy to znamená, že se objekty chovají jako "černá pole" a že využívání kódu nemusí vědět, jak své úkoly dělají. Na úrovni architektury to znamená implementaci vzorů, jako je Façade, které podporují zjednodušené rozhraní API, které orchestruje složitější interakce jménem kódu v abstraktních vrstvách. To znamená, že kód uživatelského rozhraní (například) by měl být zodpovědný pouze za zobrazení obrazovek a přijetí uživatelského vstupu; a nikdy nekomuaguje s databází přímo. Podobně by kód pro přístup k datům měl jen číst a zapisovat do databáze, ale nikdy nepracuje přímo s tlačítky nebo popisky.
• Oddělení zodpovědností – Zajistěte, aby každá komponenta (jak na úrovni architektury, tak na úrovni třídy) má jasný a dobře definovaný účel. Každá komponenta by měla provádět pouze své definované úlohy a zpřístupnit tyto funkce prostřednictvím rozhraní API, které je přístupné pro ostatní třídy, které ji potřebují používat.
• Polymorfismus – programování do rozhraní (nebo abstraktní třídy), které podporuje více implementací, znamená, že základní kód lze psát a sdílet napříč platformami a současně pracovat s funkcemi specifických pro platformu.

Přirozeným výsledkem je aplikace modelovaná po skutečném světě nebo abstraktních entitách s samostatnými logickými vrstvami. Oddělení kódu do vrstev usnadňuje pochopení, testování a údržbu aplikací. Doporučujeme, aby kód v každé vrstvě byl fyzicky samostatný (buď v adresářích, nebo dokonce samostatných projektech pro velmi velké aplikace), a logicky oddělit (pomocí oborů názvů).

Typické aplikační vrstvy

V tomto dokumentu a případových studiích odkazujeme na následující šest aplikačních vrstev:

• Datová vrstva – trvalost nestálých dat, pravděpodobně databáze SQLite, ale mohla by být implementována se soubory XML nebo jakýmkoli jiným vhodným mechanismem.
• Vrstva přístupu k datům – obálka kolem datové vrstvy , která poskytuje přístup k datům vytvoření, čtení, aktualizace, odstranění (CRUD) bez zveřejnění podrobností implementace volajícímu. Dal může například obsahovat příkazy SQL pro dotazování nebo aktualizaci dat, ale odkazující kód by to nemusel znát.
• Obchodní vrstva – (někdy označovaná jako vrstva obchodní logiky nebo BLL) obsahuje definice obchodních entit (model) a obchodní logiku. Kandidát na obchodní fasádu.
• Vrstva přístupu ke službě – používá se pro přístup ke službám v cloudu: ze složitých webových služeb (REST, JSON, WCF) až po jednoduché načítání dat a obrázků ze vzdálených serverů. Zapouzdřuje chování sítě a poskytuje jednoduché rozhraní API, které bude využívat vrstvy aplikace a uživatelského rozhraní.
• Aplikační vrstva – kód, který je obvykle specifický pro platformu (obecně nesdílený napříč platformami) nebo kód specifický pro aplikaci (obecně nejde opakovaně použít). Dobrým testem, zda umístit kód do aplikační vrstvy a vrstvy uživatelského rozhraní je (a) k určení, jestli má třída nějaké skutečné ovládací prvky zobrazení, nebo (b), zda se může sdílet mezi několika obrazovkami nebo zařízeními (např. i Telefon a iPad).
• Vrstva uživatelského rozhraní – vrstva s uživatelským přístupem, obsahuje obrazovky, widgety a kontrolery, které je spravují.

Aplikace nemusí nutně obsahovat všechny vrstvy – například vrstva přístupu ke službě neexistuje v aplikaci, která nemá přístup k síťovým prostředkům. Velmi jednoduchá aplikace může sloučit vrstvu dat a vrstvu přístupu k datům, protože operace jsou extrémně základní.

Běžné vzory mobilního softwaru

Vzory představují zavedený způsob zachycení opakovaných řešení běžných problémů. Existuje několik klíčových vzorů, které jsou užitečné k pochopení při vytváření udržovatelných/srozumitelných mobilních aplikací.

• Model, ViewModel (MVVM) – model Model-View-ViewModel je oblíbený u architektur, které podporují datové vazby, jako je Xamarin.Forms. Byla oblíbená sadami SDK s podporou XAML, jako je Windows Presentation Foundation (WPF) a Silverlight; kde Model ViewModel funguje jako přechod mezi daty (model) a uživatelským rozhraním (View) prostřednictvím datových vazeb a příkazů.
• Model, zobrazení, kontroler (MVC) – běžný a často nepochopený vzor, MVC se nejčastěji používá při vytváření uživatelských rozhraní a poskytuje oddělení mezi skutečnou definicí obrazovky uživatelského rozhraní (View), modulem za ním, který zpracovává interakci (Controller) a daty, která ho naplní (model). Model je ve skutečnosti zcela nepovinný kus, a proto jádro pochopení tohoto modelu spočívá v zobrazení a kontroleru. MVC je oblíbený přístup pro aplikace pro iOS.
• Obchodní fasáda – vzor AKA Manager poskytuje zjednodušený bod vstupu pro složitou práci. Například v aplikaci sledování úloh můžete mít TaskManager třídu s metodami, jako GetAllTasks() jsou , GetTask(taskID) , SaveTask (task) atd. Třída TaskManager poskytuje façade vnitřní práce skutečně ukládání/načítání objektů úkolů.
• Singleton – Model Singleton poskytuje způsob, jakým může existovat pouze jedna instance konkrétního objektu. Pokud například používáte SQLite v mobilních aplikacích, budete chtít jenom jednu instanci databáze. Použití vzoru Singleton je jednoduchý způsob, jak to zajistit.
• Poskytovatel – model vytvořený Microsoftem (pravděpodobně podobný strategii nebo základní injektáž závislostí), který podporuje opětovné použití kódu v aplikacích Silverlight, WPF a WinForms. Sdílený kód lze zapsat proti rozhraní nebo abstraktní třídě a konkrétní implementace specifické pro platformu se zapisují a předávají při použití kódu.
• Asynchronní – Nezaměňujte se s klíčovým slovem Async, vzor Async se používá v případě, že je potřeba spustit dlouho běžící práci bez přidržování uživatelského rozhraní nebo aktuálního zpracování. V nejjednodušší podobě asynchronní vzor jednoduše popisuje, že dlouhotrvající úlohy by se měly spustit v jiném vlákně (nebo podobné abstrakci vlákna, jako je úloha), zatímco aktuální vlákno pokračuje v procesu zpracování a naslouchá odpovědi z procesu na pozadí a pak aktualizuje uživatelské rozhraní, když se vrátí data a stav.

Každý ze vzorů bude podrobněji prozkoumán, protože jejich praktické použití je znázorněno v případových studiích. Wikipedie obsahuje podrobnější popisY MVVM, MVC, Fasáda, Singleton, Strategie a zprostředkovatel vzory (a vzory návrhu obecně).