Mobilalkalmazások két platformon

Ez a bejegyzés bevezetést nyújt a keresztplatformos mobilalkalmazások fejlesztési környezetébe, két széles körben elterjedt, webtechnológiákra épülő keretrendszer könnyen érthető leírásával: React Native és Apache Cordova. Más teljesen érvényes és népszerű választási lehetőségek, mint az Ionic, a Flutter vagy a Felgo, ebben a bejegyzésben nem kerülnek bemutatásra.

Kezdjük az elején: miért is fontosak a mobilalkalmazások? A Finances Online szerint a globális fogyasztói költés mobilalkalmazásokra tavaly meghaladta a 100 milliárd dollárt, és a statista.com előrejelzése szerint az okostelefon-felhasználók száma 2021-re 3,8 milliárdra nő. Ezért érdemes lehet, hogy a gondosan megtervezett logónk mindig ott legyen ezeken az eszközökön. Ezt elérhetjük progresszív webalkalmazások (PWA) használatával is, de véleményünk szerint a PWAs inkább a technikai körökben népszerűbbek, mint a kevésbé technikai felhasználók körében, legalábbis egyelőre, Közép-Európában.

Tehát elismertük, hogy a mobilalkalmazások érdemesek a figyelemre, és nagyon szeretnénk, ha a logónk milliók okostelefonján ott lenne, de itt jön az érdekes rész: valóban szükséges két külön alkalmazást fejleszteni (és fizetni érte) Android és iOS eszközökre? A válasz: attól függ. Mindig az alkalmazás és a kiszolgálni kívánt esetek függvénye, azonban a keresztplatformos mobilalkalmazás-keretrendszerek nagyszerű módjai lehetnek a fejlesztési költségek és komplexitás csökkentésének, és előfordulhat, hogy a teljes kódalap újrahasznosítható mindkét platformon.

A keresztplatformos mobilalkalmazás-keretrendszerek lehetővé teszik a fejlesztők számára, hogy natív vagy hibrid mobilalkalmazásokat írjanak, amelyek mind Androidon, mind iOS-en futnak, többnyire közös kódalapot használva. Ez alapvetően azt jelenti, hogy az Apple App Store-ból és a Google Play Store-ból letöltött alkalmazás nagyrészt ugyanazt a kódot tartalmazza. Ennek érdekében sok ilyen keretrendszer webtechnológiákat, például JavaScriptet vagy HTML-t használ az alkalmazás logikájának és a felhasználói felületnek a biztosítására, míg a natív funkciók eléréséhez platformspecifikus natív könyvtárakhoz való kötéseket használ, amelyeket maga a keretrendszer valósít meg. Magasabb szinten ez azt jelenti, hogy az alkalmazást többnyire JavaScriptben írják, nem pedig Kotlinban vagy Swiftben, ami számos előnnyel és hátránnyal jár.

ELŐNYÖK:

• Az alkalmazás kódja újrahasznosítható mindkét mobilplatformon.
• Az alkalmazás logikája újrahasznosítható a webalkalmazásban (sőt, néha még a felhasználói felület részei is).
• Az alkalmazás logikája újrahasznosítható a webalkalmazásban.
• Az alkalmazás fejlesztése kevesebb időt vesz igénybe.
• Az alkalmazás továbbra is natív, hozzáférhet különféle érzékelőkhöz, natív push értesítésekhez, helyadatokhoz stb.
• Az alkalmazás könnyen karbantartható.

HÁTRÁNYOK:

• A költségmegtakarítások kisebb, de létező teljesítményproblémákon vesznek el.
• Előfordulhat, hogy bizonyos platformfüggő natív kódot mégiscsak meg kell írni.
• Az alkalmazás letöltési mérete jelentősen nagyobb lesz, mint a tisztán natív alkalmazásoké.

Két kedvenc keretrendszerünk a React Native (kiterjedt használatával az Expo) és a Cordova, mivel mindkettő kiváló eszköz a megfelelő munkához, de először nézzük meg a fő különbségeket. A főbb különbségtételi szempontok a következők lesznek:

• Fejlesztési idő: arányos a fejlesztési költséggel.
• Natív animációk: nagy hatással van a felhasználói élményre.
• Teljesítmény: mindenki szereti a gyors, élénk alkalmazásokat.
• Meglévő webes komponensek újrahasznosíthatósága: hogy könnyen integrálhatók-e meglévő weboldalak komponensei.
• Támogatás OTA frissítésekhez: Az Over-The-Air frissítések gyorsak, mert nem igényelnek új alkalmazásbuildet, amit fel kell tölteni a boltokba.
• AR/VR támogatás: hogy az alkalmazás tartalmazhat-e Kiterjesztett vagy Virtuális Valóság funkciókat.
• Háttérkódfuttatás: például médialejátszás az alkalmazás háttérben futása közben.
• Licenc: hogy a keretrendszer nyílt forráskódú és ingyenesen használható-e.

Az érzékelőkhöz való hozzáférés (mint például a kamera vagy a gyorsulásmérő) és a push értesítések támogatása nem szerepel a listában, mivel ezeket minden keretrendszer támogatja. Nézzük meg, hogyan viszonyul a React Native és a Cordova a natív alkalmazásokhoz ezen tulajdonságok tekintetében.

*A megadott keretrendszer licencé, nem az alkalmazásé

Bár a fenti táblázat messze nem technikai, világosan látszik, hogy a React Native teljesítmény és „natívság” szempontjából kiemelkedik, míg a Cordova remek lehet, ha egy meglévő webalkalmazást kell mobilalkalmazás formátumba ágyazni, de nézzük meg egy kicsit mélyebben a különbségeket.

Mind a React Native, mind a Cordova jelentősen alacsony fejlesztési időt kínál a platformspecifikus natív alkalmazásfejlesztéshez képest. A React Native a „Learn once, write anywhere” filozófiát követi, ami azt jelenti, hogy ugyanazok a fejlesztési koncepciók alkalmazhatók az Android és iOS alkalmazások írására (bár a legtöbb esetben a kód újrahasznosítható). A Cordova esetében a felhasználói felületet egy minimális webböngésző rendereli, így a felhasználói felület minden platform esetében pontosan ugyanúgy fog kinézni. A natív alkalmazások esetében azonban külön fejlesztőknek kell külön kódot írniuk minden célzott platformra, ami növeli a költségeket.

Az alkalmazások ugyanazon Android emulátoron, ugyanazon PC-n futnak. Az emulátoron való futás rendkívül negatív hatással van a teljesítményre. A felvételeket minden alkalmazás 3 bemelegítő futása után készítették.

Talán a Cordova legfőbb előnye a többi választással szemben az, hogy a stílusokat CSS használatával lehet kialakítani, ami azt jelenti, hogy bármely meglévő reszponzív webes felhasználói felület újrahasznosítható jelentős módosítások nélkül. Képzeld el úgy, mintha megragadnád a webalkalmazásodat, és egy mobilalkalmazás héjába helyeznéd, natív funkciókkal kiegészítve. Megjegyzendő, hogy az összes tárgyalt platform támogatja a WebView-kat, így egyszerű HTML felhasználói felületek, mint például a feltételek és feltételek oldalak, minden esetben újrahasznosíthatók. Bár a CSS használata a stílus kialakításához előnyös lehet, jelentős teljesítményhatással bír, amikor az eszköz tájolása megváltozik, mivel a keretrendszernek újra kell számítania az összes dinamikus dimenziót és pozíciót.

Az OTA frissítések lehetővé teszik a felhasználók számára a frissítések fogadását anélkül, hogy azokat a megfelelő áruházakból kellene telepíteniük. A React Native és a Cordova esetében az alkalmazás JS-ben van írva, ami azt jelenti, hogy egy kezdeti build után az alkalmazást nem kell újrafordítani (ha az alkalmazás nincs natív függőségekkel kiegészítve). Ez lehetővé teszi a fejlesztők számára, hogy futás közben cseréljék az alkalmazás logikáját, így megvalósítva az OTA frissítéseket. A natív alkalmazások esetében ez nem lehetséges, legalábbis nem alapértelmezés szerint.

Nyilvánvaló, hogy a natív alkalmazások teljes körű támogatást nyújtanak az AR és VR funkciókhoz a Google ARCore és az Apple ARKit révén. A Cordova alapvető felépítése és elvei miatt nem képes erre, de mivel a React Native valójában natív nézeteket használ, számos nyílt forráskódú könyvtár jelenhet meg, amelyek segíthetnek keresztplatformos AR/VR alkalmazások építésében. Lásd itt működés közben. Fontos megjegyezni, hogy az AR és VR csak a megfelelő hardverkonfigurációval rendelkező eszközök által támogatott, és ez minden esetben érvényes.

Sajnos a háttérkód futtatásának alapértelmezett támogatása jelentősen korlátozott a keresztplatformos alkalmazások esetében, mivel egy JS értelmező háttérben való elindítása rendkívül nagy teljesítménybeli terhelést és hatást gyakorol az akkumulátor élettartamára. Ez nem jelenti azt, hogy egyáltalán nem lehet háttérfeladatokat futtatni. A React Native és a Cordova is biztosít API-kat az operációs rendszer által időzített JS feladatok futtatására, de számos hátrány van a natív alkalmazásokhoz képest.

Bár a greenfield alkalmazásokhoz használt keretrendszerünk a React Native, a végső választás mindig az ügyfeleinkkel együtt meghatározott tényleges követelményektől függ. Egy átlagos alkalmazás esetében hasonló teljesítmény és funkciókészlet érhető el és építhető meg bármelyik említett keretrendszerrel.

Remélem, hogy ez a bejegyzés gyakorlati bevezetőt adott a keresztplatformos mobilalkalmazások világába. Ha még mindig vannak kérdéseid, vagy csak szeretnél egy jót beszélgetni ezeknek a keretrendszereknek a technikai részleteiről, ugorjunk be egy kávéra, az ajtó mindig nyitva áll a Tűzoltó 66-ban (bejárat a Lenhossék utcából).