<section className="mb-16 text-black">
 
 Az interneten és mobilon elérhető térképekről azonnal a Google Maps jut eszünkbe, de valószínűleg találkozhattunk már más szolgáltatókkal is, mint a Mapbox vagy a Yandex Maps.
 
 
 A Yandexnek sajnos kissé foghíjas a támogatása, mert rengeteg minden nem elérhető angol nyelven vagy csak nagyon régi csomagok nyújtanak teljes értékű angol dokumentációt.
 
 
 A Mapbox viszont egy jó alternatíva lehet, mivel a mobilos SDK-juk 25000 felhasználót enged havonta, anélkül, hogy kártya adatokat kellene megadnunk.
 Van hivatalos csomagjuk, @rnmapbox/maps néven, amit már megszokott npm vagy yarn segítségével telepíthetünk, illetve a git repojukban találunk telepítési útmutatót és példát is a használatra.
 
 
 És persze a legnépszerűbb választás még mindig a Google Maps. Ezt kétféleképpen tudjuk működésre bírni: egyrészt létezik a szokásos csomagtelepítős megoldás, node package managerrel feltesszük a react-native-maps csomagot. A másik megoldás az, ha Expo projekben dolgozunk, mivel ekkor már az inicializálásnál települnek a szükséges részek.
 

 <h num="{{2}}" className="mb-4">
 Akkor nincs is ebben semmi trükk, ugye?
 </h>

 
 A témában tapasztaltnak tekinthető fejlesztők számára valószínűleg nincs, de ha most kezdjük, akkor lehet benne egy-egy trükk ami nem feltétlenül triviális elsőre.
 
 
 Amikor Expo Snack formájában online vagy lokálisan, Expo Go használatával próbálkozunk, akkor a példák tökéletesen működnek, megjelenik a térkép, tudunk navigálni, zoomolni és a API többi funkciója is okénak tűnik, mint a markerek, kijelölt szakaszok, poligonok.
 

 
 Jöhet is a build, telepítjük a telefonunkra és azzal szembesülünk, hogy ez bizony nem működik, mert vagy összeomlik, vagy nem tölt be, mivel látszik a helye, de totál üres, esetleg egyszínű a komponens.
 

 
 Ennek több oka is lehet, de a leggyakoribb, hogy nem írtuk be, vagy helytelenül használjuk az API kulcsot amit kaptunk hozzá:
 

 
 Előbbi esetben felmerülhet, hogy eddig miért működött kulcs nélkül. Snackben illetve a Go-ban azért nem volt gond, mert van saját, érvényes kulcsuk, amin keresztül a kéréseink mennek. A dokumentációjuk alapján be tudjuk illeszteni a saját kulcsunkat. Jelen verzióban a negyedik pontig teljesen működőképes is amit javasolnak, azonban magát a stringet amit a Googletől kapunk, hiába illesztjük az app.json fájlba, ha már egyszer végigment a build, sok esetben nem frissül a generált forráskód. Android esetén ezt az AndroidManifest.xml fájlban kijavíthatjuk, az application tagek közé ezt beillesztve:
 

 <codeblock language="xml" className="mt-3 mb-3 ml-6">&lt;meta-data android:name="com.google.android.maps.v2.API_KEY" android:value="KULCS_AMIT_KAPTUNK"/&gt;</codeblock>

 
 Az utóbbi eset általában egyszerűbb, az a trükk, hogy ha csak Cloud Consoleban létrehozunk egy egyszerű API kulcsot ingyen, azt bizony nem fogja elfogadni, kénytelenek vagyunk a Maps Platformon belül létrehozni, amihez be kell írnunk egy bankkártyaszámot. Persze ne ijdejünk meg, a Google nem fog kérdés nélkül lehúzni semmilyen összeget a számlánkról: Ha elérjük a kvótát, értesítést kapunk és át tudunk váltani fizetős, korlátlan hozzáférésre.
 

 
 Ezután ha frissítjük az APK-t és telepítjük, a térképünk jó eséllyel működni fog.
 
 </section>

Vegye fel velünk a kapcsolatot! Szívesen segítünk bármilyen app elkészítésében, modernizálásában!

Google Maps API React Native és Expo környezetben. Hogyan használhatom én is, a saját implementációmban? Reális alternatíva a Mapbox vagy a Yandex?

Használhatunk külső könyvtárakat, illetve beépített térkép komponenst is kapunk ha Expo alapokra építkezünk az alkalmazásunkkal.

React Native térkép komponensek használatának trükkjei

<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 tudjon fejleszteni. A piac a natív appoktól egyre inkább a cross-platform megoldások felé mozdult.

React Native

React Native térkép komponensek használatának trükkjei

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