APDE GSoC ’18: Android Mode 4.0 Integrations

Gdy uruchamiasz szkic z celem tarczy zegarka, szkic się buduje i zostaje wysłany do zegarka. Następnie aplikacja APDE wear companion automatycznie ładuje szkic i uruchamia selektor tarcz zegarka:

Szkice VR są instalowane tak jak zwykłe aplikacje. Obsługują platformę VR Google, która obejmuje zestawy słuchawkowe Cardboard i Daydream:

Jeśli chcesz dostać w swoje ręce te nowe funkcje, dołącz do APDE Preview Channel i postępuj zgodnie z instrukcjami na górze, aby dołączyć do listy testerów.

Jak na razie, v0.5.0-pre2 jest dostępne i zawiera tapety i VR, ale nie tarcze zegarków.

Jak to wszystko działa?

Kluczem do wsparcia tych nowych celów było uaktualnienie do korzystania z desktop Processing’s Android Mode 4.0, który dodał wsparcie dla tapet, tarcz zegarków i VR. Moja praca polegała tylko na przeniesieniu tych fajnych nowych funkcji do APDE, co samo w sobie nie było łatwym zadaniem.

Wcześnie zdecydowałem, że chcę, aby każdy szkic można było uruchomić dla każdego celu. Chcę, aby użytkownicy mogli wziąć dowolny szkic lub przykład i bezproblemowo przeszczepić go z jednego środowiska do innego, czy to aplikacji, tapety, tarczy zegarka, czy VR. W ten sposób uzyskuje się maksymalną elastyczność i możliwość eksploracji pełnego potencjału szkiców Processing. Jedynym wyjątkiem od tej reguły jest to, że szkice VR muszą być 3D (szkice 2D po prostu nie działają ze względu na naturę VR).

Takie podejście różni się od tego w trybie Android. Na przykład, na pulpicie, VR jest pakowane jako biblioteka, więc tylko szkice, które jawnie importują bibliotekę VR mogą być uruchamiane dla celu VR. W APDE każdy szkic 3D może być uruchomiony dla VR, a poprawny import jest dodawany automatycznie.

System kompilacji używa teraz zestawu szablonów do śledzenia wszystkich plików kompilacji, takich jak aktywności, manifesty i układy. Ta metoda jest znacznie lepsza od kodowania, które było wykonywane wcześniej. Szablony są brane całkiem dosłownie z trybu Android, ale jest kilka zmian, takich jak wsparcie dla słuchawek Daydream VR.

Żywe tapety i szkice VR są instalowane tak samo jak zwykłe szkice aplikacji, ale VR wymaga bibliotek Google VR. Podobnie, tarcze zegarków wymagają biblioteki obsługi wearable, ale nie instalują się w ten sam sposób, ponieważ muszą być zainstalowane na zegarku.

Watch Face Woes

Potrzebowałem zainstalować szkic na zegarku.

Pierwszą rzeczą, jaką wypróbowałem, było popchnięcie szkicu na zegarek i zainstalowanie go tam. Okazuje się, że boczne ładowanie APK na zegarek z Wear OS (dawniej Android Wear) nie jest tak proste, jak mogłoby się wydawać. Na telefonie z Androidem, wystarczy włączyć instalację z nieznanych źródeł w ustawieniach i wszystko gotowe. Na noszeniu, jednak, ta instalacja jest blokowana przez system i nie ma sposobu, aby go obejść bez rootowania albo telefon lub zegarek lub podłączenie zegarka do komputera. Żadne z nich nie są opcje dla środowiska rozwoju mobilnego entry-level.

Następnie próbowałem pakować aplikację jako aplikację Wear 1.x i zainstalować ją na telefonie. Przed Android Wear 2.0, wszystkie aplikacje Wear były dystrybuowane przez bycie dołączonym do aplikacji telefonu, nawet jeśli ta aplikacja telefonu była tylko pustą powłoką. To wszystko zmieniło się w 2.0, kiedy aplikacje wear stały się samodzielne. Miałem nadzieję, że będę mógł skorzystać ze starego systemu, aby zainstalować aplikację zegarka przez telefon, ale to było bezskuteczne. Nadal nie wiem, czy stara metoda instalacji jest obsługiwana na nowszych zegarkach, ale nie byłem w stanie uzyskać dowód koncepcji do pracy.

W końcu uciekłem się do ostatniej metody awaryjnej: ładowanie klasy, która jest rodzajem czarnej magii. Chodzi o to, że zamiast instalować szkic jako niezależną aplikację, mogę załadować klasę szkicu do aplikacji, która jest już uruchomiona na zegarku, usuwając potrzebę instalowania szkicu za każdym razem, gdy jest uruchamiany. Jest to model zasadniczo różny od tego, jak obecnie działa APDE. APDE buduje szkic i jest to samodzielna aplikacja, która zostaje zainstalowana. Ekran aplikacji gromadzi garść szkiców, gdy użytkownik je uruchamia i pozostają one w nim, gdy APDE jest odinstalowane. Z zegarkiem jest inaczej. Teraz szkice nie są instalowane, są po prostu ładowane. Tylko jeden szkic jest dostępny jako tarcza zegarka i znika, gdy APDE jest odinstalowane.

Okazuje się, że to podejście działa. Użytkownik instaluje na swoim zegarku aplikację pomostową ze Sklepu Play (jeszcze nie jest dostępna) o nazwie „APDE Wear Companion”. Kiedy APDE buduje szkic, wysyła go do wear companion. Ten rozpakowuje szkic i prosi użytkownika o wybranie tarczy zegarka wbudowanej w wear companion. Następnie ta tarcza zegarka ładuje szkic i wyświetla go. Jest to zaskakująco bezproblemowe.

Było kilka wyzwań.

Gdy szkic się zawiesi, jest uruchomiony w wear companion, więc cała aplikacja wear companion też się zawiesi. Obecnie próbuję ograniczyć szkody, ale czasami wear companion ulega awarii i musi zostać ponownie uruchomiony, ponieważ szkic rozbił się zbyt wiele razy. APDE nie może obecnie zobaczyć śladów stosu z rozbitych tarcz zegarka, ponieważ proces umiera, zanim ślad stosu może zostać wysłany. (Polecenia wydruku jednak działają.)

Nie ma tylko jednej tarczy zegarka; są właściwie dwie. Processing ma dwie klasy bazowe dla tarcz zegarka: jedną dla domyślnego renderera (JAVA2D) i jedną dla rendererów opartych na OpenGL (P2D i P3D). Istnieją więc dwie tarcze zegarka, po jednej dla każdego renderera. Gdy program wear companion rozpakowuje szkic, sprawdza, który renderer jest używany. Następnie odpowiednia tarcza zegarka staje się widoczna, a druga zostaje ukryta. Jest to kolejny rodzaj czarnej magii, ponieważ użytkownik nie powinien nawet tego zauważyć, ale wydaje się, że działa całkiem dobrze.

Właśnie skłamałem. W rzeczywistości są cztery tarcze zegarka. Okazuje się, że kiedy ładujesz nową tarczę zegarka, jeśli nowa jest taka sama jak stara (a wszystkie szkice używają tych samych dwóch tarcz zegarka), to system „robi zwarcie” (tak to się technicznie nazywa) i nie ładuje ponownie tarczy zegarka. To jest w porządku dla zwykłych tarcz zegarka, ale tarcza APDE musi się przeładować, aby otrzymać nowy szkic. Rozwiązanie jest brudne, ale skuteczne: wystarczy mieć dwie tarcze zegarka dla każdego renderera (w sumie cztery) i naprzemiennie je ładować podczas ładowania nowych szkiców, tak aby tarcza zegarka była zmuszona do ponownego załadowania.

Mimo tych wszystkich trudności, z przyjemnością stwierdzam, że tarcze zegarka wydają się działać całkiem dobrze, przynajmniej na dwóch zestawach urządzeń, na których je testowałem. Inne, bardziej prawdopodobne do wykorzystania cele – tapety i VR – były znacznie łatwiejsze do wdrożenia.

Patrząc w przyszłość

Kolejną ważną cechą planowaną na lato tego roku jest tryb „podglądu”. Obecnie, szkice APDE muszą być instalowane za każdym razem, gdy są uruchamiane. Takie rozwiązanie nie jest idealne, ponieważ instalator podwaja czas pomiędzy naciśnięciem „run” a zobaczeniem szkicu na niektórych telefonach. Ponadto, jak opisano powyżej, wszystkie szkice mogą zaśmiecać ekran aplikacji. Brak konieczności instalowania szkiców jest prawdopodobnie najbardziej pożądaną cechą APDE.

Początkowo miałem dwa proponowane rozwiązania tego problemu. Po pierwsze, użyć Processing.js do konwersji szkicu na JavaScript i uruchomić go w WebView. Po drugie, skorzystaj z Instant Apps, aby uruchomić szkic bez instalowania go. Oba te rozwiązania są wciąż niedoskonałe. Processing.js jest przestarzały i nie obsługuje żadnych natywnych interfejsów API Androida, takich jak akcelerometr. Instant Apps jest w najlepszym razie chwiejnym pomysłem, ponieważ nie wiem nawet, czy będzie możliwe oszukanie debuggera, aby hostować szkice lokalnie i uruchamiać je, lub czy będzie to szybsze niż ich instalacja.

Na szczęście, rozbicie nakrętki z tarczą zegarka dało mi nowe podejście. APDE nie musi konwertować szkicu na JavaScript lub budować natychmiastowej aplikacji. Po prostu musi wziąć istniejący szkic i załadować go klasami zamiast go instalować.

Z tym podejściem APDE musi tylko zbudować zasoby z AAPT, skompilować klasy z ECJ, i zdexować klasy. Na moim telefonie cały ten proces trwa mniej niż dwie sekundy (choć wiele telefonów jest znacznie wolniejszych), co jest ogromnym usprawnieniem w porównaniu z koniecznością budowania APK i instalowania go.

Patrząc jeszcze dalej w przyszłość, planuję tego lata wdrożyć kompilację przyrostową, tzn. uruchomić kompilator w tle, aby wyświetlać błędy w czasie rzeczywistym. Dzięki temu systemowi szkic będzie prawdopodobnie skompilowany jeszcze przed naciśnięciem przez użytkownika przycisku run, co oznacza, że jedyne co pozostanie to dexing. Innymi słowy, ładowarki klas mogłyby zmniejszyć proces kompilacji do mniej niż sekundy, oczywiście w zależności od sprzętu telefonu.

Jeszcze wiele emocji przed nami tego lata!

Fin

Jeśli chcesz poznać zmiany, które wprowadziłem bardziej szczegółowo, sprawdź gałąź android-mode-4 na GitHubie. Zostawiłem szczegółowe wiadomości commit (przez większość czasu) i cały kod tam jest.

Stay tuned for preview mode!

.