<section className="mb-16 text-black">
 Ez alapvetően két dolognak köszönhető:
 <ul className="list-outside list-disc mb-3">
 <li className="ml-6">
 Borzasztó nehéz több kódbázist szinkronban fejleszteni az adott platformon
 megfelelő képzettséggel rendelkező szakemberekkel. Sokkal több időt vesz
 igénybe, illetve a menedzsment a nagyobb létszám miatt értelemszerűen
 bonyolultabb feladat.
 </li>
 <li className="ml-6">
 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.
 </li>
 </ul>

 
 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:
 
 <codeblock className="mt-3 mb-3 ml-6"
 >await Battery.getBatteryLevelAsync(); // 0.8</codeblock
 >
 
 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:
 

 <codeblock className="mt-3 mb-3 ml-6"
 >Accelerometer.setUpdateInterval(1000);</codeblock
 >
 
 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:
 <codeblock className="mt-3 mb-3 ml-6"
 >await Network.getIpAddressAsync();</codeblock
 >
 
 Illetve nem csak függvényeket, de propertyket is kapunk:
 
 <codeblock className="mt-3 mb-3 ml-6">Device.totalMemory;</codeblock>

 
 Í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
 <a className="underline" href="{{routes.app}}" locale="hu"
 >mobil alkalmazás fejlesztés</a
 >
 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.
 
</section>

Vegye fel velünk a kapcsolatot! Csapatunk szívesen segít bármilyen digitális megoldás elkészítésében.

A cross-platform appok segítségével egyszerre fejleszthetünk mindkét nagy rendszerre. Cikkünkben megismerheti a natív megoldásokkal szembeni előnyöket.

Az okostelefon elterjedése óta számos megoldás született arra, hogy a programozó minél könnyebben, gyorsabban tudjanak fejleszteni. A piac a natív appoktól egyre inkább a cross-platform megoldások felé mozdult.

React Native

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