Jak jsme použili React Native v HoppyGo
S React Native pracuji aktivně skoro dva roky, a ještě předtím jsem dlouhou dobu React Native (RN) zpovzdálí sledoval. Přiznávám, že jsem zpočátku byl k React Native skeptický, neboť podobný Native Script se na trhu nedokázal výrazně prosadit. Co mě ale na React Native zaujalo bylo to, že s ním přišel Facebook — tato firma občas dokáže změnit celé odvětví vývoje, jako jsme toho byli svědkem u Reactu.
Aktivně jsem dříve vyvíjel mobilní aplikace postavené na Ionic 2, nicméně jsem tam narazil na docela zásadní limity, které React Native dokázal řešit (především věci okolo performance a práce s nativními mapami).
Má smysl psát aplikaci velikosti Airbnb v React Native?
Ano, je to překvapivě v pohodě. Někdy v říjnu 2016 jsem stál u zrodu car-sharingu HoppyGo (http://hoppygo.cz), který rozjela Škoda Digilab a funguje dodnes. Měli jsme relativně svobodnou ruku při výběru technologií a celkem odvážně jsme zvolili React Native. Zpětně to hodnotím jako velice dobré rozhodnutí, byť dělat mobilní aplikaci velikosti Airbnb v technologii React Native nebylo v této době úplně obvyklé.
Zpětně mohu říci, že nám vývoj HoppyGo na React Native žádné nepřekonatelné problémy nepřinesl a ani po roce a půl vývoje aplikace bych toto rozhodnutí neměnil, pokud bych měl začít pracovat na podobné aplikaci znovu.
Při vývoji aplikace jsme se snažili, co nejdříve vydat MVP (Minimum Viable Product), abychom mohli vyzkoušet službu v praxi a ukázali investorovi naši práci. MVP se nám povedlo vytvořit asi po 3–4 měsících vývoje, což je na takto velkou aplikaci pro dvě platformy (iOS, Android) opravdu dost dobré. Samozřejmě se na produkci ukázala v aplikaci celé řada nedostatků, avšak důležitý základ appky víceméně fungoval. Od té doby se aplikace hodně posunula a už je stabilní a dobře použitelná. Bohužel špatných hodnocení na storech z dob MVP se aplikace už nezbaví. Lidé nám na App Store a Google play hodnotili aplikaci špatně především ze tří důvodů:
- Chyby v aplikaci — Těch bylo v MVP docela dost a aplikace relativně často padala nebo něco nefungovalo.
- Špatné UX — Původně jsme měli celý proces schválení výpůjčky navržený příliš složitě (bylo nutné poslat poptávku na 1…n aut, poté výpůjčku musel nějaký vlastník auta schválit a nakonec ji musel řidič znovu finálně potvrdit). Zároveň bylo nutné se před samotným vyhledáváním auta složitě registrovat. Byrokracie na úřadech proti tomu byla hadr. A i přesto se zde našli lidé, kteří dokázali udělat výpůjčku. Myslím, že stále hodně, co zlepšovat, třeba takový proces předávání auta je stále moc složitý a nebyl bych ochoten jej absolvovat, pokud bych někomu půjčovat auto jen na den.
- “Ženy a auta se nepůjčují” — Tento důvod jsme v recenzích četli až neobvykle často. Sice toto slovní spojení znám, ale vlastně vůbec nevím, kde se vzalo (nevíte někdo?). Zajímavé je, že si lidé, kteří nechtějí půjčovat auto stáhli naši aplikaci a dali si tu práci, aby nám ji i ohodnotili. Ale možná jsme jen špatně zvolili cílovou skupinu :-)
Srovnání HoppyGo s Airbnb možná není úplně přesné, neboť Airbnb je stále výrazně větší a dlouhodobější projekt než HoppyGo. Nicméně pokud si člověk prokliká aplikaci HoppyGo, zjistí, že obsahuje cca 80 obrazovek a nabízí docela rozsáhlé možnosti. Třeba v oblasti filtrace aut nabízíme mnohem lepší možnosti než zmíněné Airbnb (kde mimochodem nejde vyfiltrovat ani dům se saunou, což mě neskutečně vytáčí) nebo konkureční aplikace na půjčování aut.
Při vývoji HoppyGo jsem samozřejmě bedlivě sledoval konkurenci v čele se SmileCar. Zajímavé byly také zahraniční car-sharingové startupy jako Drivy, Turo nebo Getaround.
iOS aplikace od SmileCar vypadala od začátku hezky, nicméně po vyzkoušení Android verze se člověk nestačí divit jak velký rozdíl může být v kvalitě dvou aplikací stejné služby. Android verze SmileCar je totiž vytvořena pouze jako wrapper nad webovou verzí. To sice na papíře funguje, ale v praxi je aplikace uživatelsky velice nepřívětivá a pomalá. Na možnost použití nativních prvků můžeme rovnou zapomenout. iOS verze SmileCar je na tom o mnoho lépe, ale i tak si myslím, že uživatelská zkušenost (UX) a možnosti filtrace jsou tam udělané velice nešťastně.
Na příkladu SmileCaru je dobře vidět nevýhoda nativního vývoje. Zatímco jedna platforma (iOS) je relativně dotažená, druhá (Android) je prakticky nepoužitelná. Předpokládám, že na doladění druhé platformy nebyly peníze nebo čas, neboť dělat aplikaci dvakrát je mnohem těžší než jen jednou. To ale reálně znamená, že nějakých 70 % uživatelů (tolik lidí obvykle používá platformu Android) je znevýhodněných, nepoužívá se jim aplikace dobře a firma přichází své o potenciální zákazníky. Na druhou stranu by se dala pozitivně hodnotit webová verze SmileCar, která je použita na dvou platformách. Avšak při multiplatformním vývoji by aplikace měly být dobře použitelné na všech podporovaných systémech. Já osobně se kloním k tomu, že ideálnější řešení pro kombinaci mobilní aplikace + web je React Native se sdílenou business logikou pro web a oddělené šablony.
Prakticky nikdy jsme se při vývoji aplikace nedostali do situace, kdy bychom potřebovali sami něco implementovat nativně. Vše, co jsme potřebovali už někdo před námi vytvořil a udělal bridge do RN (na hledání modulů doporučuji https://js.coach/react-native). S novými SDK samozřejmě může být problém, ale většinou ani netrvá moc dlouho než je komunita vytvoří. Při vývoji aplikací v React Native je kromě znalostí Javascriptu důležité orientovat se v XCode a obecně jejich iOSu, Androidu, jejich guidelines a podobně. Říká se, že u RN je možná sdílet cca 60 % kódu napříč iOS a Android platformami. Já osobně bych odhadl, že bez externích knihoven se dá sdílet až 95 %, pokud se nemá aplikace nějak zásadně lišit v grafice a UX. Věci jako animace mezi obrazovkami nebo headery jsou relativně snadné (nepočítám-li nový iOS a jeho headery, ale už i na to jsou knihovny). Čím více bude aplikace specifická pro danou platformu, tím je to samozřejmě lepší, ale musíme brát v potaz také to, že finanční zdroje jsou zpravidla omezené.
Proč používat React Native
Dělat aplikaci několikrát, pokud to není nutné, je zkrátka blbost. Žádný zákazník by dobrovolně nezaplatil za vývoj dvakrát, pokud by ho k tomu netlačily vývojářské firmy. Ty se samozřejmě do nějakého efektivnějšího a levnějšího řešení netlačí. Automaticky svým zákazníkům říkají, že udělat multiplatformní aplikaci přizpůsobenou podle guidelines jednotlivých platforem nejde. A to není pravda.
Co konkrétně mi přijde na React Native zajímavé:
- Na vývoj aplikace pro platformy Android a iOS stačí jedna codebase a jeden tým programátorů se znalostmi stejné technologie. Dokonce můžete jít tak daleko, že budete sdílet business logiku i společně s webovou aplikací.
- Novou funkcionalitu stačí implementovat pouze jednou. U nativního vývoje to opět děláte tolikrát, kolik platforem máte.
- Vývoj dvou aplikací trvá polovinu času a stojí polovinu peněz (samozřejmě přibližně). Já osobně bych raději investoval peníze do zlepšení produktu než do dvojnásobně dlouhé implementace stejné věci.
- Píšete v Reactu. React je super a kdo ho nevyzkoušel, tak nepochopí. Sbohem, drahý Angulare!
- Když máte jednu aplikaci, nemusíte testovat dvě aplikace. Zní to sice jak moudro od Jolandy, ale je to pravda.
- S React Native pracují i velké firmy — Facebook, Instagram, Airbnb, Vogue, Microsoft nebo třeba HoppyGo :-)
Občas přemýšlím, zda se vývoj aplikací vůbec může vyplatit firmám, pro které mobilní aplikace nejsou core business, v němž získávají nejvíce zákazníků. Jejich vývoj je totiž sakra drahý.
Obecně i samotný koncept mobilních aplikací je pro mě trochu zvláštní — například aplikaci musím stahovat ze specializovaných obchodů a zabírá dost místa v telefonu. Svým způsobem mi do budoucna dává mnohem větší smysl sjednotit mobilní a webové aplikace (podobným způsobem jako se o to snaží třeba Progressive Web Apps). Ale na tohle ještě asi není svět dostatečně připravený.
A co nativní vývoj aplikací?
Těch důvodů proti nativním aplikacím je relativně dost, ale samozřejmě to není černobílé a já si uvědomuji, že nativní aplikace mají i spoustu výhod — Podpora od samotných výrobců OS, možnost používat nejnovější SDK, stále vysoká poptávka po tomto způsobu vývoje, efektivnější využívání výpočetního výkonu a podobně jsou silné argumenty pro to, nezatracovat nativní vývoj.
Při volbě, zda používat RN nebo nativní vývoj, je důležité se zamyslet nad tím, na co ho vlastně chcete používat. Pokud je třeba úkolem dělat hry, ani React Native, ani nativní vývoj nemusí být vhodnou volbou, neboť jsou lepší specializované a multiplatformní herní platformy (například Unity). Pokud chci vytvořit aplikaci pouze pro jednu platformu, dává smysl nativní vývoj. Podobné je to, pokud chci například dělat aplikaci s pokročilými animacemi nebo pro práci s obrázky či videem. Jednou jsem například dělal složitější Parallax v React Native a musím uznat, že rozdíl mezi nativní appkou a RN byl v plynulosti hodně znát (v RN jde použít při animacích na transformace native driver, kde se potom animace nesekají, ale třeba při dynamické změně výšky to může být problém). Nicméně i tak si myslím, že tyto věci jdou optimalizovat, jen to zabere více času, než to udělat nativně.
Co mě štve na React Native
React Native má své mouchy. Občas jsem se dostal do situací, kdy mě používání RN limitovalo. Asi nejvážnější problémy byly tyto:
- Pokud mám vynucenou orientaci v aplikaci na portrait a poté zapnu foťák, který má mnou implementované vlastní UI, kde fotím na landscape, občas se stává, že se orientace nechce přetočit zpátky. Tento problém jsem řešil docela dlouho a nepodařilo se mi to uspokojivě vyřešit. Naštěstí se to nestávalo tak moc často anebo tam byla jen dlouhá prodleva na vracení orientace. Věřím, že pomoc programátora, co zná nativní jazyky by mohla pomoci.
- Animace výjezdu modálních oken v react routeru stále není správně udělaná.
- Sekal se mi výše zmíněný parallax, když jsem dělal něco podobného jako mělo dříve Airbnb v header baru: https://medium.com/@moses.gunesch/conductor-orchestrate-animation-in-react-native-edd22b59ad17
- Na iOS v react-native-maps byl problém, pokud jsem měl na mapě hodně markerů a při zoomu jsem dvěma prsty začal na jednom z markerů
- Vertikální swiper na Androidu prakticky nešel udělat, horizontální byl bez problému.
- Nutnost jednou za čas updatovat verzi React Native. Vývoj React Native je až příliš rychlý takže musíte realtivně často updatovat a upravovat breaking changes.
Většina z toho jsou docela drobnosti, které se dají řešit jiným UX návrhem nebo případným řešením v nativním kódu.
Další doporučené zdroje
- https://hackernoon.com/the-cost-of-native-mobile-app-development-is-too-damn-high-4d258025033a
- http://janvaclavik.cz/jak-vyvijet-mobilni-aplikace/
Díky za přečtení. Budu rád, pokud mi napíšete do komentářů Vaše zkušenosti s React Native.
