APDE GSoC ’18: Android Mode 4.0 Integrációk
Amikor egy vázlatot futtatsz a watch face célponttal, a vázlat felépül és elküldésre kerül az órára. Ezután az APDE wear companion app automatikusan betölti a vázlatot, és elindítja az óralapválasztót:
A VR vázlatok ugyanúgy települnek, mint a hagyományos alkalmazások. Támogatják a Google VR platformját, amely magában foglalja a Cardboard és Daydream headseteket:
Ha szeretnéd kipróbálni ezeket az új funkciókat, csatlakozz az APDE Preview Channelhez, és kövesd a tetején található utasításokat a tesztelői listához való csatlakozáshoz.
A cikk írásakor a v0.5.0-pre2 elérhető, és tartalmazza a háttérképeket és a VR-t, de nem tartalmazza a watch faces-t.
Hogyan működik mindez?
Az új célok támogatásának kulcsa az asztali Processing Android Mode 4.0-ás Android Mode használatára történő frissítés volt, amely hozzáadta a háttérképek, a watch faces és a VR támogatását. Az én munkám csak abból állt, hogy ezeket a klassz új funkciókat átültettem az APDE-be, ami önmagában nem volt könnyű feladat.
Még korán eldöntöttem, hogy azt akarom, hogy minden skicc minden célponton futtatható legyen. Azt akarom, hogy a felhasználók képesek legyenek bármilyen vázlatot vagy példát venni, és zökkenőmentesen átültetni az egyik környezetből a másikba, legyen az alkalmazás, háttérkép, óralap vagy VR. Így maximális rugalmasság és kapacitás áll rendelkezésre a Processing vázlatok teljes potenciáljának felfedezéséhez. Az egyetlen kivétel ez alól az, hogy a VR vázlatoknak 3D-snek kell lenniük (a 2D-s vázlatok egyszerűen nem működnek a VR természetéből adódóan).
Ez a megközelítés eltér az Android módtól. Az asztali számítógépen például a VR könyvtárként van csomagolva, így csak olyan vázlatok futtathatók a VR-célponthoz, amelyek kifejezetten importálják a VR-könyvtárat. Az APDE-ben minden 3D vázlat futtatható a VR-hez, és a megfelelő importok automatikusan hozzáadódnak.
A build rendszer most egy sablonkészletet használ az összes build fájl, például a tevékenységek, manifesztek és elrendezések nyomon követésére. Ez a módszer sokkal előnyösebb, mint a korábban alkalmazott kemény kódolás. A sablonok nagyjából szó szerint az Android módból származnak, de van néhány változás, például a Daydream VR headsetek támogatása.
A live háttérképek és a VR vázlatok ugyanúgy települnek, mint a hagyományos alkalmazások vázlatai, de a VR-hez a Google VR könyvtárakra van szükség. Hasonlóképpen, az óraarcokhoz is szükség van a viselhető eszközök támogatására szolgáló könyvtárra, de nem ugyanúgy települnek, mert az órára kell telepíteni őket.
Watch Face Woes
A vázlatot az órára kellett telepítenem.
Az első dolog, amit megpróbáltam, az volt, hogy a vázlatot az órára toltam és ott telepítettem. Kiderült, hogy egy APK oldaltöltése egy Wear OS (korábban Android Wear) órára nem olyan egyszerű, mint amilyennek látszik. Androidos telefonon csak engedélyezni kell a beállításokban az ismeretlen forrásból történő telepítést, és máris kész. A wear-en azonban ezt a telepítést a rendszer blokkolja, és ezt nem lehet megkerülni anélkül, hogy rootolnánk akár a telefont, akár az órát, vagy csatlakoztatnánk az órát egy számítógéphez. Ezek egyike sem opció egy belépő szintű mobilfejlesztői környezetben.
A következő lépésben megpróbáltam az alkalmazást Wear 1.x alkalmazásként csomagolni és telepíteni a telefonra. Az Android Wear 2.0 előtt minden Wear-alkalmazást telefonos alkalmazásokba csomagolva terjesztettek, még akkor is, ha az a telefonos alkalmazás csak egy üres héj volt. Ez mind megváltozott a 2.0-ban, amikor a wear alkalmazások önállóvá váltak. A remény az volt, hogy a régi rendszert kihasználva a telefonon keresztül telepíthetem az óraalkalmazást, de ez nem járt sikerrel. Még mindig nem tudom, hogy a régi telepítési módszer támogatott-e az újabb órákon, de egy proof of concept-et nem tudtam működésre bírni.
Végül egy utolsó utáni módszerhez folyamodtam: az osztályok betöltéséhez, ami egyfajta fekete mágia. Az ötlet lényege, hogy ahelyett, hogy a vázlatot önálló alkalmazásként telepíteném, a vázlat osztályát betölthetem egy olyan alkalmazásba, amely már fut az órán, így nem kell a vázlatot minden egyes futtatáskor telepíteni. Ez egy alapvetően más modell, mint ahogy az APDE jelenleg működik. Az APDE létrehoz egy vázlatot, és ez egy önálló alkalmazás, amely telepítésre kerül. Az alkalmazások képernyője felhalmoz egy csomó vázlatot, ahogy a felhasználó futtatja őket, és ezek akkor is megmaradnak, amikor az APDE-t eltávolítják. Az óra más. Most a vázlatok nem települnek, csak betöltődnek. Mindig csak egy vázlat áll rendelkezésre óraszámlapként, és az eltűnik, amikor az APDE-t eltávolítják.
Kiderült, hogy ez a megközelítés működik. A felhasználó telepít egy bridge alkalmazást az órájára a Play Store-ból (még nem elérhető) “APDE Wear Companion” néven. Amikor az APDE elkészít egy vázlatot, elküldi azt a wear companionnak. A wear companion kicsomagolja a vázlatot, és felkéri a felhasználót, hogy válasszon egy, a wear companionba épített óralapot. Ezután ez az óralap betölti a vázlatot és megjeleníti azt. Ez meglepően zökkenőmentes.
Volt néhány kihívás.
Amikor a vázlat összeomlik, az a wear companionban fut, így az egész wear companion alkalmazás is összeomlik. Jelenleg próbálom megfékezni a károkat, de néha a wear companion elromlik, és újra kell indítani, mert a vázlat túl sokszor összeomlott. Az APDE jelenleg nem látja a stack traces-t sem az összeomló watch face-ekből, mert a folyamat meghal, mielőtt a stack trace elküldhető lenne. (A nyomtatási utasítások azonban működnek.)
Nem csak egy watch face van, hanem valójában kettő. A Processingnek két alaposztálya van a watch face-ekhez: egy az alapértelmezett renderelőhöz (JAVA2D) és egy az OpenGL-alapú renderelőkhöz (P2D és P3D). Így két watch face van, egy-egy renderelőhöz. Amikor a wear companion kicsomagol egy vázlatot, ellenőrzi, hogy az melyik renderelőt használja. Ezután a megfelelő watch face láthatóvá válik, a másik pedig elrejtődik. Ez egy másik fajta fekete mágia, mert a felhasználónak észre sem szabadna vennie, de úgy tűnik, elég jól működik.
Most hazudtam. Valójában négy óralap van. Kiderült, hogy amikor betöltesz egy új óralapot, ha az új ugyanaz, mint a régi (és minden vázlat ugyanazt a két óralapot használja), akkor a rendszer “rövidre zárja” (ez a szakkifejezés erre) és nem tölti újra az óralapot. Ez a normál óralapok esetében rendben is van, de az APDE óralapot újra kell tölteni ahhoz, hogy megkapja az új vázlatot. A megoldás piszkos, de hatékony: legyen két watch face minden renderelőhöz (összesen négy), és váltogassuk őket az új vázlatok betöltésekor, hogy a watch face kénytelen legyen újratölteni.
A fenti nehézségek ellenére örömmel mondhatom, hogy a watch face-ek elég jól működnek, legalábbis azon a két eszközön, amelyeken teszteltem őket. A többi, nagyobb valószínűséggel használt célt – háttérképek és VR – lényegesen könnyebb volt megvalósítani.
Nézünk előre
A nyárra tervezett következő nagyobb funkció egy “előnézeti” mód. Jelenleg az APDE vázlatokat minden egyes futtatáskor telepíteni kell. Ez az elrendezés nem ideális, mert a telepítő megduplázza a “futtatás” megnyomása és a vázlat megjelenése közötti időt néhány telefonon. Továbbá, ahogy fentebb leírtuk, a vázlatok összezsúfolhatják az alkalmazások képernyőjét. A vázlatok telepítésének elkerülése valószínűleg az APDE legkeresettebb funkciója.
Eredetileg két megoldási javaslatom volt erre a problémára. Először is, a Processing.js segítségével konvertáljuk a vázlatot JavaScriptre, és futtassuk egy WebView-ban. Másodszor, kihasználni az Instant Apps előnyeit a vázlat telepítés nélküli futtatásához. Mindkét megoldás még mindig tökéletlen. A Processing.js elavult, és nem támogat semmilyen natív Android API-t, például a gyorsulásmérőt. Az Instant Apps a legjobb esetben is bizonytalan ötlet, mert még azt sem tudom, hogy lehetséges lesz-e a debugger meghamisítása a vázlatok helyi hosztolásához és futtatásához, vagy hogy ez gyorsabb lenne-e, mintha csak telepítenénk őket.
Hála Istennek, a watch face dió feltörése új megközelítést adott nekem. Az APDE-nek nem kell a vázlatot JavaScriptre konvertálni vagy azonnali alkalmazást készíteni. Csak a meglévő vázlatot kell vennie és osztálybetöltenie ahelyett, hogy telepítené.
Ezzel a megközelítéssel az APDE-nek csak az AAPT-vel kell létrehoznia az erőforrásokat, az ECJ-vel lefordítania az osztályokat, és dex-elnie az osztályokat. Az én telefonomon ez az egész folyamat kevesebb mint két másodpercet vesz igénybe (bár sok telefon jelentősen lassabb), ami hatalmas előrelépés az APK elkészítéséhez és telepítéséhez képest.
Még előrébb tekintve, idén nyáron tervezem megvalósítani az inkrementális fordítást, azaz a fordítót a háttérben futtatni, hogy valós időben jelenítse meg a hibákat. Ezzel a rendszerrel a vázlat valószínűleg már azelőtt le lesz fordítva, mielőtt a felhasználó megnyomná a futtatás gombot, ami azt jelenti, hogy már csak a dexelés marad. Más szóval, az osztály betöltők elképzelhető, hogy a build folyamatot kevesebb, mint egy másodpercre zsugoríthatják, természetesen a telefon hardverétől függően.
A nyáron még sok izgalom vár ránk!
Fin
Ha részletesebben szeretnéd felfedezni az általam elvégzett változtatásokat, nézd meg az android-mode-4 ágat a GitHubon. Részletes commit üzeneteket hagytam (legtöbbször), és az összes kód ott van.
Tartózkodjatok az előnézeti módhoz!