android hacking 2日目

昨日も時間があったのでandroidをいじってみた。やはりJavaは面倒くさい。というより、リソースファイルとか多すぎて面倒だ。1週間でそれっぽいアプリが作れるかどうか、だんだん希望が見えなくなってきた。

昨日はAndroidに詳しい知人もいたので、いろいろ聞きながら作業をすすめていた。2日目はそれほどコードが増えたことは無かったのだけど、分かったこともそれなりにある。

• 初日の時点ではSurfaceViewのUIが点滅していて、原因が分からなかったのだけど、どうやらSurfaceView.getHolder().lockCanvas() で返ってくるCanvasがひとつではないようだ。androidのlockCanvasは、単なる描画ロックというより、ダブルバッファリングを用いた実装になっていると説明されているのだけど（あくまで現在の実装の話）、具体的には、onSurfaceCreated()のコールバック時にlockCanvas()で返されるCanvasと、アプリケーションが開始されてから（独自スレッド内で呼び出された時に）返されるCanvasとでは、インスタンスが違っているようだ。新しいCanvasにも画面全体を描画するようにしたら解決した。
• android端末の画面はずいぶん小さいなと思っていたら、avdを作成する時にカスタマイズすることができた。NexusOneは800x480とかあるらしいけど、十分すぎる。HT03Aなど古い端末では見えなくなりそうなので、多少は対応しようとも思うけど、そもそも大量のJetPlayerから飛んでくる大量のMIDIメッセージ（になるはず）を処理できるかどうか、かなり疑わしい。
• androidにはファイルシステムが存在するのに、標準的なファイルダイアログが存在しない(!)。どうやっているかというと、ファイル選択用のアプリケーションとIntentというものを使ってアプリケーション間通信のようにして行ったりするらしい。ファイル選択を実装しているopen-data-kitというプロジェクトを発見したので、このソースを再利用しようかとも思ったのだけど、単なる.javaソースの移動だけでは足りず、プロジェクトファイル全体の構成がややこしいことになりそうなので躊躇している。Intentを使うやっつけで対応した方が、とりあえずは良いのかもしれない。
• JetPlayerではmidiファイルをそのまま再生することができない。JetCreatorなどのツールを使うことになるのだけど、これがwxPythonで書かれたGUIツールで、android上で呼び出せるAPIのようなかたちにはなっていない。これでは困る。
• alsa-rawmidiはandroidに含まれているようだけど、どうやら標準のNDKにはヘッダファイルもライブラリも含まれていないようだ。ヘッダファイルはalsaのソースから拾ってくればいいし、ライブラリは実機から吸い出してしまえば良いのではないか...というのが友人の弁だった(!)

というわけで、まずJetPlayerで再生できるファイルをどうにかして作れるようにする必要がある。それが出来たら、今度はそれをプレイヤの画面でファイル選択ができるようにしなければならない。どちらもmidiプレイヤを作るための本来のタスクではないような気がしてきた。

あと、TouchDownは取得できるのにTouchUpが取得できないという（たぶん初歩的な）問題にぶつかって、早送りが実現できるようになったら困る予定だ（JetPlayerではテンポが変更できないので、早送りが実現できる予定は今のところ無い）。

いろいろ壁もあるけど、楽しい部分は楽しい気がしてきた。