APDE GSoC ’18: Android Mode 4.0 Integrations

BY admin
|

Watch Face ターゲットでスケッチを実行すると、スケッチがビルドされて時計に送信されます。 その後、APDE ウェア コンパニオン アプリが自動的にスケッチをロードし、ウォッチ フェイス セレクタを起動します。

VR スケッチは通常のアプリと同様にインストールされます。 Cardboard および Daydream ヘッドセットを含む Google の VR プラットフォームをサポートします。

これらの新機能を入手したい場合は、APDE Preview Channel に参加して、上部にある指示に従ってテスター リストに参加してください。5.0-pre2 が利用可能で、壁紙と VR が含まれていますが、ウォッチ フェイスは含まれていません。

これはどのように動作するのでしょうか。

これらの新しいターゲットをサポートする鍵は、壁紙、ウォッチ フェイスおよび VR のサポートを追加する desktop Processing の Android Mode 4.0 を使用するようにアップグレードすることでした。 私の仕事は、これらのクールな新機能を APDE に移植することでしたが、それ自体、簡単な作業ではありませんでした。 ユーザーが任意のスケッチまたはサンプルを、アプリ、壁紙、ウォッチフェイス、または VR など、ある環境から他の環境にシームレスに移植できるようにしたいのです。 そうすることで、Processingスケッチの可能性を最大限に引き出す柔軟性とキャパシティが生まれます。 このルールの唯一の例外は、VR スケッチが 3D でなければならないことです (2D スケッチは VR の性質上、うまくいきません)。 たとえば、デスクトップでは、VR はライブラリとしてパッケージ化されているため、VR ライブラリを明示的にインポートしたスケッチのみが VR ターゲットに対して実行可能です。 APDE では、すべての 3D スケッチが VR 用に実行でき、正しいインポートが自動的に追加されます。

ビルド システムでは、アクティビティのようなビルド ファイルのすべてを追跡するために、一連のテンプレートを使用するようになりました。 この方法は、以前行われていたハードコーディングよりもはるかに好ましいものです。 テンプレートは Android モードからほぼそのまま引き継がれますが、Daydream VR ヘッドセットのサポートなど、いくつかの変更があります。

Live 壁紙と VR スケッチは通常のアプリのスケッチと同様にインストールされますが、VR は Google VR ライブラリを必要とします。 同様に、ウォッチ フェイスはウェアラブル サポート ライブラリを必要としますが、ウォッチにインストールする必要があるため、同じようにはインストールされません。

Watch Face Woes

スケッチをウォッチにインストールする必要がありました。

最初に試したのは、スケッチをウォッチに押し込んでそこにインストールすることでした。 Wear OS (旧 Android Wear) の時計に APK をサイドロードすることは、見た目ほど簡単ではないことがわかりました。 Android携帯では、設定で不明なソースからのインストールを有効にすれば完了です。 しかし、ウェアの場合、このインストールはシステムによってブロックされており、スマホかウォッチのどちらかをroot化するか、ウォッチをコンピューターに接続しない限り、回避する方法はありません。

次に、アプリを Wear 1.x アプリとしてパッケージ化し、携帯電話にインストールしてみました。 Android Wear 2.0 より前は、すべての Wear アプリは電話アプリにバンドルされて配布されており、その電話アプリが単なる空のシェルであったとしても、です。 しかし、2.0では、Wearアプリが単独で提供されるようになり、すべてが変わりました。 旧システムを利用して、スマホからウォッチアプリをインストールできるのではと期待したが、これは無駄だった。 古いインストール方法が新しい時計でサポートされているかどうかはまだわかりませんが、コンセプトの実証を行うことはできませんでした。

最終的に、私は最後の手段として、クラス ローディングという黒魔術のような方法に頼りました。 このアイデアは、スケッチを独立したアプリとしてインストールする代わりに、時計上ですでに実行されているアプリにスケッチのクラスをロードし、スケッチが実行されるたびにインストールする必要をなくすことができるというものです。 これは、現在のAPDEの仕組みとは根本的に異なるモデルです。 APDEはスケッチをビルドし、それはインストールされるスタンドアロンアプリです。 アプリの画面には、ユーザが実行したスケッチの束が蓄積され、APDEがアンインストールされたときにも、それらは残っています。 時計は違います。 スケッチはインストールされず、ただロードされるだけです。 時計の文字盤として利用できるスケッチは 1 つだけで、APDE がアンインストールされると消えます。

このアプローチがうまくいくことがわかりました。 ユーザーは、Play ストア (まだ利用できません) から「APDE Wear Companion」と呼ばれるブリッジ アプリを腕時計にインストールします。 APDE がスケッチを構築すると、それをウェア コンパニオンに送信します。 ウェアコンパニオンはスケッチを解凍し、ウェアコンパニオンに内蔵されているウォッチフェイスを選択するようユーザーに促します。 そして、そのウォッチフェイスがスケッチをロードして表示します。

スケッチがクラッシュすると、ウェア コンパニオンで実行されているので、ウェア コンパニオン アプリ全体もクラッシュします。 現在、被害を食い止めようとしていますが、スケッチが何度もクラッシュするため、wear companion が壊れて再起動する必要があることがあります。 APDEも、スタックトレースが送信される前にプロセスが終了してしまうので、今のところクラッシュしたウォッチフェイスのスタックトレースを見ることができません。 (Print ステートメントは動作しますが。)

ウォッチフェイスは 1 つだけでなく、実際には 2 つあります。 1 つはデフォルトのレンダラー (JAVA2D) 用、もう 1 つは OpenGL ベースのレンダラー (P2D および P3D) 用です。 したがって、それぞれのレンダラ用に2つのウォッチフェイスがあります。 ウェア コンパニオンがスケッチを解凍すると、それがどのレンダラーを使用しているかが確認されます。 そして、対応するウォッチフェイスが表示され、もう1つのウォッチフェイスは非表示になります。 これは、ユーザーが気づかないはずなので、別の種類の黒魔術ですが、かなりうまく機能しているようです。 実際には4つのウォッチフェイスがあります。 新しいウォッチフェイスをロードするとき、新しいものが古いものと同じであれば (そして、すべてのスケッチは同じ 2 つのウォッチフェイスを使用します)、システムは「短絡」して (これは技術用語です)、ウォッチフェイスを再ロードしないことが判明しました。 これは通常のウォッチフェイスでは問題ありませんが、APDEのウォッチフェイスは新しいスケッチを取得するためにリロードする必要があります。 各レンダラー (合計 4 つ) に 2 つのウォッチ フェイスを用意し、新しいスケッチをロードするときにそれらを交互に使用して、ウォッチ フェイスが強制的に再ロードされるようにするのです。

Looking Forward

この夏に予定されている次の大きな機能は、「プレビュー」モードです。 現在、APDE スケッチは、実行するたびにインストールする必要があります。 この配置は、いくつかの携帯電話で “実行” を押してからスケッチを見るまでの時間がインストーラによって倍増されるため、理想的ではありません。 また、上述したように、すべてのスケッチがアプリの画面を乱す可能性があります。 スケッチをインストールする必要がないことは、おそらく APDE の最も要求の多い機能です。

私はもともと、この問題に対して 2 つの解決策を提案していました。 まず、Processing.js を使用してスケッチを JavaScript に変換し、それを WebView で実行します。 2 つ目は、Instant Apps を利用して、スケッチをインストールせずに実行することです。 これらの解決策はどちらもまだ不完全です。 Processing.jsは時代遅れで、加速度計などのAndroidネイティブAPIをサポートしていません。 Instant Apps は、スケッチをローカルにホストして実行するためにデバッガを偽装することが可能かどうか、あるいは、インストールするよりも速いかどうかさえ分からないので、せいぜい不安定なアイデアです。 APDE では、スケッチを JavaScript に変換したり、インスタント アプリケーションを構築したりする必要はありません。 このアプローチでは、APDE は AAPT でリソースを構築し、ECJ でクラスをコンパイルし、クラスをデックスする必要があるだけです。 私の携帯電話では、このプロセス全体が 2 秒未満で済み (多くの携帯電話はかなり遅いですが)、APK をビルドしてそれをインストールするよりも大幅に改善されました。 このシステムを導入すると、ユーザーが実行ボタンを押す前にスケッチがコンパイルされている可能性が高く、つまり、残っているのはデキシングだけです。 言い換えれば、クラス ローダーは、もちろん携帯電話のハードウェアに依存しますが、ビルド プロセスを 1 秒未満に短縮することが可能です。

この夏には、まだ多くの興奮が待っています！

Fin

私が行った変更をより詳細に調査したい場合、GitHub の android-mode-4 ブランチをチェックしてみてください。 私は詳細なコミットメッセージを残しており (ほとんどの場合)、すべてのコードがそこにあります。

Stay tuned for preview mode!