棚からパルチャギ

iアプリでの定石(なのかも微妙だけど)だと、アプリケーション本体であるIApplicationと描画用のCanvasを継承したクラスを1つずつ用意して、 Canvasのメソッド内でメインループを回すのが一般的だと思います。 メインループはwhile()で回して、System.getCurrentMiils()を見ながらFPSを調整、キー情報はループ毎にポーリングして、 描画はCanvasから取得したGraphicsにlock/unlockして描画みたいな。

AndroidではIApplocationに相当するものがActivity。 描画はCanvasそのものに描くのではなくて、View#OnDraw()で引数として渡されるCanvasに描画。 メインループは、Handlerで定期的に内部処理と描画の更新を行うというのが作法(?)みたいですね。

速度や正確さを求めると結局はwhile()で回すことになるのかもしれないけど、 携帯アプリみたいにほぼシングルスレッドで動作するわけでもなさそうなので、とりあえずは奇麗な方法で。 キー情報はonKeyイベントが発生するまで状態を取得する手段が無いっぽいので、 イベントハンドラでキー状態を保持するようにKeyPadStateクラスを作成しました。 とりあえずメインループとキー情報が取れて、描画対象が1枚だけということになれば携帯アプリと同じような感覚で作れるかなー、 ということで三角形が動くだけのサンプルでも置いておきます。
描画関係だと、あとはスプライトとして使っていたImageはDrawableで代用。 背景なんかは従来通りにBitmapで保持して、BitmapDrawableで描画すればなんとかなりそう。 ダブルバッファリングはonDraw()の最中に表示スクリーンが再描画されることはないので、特に意識する必要はなさそう。 シーン管理を書けばゲームっぽいものなら作れる気がしますね。

あと必要そうなのは、データの読み書きと通信処理、サウンド機能。OpenGLとか3D関連は苦手。 端末機能は当面使わないので保留。公式のサンプルコードはじっくり読むとかなり参考になるので、 ドキュメントと合わせてもう少し勉強します。

DDMS(Dalvik Debug Monitor Service) Toolという素敵っぽいツールが付属しているんですが、 いまいち使い方が把握できていないので、とりあえずは原始的にprintデバッグ的な。 Eclipseと統合していれば、この辺もコンソールに表示されたりするんだろうなー、とか思いつつ。

Androidのデバッグ出力はSystem.out.println()ではなく、android.util.Logを使います。 staticなメソッドがあるので、そのままこんな感じで(↓)呼び出します。 「Log.」に続く一文字がエラーレベルを示します。「e」ならば「ERROR」。 ERRORが最も深刻度が高く、順にWARNING→INFO→…と下がっていきます。 第1引数はログメッセージにつけるタグ名で、ログをフィルタリングする際に使用するので、 アプリケーションの名前などを設定しておくと良いと思います。

吐き出されたログメッセージは、adb logcat で閲覧できます。 そのまま表示すると大量に流れてしまうので、オプションでタグ名とエラーレベル(優先度)を指定してフィルタリングします。 上記の例では、タグが「APPNAME」でエラーレベルがDEBUG以上のメッセージのみを表示します。 タグ名は「*」にすると、全てのタグを対象にすることができます。 エラーレベル(優先度)に指定できる文字列は以下の通り。調べるまでもないかもですが…。

書き忘れていたので、補足です。
Androidのアプリケーションはパッケージ単位で認識されているようなので、 たとえば com.example というパッケージでは1つのアプリケーションしか登録することができません。多分。 なので、com.example.Foo と com.example.Bar というアプリケーションを同時にインストールすることはできず、 どちらか一方だけが有効になります。

パッケージ名はアプリケーション名まで含めて com.example.foo.Foo のように命名したほうが良さそうですね。 …って、これJavaでは常識だったりしますか？？？


あとは、アプリケーションの削除について。 エミュレータのインターフェース上ではアプリケーションを削除することができないので、ここでもadb(Android Debug Bridge)を使用します。