Így kavarja össze a webet a natívval az Android

Komoly problémája a natív alkalmazásoknak az óriási súrlódás. Cselle Gábor rengeteget idézett, és mára klasszikussá vált posztjában fogalmazta meg, hogy minden lépéssel a felhasználók 10-20 százaléka morzsolódik le, még mielőtt az alkalmazás lényegi részéhez érnének. A konkrét lemorzsolódást persze rengeteg tényező befolyásolja, de a lényegen ez nem változtat: minél több akadályt görgetünk a felhasználó és az áhított tartalom (vagy funkció) közé, annál többet veszítünk el.

^{Sematikusan: így fogy a nép minden kattintással.}

De ezzel még nincs vége a vesszőfutásnak. A nehezen és drágán megszerzett natív app felhasználók is nagyon könnyen morzsolódnak tovább. A Localytics legfrissebb jelentése alapján a felhasználók 23 százaléka csupán egyszer indítja el az appot, utána soha nem tér már vissza. Ez egybevág azokkal a felmérésekkel, amelyek szerint a felhasználók mobilon töltött idejének túlnyomó többségét csupán néhány alkalmazás viszi el, a többit csak szükség esetén (értsd: ritkán) nyitják meg.

Lehet megoldás?

A Google nyilván pontosan tisztában van a problémával: a natív appok továbbra is rengeteg tevékenységhez ideálisak, de a web azonnaliságát és minimális súrlódását egyszerűen nem tudják nyújtani jelenleg. Ez pedig probléma a cégnek: mint webes óriás és mint a legnagyobb natív platform (az Android) tulajdonosa erre a Google-nek is sürgető megoldást találni. A tavalyi fejlesztői konferencián már felvillant az első néhány ötlet - a web oldaláról a Progressive Web Apps az első nagyobb lépés, amely a web néhány friss vívmányát egybe csomagolva igyekszik nevet (sőt: brandet) adni a natívhoz közeledő webes alkalmazásoknak.

Az androidos oldalról az első kezdeményezés talán a jogosultság-kezelés átalakítása volt, amelyben a Google az Apple-féle modellt honosította meg, az appok akkor kérnek hozzáférést a rendszer egyik-másik részéhez, amikor szükségük van rá (nem pedig telepítéskor). Ezzel a telepítési folyamatból került ki egy leokézandó képernyő, ennyivel is csökkent a telepítés súrlódása. Szintén fontos fejlemény volt a webes-natív közeledésben az App Links bevezetése, ezzel a weben lehet elhelyezni az app mélyére mutató linkeket.

Szintén ide, a közeledésre mutat az App Indexing is, vagyis hogy az appok mélyére nem csak linkelni lehet, hanem ide a keresőmotorok is be tudnak jutni, így értelemszerűen keresni is lehet. Így az appok tartalma megjelenik a Google keresési találataiban is, ezeket pedig mobilon nézve még ki is emeli a találati oldal.

...és akkor jöttek az Instant Appok

A törekvésre a koronát azonban egyértelműen az Instant Apps teszi fel, amely az androidos appok legnagyobb problémáját, a telepítési folyamatot nullázza ki. Az app-telepítés ugyanis fejlesztői szemmel igazi horror: a felhasználót el kell irányítani a Play Store-ba, ott a felhasználónak kell indítania a telepítést, majd a hosszas letöltés-telepítés után végre használhatóvá válik az alkalmazás. A rengeteg lépésből álló és körülményes, lassú procedúra masszív lemorzsolódást jelent, nem véletlen, hogy mára oda jutottunk, hogy a többség egyszerűen leszokott az appok telepítéséről.

A nagy dobás az idei Google I/O-n jött, az Instant Apps formájában. A koncepció maga nagyon egyszerű: az appok futtathatóak lesznek telepítés nélkül is, pont úgy, mint a webes alkalmazások a böngészőben. Mindezt úgy, hogy közben a natív alkalmazások egyes kritikus elemei megmaradnak - egyszerűbb megnézni a következő videót, mint részletesen megmagyarázni az élményt.

A koncepció lényeges eleme, hogy az Instant Apps nem csak webes linkekből vagy más alkalmazásokból hívható meg, erre lehetőség van például NFC-n vagy várhatóan Bluetooth-alapon is (például a Google Nearby segítségével).

Hogyan működik?

A felhasználó felé az Instant Apps roppant egyszerűen működik, de csak azért, mert a háttérben a fejlesztő elvégzi a munkát. Ahhoz ugyanis, hogy a megközelítés működjön, az appokat teljesen újra kell szabni.

Érdekes amúgy, hogy a Google eredetileg nem ebbe az irányba indult el, az eredeti koncepció szerint inkább streamingben gondolkodott a cég. Erre utal, hogy a Google szinte pontosan egy éve vásárolta meg az Agawi csapatát, amely natív alkalmazások streamelésével foglalkozott. A technológiát pedig később a Google egy újfajta hirdetési formánál, a streamelt app-demóknál tesztelte is, valószínűleg ez vezetett oda, hogy a cég újragondolta a megoldást és helyette egy másik megközelítést választott.

Merthogy az Instant Apps esetében már nincs szó streamingről. Helyette az alkalmazásokat bontja fel modulokra, amelyekből függőségi alapon hálót generál, és e hálóból mindig csak annyit tölt le, amennyire éppen szükség van. Az eredmény, hogy a modulok képesek villámgyorsan letöltődni és futni a felhasználó készülékén, telepítés és további lépések nélkül - pont úgy, mint a weboldalak esetében.

Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.

Gyakorlatban ez a következőképp néz ki: egy étteremkereső alkalmazásba, egy adott étteremre mutató deep link lekattintását követően letöltődik az alkalmazásnak az a része, amely az adott adatlap kiszolgálásához szükséges - az adott nézethez feltétlenül szükséges függőségekkel egütt. Amíg az adott képernyőt nézi a felhasználó, a háttérben letöltődik a következő képernyőkhöz tartozó kód is. Az elemeket a rendszer gyorsítótárazza (újabb webes hasonlóság), így ha újra lekattintjuk ugyanazt a linket, akkor nem generálunk újra hálózati forgalmat. A felhasználó lehetőséget kap arra, hogy az app "maradékát" is telepítse, amennyiben megteszik neki a funkcionalitás.

Az appok feldarabolásának hogyanjáról és mikéntjéről egyelőre csak korlátozott információk állnak rendelkezésre, a Google csak fokozatosan nyitja meg a technológiát a külső fejlesztők előtt, a dokumentációból azonban már sok minden kiolvasható.

A legfontosabb: a tulajdonképpeni Instant Apps implementáció nem az Android rendszer részeként, hanem a Play Services elemeként érkezik meg, Android 4.1-gyel bezárólag. Ez azt jelenti, hogy a rajt után az aktív eszközök mintegy 90 százalékán elérhető lesz ez a funkció. Így szerencsére nem kell éveket várni arra, hogy az aktuális Android-kiadás elterjedjen, az Instant Apps a rajt után rögtön célozható lesz.

A fejlesztők szempontjából az is előny, hogy az Instant Apps-hoz nem kell külön alkalmazást fejleszteni, tehát nem kell két appot fenntartani sem. Gradle-ben teljesen logikus módon létrejön két build artifact, egy a telepíthető, hagyományos .apk formátumú apphoz, egy pedig az Instant Appokhoz, mögöttük viszont ugyanaz a forráskód marad, a dupla munkára nem lesz szükség.

Szerencsére az appokhoz nem kell mélyen hozzányúlni a modularizációhoz sem, az Android a kezdetektől úgy épült, hogy ez a paradigma könnyen ráhúzható. A build alrendszer, az alkalmazáskomponensek, az Activity-k, a Fragmentek, az Intentek, a Service-ek, a Loaderek mind-mind megtalálják a helyüket a moduláris világban is. Mindez azt jelenti, hogy ha az alkalmazás úgy épül fel, hogy az egyes Activity-k és Fragmentek egymástól teljesen függetlenül be tudnak töltődni, akkor az Instant Apps további komoly erőfeszítést már nem is igényel, az alkalmazás modulonként is működni fog.

Probléma csak a "spagettikód" esetén van, amikor a különböző helyekre tartozó elemek keveredni kezdenek. Ilyenkor bizony az első lépés az lesz, hogy a teljes alkalmazást szét kell szálazni, hiszen a modularizációt is csak ezután lehet megvalósítani. Az ökölszabály tehát: az alkalmazás egyes komponensei minél kisebbek legyenek, a függőségek jól elváljanak, a modulok pedig egymástól függetlenül is jól működjenek, egy-egy képességet hatékonyan el tudjanak végezni.

Az Instant Apps programba Google-nál lehet jelentkezni, azoknak, akik gyorsan akarnak lépni, érdemes ezt minél gyorsabban megtenniük.

A cikk szerzője Orosz Gábor, a Budapest Mobile fejlesztői Facebook-csoport alapítója.