Az appok 2022-ben: A natív, a webes és a hibrid

Ez alapvetően két dolognak köszönhető:

• Borzasztó nehéz több kódbázist szinkronban fejleszteni, még akkor is ha az adott platformon megfelelő képzettséggel rendelkező szakemberekkel rendelkezünk. Sokkal több időt vesz igénybe, illetve a menedzsment a nagyobb létszám miatt értelemszerűen bonyolultabb feladat.
• A megnövekedett időigény egyenes következménye a költségek növekedése, ez pedig azt jelenti majd, hogy rengeteg jó ötlet nem valósulhat meg, egyszerű pénzhiány miatt.

A cross-platform megoldásoknál ezek a problémák mérséklődnek.

Minden ilyen megoldásnak a központi céljai között van, hogy a kódbázis amiből a végleges állományokat fordítjuk, minél kevesebb platformspecifikus részt tartalmazzon. Ez a gyakorlatban azt jelenti, hogy ha van egy iPhoneunk és egy Androidos telefonunk is, akkor az általunk megírt dolgok ne igényeljenek külön kezelést az egyes eszközökre, azaz ne kelljen különbséget tennünk a forrásban, hogy most éppen milyen telefonon vagy tableten fut a kész állományunk.

A natívhoz képest a másik véglet a web, itt egy úgynevezett WebViewt hozunk létre, ami gyakorlatilag egy böngészőablak, kezelőfelület nélkül, teljes kijelzőre méretezve. Mivel a böngészőmotorok nagyon hasonló funkciólistával rendelkeznek, egyszerre implementálhatunk mindent PC-re és okostelefonra. Így az egész nagyon gyorsan elkészül és ha nem kell a hardvert elérni (pl. rezgőmotort, értesítő ledet, ujjlenyomat olvasót), akkor verhetetlenül olcsó is.

Persze van hátránya is:

A futásteljesítmény és az előbb említett hardverkezelés. Előbbi ritkán jelent problémát, a jó optimalizáción múlik igazán, nem azon, hogy miben készül a termékünk.

Utóbbi már képes nagyobb gondokat okozni, mivel valahogy kötnünk kell a WebView tartalmát a natív funkciókhoz. Talán a legkézenfekvőbb egy saját API-t gyártani, amely csak a szükséges natív funkciókat implementálja, de ez olyan, mint újra feltalálni a kereket: Már van rá megoldás, az esetek nagy részében nem éri meg újat csinálni.

Erre nyújtanak megoldást a hybrid frameworkök, melyek általában webhez hasonló szintaxissal rendelkeznek, de olyan komponenseket is tartalmaznak, melyekkel kihasználhatóak a natív funkciók.

Gyakran használt kombináció a React Native és az Expo párosítása. Ha megnézzük előbbi dokumentációját, akkor viszonylag kevés alap komponenst találunk és ezek is inkább a layout kialakítására fókuszálnak. Az Expo ezt egészíti ki jónéhány hasznos dologgal.

Az egyszerűség kedvéért nézzük meg például, hogy miképpen lehet az akkumulátor töltöttségét lekérdezni. Ugye WebViewnál natív oldalon le kell kérdeznünk a BatteryManagertől ezt az adatot, aztán valahogy visszaadni egy végponton. Ezzel szemben a hibrid megoldást is elbonyolíthatjuk mindenfélével, de a lényeg nagyjából ennyi:

Ennél könnyebb dolgunk nem igazán lehetne, JSX-ben simán egyetlen sor a lekérdezés, ami egy 0 és 1 közötti float értéket ad vissza, illetve -1-et ha nem támogatott (pl. Android TV-ben hiába keresnénk akkumulátort).

Persze nem csak ennyi a történet, rengeteg mindent paraméterezhetünk. Például a gyorsulásmérő lekérdezésénél megadható az adatok frissítési intervalluma:

Ebben az esetben 1000ms-re állítottuk, azaz másodpercenként egyszer fog frissülni a mért érték.

Ugyanígy például az IP címet is lekérhetjük:

Illetve nem csak függvényeket, de propertyket is kapunk:

Így megkapjuk byteban az eszközbe épített RAM méretét. Ez értelemszerűen időben nem változik, így felesleges lenne aszinkron lekérdezés hozzá.

Látható tehát, hogy ha szeretnénk az eszköz beépített funkcióit is használni a mobil alkalmazás fejlesztés során, akkor érdemes a hibrid megoldásokat is számításba venni, mivel jelentősen megkönnyítheti a dolgunkat és rengeteg pénzt, illetve időt spórolhat nekünk.