冬休みからしばらくの間、イベント処理を簡単に実現するためのフレームワークとしてRxを実装していたのだけど、先週でひと区切りつけられたので、今週はRx自体の実装から離れて、入力イベントを簡単に記述できる手段を実現できないものかと模索していた。とりあえず「複雑なイベント処理を簡単に実装できるようにする」例として、タッチイベントによるジェスチャーの実装が思い浮かんだ。
Androidでは、タッチイベントはMotionEventとしてGestureViewOverlayを経由して受け取ることができる。これにはdown, move, up, あとcancelというイベントが渡ってくる（触ってすぐ戻るとキャンセルになるようだ）。これを組み合わせることで、複雑なイベントを実現できるはずだ。たとえばholdなら、downの後しばらくupが無ければトリガーしても良さそうだ。
こういう一連のイベントの流れを、よりわかりやすい形で記述できないものか。そう思いながら、何となく独自の記法で、今すでにあるようなイベントの仕組みを推測しながら、書いてみた。
この種の記法で、イベント自体が記述できればもちろんそれも良いし、実際にコードまで落とし込めなくても、設計を考えるときの足しになれば、有用なんじゃないかと思う。
実のところ、Androidにはandroid.gestureというパッケージが提供されていて、Gestureクラスには連続的なtimestamp付きの座標リストが渡されてくるので、そこまで面倒を自分で見る必要は無い。自分でやるとしたら、認識方法を自分の好みにカスタマイズしたい場合くらいだろう。さらに、GestureDetectorというクラスも用意されていて、一定のパターンの入力イベントを認識して特別なイベントを発行するようになっているようだ。2本指でzoomする場合にはScaleGestureDetectorが使える、といった具合だ。もっとも、OnGesturePerformedListenerがどういうタイミングでイベントを送ってくるかは、実験してみないと分からない。downの後upが来る前に送られてくるとしたら、イベント処理に重複が発生しそうだし（パフォーマンスも悪そうだ）、upがあって初めてイベントが送られてくるとしたら、ホールド状態の時にイベントを発生させたり次のイベントの条件に繋げたい場合などに使えない。
...といったわけで、自分でGestureDetectorに相当するものを作るのもそれなりに有用ではないかと考えている。
もう一つ、この週末に引っかかっていたのは、ジェスチャーライブラリの類はプラットフォーム非依存に出来るのではないかということだ。どのプラットフォームでも、タッチ入力にはdown, move, upくらいはあるだろうし、そこでマルチタッチも扱えているのではないかと思う。それらを共通化してしまえば、後はプラットフォーム独立のやり方でgesture detectorを実現できるのではないかと思う。
android.gestureがandroid.viewから独立しているのも、ある程度プラットフォーム中立の仕組みになっていることを開発者も認識しているから、ではないかという気がしている。
実のところ、そのような発想に近い形でプラットフォーム中立の入力インターフェースロジックを実現しているものがある。TUIOというプロジェクトで、reactableなどを実現している。メディアアートの系譜で使われているようだ。ただし、これはイベントの入力装置 (tracker) とイベントの処理装置 (client) が別々になっていることを前提とするモデルで、その間はOSCを経由している。UDPだからTCPよりはましだけど、ローカルのイベント処理にそこまで抽象化してリソースを浪費するのはちょっともったいないと思う。
といった感じで、いろいろ考えることはあったけど、ひさびさに実装には全く至らない週末だった。この辺は時間がとれたら面白いことが出来そうだけど、そこまで余裕が出来るかは分からない。
