APDE GSoC ’18 : Intégrations Android Mode 4.0

Lorsque vous exécutez un sketch avec la cible watch face, le sketch se construit et est envoyé à la montre. Ensuite, l’application APDE wear companion charge automatiquement le sketch et lance le sélecteur de face de montre :

Les sketches VR sont installés comme des applications ordinaires. Ils prennent en charge la plateforme VR de Google, qui comprend les casques Cardboard et Daydream :

Si vous voulez mettre la main sur ces nouvelles fonctionnalités, veuillez rejoindre le canal APDE Preview et suivre les instructions en haut pour rejoindre la liste des testeurs.

Au moment d’écrire ces lignes, la v0.5.0-pre2 est disponible et inclut les fonds d’écran et la RV, mais pas les watch faces.

Comment tout cela fonctionne-t-il ?

La clé pour supporter ces nouvelles cibles était la mise à niveau pour utiliser le mode Android 4.0 de desktop Processing, qui a ajouté le support des fonds d’écran, des watch faces et de la RV. Mon travail consistait juste à porter ces nouvelles fonctionnalités sympas sur APDE, ce qui n’était pas en soi une tâche facile.

J’ai décidé très tôt que je voulais que chaque croquis soit exécutable pour chaque cible. Je veux que les utilisateurs puissent prendre n’importe quel croquis ou exemple et le transplanter de manière transparente d’un environnement à un autre, qu’il s’agisse d’une application, d’un fond d’écran, d’un visage de montre ou d’une RV. De cette façon, la flexibilité et la capacité d’explorer tout le potentiel des croquis de Processing sont maximales. La seule exception à cette règle est que les croquis VR doivent être en 3D (les croquis 2D ne fonctionnent tout simplement pas en raison de la nature de la VR).

Cette approche diffère de celle du mode Android. Par exemple, sur le bureau, VR est emballé comme une bibliothèque, donc seules les esquisses qui importent explicitement la bibliothèque VR peuvent être exécutées pour la cible VR. Dans APDE, chaque esquisse 3D peut être exécutée pour VR et les importations correctes sont ajoutées automatiquement.

Le système de construction utilise maintenant un ensemble de modèles pour garder la trace de tous les fichiers de construction comme les activités, les manifestes et les layouts. Cette méthode est bien préférable au codage en dur qui était fait auparavant. Les modèles sont repris à peu près mot pour mot du mode Android, mais il y a quelques changements, comme la prise en charge des casques Daydream VR.

Les fonds d’écran vivants et les croquis VR sont installés comme les croquis d’applications ordinaires, mais VR nécessite les bibliothèques Google VR. De même, les visages de montre nécessitent la bibliothèque de support de wearable, mais ils ne s’installent pas de la même manière car ils doivent être installés sur une montre.

Watch Face Woes

J’avais besoin d’installer le sketch sur la montre.

La première chose que j’ai essayée était de pousser le sketch sur la montre et de l’installer là. Il s’avère que le téléchargement latéral d’un APK sur une montre Wear OS (anciennement Android Wear) n’est pas aussi facile qu’il n’y paraît. Sur un téléphone Android, il suffit d’activer l’installation à partir de sources inconnues dans les paramètres et le tour est joué. Sur Wear, en revanche, cette installation est bloquée par le système et il n’y a aucun moyen de la contourner sans rooter le téléphone ou la montre ou sans connecter la montre à un ordinateur. Aucune de ces options n’est envisageable pour un environnement de développement mobile d’entrée de gamme.

Puis, j’ai essayé de packager l’application comme une application Wear 1.x et de l’installer sur le téléphone. Avant Android Wear 2.0, toutes les apps Wear étaient distribuées en étant regroupées dans des apps de téléphone, même si cette app de téléphone était juste une coquille vide. Tout cela a changé en 2.0, lorsque les applications Wear sont devenues autonomes. J’espérais pouvoir profiter de l’ancien système pour installer l’application de la montre via le téléphone, mais en vain. Je ne sais toujours pas si l’ancienne méthode d’installation est prise en charge ou non sur les montres plus récentes, mais je n’ai pas réussi à faire fonctionner une preuve de concept.

Enfin, j’ai eu recours à une méthode de la dernière chance : le chargement de classe, qui est une sorte de magie noire. L’idée est qu’au lieu d’installer le sketch en tant qu’app indépendante, je peux charger la classe du sketch dans une app qui est déjà en cours d’exécution sur la montre, supprimant ainsi la nécessité d’installer le sketch à chaque fois qu’il est exécuté. Il s’agit d’un modèle fondamentalement différent du fonctionnement actuel d’APDE. APDE crée un sketch et c’est une application autonome qui est installée. L’écran de l’application accumule un tas de croquis au fur et à mesure que l’utilisateur les exécute et ils restent en place lorsque APDE est désinstallé. La montre est différente. Maintenant, les croquis ne sont pas installés, ils sont juste chargés. Il n’y a jamais qu’un seul croquis disponible comme visage de montre, et il disparaît quand APDE est désinstallé.

Il s’avère que cette approche fonctionne. L’utilisateur installe une application passerelle sur sa montre depuis le Play Store (pas encore disponible) appelée « APDE Wear Companion ». Quand APDE construit un sketch, il l’envoie au Wear Companion. Le Wear Companion décompresse le croquis et invite l’utilisateur à sélectionner un visage de montre intégré au Wear Companion. Ce dernier charge alors le croquis et l’affiche. C’est étonnamment transparent.

Il y a eu quelques défis.

Lorsque le sketch se plante, il est exécuté dans le wear companion, donc toute l’application du wear companion se plante aussi. J’essaie actuellement de contenir les dégâts, mais parfois le wear companion se brise et doit être redémarré parce que le sketch s’est écrasé trop de fois. APDE ne peut pas non plus voir les traces de pile des watch faces qui se plantent pour le moment parce que le processus meurt avant que la trace de pile puisse être envoyée. (Les instructions d’impression fonctionnent cependant.)

Il n’y a pas qu’un seul watch face ; il y en a en fait deux. Processing a deux classes de base pour les watch faces : une pour le moteur de rendu par défaut (JAVA2D) et une pour les moteurs de rendu basés sur OpenGL (P2D et P3D). Il y a donc deux watch faces, une pour chaque moteur de rendu. Lorsque le compagnon de portage décompresse une esquisse, il vérifie quel moteur de rendu elle utilise. Ensuite, le visage de montre correspondant est rendu visible et l’autre est caché. C’est une autre sorte de magie noire car l’utilisateur ne devrait même pas le remarquer, mais cela semble fonctionner assez bien.

Je viens de mentir. Il y a en fait quatre visages de montre. Il s’avère que lorsque vous chargez un nouveau visage de montre, si le nouveau est le même que l’ancien (et tous les sketches utilisent les deux mêmes visages de montre), alors le système « court-circuite » (c’est le terme technique pour cela) et ne recharge pas le visage de montre. C’est très bien pour les cadrans normaux, mais le cadran APDE doit être rechargé pour obtenir le nouveau croquis. La solution est sale, mais efficace : il suffit d’avoir deux watch faces pour chaque moteur de rendu (quatre au total) et d’alterner entre eux lors du chargement de nouvelles esquisses afin que le watch face soit obligé de se recharger.

Malgré toutes ces difficultés, je suis heureux de dire que les watch faces semblent fonctionner assez bien, du moins sur les deux ensembles d’appareils sur lesquels je les ai testés. Les autres cibles, plus susceptibles d’être utilisées – fonds d’écran et RV – ont été nettement plus faciles à mettre en œuvre.

Looking Forward

La prochaine fonctionnalité majeure prévue pour cet été est un mode « aperçu ». Actuellement, les esquisses APDE doivent être installées à chaque fois qu’elles sont exécutées. Cette disposition n’est pas idéale car l’installateur double le temps entre l’appui sur « run » et la visualisation du sketch sur certains téléphones. De plus, comme décrit ci-dessus, tous les sketches peuvent encombrer l’écran des applications. Ne pas avoir à installer les croquis est probablement la fonctionnalité la plus demandée d’APDE.

J’avais initialement deux propositions de solutions à ce problème. Premièrement, utiliser Processing.js pour convertir le croquis en JavaScript et l’exécuter dans une WebView. Deuxièmement, profiter des Instant Apps pour exécuter un croquis sans l’installer. Ces deux solutions sont encore imparfaites. Processing.js est obsolète et ne prend en charge aucune API Android native, comme l’accéléromètre. Instant Apps est une idée bancale au mieux parce que je ne sais même pas s’il sera possible d’usurper le débogueur pour héberger les sketches localement et les exécuter, ou si cela serait plus rapide que de simplement les installer.

Heureusement, le fait de craquer l’écrou de la montre m’a donné une nouvelle approche. APDE n’a pas besoin de convertir une esquisse en JavaScript ou de construire une application instantanée. Il a juste besoin de prendre le sketch existant et de le charger en classe au lieu de l’installer.

Avec cette approche, APDE a seulement besoin de construire les ressources avec AAPT, de compiler les classes avec ECJ, et dex les classes. Sur mon téléphone, l’ensemble de ce processus prend moins de deux secondes (bien que de nombreux téléphones soient considérablement plus lents), ce qui est une énorme amélioration par rapport à la nécessité de construire l’APK et de l’installer.

Pour aller encore plus loin, je prévois d’implémenter la compilation incrémentale cet été, c’est-à-dire de faire fonctionner le compilateur en arrière-plan pour afficher les erreurs en temps réel. Avec ce système en place, l’esquisse sera probablement compilée avant même que l’utilisateur n’appuie sur le bouton d’exécution, ce qui signifie qu’il ne reste plus qu’à faire du dexing. En d’autres termes, les chargeurs de classe pourraient vraisemblablement réduire le processus de construction à moins d’une seconde, en fonction du matériel du téléphone bien sûr.

Il y a encore beaucoup d’excitation à venir cet été !

Fin

Si vous voulez explorer les changements que j’ai faits plus en détail, consultez la branche android-mode-4 sur GitHub. J’ai laissé des messages de commit détaillés (la plupart du temps) et tout le code s’y trouve.

Restez à l’écoute pour le mode preview !