APDE GSoC ’18: Integration av Android Mode 4.0

När du kör en skiss med målet för urtavlan byggs skissen och skickas till klockan. Sedan laddar APDE wear companion-appen automatiskt skissen och startar watch face chooser:

VR-skisser installeras precis som vanliga appar. De stöder Googles VR-plattform, som inkluderar Cardboard- och Daydream-headsets:

Om du vill få tillgång till de här nya funktionerna kan du gå med i APDE Preview Channel och följa instruktionerna högst upp för att ansluta dig till testlistan.

I skrivande stund är v0.5.0-pre2 finns tillgänglig och innehåller bakgrundsbilder och VR, men inte urtavlor.

Hur fungerar allt detta?

Nyckeln till stöd för dessa nya mål var att uppgradera för att använda desktop Processing’s Android Mode 4.0, vilket gav stöd för bakgrundsbilder, urtavlor och VR. Mitt arbete bestod bara i att portera dessa coola nya funktioner över till APDE, vilket i sig inte var någon lätt uppgift.

Jag bestämde mig tidigt för att jag vill att varje skiss ska kunna köras för varje mål. Jag vill att användarna ska kunna ta en skiss eller ett exempel och sömlöst överföra det från en miljö till en annan, oavsett om det är en app, bakgrundsbild, urtavla eller VR. På så sätt finns det maximal flexibilitet och kapacitet för att utforska Processing-sketchernas fulla potential. Det enda undantaget från denna regel är att VR-skisser måste vara i 3D (2D-skisser fungerar helt enkelt inte på grund av VR:s natur).

Detta tillvägagångssätt skiljer sig från tillvägagångssättet för Android-läge. På skrivbordet är VR till exempel paketerat som ett bibliotek, så endast skisser som uttryckligen importerar VR-biblioteket kan köras för VR-målet. I APDE kan varje 3D-skiss köras för VR och rätt import läggs till automatiskt.

Byggsystemet använder nu en uppsättning mallar för att hålla reda på alla byggfiler som aktiviteter, manifest och layouter. Denna metod är mycket att föredra framför den hårdkodning som gjordes tidigare. Mallarna är i stort sett ordagrant hämtade från Android-läge, men det finns ett par förändringar, till exempel stöd för Daydream VR-headsets.

Live wallpapers och VR-skisser installeras precis som skisser för vanliga appar, men för VR krävs Googles VR-bibliotek. På samma sätt kräver watch faces biblioteket för wearable support, men de installeras inte på samma sätt eftersom de måste installeras på en klocka.

Watch Face Woes

Jag behövde installera skissen på klockan.

Det första jag försökte var att skjuta skissen till klockan och installera den där. Det visar sig att det inte är så enkelt som det kan verka att sidolasta en APK till en Wear OS-klocka (tidigare Android Wear). På en Android-telefon behöver du bara aktivera installation från okända källor i inställningarna så är du klar. På wear blockeras dock denna installation av systemet och det finns inget sätt att komma runt det utan att roota antingen telefonen eller klockan eller ansluta klockan till en dator. Inget av dessa är alternativ för en mobilutvecklingsmiljö på instegsnivå.

Nästan försökte jag paketera appen som en Wear 1.x-app och installera den på telefonen. Före Android Wear 2.0 distribuerades alla Wear-appar genom att de paketerades i telefonappar, även om telefonappen bara var ett tomt skal. Allt detta ändrades i 2.0 när Wear-appar blev fristående. Förhoppningen var att jag skulle kunna dra nytta av det gamla systemet för att installera klockappen via telefonen, men detta var till ingen nytta. Jag vet fortfarande inte om den gamla installationsmetoden stöds på nyare klockor eller inte, men jag kunde inte få ett proof of concept att fungera.

Slutligt tog jag till en sista desperat metod: class loading, som är ett slags svart magi. Tanken är att i stället för att installera skissen som en oberoende app kan jag ladda skissens klass i en app som redan körs på klockan, vilket gör att jag inte behöver installera skissen varje gång den körs. Det här är en helt annan modell än hur APDE fungerar för närvarande. APDE bygger en skiss och det är en fristående app som installeras. På appskärmen samlas en mängd skisser när användaren kör dem och de stannar kvar när APDE avinstalleras. Klockan är annorlunda. Nu installeras inte skisserna, de laddas bara. Det finns alltid bara en skiss tillgänglig som urtavla, och den försvinner när APDE avinstalleras.

Det visar sig att detta tillvägagångssätt fungerar. Användaren installerar en bridge-app på sin klocka från Play Store (inte tillgänglig ännu) som kallas ”APDE Wear Companion”. När APDE bygger en skiss skickar den den till wear companion. Wear Companion packar upp skissen och uppmanar användaren att välja en urtavla som är inbyggd i Wear Companion. Därefter laddar klockan in skissen och visar den. Detta är förvånansvärt smidigt.

Det fanns ett par utmaningar.

När skissen kraschar körs den i wear companion, så hela wear companion-appen kraschar också. Jag försöker för närvarande begränsa skadan, men ibland går wear companion sönder och måste startas om eftersom skissen kraschade för många gånger. APDE kan inte heller se stackspåren från kraschande urtavlor för tillfället eftersom processen dör innan stackspåren kan skickas ut. (Utskriftsdeklarationer fungerar dock.)

Det finns inte bara ett urtavlan; det finns faktiskt två. Processing har två basklasser för watch faces: en för standardrenderaren (JAVA2D) och en för OpenGL-baserade renderare (P2D och P3D). Det finns alltså två watch faces, en för varje renderare. När wear companion packar upp en skiss kontrollerar den vilken renderer den använder. Därefter görs motsvarande urtavla synlig och den andra döljs. Detta är en annan typ av svart magi eftersom användaren inte ens ska märka det, men det verkar fungera ganska bra.

Jag ljög precis. Det finns faktiskt fyra urtavlor. Det visar sig att när du laddar en ny urtavla, om den nya är densamma som den gamla (och alla skisser använder samma två urtavlor), så ”kortsluter” systemet (det är den tekniska termen för det) och laddar inte om urtavlan. Detta är helt okej för vanliga urtavlor, men APDE-urtavlan måste laddas om för att få den nya skissen. Lösningen är smutsig men effektiv: ha bara två urtavlor för varje renderare (fyra totalt) och växla mellan dem när du laddar nya skisser så att urtavlan tvingas ladda om.

Trots alla dessa svårigheter är jag glad att kunna säga att urtavlor verkar fungera ganska bra, åtminstone på de två uppsättningar av enheter som jag har testat dem på. De andra, mer sannolikt använda målen – bakgrundsbilder och VR – var betydligt lättare att implementera.

Att blicka framåt

Nästa stora funktion som planeras till sommaren är ett ”förhandsgranskningsläge”. För närvarande måste APDE-skisser installeras varje gång de körs. Detta arrangemang är inte idealiskt eftersom installationsprogrammet fördubblar tiden mellan det att man trycker på ”run” och ser skissen på vissa telefoner. Dessutom, som beskrivits ovan, kan alla skisser förstöra programskärmen. Att inte behöva installera skisser är förmodligen APDE:s mest efterfrågade funktion.

Jag hade ursprungligen två förslag till lösningar på detta problem. För det första använda Processing.js för att konvertera skissen till JavaScript och köra den i en WebView. För det andra, utnyttja Instant Apps för att köra en skiss utan att installera den. Båda dessa lösningar är fortfarande bristfälliga. Processing.js är föråldrad och har inte stöd för några inhemska Android-API:er, t.ex. accelerometern. Instant Apps är i bästa fall en skakig idé eftersom jag inte ens vet om det kommer att vara möjligt att förvränga felsökaren för att vara värd för skisserna lokalt och köra dem, eller om detta skulle vara snabbare än att bara installera dem.

Tacksamt nog har knäckandet av klockavsnittsnöten gett mig ett nytt tillvägagångssätt. APDE behöver inte konvertera en skiss till JavaScript eller bygga en omedelbar app. Den behöver bara ta den befintliga skissen och klassladda den i stället för att installera den.

Med detta tillvägagångssätt behöver APDE bara bygga resurserna med AAPT, kompilera klasserna med ECJ och dexa klasserna. På min telefon tar hela denna process mindre än två sekunder (även om många telefoner är betydligt långsammare), vilket är en stor förbättring jämfört med att behöva bygga APK:n och installera den.

Om jag ser ännu längre fram planerar jag att implementera inkrementell kompilering i sommar, dvs. att låta kompilatorn köras i bakgrunden för att visa felen i realtid. Med detta system på plats kommer skissen sannolikt att vara kompilerad redan innan användaren trycker på kör-knappen, vilket innebär att allt som återstår är dexing. Med andra ord kan class loaders tänkas krympa byggprocessen till mindre än en sekund, beroende på telefonens hårdvara förstås.

Det finns mycket spänning kvar i sommar!

Fin

Om du vill utforska ändringarna som jag har gjort mer i detalj kan du kolla in android-mode-4-grenen på GitHub. Jag har lämnat detaljerade commitmeddelanden (för det mesta) och all kod finns där.

Håll dig uppdaterad för förhandsvisning!