React Native pro firemní aplikace: co zvládne jeden kód

React Native s Expo se hodí, když uživatelé na iOS i Androidu potřebují stejné postupy. U zákaznických i interních aplikací je to běžné: obrazovky, pravidla a volání API mohou sdílet jeden kód.

Samostatně plánujte rozdíly platforem, nativní SDK, testování na zařízeních a vydání v obchodech. Všechny tyto části zůstávají součástí dodání, i když je většina kódu společná.

Článek vysvětluje, kde sdílený kód pomáhá, kde vyžaduje práci navíc a co si ujasnit před volbou technologie. Navazuje na část o React Native na stránce vývoj mobilních aplikací.

Kdy stačí jeden kód pro iOS i Android?

React Native umožňuje sdílet aplikační kód mezi iOS a Androidem a TypeScript k němu přidává typy, které se kontrolují ještě před spuštěním aplikace. U většiny firemních aplikací je převážná část práce na obou platformách stejná:

• Obrazovky: Seznamy, detaily, formuláře a přehledy nad daty z vašeho API.
• Pravidla: Validace, stavy požadavků a zobrazení oprávnění v rozhraní.
• Relace a data: Přihlášení, správa relace a volání backendu.
• Notifikace: Návrat uživatele ke správnému úkolu.

Když obě platformy slouží stejným uživatelům a postupům, jedna sada obrazovek pomáhá udržet jejich chování jednotné. Společná změna může být součástí obou sestavení; schvalování a termín vydání v obchodech zůstávají samostatné.

Expo tento postup podporuje nástroji pro sestavení, konfiguraci a vydávání aplikací v React Native a umožňuje práci s nativními moduly, když je aplikace potřebuje.

Kdy zvážit nativní vývoj?

U některých projektů je vhodná podrobnější technická diskuse ještě před volbou sdíleného kódu:

• Aplikace závisí na specializovaném hardwaru nebo neobvyklé integraci se zařízením.
• Produkt stojí na náročné grafice nebo animacích nad rámec běžných firemních rozhraní.
• Už existuje rozsáhlá nativní aplikace pro iOS nebo Android, do které musí nová práce zapadnout.

Nic z toho React Native automaticky nevylučuje, ale každá z těchto věcí patří do prvního technického rozhovoru, ne doprostřed vývoje.

Co sdílený kód neodstraní

Rozdělení je přehlednější, když má každá oblast určeného vlastníka. Tabulka popisuje běžný výchozí stav, ne záruku pro každou aplikaci:

Rozdíly mezi platformami

iOS a Android mají odlišné zvyklosti: navigační gesta, tlačítko zpět na Androidu, podobu žádostí o oprávnění, seskupování a zobrazení notifikací. React Native nabízí způsoby, jak psát kód specifický pro platformu tam, kde se obě verze musí lišit (dokumentace React Native, anglicky). Ve většině firemních aplikací je takového kódu málo, ale existuje a je potřeba ho navrhnout a otestovat.

Nativní SDK

Platební brány, ověření identity, mapy, skenování nebo funkce zařízení se často dodávají jako nativní SDK pro iOS a Android. Před dohodou o rozsahu ověřte, zda má každé potřebné SDK udržovanou integraci pro React Native nebo Expo, nebo zda je nutné napsat nativní modul. Expo Modules umožňují takové propojení napsat ve Swiftu a Kotlinu (dokumentace Expo, anglicky).

U fintech aplikace je typickým příkladem platební nebo karetní SDK. Vyplatí se včas prověřit, které verze platforem podporuje, jak zobrazuje vlastní obrazovky a co vyžaduje od vašeho backendu.

Práce bez připojení

Práci offline je potřeba výslovně vymezit. Dohodněte, které úkoly fungují bez připojení, jaká data zůstávají v zařízení, jak se čekající změny odešlou a jak se vyřeší konflikty.

Terénní aplikace může potřebovat dokončit celou návštěvu offline. Aplikace se živým zůstatkem na účtu může místo toho potřebovat srozumitelnou zprávu o ztrátě připojení. Návrh vychází z konkrétního požadavku.

Testování na obou platformách

Každé vydání otestujte na obou platformách. Sdílený kód běží na různých systémech, velikostech displejů a verzích OS. Vedle simulátorů zapojte skutečná zařízení a ověřte přihlášení, notifikace, oprávnění i průchody nativními SDK.

Dvě vydání

App Store a Google Play mají oddělené účty, podepisování, schvalovací procesy a požadavky (pravidla App Store, anglicky, vydání na Google Play, anglicky). Někdo musí spravovat vývojářské účty a stránky aplikace v obchodech a rozhodovat o vydání. Před spuštěním dohodněte, kdo za co odpovídá.

Co si ujasnit před volbou

1. Potřebují uživatelé na iOS i Androidu stejné úkoly, nebo je jedna platforma důležitější?
2. Která nativní SDK a funkce zařízení aplikace potřebuje a mají integraci pro React Native nebo Expo?
3. Které úkoly musí fungovat offline, pokud vůbec nějaké?
4. Existuje už nativní aplikace a co se s ní stane?
5. Kdo vlastní vývojářské účty a odpovídá za vydání v obchodech?

Pokud odpovědi ukazují na společné procesy a na SDK, která jsou dostupná nebo je lze propojit, je jeden kód obvykle rozumnou výchozí volbou. Pokud ne, má technickou volbu určovat povaha projektu, ne naopak. Technologie musí odpovídat produktu.

Ilustrační rozhodnutí

Představme si fiktivní aplikaci pro schvalování požadavků. Na obou platformách ukazuje stejnou frontu, detail a formulář pro schválení nebo vrácení. Obrazovky, validační pravidla a volání API jsou sdílené.

Práce pro jednotlivé platformy: Face ID a biometrika Androidu používají udržovaný modul kompatibilní s Expo. Náhradní způsob ověření se testuje na obou platformách. Push notifikace otevírají stejný požadavek, ale přihlašovací údaje Apple a Google zůstávají oddělené.

Hranice první verze: Rozepsaný formulář zůstává jen po dobu otevření aplikace. Úplné offline schvalování počká na pravidla pro řešení konfliktů.

Rozhodnutí by znělo: začít jedním kódem v React Native, přiřadit produktovému vlastníkovi společný průchod, správci backendu události pro notifikace, týmu aplikace chování obou platforem a klientské organizaci oba účty v obchodech. Rozhodnutí se znovu otevře, pokud nezbytné schvalovací nebo bezpečnostní SDK vyžaduje nepřiměřené množství nativní práce. Jde o ilustrační rozhodnutí, ne o vydávaný výsledek projektu Tolaronu.

Co musí aplikaci poskytnout váš backend, rozebírá článek co musí umět vaše API, než začneme stavět aplikaci. Co přiložit k žádosti o odhad, popisuje článek jaké podklady poslat před poptávkou mobilní aplikace.

Další krok

Pokud zvažujete React Native pro firemní aplikaci, pošlete přes kontaktní stránku stručný popis uživatelů, hlavních úkolů a SDK nebo funkcí zařízení, na kterých aplikace závisí. Do první zprávy prosím nevkládejte přístupové údaje ani zákaznická data, k posouzení spolupráce nejsou potřeba.