Jak vyvíjet mobilní aplikace

Na všech vývojářských platformách, které jsou určeny pro širší publikum platí dvě základní pravidla, která by měla úspěšná aplikace splňovat. Musí být použitelná z hlediska lidského a univerzální z hlediska ekonomického.

V případě mobilních aplikací platí toto tvrzení dvojnásob. Lidé jsou značně limitování časem, velikostí displeje, ale také vyrušováním z okolního světa. Nesmějí mít pocit, že je aplikace zdržuje nebo nad ní musí přemýšlet. Z hlediska použitelnosti dnes hrají prim nativní aplikace. Co se ale týče univerzálnosti, jsou naprosto mizerné. Proč a co mizerné není? To popíši v následujících odstavcích.

Od začátku svých setkání s Internetem se zajímám o webové technologie více než o cokoliv jiného, a to je důvod, proč už několik let sleduji hybridní vývoj mobilních aplikací. Je to jedna z možností, jak vyvíjet mobilní aplikace rychleji a především levněji než klasickým nativním způsobem. I když je tento způsob vývoje byl používán již relativně dlouho bez většího zastoupení vývojářů, teprve v posledním roce zažívá jakousi renesanci. Za to vděčíme především tomu, že dnes máme na trhu dostatečně výkonné telefony, prohlížeče, které dodržují standardy, ale i zajímavé javascriptové frameworky – jako například angularovský Ionic. Ne náhodou je 34. nejvíce hvězdičkovaným projektem na GitHubu!

V čem je problém při vývoji nativní mobilní aplikace?

Považuji dlouhodobě neudržitelné vyvíjet mobilní aplikace pro každou platformu zvlášť, a to navíc ještě s úplně odlišným přístupem, platformou i IDE. Zatím to však udržitelné (z nedostatku alternativ) bylo.

Pokud si chce dnes firma nechat vyvinout mobilní aplikaci pro tři hlavní platformy (Android, iOS, Windows Phone) nezbývá jí než sehnat 3 vývojáře, kteří budou implementovat stejnou věc 3x jinak, aby docílili stejného výsledku. A navíc to ještě 3x zaplatí. Abychom si ujasnili o jaké částce se při vývoji aplikace bavíme, bylo by dobré uvést nějaký průměrný odhad, kolik taková aplikace stojí – není to zrovna levná záležitost, cena vývoje jedné aplikace se může v průměru pohybovat někde okolo 50 000–70 000 Kč. Pokud ji chce zákazník vyvinout aplikaci pro všechny 3 hlavní platformy, tak se toto číslo musí ještě cca 2,5x vynásobit. K tomu ještě budeme pravděpodobně potřebovat nějaké API, administraci nebo hosting. A hle, máme utraceno čtvrt milionu korun za „jednu“ mobilní aplikaci.

Pokud jsme se přeci jen rozhodli investovat tuto nepěknou částku do vývoje mobilní aplikace a po čase zjistíme, že nám přesto aplikace plně nevyhovuje, tudíž chceme některé věci upravit, opět nastává problém. Za úpravu aplikace zaplatíme znovu (to se dalo čekat), ale také 3x. Neopravujeme totiž jednu aplikaci, ale hned tři. Dává to ještě smysl?

Ne každý je ochoten platit tolik peněz za věc, která není podstatná. A aplikace částo podstatné nejsou. Tvoří se jich mnoho, ale dlouhodobě se jich používá jen velmi málo. Jsou však moderní, hezky vypadají, zpravidla se krásně ovládají a dobře se za ně utrácí peníze určené pro marketing. Bohužel ale v mnoha případech nemusejí dosáhnout očekávaného přínosu. Proto lze říci, že do budoucna není příliš rentabilní zajišťovat vývoj pro více než jednu nebo dvě platformy. Donedávna postačovalo vyvíjet aplikace jen pro Android a iOS, ale s nárustem oblíbenosti Windows Phone a velkými plány do budoucna ohledně Windows 10, nebude možné tuto platformu přehlížet. Z toho lze předpoklávat, že situace dopadne buď tak, že jedna z platforem převálcuje ostatní a nebude potřeba vyvíjet několik duplicitních aplikací nebo je nahradí jiné dostatečně univerzální řešení. Vzhledem k tomu, že rozmanitost (nebo-li v tomto případě konkurence) je zdravá, můžeme doufat ve druhý scénář.

Jedna věc je ale i tak jistá – vývojáři mobilních aplikací budou ještě hodně dlouho upřednosťnovat vývoj nativních aplikací. A nebude to jen z důvovu, že nabízejí nejvíce možností pro danou platformu. Možná tam bude také důvod typu: „Starého psa novým kouskům nenaučíš“ anebo, že na třech aplikacích se dá vydělat více peněz než na jedné. A co si budeme povídat – ať jsou firmy jakkoliv svobodné nebo podporují pěstování fair trade kávy v Africe, tak peníze jsou ve skutečnosti to jediné, o co jde.

Možnosti vývoje mobilních aplikací

V čem ale tedy aplikace pro telefony vyvíjet? Jsou zhruba 3 způsoby, jak to dělat

  • Vývoj nativních mobilních aplikací (jazyky Java, ObjectiveC/Swift, C#)
  • Hybridní aplikace (HTML, CSS, Javascript, Cordova/PhoneGap)
  • Mobilní weby (HTML, CSS, Javascript) .

Každý způsob vývoje slouží k jinému typu a použití aplikací. Je nutné se nad tím zamyslet před tím, než se člověk opravdu pustí do nějakého vývoje. Pojďme si tedy jednotlivé možnosti podrobněji rozepsat.

Nativní vývoj aplikací

Drtivá většina vývojářů dnes využívá právě tohoto přístupu. Je to z důvodu, že tento přístup doporučují samotní vývojáři platforem (Google, Apple, Microsoft), kterým tolik nezáleží na multiplatformnosti aplikací (nutno ale podotknout že Google i Microsoft jdou v poslední době i směrem k vývoji pro více platforem). Tento přístup přináší největší možnosti a nejlepší výkon. Ale za cenu toho, že se tyto problémy musí řešit v každé platformě zvlášť. To, že většina aplikací pravděpodobně tyto možnosti nikdy nevyužije už je věc jiná. Mnoho aplikací se v dnešní době zaměřuje pouze na to, že stahuje data z API a ty dodává v použitelné formě do mobilní aplikace.

Stahování dat z API není zrovna žádná raketová věda, co by nešla udělat snáze.

Mnoho lidí, kteří podporují pouze vývoj nativních aplikací argumentuje tím, že „nativní aplikace mají ten správný feeling“ a jejich uživatelská zkušenost je nepřekonatelná – mají pěkný bounce scroll, nesekají se, dají se na nich často používat gesta, dodržují guidelines platforem a bla bla bla… S tím lze souhlasit, ale neznamená to, že všechny nativní aplikace jsou udělány správně a všechny ostatní jsou udělány špatně. Důležité je, že rozličnými způsoby lze vyvinout aplikaci, kde člověk nepozná, zda je nativní nebo není. A to je ve výsledku to jediné důležité.

Velmi zajímavou kapitolou nativního vývoje jsou také nástroje umožňující kompilovat jiný zdrojový kód do nativního kódu. Mezi takové patří například Native Script nebo React Native od Facebooku, kde pomocí Javascriptu jsme schopni aplikaci naprogramovat a poté ji zkompilovat do nativního kódu pro Android nebo iOS. I přesto, že React Native není úplným zastáncem strategie: „Udělej jednou, nasaď všude“, tak tento způsob vývojářům do budoucna může hodně usnadnit život. Hlavní nevýhodou tohoto přístupu je v současné době nerozšířená komunita a velmi omezená dokumentace.

Výhody nativního vývoje

  • Výkon – Aplikace jsou napsány ve více „low-level“ jazycích než hybridní aplikace nebo mobilní web.
  • Podpora nejnovějších API – Lze používat nespočet různých API telefnu pro ovládání všeho možného.
  • Nativní UI prvky – Vývojář software podporuje UI prvky přímo v telefonu a vývojář to nemusí příliš řešit.

Nevýhody nativního vývoje

  • Nemultiplatformnost – S touto nevýhodou toho souvisí více:
    • Vysoká cena – Aplikaci je nutné napsat pro každou platformu znovu, takže výsledná aplikace je násobně dražší.
    • Nároky na programátory – Je nutné mít programátory, kteří umí hned několik zcela syntakticky odlišných jazyků: Objective C/Swift, Java a C#/C++. Obzvlášť ObjectiveC je pro masochisty (možná právě díky tomu bývá tak dobře placené)
    • Náročné opravy aplikací – Jak již bylo zmíněno, stejné úpravy v aplikaci se musejí provádět v každé aplikaci zvlášť

Hybridní mobilní aplikace

Každá platforma dnes obsahuje něco, čemu se odborně říká „WebView“, nebo-li instanci prohlížeče. Laicky řečeno se jedná o obrazovku, která zobrazuje webový obsah v mobilní aplikaci za pomoci nainstalovaného prohlížeče. Hybridní mobilní aplikace pak používají přesně toto řešení – jejich základem je pouhé WebView, které zobrazuje pro telefony optimalizovanou webovou aplikaci.

Slovíčko „hybridní“ v dnešní době evokuje spojení dvou rozdílných přístupů a je nějakým způsobem zažité, že to nebývá přístup ideální. Podobně jako u automobilů vypadá hybrid jako jakýsi přechod mezi benzínovými motory a „něčím ekologičtějším“. Osobně si myslím, že to dnes v případě hybridních mobilních aplikací už úplně neplatí. Jediné, co zde může dnes reálně způsobit zásadnější problémy je špatná implementace WebView od vývojářů dané platformy nebo nedostupnost API od výrobců hardware. Jak ale říkají zastánci Cordovy: „Už není rok 2007, kdy se sekalo scrollování v každé hybridní aplikaci“. A nezbývá jim dát než za pravdu – na většině telefonu a platforem (iOS >= 7, Android >= 4, WP >= 8) lze dnes pomocí WebView udělat takovou uživatelskou zkušenost, že to nikdo nepozná.

Díky integraci Crosswalku už není problém ani se starými Android Browsery a kde javascriptové scrollování nezvládaly prohlížeče, tam přišel native scroll. Jedna z velkých výtek ze směru iOS vývojářů byla také absence některých funkcí z iOS platformy. Mezi takové patřilo například Swipe-to-back gesto (pokud se chci vrátit o obrazovku zpět, stačí posunout ve většině aplikací prst zprava doleva). I to dnes už hybridní appky umí – Nativně toto gesto podporuje Ionic nebo iDangerous (animace k vidění zde).

Stále zde však zůstávají některé výzvy – jednou z nich je například uživatelské rozhraní Windows Phone 8, které je koncepčně odlišné od ostatních platforem. Android a iOS se od sebe naopak koncepcí tolik neliší (proto se také Steve Jobs tak zlobil na tvůrce Androidu) a například v Ionicu se mobilní aplikace automaticky přizpůsobuje podle guidelines platformy. Takže stejná aplikace na iOS a Android bude vypadat jinak. Například Android používá jiné přechody mezi stránkami, má jiné UI prvky, nadpisy, dialogy a mnoho dalšího. Nic z toho není potřeba v hybridních aplikacích, postavených na Ionicu řešit. Zajímavé je podívat se například na článek o platform continuity na Ionicu.

Daleko nejrozšířenějším řešením pro vývoj hybridních mobilních aplikací je Cordova (nebo-li také PhoneGap). Jedná se o framework v nativním kódu platformy, který obsahuje WebView zvětšené na celou obrazovku, kde je spuštěna webová aplikace. Tuto aplikaci pak lze propojit se službami telefonu pomocí pluginů z Cordovy. Díky tomu je pak možné ve webové aplikaci používat například fotoaparát, přístup ke kontaktům, získávat údaje z GPS, gyroskopu a mnoho dalších funkcí.

Možná jste z předchozích odstavců zaznamenali můj zvýšený zájem o hybridní aplikace. Je to pravděpodobně tím, že pracuji jako vývojář hybridních aplikací v Userte.ch, a dost jim fandím. Za svoji praxi jsem si vyzkoušel nativní vývoj pro Android i pro iOS, ale nakonec jsem skončil u Javascriptu. Samozřejmě nelze řici, že jeden přístup byl špatný a druhý správný, stejně tak jako se nedá říci, že se nějaký způsob používá dnes, a tak se bude používat i v budoucnosti.

Výhody hybridního vývoje

  • Multiplatformnost – Nejsilnější stránka tohoto přístupu. Zpravidla díky tomu lze vyvíjet aplikaci 2-3x levněji než při vývoji nativních aplikací.
  • Snadné testování – 90 % práce na aplikaci lze simulovat v prohlížeči. Není potřeba zdlouhavě nasazovat aplikaci na zařízení nebo do simulátoru.
  • Webové technologie – Vývoj aplikace vyžaduje znalosti webových technologií, které jsou zpravidla jednodušší na naučení než nativně používané jazyky (Java, ObjectiveC/Swift, C#/C++).

Zní to až moc geniálně, že? Ve skutečnosti není volba mezi nativním a hybridním vývojem tak jednoduchá, jak se zdá. Dalo by se říci, že většina mobilních aplikací funguje tak, že pouze manipuluje s daty pomocí nějakého webového API. K tomu občas používá některá rozšíření telefonu (třeba geolokaci, přístup ke kontaktům v telefonu a podobně). Pro tento typ aplikací je hybridní aplikace velmi dobrou volbou.

NevÝHODY HYBRIDNÍHO VÝVOJE

  • Vyšší požadavky na hardware – Vzhledem k tomu, že webová aplikace, která se tváří jako mobilní aplikace je ve skutečnosti jen vložena v instanci prohlížeče, tak to znamená jistá hardwarová omezení. V dnešní době se tento problém minimalizuje se zlepšujícím se výkonem telefonů a prohlížečů.
  • Možná nedostupnost API – Vývojáři neustále vyvíjejí nová API, pro přístup k novým funkcím telefonu. V případě hybridní aplikace se může stát, že nově dostupná API nejsou podporována (drtivá většina používaných však je).
  • Chybí nativní UI prvky – Velkou nevýhodou je to, že zde v základu naprosto chybí jakékoliv UI prvky, na které jsou uživatelé platformy zvyklí. I když se to nezdá, tak napodobení uživatelského rozhraní nativních aplikací je tvrdý ořišek. Nemusíme ale už vynalézat znovu kolo, máme zde mnoho zajímavých frameworků pro uživatelské rozhraní – Ionic, Onsen, Famo.us, idangero.us a další.

Mobilní web

Pokud by mobilní aplikace kopírovala funkcionalitu z již běžící webové aplikace, pak stálo za to zamyslet se nad tím, zda by nestačilo udělat dobře optimalizovaný mobilní web.

Výhody mobilního webu

  • Rychlost vývoje – Vývoj mobilního webu v případě jednodušších webů často zahrnuje pouze změnu CSS.
  • Univerzálnost – Při úpravách na webu není potřeba měnit kód ve více aplikacích.
  • Není nutné instalovat aplikaci do telefonu.
  • Aplikace není potřeba distribuovat přes obchodu třetích stran – Toto je na jednu stranu nevýhoda, ale na stranu druhou, jsme schopni aplikaci nasadit ihned (na druhé straně nasazení do obchodu trvá cca 3h u Google Play a týden u App Store).

Mobilní web se hodí hlavně pro malé a nenáročné aplikace, které nevyžadují žádnou speciální funkčnost a předpokládají, že uživatel je připojen k Internetu. Mimo pouhé přestylování aplikace na mobilní zařízení ale také existuje možnost vytvořit mobilní web jako samostatnou aplikaci a zobrazovat ji pouze na zařízeních s menším displejem. Tento přístup se používá hlavně u velkých webových aplikací, které není možné správně optimalizovat pro mobily. V takovém případě už stojí za úvahu, zda by nebylo lepší použít jiný přístup.

Nevýhody mobilního webu

  • Mizerný „uživatelský prožitek“ – Je mnohem složitější přizpůsobit web bez dodatečných knihoven tak, aby uživatel měl dojem z webu stejný jako v případě používání nativní aplikace.
  • Chybí napojení na API telefonu – Některé služby jako například GPS je možné napojit i do webové aplikace, ale proti nativnímu nebo hybridnímu vývoji jsou možnosti chudší.
  • Chybí nativní prvky UI – Vše je potřeba si nastylovat, nebo zkusit najít knihovny, které tyto prvky implementují. Často je složité je implementovat na již existující web, protože mohou měnit strukturu a je potřeba pamatovat na to, jak vypadá web i v počítači.
  • Nutnost být on-line a mít otevřený web v prohlížeči – Toto je možná vůbec největší problém. Ještě stále každý nemá připojení a mnoha uživatelům bude také chybět ikonka aplikace v menu (nicméně na iOS se dá docela snadno do menu přidat).

Srovnání pro a proti

Stručně jsme si tedy definovali výhody a nevýhody jednotlivých platforem. Teď si zkusíme uvést příklady aplikací, které se hodí pro konkrétní implementace:

Vhodné použití Nevhodné použití
Nativní vývoj Složité animace

2D/3D hry

Aplikace určené pro jednu platformu

Aplikace vyžadující méně používaná API

Vývojářsky jednoduché aplikace

Prototypování

Multiplatformní aplikace

Hybridní vývoj Aplikace pro stahování dat z API

2D hry

Prototypování

Aplikace s důrazem na nízkou cenu

Multiplatformní aplikace

Výpočetně náročné operace

Složité animace

3D hry

Rozšířená realita

Mobilní web Jednoduché aplikace s důrazem na nízkou cenu

Aplikace nevyžadující příliš specifické služby telefonu

Aplikace, které nemusejí dodržovat guidelines

Aplikace, která je založena na webové verzi

Nevhodné například pro načítání kontaktů z telefonu

Také ke všemu, co hybridní aplikace

Abychom byli více konkrétní, zkusíme si udělat 2 jednoduché analýzy aplikací:

1. Zobrazení počasí

Chceme vytvořit jednoduchou aplikaci (včetně grafiky), která nám bude načítat počasí z cizího API podle naší aktuální polohy a bude dostupná pro 3 hlavní platformy. Tento typ aplikace velmi dobře zvládají všechny tři způsoby vývoje.

Počet lidí Náklady Doba vývoje (včetně nasazení do obchodů) Poměr cena/výkon
Nativní vývoj 1 (grafika) + 3 (mobilní aplikace) = 4 ~80 000 Kč 10 dní Velmi špatný
Hybridní vývoj 1 + 1 = 2 ~25 000 Kč 10 dní Průměr
Mobilní web 1 + 1 = 2 ~15 000 Kč 3 dny Vynikající

Z tabulky je vidět, že pro tento typ aplikace teoreticky není potřeba dělat speciální aplikaci uloženou v telefonu. Data o počasí se totiž ve všech třech případech načítají z Internetu a geolokaci podle GPS zvládne každé řešení. Žádné další záludnosti zde nejsou a podle kritéria cena/výkon zde jasně vítězí mobilní web. Jediná nevýhoda u webové mobilní aplikace je ta, že k mobilním webům se uživatel telefonu nedostane tak snadno přímo z menu telefonu, ale musí ji spustit přes prohlížeč. Na druhou stranu je ale univerzální a lze k ní přistupovat stejně dobře i z počítače.

2. Načítání webového API a služby telefonu

Naším druhým cílem je vytvořit aplikaci, která bude pracovat se seznamem restaurací, který se bude synchronizovat s naším externím API (počítá se s ním v kalkulaci). Restaurace bude možné hodnotit, zobrazovat je na mapě a k hodnocení půjdou přiložit fotografie z fotoaparátu.

Počet lidí Náklady Doba vývoje (včetně nasazení do obchodů) Poznámka Poměr cena/výkon
Nativní vývoj 3 (aplikace) + 1 (API) + 1 (grafika) + 1 (tester) = 6 ~190 000 Kč 26 dní Velmi špatný
Hybridní vývoj 1 + 1 + 1 + 1 = 4 ~90 000 Kč 25 dní Vynikající
Mobilní web 1 + 1 + 1 + 1 = 4 ~60 000 Kč 15 dny Aplikaci nelze propojit přímo s fotoaparátem.Chybí nativní UI platforem. Průměr

I když zde podle počtu lidí, ceny vývoje i doby opět vítězí mobilní aplikace, tak zde nastává jeden velký problém s nemožností použití fotoaparátu v webové aplikaci. Sice je zde alternativní možnost použít API pro webkameru, ale mobilní platformy toto API v současné verzi ještě neumějí spojit s fotoaparátem. U této složitější aplikace už také budou u mobilního webu vidět nedostatky ohledně uživatelského rozhraní, které je závislé na platformě. Proto zde už nelze doporučit tvorbu mobilního webu, ale raději se zaměřit na hybridní vývoj, který zde využívá své silné stránky. Naopak nativní vývoj je zde zbytečně drahý a náročný na lidské zdroje.

Aplikací jako je tato se dnes dělá většina. Načítání API z webu, práce s ním a používání některých služeb z telefonu. Hlavně toto je důvod proč jsou hybridní platformy zajímavé.

V příštím díle se podíváme konkrétněji na AngularJS a Ionic framework.

Neberte, prosím, data v tabulkách jako nějaké dogmatické statistiky, jedná se pouze o odhady, byť na základě zkušeností.

Jan Václavík
Jan Václavík
Vystudoval jsem ČVUT FIT a pracuji v Productboard jako Software engineer. Kromě toho občas přednáším o programování, baví mě cestovat do neznámých krajin, lézt po horách a občas o tom píšu na tento blog. Na Twitteru mě najdete jako @janvaclavik.

1 komentář

  1. Super článek!… Výborně srozumitelné vysvětlení a srovnání technologií pro klienty poptávající vývoj, i pro lidi, kteří nejsou 100% vývojáři. 🙂

Odeslat komentář