Így kavarja össze a webet a natívval az Android
A jól modularizált alkalmazások könnyedén válhatnak Instant Apps-á, függőségeiket rosszul kezelő natív appok esetében már most érdemes megkezdeni a felkészülést. Néhány hónap múlva ugyanis kvázi-forradalom kezdődik, az elején pedig nagyot lehet nyerni.
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.
Google Instant Apps on Android are really fast
Még több videó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.
A Gitlab mint DevSecOps platform (x) Gyere el Radovan Baćović (Gitlab, Data Engineer) előadására a november 7-i DevOps Natives meetupon.
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.