APDE GSoC ’18: Android Mode 4.0 -integraatiot

Kun suoritat luonnoksen kellotaustakohteella, luonnos rakentuu ja lähetetään kelloon. Sitten APDE wear companion -sovellus lataa luonnoksen automaattisesti ja käynnistää watch face -valitsimen:

VR-luonnokset asennetaan aivan kuten tavalliset sovellukset. Ne tukevat Googlen VR-alustaa, johon kuuluvat Cardboard- ja Daydream-kuulokkeet:

Jos haluat päästä käsiksi näihin uusiin ominaisuuksiin, liity APDE:n esikatselukanavaan ja noudata ylhäällä olevia ohjeita liittyäksesi testaajaluetteloon.

Kirjoitushetkellä v0.5.0-pre2 on saatavilla, ja se sisältää taustakuvat ja VR:n, mutta ei kellotauluja.

Miten tämä kaikki toimii?

Valinta näiden uusien kohteiden tukemiseen oli päivittäminen käyttämään työpöydän Processingin Android Mode 4.0:a, joka lisäsi tuen taustakuville, kellotauluille ja VR:lle. Työni oli vain näiden hienojen uusien ominaisuuksien siirtämistä APDE:hen, mikä ei sinänsä ollut helppo tehtävä.

Päädyin jo varhain siihen, että haluan jokaisen luonnoksen olevan ajettavissa kaikissa kohteissa. Haluan, että käyttäjät voivat ottaa minkä tahansa luonnoksen tai esimerkin ja siirtää sen saumattomasti yhdestä ympäristöstä mihin tahansa toiseen, oli se sitten sovellus, taustakuva, kellotaulu tai VR. Näin Processing-luonnosten koko potentiaali voidaan hyödyntää mahdollisimman joustavasti ja monipuolisesti. Ainoa poikkeus tähän sääntöön on, että VR-luonnosten on oltava 3D-luonnoksia (2D-luonnokset eivät vain toimi VR:n luonteen vuoksi).

Tämä lähestymistapa eroaa Android-tilan lähestymistavasta. Esimerkiksi työpöydällä VR on pakattu kirjastoksi, joten vain luonnokset, jotka tuovat nimenomaisesti VR-kirjaston, voidaan ajaa VR-kohteelle. APDE:ssä jokainen 3D-luonnos voidaan ajaa VR:ää varten, ja oikeat tuonnit lisätään automaattisesti.

Kehitysjärjestelmä käyttää nyt joukon malleja pitämään kirjaa kaikista rakennustiedostoista, kuten aktiviteeteista, manifesteista ja asetteluista. Tämä menetelmä on paljon parempi kuin aiemmin tehty kovakoodaus. Mallit on otettu melko lailla sanatarkasti Android-tilasta, mutta niissä on pari muutosta, kuten tuki Daydream VR -kuulokkeille.

Live-taustakuvat ja VR-luonnokset asennetaan aivan kuten tavallisten sovellusten luonnokset, mutta VR vaatii Googlen VR-kirjastot. Vastaavasti kellotaustat vaativat wearable-tukikirjaston, mutta ne eivät asennu samalla tavalla, koska ne on asennettava kelloon.

Watch Face Woes

Minun piti asentaa luonnos kelloon.

Ensimmäisenä kokeilin työntää luonnoksen kelloon ja asentaa sen sinne. Kävi ilmi, että APK:n sivulataaminen Wear OS (entinen Android Wear) -kelloon ei ole niin helppoa kuin miltä se saattaa vaikuttaa. Android-puhelimessa sinun tarvitsee vain sallia asennus tuntemattomista lähteistä asetuksissa ja olet valmis. Wearissa järjestelmä kuitenkin estää tämän asennuksen, eikä sitä voi kiertää ilman puhelimen tai kellon juurruttamista tai kellon liittämistä tietokoneeseen. Mikään näistä ei ole vaihtoehtoja aloittelevan tason mobiilikehitysympäristössä.

Seuraavaksi yritin paketoida sovelluksen Wear 1.x -sovellukseksi ja asentaa sen puhelimeen. Ennen Android Wear 2.0:a kaikki Wear-sovellukset jaettiin niputtamalla ne puhelinsovelluksiin, vaikka puhelinsovellus olisi ollut vain tyhjä kuori. Tämä kaikki muuttui 2.0:ssa, kun Wear-sovelluksista tuli itsenäisiä. Toiveena oli, että voisin hyödyntää vanhaa järjestelmää asentaakseni kellosovelluksen puhelimen kautta, mutta siitä ei ollut hyötyä. En edelleenkään tiedä, tuetaanko vanhaa asennustapaa uudemmissa kelloissa, mutta en saanut proof of conceptia toimimaan.

Lopulta turvauduin viimeiseen keinoon: luokkien lataamiseen, joka on eräänlaista mustaa magiaa. Ideana on, että sen sijaan, että asentaisin luonnoksen itsenäisenä sovelluksena, voin ladata luonnoksen luokan sovellukseen, joka on jo käynnissä kellossa, jolloin luonnosta ei tarvitse asentaa joka kerta, kun se ajetaan. Tämä on pohjimmiltaan erilainen malli kuin APDE:n nykyinen toimintatapa. APDE rakentaa luonnoksen, ja se on itsenäinen sovellus, joka asennetaan. Sovellusten näyttöön kertyy joukko luonnoksia, kun käyttäjä suorittaa niitä, ja ne pysyvät tallessa, kun APDE poistetaan. Kello on erilainen. Nyt luonnoksia ei asenneta, vaan ne vain ladataan. Kellotauluna on aina vain yksi luonnos käytettävissä, ja se katoaa, kun APDE poistetaan.

Kävi ilmi, että tämä lähestymistapa toimii. Käyttäjä asentaa kelloonsa Play-kaupasta siltasovelluksen (ei vielä saatavilla) nimeltä ”APDE Wear Companion”. Kun APDE rakentaa luonnoksen, se lähettää sen wear companioniin. Wear Companion purkaa luonnoksen ja kehottaa käyttäjää valitsemaan wear companioniin rakennetun kellotaulun. Sitten kyseinen kellotaulu lataa luonnoksen ja näyttää sen. Tämä on yllättävän saumatonta.

Tässä oli pari haastetta.

Kun luonnos kaatuu, se on käynnissä wear companionissa, joten koko wear companion -sovellus kaatuu myös. Yritän tällä hetkellä hillitä vahinkoa, mutta joskus wear companion hajoaa ja se on käynnistettävä uudelleen, koska luonnos kaatui liian monta kertaa. APDE ei myöskään näe tällä hetkellä kaatuvien kellotaulujen pinojälkiä, koska prosessi kuolee ennen kuin pinojälki voidaan lähettää. (Tulostuslausekkeet toimivat kuitenkin.)

Ei ole vain yhtä kellotaulua, vaan itse asiassa niitä on kaksi. Processingilla on kaksi perusluokkaa watch faceja varten: yksi oletusrenderöijälle (JAVA2D) ja yksi OpenGL-pohjaisille renderöijille (P2D ja P3D). Näin ollen watch faceja on kaksi, yksi kummallekin renderöijälle. Kun wear companion purkaa luonnoksen, se tarkistaa, mitä renderöijää se käyttää. Sen jälkeen vastaava kellotaulu tulee näkyviin ja toinen piilotetaan. Tämä on toisenlaista mustaa magiaa, koska käyttäjän ei pitäisi edes huomata, mutta se näyttää toimivan melko hyvin.

Valehtelin juuri. Kellotauluja on oikeasti neljä. Kävi ilmi, että kun lataat uuden kellotaulun, jos uusi kellotaulu on sama kuin vanha (ja kaikki luonnokset käyttävät samoja kahta kellotaulua), niin järjestelmä ”oikosulkee” (se on tekninen termi sille) eikä lataa kellotaulua uudelleen. Tämä on hienoa tavallisille kellotauluille, mutta APDE-kellotaulun on latauduttava uudelleen saadakseen uuden luonnoksen. Ratkaisu on likainen, mutta tehokas: pitää vain olla kaksi kellotaulua jokaiselle renderöijälle (yhteensä neljä) ja vuorotella niiden välillä ladattaessa uusia luonnoksia niin, että kellotaulun on pakko latautua uudelleen.

Kaikista näistä vaikeuksista huolimatta olen iloinen voidessani sanoa, että kellotaulut näyttävät toimivan melko hyvin, ainakin niillä kahdella laitteella, joilla olen niitä testannut. Muut, todennäköisemmin käytettävät kohteet – taustakuvat ja VR – olivat huomattavasti helpommin toteutettavissa.

Katse eteenpäin

Kesään suunniteltu seuraava merkittävä ominaisuus on ”esikatselutila”. Tällä hetkellä APDE-luonnokset on asennettava joka kerta, kun niitä ajetaan. Tämä järjestely ei ole ihanteellinen, koska asennusohjelma tuplaa ajan ”run” -painikkeen painamisen ja luonnoksen näkymisen välillä joissakin puhelimissa. Lisäksi, kuten edellä on kuvattu, kaikki luonnokset voivat sotkea sovellusten näytön. Luonnosten asentamatta jättäminen on luultavasti APDE:n eniten toivottu ominaisuus.

Alun perin minulla oli kaksi ratkaisuehdotusta tähän ongelmaan. Ensinnäkin Processing.js:n käyttäminen muunnetaan luonnos JavaScriptiksi ja ajetaan se WebView:ssä. Toiseksi, hyödyntää Instant Apps -sovelluksia luonnoksen ajamiseen ilman sen asentamista. Molemmat ratkaisut ovat edelleen epätäydellisiä. Processing.js on vanhentunut, eikä se tue mitään natiiveja Androidin sovellusliittymiä, kuten kiihtyvyysmittaria. Instant Apps on parhaimmillaankin horjuva ajatus, koska en edes tiedä, onko mahdollista huijata debuggeria isännöimään sketsejä paikallisesti ja ajamaan niitä, tai olisiko tämä nopeampaa kuin pelkkä asentaminen.

Onneksi kellotaulupähkinän murtaminen on antanut minulle uuden lähestymistavan. APDE:n ei tarvitse muuntaa sketsiä JavaScriptiksi tai rakentaa välitöntä sovellusta. Sen tarvitsee vain ottaa olemassa oleva luonnos ja ladata se luokkiin sen sijaan, että se asentaisi sen.

Tällä lähestymistavalla APDE:n tarvitsee vain rakentaa resurssit AAPT:llä, kääntää luokat ECJ:llä ja dexata luokat. Puhelimessani tämä koko prosessi kestää alle kaksi sekuntia (vaikka monet puhelimet ovat huomattavasti hitaampia), mikä on valtava parannus verrattuna APK:n rakentamiseen ja asentamiseen.

Katsoen vielä pidemmälle tulevaisuuteen, aion ottaa käyttöön inkrementaalisen kääntämisen tänä kesänä, eli kääntäjän suorittamisen taustalla, jotta virheet näkyvät reaaliajassa. Kun tämä järjestelmä on käytössä, luonnos on todennäköisesti käännetty jo ennen kuin käyttäjä painaa run-nappia, mikä tarkoittaa, että jäljellä on enää dexaus. Toisin sanoen, luokkien lataajat voisivat mahdollisesti kutistaa rakentamisprosessin alle sekuntiin, riippuen tietysti puhelimen laitteistosta.

Tänä kesänä on vielä paljon jännittävää tulossa!

Fin

Jos haluat tutustua tekemiini muutoksiin tarkemmin, tutustu android-mode-4-haaraan GitHubissa. Olen jättänyt yksityiskohtaisia commit-viestejä (suurimman osan ajasta) ja kaikki koodi on siellä.

Pysy kuulolla esikatselumoodia varten!