Aplikačný rámec pre vývoj multiplatformových frontendov

Článok sa venuje vývoju multiplatformových frontendov informačných systémov so zreteľom na responzívnosť používateľského rozhrania. V tomto článku navrhneme vlastný operačný rámec pre framework Xamarin a otestujeme ho implementovaním informačného systému pokladne.

Mobilné telefóny sa stali neoddeliteľnou súčasťou sveta. Za posledné roky počet používateľov mobilných telefónov narástal obrovským tempom. Spoločnosti rozpoznali potrebu aplikácií pre chytré mobilné zariadenia a začali zaplňovať trh aplikáciami pre rôzne potreby. Zo začiatku boli aplikácie vyvýjané veľkými IT spoločnosťami, prípadne open-source komunitami. Dnes je situácia iná, do hry vstúpili aj oveľa menšie spoločnosti, startupy a niekedy dokonca aj jednotlivci.

Tieto malé tímy a jednotlivci nemusia mať dostatok skúseností, zdrojov a času na vývoj, taktiež aby aplikácia zarábala čo najviac, je vždy cieľom získať čo najviac používateľov. Ak chceme mať čo najviac používateľov, oplatí sa vyvýjať aplikácie pre všetky relevantné mobilné operačné systémy. Pre veľké spoločnosti nemusí byť problém vyvýjať nativné aplikácie pre každú mobilnú platformu. Pre jednotlivcov a menšie tímy to nie je také jednoduché, môžu mať spomínané problémy ako nedostatok času, skúseností alebo financií.

Na prekonanie hore spomenutých problémov slúžia multiplatformové frameworky, ktoré dokážu uľahčiť a urýchliť vývoj pre viaceré mobilné operačné systémy. Tieto frameworky znižujú počet riadkov kódu a celkové náklady na vývoj. Používajú na to vstavané prehliadače alebo špeciálne kompilátory.

Výhody, ktoré tento postup prináša sú tieto:

• Jednoduchšia údržba. Je jednoduchšie udržiavať jeden projekt ako viacero, máme jeden vývojarský tím, aktualizácie vychádzajú naraz na všetky platformy.
• Väčší dosah. Je jednoduchšie získať väčší počet používateľov podporovaním všetkých dôležitých platforiem.
• Menšie náklady na vývoj. Vyvýjať jednu multiplatformovú aplikáciu so zdieľaným zdrojovým kódom a jedným vývojárskym tímom je ekonomicky výhodnejšie ako viacero natívnych aplikácií určených pre jednu platformu.
• Znovu-použiteľný kód. Nie je potrebné písať kód pre danú úlohu opäť pre ďalšiu platformu, použije sa už existujúci kód.

Pre tento projekt budeme používať framework Xamarin.

Xamarin

Xamarin používa multiplatformové knižnice Mono for Android a MonoTouch, ktoré umožňujú programovať pomocou.NET technológií aplikácie pre Android a iOS[6, 7]. Výstupom kompilovania je rovnaký súbor ako pri natívnom vývoji. Nevýhodou je však veľkosť balíčku, keďže použité .NET knižnice musia byť jeho súčasťou. Xamarin dokonca zvláda použiť aj knižnice napísané v Jave alebo Objective-C pomocou Bindings Library projektov.

Hlavnou časťou riešenia v Xamarine je projekt so zdieľaným kódom. V ňom je implementovaná komunikácia s webovými službami, práca s databázou, dátové modely a iné business služby. Na tento zdieľaný projekt sa odkazujú všetky projekty jednotlivých platforiem, ako je vysvetlené v dokumentácii.

Xamarin Native vs Xamarin.Forms

Pod pojmom Xamarin Native sa skrýva Xamarin.Android a Xamarin.iOS. Pre vývoj Androidu v jazyku C# je potrebné Visual Studio, .NET Framework a Android SDK. Pri iOS je situácia trošku komplikovanejšia. Nie je možné skompilovať iOS aplikáciu na zariadení s operačným systémom Windows, vždy je potrebné používať počítač s Mac OS od spoločnosti Apple. Tvorcovia Xamarinu ale spravili všetko čo najpohodlnejšie a stačí ak Macintosh sa nachádza v lokálnej sieti a máte ho nakonfigurovaný vo Visual Studiu na zariadení s Windowsom pre vzdialené kompilovanie.

Pri použití Xamarin.Forms nie je zdieľaná len biznis logika aplikácií, ale aj vzhľad. V Xamarin Native sa v Android projektoch na definovanie používateľského rozhrania používa XML, v iOS sú to Storyboardy a v Xamarin Forms sa používa XAML. Okrem väčšieho podielu zdieľaného kódu môžu byť faktorom pri rozhodovaní aj skúsenosti. Napríklad vývojár nemusí vedieť vôbec nič o vývoji pre iOS, ale pozná XAML a .NET.

Na obrázku vidíme mapovanie objektov v Xamarin Forms. Xamarin Forms je vlastne knižnica abstraktných modelov, z ktorých vývojár vyskladá používateľské rozhranie. Tieto abstraktné modely sú za behu aplikácie nahradené natívnymi komponentmi danej platformy. To znamená, že na každej platforme má aplikácia natívny vzhľad. O konvertovanie abstraktných modelov na natívne komponenty sa stará objekt Renderer. Každá platforma má vlastné objekty Renderer pre všetky komponenty obsiahnuté v Xamarin Forms.

Z tohto vyplýva, že Forms sú vhodné pre jednoduchšie aplikácie, ktoré používajú málo funkcionalít jedinečných pre danú platformu a majú jednoduchý vzhľad. Je možné vytvoriť vlastný objekt renderer ak potrebujeme špeciálnu animáciu alebo iné zložitejšie chovanie. Taktiež je možné zavolať API špecifické pre platformu ak ho neobsahuje Xamarin Forms, ale ak by bola aplikácia na týchto zložitejších funkcionalitách veľmi závislá, vývoj pomocou Forms by priniesol viac starostí ako úžitku.

Požiadavky na aplikačný rámec

Informačný systém (IS) je systém na zber, udržiavanie, spracovanie, analyzovanie a poskytovanie informácií. IS vznikol kvôli potrebe orientovať sa v stále väčšom množstve informácií. Hlavnou úlohou IS je zvládať procesy danej organizácie a práce zamestnancov s cieľom uľahčovať tieto činnosti, zvyšovať produktivitu a znižovať náklady.

IS majú spravidla formulárový vzhľad, obsahujú veľké množstvo textových polí, prepínačov a rozbaľovacích menu. Preto je podľa mňa dôležité, aby rámec obsahoval element, ktorý podľa prijatého dátového modelu dokáže sám vygenerovať grafické rozhranie formuláru. Predstavujem si ho ako dvojice, názov vlastnosti a textové pole, poukladané pod sebou. Ak daná vlastnosť má obmedzené hodnoty, čiže je enumeračný typ, tak sa namiesto textového poľa vygeneruje rozbaľovacie menu.

Údaje, ktoré používateľ zadáva do týchto formulárov nemôžu byť náhodné. Väčšinou je potrebné aby spĺňali určité kritéria. Textové pole v Xamarine nedokáže zobraziť chybu v prípade zlého vstupu. Chcem pripraviť element, ktorý bude schopný prijať používateľský vstup, skontrolovať ho podľa kritérií definovaných vývojarom a podľa potreby zobraziť chybu. Vývojár bude musieť len definovať pravidlá kontroly a chybovú hlášku, o všetko ostatné už bude postarané.

Všetky tieto elemetny musia byť umiestnené v nejakom pohľade (z anglického view v .NETe). Pre formulárové aplikácie sa veľmi často používa master-detail štýl. Master obsahuje zoznam vlastností alebo objektov z danej dómeny a po kliknutí na položku zoznamu sa zobrazia jej detailné informácie v detail časti pohľadu. Xamarin obsahuje Master-Detail pohľad. Chcem sa pozrieť na možnosti ako prácu s ním urýchliť a zjednodušiť.

Zhrnutie:

• Komponent pre generovanie formulárových štruktúr
• Textové pole obohatené o funkciu validácie používateľského vstupu
• Zjednodušiť implementáciu master-detail pohľadu

Operačný rámec

Operačný rámec bude implementovaný ako .NET Standard Class Library, ktorá bude referencovaná ostatnými projektmi v Xamarin riešení. Implementovaná bude v jazyku C#.

Validovaný vstup

Validácia vstupu používateľa je navrhnutá z dvoch hlavných častí, komponentu skladajúceho sa z Entry a Label a validátora typu Behavior.

Komponent ValidatedEntry sa skladá z Entry a Label umiestnených v StackLayout. Do textového poľa zadáva používateľ vstup, či už to je login, heslo, meno tovaru alebo cena.

Vstup je kontrolovaný objektom ValidatedEntryValidator, čo je rozšírený objekt typu Behavior. Každý takýto validátor obsahuje vlastnosti IsValid a ErrorMessage. IsValid je boolean, podľa ktorého je možné zistiť, či text spĺňa pravidlá validácie. ErrorMessage je chybová hláška znázornená v Label ak vstup neprešiel validáciou. Pri pripojení validátora ku komponentu je zaregistrovaný event Bindable_TextChanged, ktorý je vyvolávaný z komponentu. Vývojár pri implementácii vlastného validátora prepíše tento event a umiestni sem logiku a pravidlá validácie, napríklad kontrolu pomocou regulárneho výrazu.

V ukážke je znázornená implementácia validátora adresy. Regulárny výraz je kvôli svojej dĺžke skrátený. Výsledok kontroly je priradený premennej IsValid a potom je zavolaná základná časť metódy, ktorá podľa výsledku zobrazí chybu a zmení farbu textu. Premenná IsValid môže byť aj v XAML kóde priradená vlastnosti tlačidla IsEnabled, aby sa zablokoval ďalší postup používateľa kým nezadá vyhovujúce údaje.

private const string UrlRegex = @"^(http:\/\/www\.|https:\/\/www\.|..."

protected override void Bindable_TextChanged(object sender, ValidatedEntryEventArgs e)
{
   if (e.NewValue == null) return;

   IsValid = (Regex.IsMatch(e.NewValue, UrlRegex, RegexOptions.None,   
      TimeSpan.FromMilliseconds(250)));
   base.Bindable_TextChanged(sender, e);
}

Generovanie formulára

Formuláre sú hlavnou časťou IS pre prácu s údajmi. Na vygenerovanie používateľského rozhrania s formulárom je potrebný dátový model, podľa ktorého sa do formulára vložia príslušné komponenty používateľského rozhrania.

Údaje možu byť do IS zadávané pri vytváraní nového záznamu alebo úprave už existujúcich dát. Pri vytváraní nového záznamu sa ako parameter generátoru dáva objekt typu Type, ktorý reprezentuje deklarácie tried. V tomto prípade je vygenerovaný formulár prázdny, textové polia nie su vyplnené a zoznamy obsahujú nula položiek. Pri úprave existujúcich dát sa ako parameter generátoru posiela konkrétny objekt. Vygenerovaný formulár potom obsahuje aj vyplnené aktuálne hodnoty v textových poliach a zoznamy obsahujú svoje položky.

XAML kód generátora obsahuje jediný StackLayout element s vertikálnou orientáciou. Tento StackLayout je prázdny, nemá žiadnych potomkov, pretože sú pridávaný až v kóde za behu aplikácie. Za behu aplikácie je napĺňaný dvojicami Label + jeden z podporovaných elementov, ktoré sú umiestnené vertikálne v ďalšom StackLayoute.

Master-Detail

Xamarin Forms obsahuje MasterDetailPage, ktorá má vlastnosti Master a Detail typu Page. Je na vývojárovi aby vytvoril master zoznam a vytvoril logiku pre prepínanie detail pohľadov pri kliknutí na položku zoznamu. Tento proces sa dá urýchliť. Vieme, že vo väčšine prípadov master časť tvorí obyčajný zoznam s textovými reťazcami a prípadnými ikonkami. Chovanie je tiež rovnaké, po kliknutí na názov detailného pohľadu sa má Detail premenná nastaviť na novú hodnotu.

Navrhnutý komponent má metódu Add, ktorá má parametre:

• ikonku položky,
• názov položky v zozname,
• typ ContentPage, ktorý sa má zobraziť v detail časti po vybratí,
• parametre, ktoré sa majú ContentPage predať.

Tieto informácie stačia na vyskladanie zoznamu. Cesta k zdroju ikonky položky nie je povinná, môže byť null, rovnako aj parametre pre detail sa zadávajú podľa potreby. Zoznam sa nastaví ako obsah automaticky vytvorenej master časti a zaregistruje sa handler pre event SelectedItem. V handleri sa vytvorí nová inštancia danej ContentPage a nastaví ako obsah Detail vlastnosti MasterDetailPage.

Pokladňa

Náš aplikačný rámec je potrebné otestovať implementovaním riešenia a nasadením na rôzne platformy. Implementovať budeme informačný systém pokladne schopný fungovať ako na stolových počítačoch, tak aj na mobilných zariadeniach s rôznymi operačnými systémami. Pokladňa sa skladá z front officu a back officu.

Front office

Front office je v pokladničných systémoch priestor, ktorý ma na starosti predaj a účtovanie tovaru zákazníkom. Front office sa skladá zo:

• zoznamu ponúkaných predmetov,
• skupiny tlačidiel pre ručné zadávanie kódov,
• nákupného košíka zákazníka.

Naša pokladňa je multiplatformová. Každá z týchto platforiem má aj viacero typov zariadení. Android má tablety a mobily. UWP má mobily, tablety a stolné počítače. iOS má tiež svoje varianty zariadení. Základ rozhrania pokladníka tvorí layout Grid s tromi stĺpcami. Prvý pre zoznam tovaru, v druhom sídli klávesnica a posledný pre nákupný košík. Vizuálne stavy v tomto prípade menia šírku niektorého zo stĺpcov, viditeľnosť objektov v nich a pridávajú/odoberajú tlačidlá z navigačného panelu.

Back office

V back office pokladničného systému je možné upravovať informácie o ponúkanom tovare, samotný ponúkaný tovar, informácie o pobočkách a ich vybavení. K týmto informáciám nemajú prístup všetci zamestnanci, ale iba manažéri. Preto sa po prihlásení posiela požiadavka GetUserData, ktorá okrem iných informácií vracia aj pozíciu zamestnanca. Ak je zamestnancova pozícia manažér potom sa do sekundárneho menu navigačného panela pridá tlačidlo pre vstup do back officu.

V detail obrazovkách sa manažér chce najprv dostať k objektu, ktorého informácie chce zmeniť alebo na ich úrovni vytvoriť nový objekt. V prípade obchodov po kliknutí na Chains sa zobrazí najvyššia úroveň reťazca, napríklad nádnarodná ak nejaká existuje a postupne sa manažér prefiltruje ku samotným pobočkám. Na každej úrovni vie vytvoriť nový reťazec a na najnižšej vie vytvoriť novú pobočku. Po vybratí pobočky sa zobrazia jej informácie. Detaily o pobočke alebo formulár na vytvorenie novej pobočky sa zobrazujú pomocou generátora dátových modelov.

Podobne sa pracuje so zoznamom tovaru. Po vybratí sa zobrazia jeho detaily pomocou generátora. Kliknutie na Add New v zozname zobrazí formulár novej položky. Potvrdenie zadaných údajov prikáže generátoru vytvoriť objekt daného údajového typu a nastaviť mu premenné podľa zadaných hodnôt. Tento objekt potom slúži ako telo požiadavky posielanej na backend.

Záver

Hlavným cieľom tejto práce bolo navrhnúť a implementovať aplikačný rámec pre vývoj multiplatformových frontendov aplikácií. Rámec bol vytvorený pre prácu s frameworkom Xamarin Forms. Funkcie rámca boli definované podľa analýzy. Na otestovanie rámca bol vytvorený informačný systém pokladne. Pri pokladni sa dbalo na responzívne používateľské prostredie, keďže bola vyvýjaná pre viaceré formy zariadení.

Celkový zoznam funkcií rámca a miesto kde boli použité v pokladni je:

• validované textové pole – prihlasovacia obrazovka a back office ako súčasť generátora,
• generátor– back office na generovanie formulárov,
• rozšírené Entry EntryEx – vo ValidatedEntry a v generátore ak nie je potrebná validácia vstupu,
• Toast Service – notifikuje pokladníka o pridaní tovaru na mobilných zariadeniach. Stolné počítače majú viditeľný košík stále, pokladník vidí keď je tovar pridaný.