Vývoj multiplatformních aplikací v Embarcadero RAD studiu

Mobilní zařízení se stala nedílnou součástí našeho života. Masivní využití se našlo v oblasti zábavy, ale přibývají i aplikace pro profesionální použití. Zde často nahrazuje kombinace tabletu s vhodnou aplikaci dráhé specializované terminály. Oproti klasickému notebooku mají mobilní zařízení několik výhod: jsou kompaktnější, lépe se přenášejí a mají integrované rozšiřující moduly jako je GSM, GPRS, GPS, fotoaparát a řadu dalších. Pro vývojáře i uživatele se tímto otevírá zcela nový prostor. Situaci však komplikuje existence více mobilních platforem, které staví vývojáře před volbu jak a v jakém vývojovém prostředí aplikaci vytvořit.

Jistě je možné vytvořit webovou aplikaci a problémy s rozdílnými vlastnostmi jednotlivých platforem překlenout použitím prohlížeče daného mobilního zařízení. Tento typ aplikace ale není vždy nejvhodnější. Jsou případy, kdy je z mnoha důvodů lepší vytvořit klienta přímo pro konkrétní platformu. Vývojář potom musí vážit možné varianty: vybrat pouze jednu z platforem, pro kterou aplikaci psát, nebo pro každou platformu vytvořit specifickou aplikaci. Existuje však i další možnost, o které bych se zde rád zmínil podrobněji, a to je použít RAD studio od společnosti Embarcadero, které umožňuje vývoj aplikací pro více platforem za použití jednoho kódu, v jednom vývojovém prostředí a to jak pro serverovou část, tak pro část klientskou.

Požadavky na aplikaci

Řadu let se věnuji programování firemních aplikací, které vždy pracovaly výhradně v prostředí operačního systému Windows. Jednou z nich je program pro servis výtahových zařízení. Nejprve několik slov o samotné aplikaci.

Jedná se klasickou aplikaci typu klient/server, která pracuje v rámci lokální počítačové sítě. Ve zkratce je možné říci, že program obsahuje evidenci zařízení, pro které se plánuje a provádí servisní činnost. Existující verze obsahuje mnoho manuálních vstupů od uživatelů. S cílem zvýšit efektivitu bylo rozhodnuto doplnit tento program modulem určeným pro mobilní zařízení. Technik vybavený mobilním zařízením dostane na toto zařízení seznam činností, které má vykonat a zároveň bude mít možnost přes mobilní zařízení potvrdit, že zadaný požadavek byl splněn.

Byl jsem tak postaven před problém vývoje své první mobilní aplikace. Času nebylo mnoho a já jsem bohužel neměl příliš představu o tom, jak vytčeného cíle dosáhnout.

Volba mobilní platformy

Prvním problémem bylo jakou platformu vůbec zvolit. Na trhu existuje nepřeberné množství zařízení s různými technickými parametry. Proto jsem si stanovil následující kritéria:

• Jedno nebo více zařízení
• Velikost zařízení
• Množství údajů předávaných na zařízení
• Množství údajů pořizovaných na zařízení
• Venkovní prostředí v jakém bude zařízení provozováno
• Cílová mobilní platforma

Jedno nebo více zařízení. Zde jsem zvažoval, zda techniky vybavit dalším mobilním zařízením, nebo aplikaci nasadit na mobilní telefony, které již aktuálně mají dispozici. Náklady rozhodly o tom, že pro pilotní provoz budou použity stávající mobilní zařízení.

Velikost zařízení. O velikost a rozlišení displeje se již diskutovalo na mnoha místech. Jedná se vždy o kompromis mezi velikostí zařízení a množstvím informací, které je potřeba zobrazit. Pro pilotní provoz, který počítá s využitím stávajících mobilních zařízení, jsme zobrazované informace minimalizovali na velikost zhruba odpovídající SMS zprávě (řádově do 500 znaků).

Množství údajů předávaných na zařízení. Při výběru zařízení je třeba zvážit, jak často budou informace na zařízení přicházet, respektive, jak často se budou zařízení synchronizovat. Dále je třeba vzít v úvahu, jakým způsobem budou uživateli mobilního zařízení informace prezentovány. Pro ověřovací provoz byl objem předaných informací na klienta odhadnut na jednotky zpráv denně. Jednotlivé zprávy budou uživateli zobrazeny ve formě seznamu, který bude možné jednoduše procházet.

Množství údajů pořizovaných na zařízení. Velkým problémem může být vlastní pořizování informací o provedených činnostech. Mobilní zařízení nejsou příliš vhodná pro pořizování dlouhých textů. V naší aplikaci proto uvažujeme především o potvrzení, že daná činnost byla provedena a zadávání volných textů se úvodní fázi nepředpokládá.

Venkovní prostředí. Důležitou vlastností bude odolnost proti vlivům okolního prostředí, ve kterém mobilní zařízení provozujeme. Například, pokud technik pracuje v nečistém prostředí, je psaní s pomocí dotykového displeje s rukama od maziva minimálně problematické. Pokud bude v takové situaci do budoucna potřeba vkládat větší množství údajů, bude vhodné uvažovat o použití externí klávesnice.

Výběr mobilní platformy. V současné době je k dispozici několik mobilních platforem: iOS, Android, Windows phone, Blackberry nebo Symbian. Klíčovou roli hrají především mobilní zařízení s operačními systémy Andorid a iOS. Společně mají zcela dominantní podíl na trhu. Pro určitou část aplikací se ukazuje jako možné řešení použít klasické Windows na zařízeních "2 v 1". Tento typ zařízení má oddělitelnou klasickou klávesnici a kombinuje tak v sobě přednosti notebooku a tabletu.

Volba vývojového prostředí

Pokud bychom chtěli vytvořit aplikaci použitelnou pro všechny platformy současně, máme před sebou nepříliš lákavou vidinu psaní sice jediné aplikace, avšak ve třech různých vývojových prostředích. Proto mě během průzkumu možností vývoje zaujalo RAD studio od společnosti Embarcadero. Požadavky, které jsem kladl na vývojové prostředí, jsou uvedeny v následujících bodech:

• Přenositelnost na různé platformy (Android, iOS a případně Windows)
• Možnost klasického klienta pouze s občasným připojením na síť
• Vhodné komponenty nebo celý aplikační rámec (framework)
• Historie a podpora produktu
  
  

Přenositelnost na různé platformy. Požadavek na přenositelnost jsem zmínil již v úvodu. Embarcadero RAD studio tento požadavek splňuje velmi dobře, což je patrné z následující tabulky:

Pro vlastní programovaní si můžeme vybrat jazyk Object Pascal nebo C++. Základem přenositelnosti je použití knihovny komponent pro uživatelské rozhraní FireMonkey (FMX), která je k dispozici pro všechny výše uvedené platformy.

Klasický klient s občasným připojením na síť. Při rozhodování o architektuře řešení bylo třeba vzít v úvahu, že připojení k síti nemusí být vždy k dispozici. Zvolen byl proto klasický (tlustý) klient a propojení se serverem s využitím technologie DataSnap, která je součástí dodávky RAD Studia. Výhodou je možnost načtení potřebných číselníků na klienta a jejich následná dostupnost bez připojení k serveru.

Vhodné komponenty. Dalším požadavek byl, aby ve vývojovém prostředí byly k dispozici již předpřipravené dostatečně vybavené komponenty pro rychlý návrh aplikace. Z tohoto pohledu je RAD studio vybaveno více než dobře, protože obsahuje hned dvě knihovny s širokou nabídkou komponent pro vytváření grafického rozhraní aplikace (FireMonkey nebo klasická VCL). Samozřejmostí jsou i komponenty pro přístup k datům a to včetně podpory n-úrovňových aplikací nebo komponenty pro práci s hardware, které může mobilní zařízení obsahovat. Nalezneme zde však i méně obvyklé komponenty, které možnosti vývoje dále rozšiřují. V poslední verzi XE8 například přibyla podpora pro takzvané majáčky (beacon). Komponentový přístup přináší rychlý vývoj aplikace a je možné říci, že 3 písmenka v názvu RAD - Rapid Application Development mají své opodstatnění. Na závěr tohoto odstavce je ještě třeba zmínit, kterou edici RAD studia použít. Pro účely naší aplikace byla jako nejvhodnější zvolena edice Enterprise, která obsahuje podporu všech potřebných technologií.

Historie produktu. V neposlední řadě při výběru produktu hrál roli také fakt, že Embarcadero RAD studio je na trhu již řadu let a jedná se o stabilní produkt, u kterého lze přepokládat další rozvoj i v budoucnosti. Je totiž třeba vzít v úvahu nejen přímé náklady, ale i investice vložené do ovládnutí vývojového prostředí. Dalším, a to velice důležitým argumentem, je podpora vývoje. Nejedná se pouze o dokumentaci, ale také uživatelské skupiny a tutoriály. Co se nápovědy týče, není problém v dokumentaci k produktu dohledat veškeré potřebné informace. K dispozici je jako klasický „help“, ale také jako Embarcadero – DocWiki. Uspořádání je v obou případech přehledné a intuitivní. K RAD Studiu (Delphi, C++ Builderu) je k dispozici velké množství různých diskusních fór a na YouTube najdete mnoho video tutoriálů. Zde platí oblíbené heslo, že jakýkoliv problém při vývoji mám, již ho někdo řešil přede mnou. Pro inspiraci, jak daný problém řešit je možné využít i bohaté kolekce příkladů, které jsou součástí instalace nástroje.

Pro námi plánovanou aplikaci bylo velmi důležité, že RAD Studio umožňuje nejen návrh klientské části, ale zároveň je možné jej použít i pro vývoj aplikačního serveru, který bude provozován na operačním systému Windows.

Serverová část aplikace

První krok bylo vytvoření serveru. Postup byl mnohem jednodušší, než jsem se na začátku obával. Jak jsem již uvedl, Embarcadero RAD studio obsahuje celou řadu užitečných komponent, které vývoj aplikace značně urychlují.
Jednou z nich, kterou jsem použil, je DataSnap server komponenta. DataSnap je sada komponent, které zpřístupňují technologie pro návrh distribuovaných aplikací, které jsou kompatibilní se zavedenými standardy (COM/DCOM, TCP/IP, http, HTTPS nebo RESTful service). Základní vlastností DataSnap je schopnost spouštět z klienta metody umístěné na aplikačním serveru. V dokumentaci najdeme podrobný popis jak server vytvořit, ale pokud chceme začít rychle, bez zdlouhavého studia, můžeme se nechat vést vestavěným průvodcem. Ten pro nás v několika krocích vytvoří základ serveru.

Postupně v grafickém průvodci zvolíme:

• Typ serverové aplikace. Na výběr je klasická Windows aplikace, konzolová aplikace bez grafického rozhraní, nebo služba operačního systému Windows.
• Nastavení vlastností, které od serveru požadujeme:
• Použitý protokol (TCP/IP, HTTP, HTTPS). Máme samozřejmě možnost zvolit, na jakých portech bude server pracovat.
• Ověřování uživatelů a případně práv pro přístup k serverovým funkcím na základě role uživatele.
• Třídu pro serverové funkce, tedy umístění, kam budeme umisťovat naše "užitečné" funkce, které budou volány z mobilního klienta.
• Komprese a šifrování komunikačního protokolu.
• JavaScript pro vývoj REST klienta
• DataSnap konektor pro Mobilní zařízení

Po ukončení průvodce máme k dispozici funkční základ serveru. Nyní již jen potřebujeme do zvolené třídy doplnit aplikační logiku (výkonné funkce serveru), které budou k dispozici mobilním klientům. Typicky se jedná o zpřístupnění dat z SQL databáze nebo jejich zpracování. Pro inspiraci, jak takovéto funkce implementovat opět doporučuji projít dostupné příklady.

Postup vývoje je velmi přímočarý. Díky bohaté knihovně sestavujeme aplikaci z předpřipravených stavebních bloků – komponent, které v návrhovém módu umisťujeme na formuláře. Ty mohou být viditelné (pak reprezentují okna aplikace) nebo neviditelné (zde jsou použity jako kontejnery pro nevizuální komponenty a uživatelské procedury či funkce). Vlastní DataSnap Server je vygenerován prostředím včetně primárního kontejneru „ServerMethodUnit1“. Jméno jednotky můžeme samozřejmě změnit a přidat libovolné množství dalších.

Pro základní úlohy se obejdeme prakticky bez kódování. Na formulář „ServerMethodUnit“ přidáme z palety komponent prvky „FDConnection“ a ve vestavěném editoru vyplníme parametry připojení ke zvolenému databázovému stroji. Komponenta FDQuery umožňuje zadat a spustit definovaný SQL dotaz. Dále musíme pro tuto DB přidat komponentu „PhysicalDriverLink“, která reprezentuje nativní databázový ovladač a komponentu „WaitCursor“, která implementuje multiplatformní „přesýpací hodiny“ pro déle trvající operace. Aby se bylo možné k datům připojit z libovolného klienta pomocí REST, musíme ještě použít komponenty „FDStanStorageBinLink“ a „FDStanStorageJSONLink“. Funkce pro získání dat bude vypadat následovně:

function TServerMethods1.GetFirmy: TFDJSONDataSets;

begin

FDQuery1.Active := False;

Result := TFDJSONDataSets.Create;

TFDJSONDataSetsWriter.ListAdd(Result, FDQuery1);

end;

Kód nejprve deaktivuje komponentu „FDQuery“, čímž dojde k vyprázdnění datové sady, pokud by již byla naplněna. V dalším kroku si vytvoříme datovou sadu JSON pro uložení dat. Třetí řádek spustí „FDQuery“ a získanou datovou sadu zapíše do výše vytvořené datové sady JSON.

Na závěr server přeložíme jako samostatnou aplikaci. Nasazení takto vytvořené aplikace je zdarma bez jakýchkoliv následných poplatků. Pokud bychom serverovou část vytvářet nechtěli, je možné použít EMS (Enterprise Mobility Service) server. Jedná se o hotový aplikační server s bohatou funkčností včetně správy a sledování. Návrh aplikační logiky v RAD Studiu je pro EMS zcela totožný. Na server se nasazuje ve formě přeložených knihoven. Nasazení EMS na rozdíl od technologie DataSnap podléhá licenčním poplatkům.

Mobilní klient

Dalším krokem byl vývoj klienta. Jako na první byl zvolen operační systém Android. Aplikace se v RAD Studiu vyvíjí bez ohledu na cílovou platformu. Její volba je důležitá až při překladu aplikace. Pro Android však hovořil fakt, že jsem měl k dispozici starý Samsung Galaxy S2 a mohl jej tak použít pro testování. Jedná se o poměrně starý hardware, takže pokud bude na S2 aplikace funkční a svižná, na novějších zařízeních to může být jen lepší. Při připojování S2 k počítači se mi vyskytl malý problém, a to, že jsem v prostředí zpočátku neviděl S2 v seznamu cílů vývoje (target). Musel jsem tak na počítač, kde je instalace RAD studia doinstalovat Samsung USB driver for mobile v jeho poslední verzi. Od tohoto okamžiku byl Samsung „viditelný“. RAD studio si ještě automaticky doinstalovalo potřebnou verzi SDK pro Androidu S2 a vše bylo připraveno. Pro otestování jsem vytvořil jednoduchou aplikaci typu "Hello World" a spustil jsem překlad, který zároveň zajistil instalaci a spuštění aplikace na připojeném mobilním zařízení. Po chvíli se obrazovka mobilu rozzářila nápisem "Hello World" a moje první mobilní "aplikace" byla na světě!

Povzbuzen tímto "úspěchem", jsem se pustil do vlastního mobilního klienta. Pro první fázi jsem si stanovil pouze jednoduchý cíl a to zobrazit seznam úkolu na mobilním zařízení.

Kostru aplikace s jednou obrazovkou nám opět vygeneruje vývojové prostředí prostředí. Pro prezentaci dat na něj umístíme komponentu „ListView“. Pro uložení dat na zařízení použijeme InMemmory databázi (komponenta „FDMemTable“). Stejně jako u serveru je třeba přidat komponenty „FDStanStorageBinLink“ a „FDStanStorageJSONLink“ pro přenos dat. Na závěr přidáme tlačítko „Button1“, které spustí naši serverovou funkci a zobrazí data. Propojení dat a komponent pro jejich zobrazení můžeme provádět jak v kódu, tak ve vizuálním návrháři „LiveBindings Designer“ (viz obrázek níže). Ten automaticky na formulář doplní komponenty „BindingsList“ a „BindSource“. Kód, který je potřeba pro „oživení“ aplikace napsat je opět velmi stručný. Přidáme proceduru „GetFirmy“, která zavolá na serveru definovanou funkci stejného jména. Data načteme do lokální datové sady „FDMemTable“ a zpřístupníme ji. V proceduře pro ošetření stisku tlačítka pak jen zavoláme výše uvedenou proceduru:

procedure TForm1.GetFirmy;

var

DataSetList: TFDJSONDataSets;

begin

DataSetList := ClientModule1.ServerMethods1Client.GetFirmy;

FDMemTable1.AppendData(TFDJSONDataSetsReader.GetListValue(

DataSetList, 0));

FDMemTable1.Open;

end;

procedure TForm1.Button1Click(Sender: TObject);

begin

GetFirmy;

end;

Nyní klientskou aplikaci přeložíme pro zvolené cílové platformy.

Zhodnocení

Cílem tohoto projektu bylo najít vhodnou platformu pro vývoj mobilních aplikací, které se budou používat pro firemní nasazení. Tyto aplikace pracují s daty, které jsou přenášeny mezi mobilním zařízením a serverem s možností práce v offline režimu. Dalším požadavkem bylo snadné ovládnutí technologie. Všechny požadavky, které jsem si na začátku vývoje stanovil, RAD studio beze zbytku splnilo. Samozřejmě existují i jiné možnosti, jak podobné aplikace vytvářet, ale u RAD studia musím ocenit provedení "vše v jednom", tj. vše co potřebuji pro vývoj serveru i klienta v jediném prostředí. Klienta je navíc možné z jednoho zdrojového kódu přeložit pro různé platformy. Na závěr bych chtěl touto cestou poděkovat za podporu a pomoc v případě nesnází a pružné odklízení vzniklých problémů z cesty Petrovi Houfovi ze společnosti Embt.biz s.r.o. Vám všem ostatním, kteří se pustíte do vývoje mobilních aplikací, přeji mnoho bezchybných řádků kódu.

Použitá dokumentace

Embarcadero - DocWiki http://docwiki.embarcadero.com

Ing. Martin Čeřovský

věnuje konzultacím a vývoji software na platformě Windows již více než 20 let