いうサンプルを提供しているようなので、落として動かして見ました。ダウンロードしてきます。プログラムを書いていると、イベントリスナを実装することは日常茶飯事ですが、「インターフェースを実装した実体であれば何でもよい」という緩い制約のため、いろいろな書き方があります。普段何気なく使い分けているのですが、どのように使い分けているのか自分の整理も含めて書いてみることにしました。この方法、よく見かけるのですが、私は多用しないようにしています。実装した場合のことを考えます。呼ばれる」という状況は分かりにくいこと極まりません。私は、「名は体を表す」ように実装してあげるように心がけるべきだと思います。}}この方法もよく見かけますし、私もよく使います。慣れるまではちょっと見にくいかもしれませんが、慣れてしまえば、簡単な処理なら内容をすぐ確認できるため便利です。複雑な処理を書く場合は見にくくなったりする難点があります。呼ぶたびにインスタンスが生成されるため、多少パフォーマンス的に難ありだと思われます。1」の問題を回避するために私が時々使う方法です。参照を持たせておくわけです。クリックしたときの処理が複雑で長くなる場合や、別々のボタンに同じ処理を持たせたい場合に便利です。メンバ変数を持たせると、いろいろなボタンで使いまわせなくなるので要注意です。この記述、あまり見かけないのは、そういう意味でJavaの思想からずれているからかもしれません。「あまり見かけない」というのは勘違いでした。ソースコードの中でも結構使っていますね。この方法で一番のメリットは、インスタンスの生成が1度きり。ようなリソースが限られた環境の場合は、意味がある場合もあります。メリットとデメリットをよく理解した上で使用しないと痛い目にあうかも...。この方法、クラスは匿名なのですが、メンバ変数に名前が必要で、その命名が難しいことが難点です。あることが分かりにくくなってしまいます。意味が変わってしまいます。とでも付けるのが良いのでしょうが、「長い割にわかりにくいかなー」と思い採用していません。};}ある意味、一番王道です。実装をきちんと定義してあげるわけですね。この問題も、3番同様、名前の付け方が難しいという問題を持っています。インナークラスとして実装していますが、インナークラスとして実装出来るような場合は、3番の方が使い易いでしょう。(インスタンスの生成タイミングを制御したい場合などは別ですが)この方法は様々なクラスで同じイベントリスナを使いたいというような場合に使えます。見えなくなっても、センサからの参照は生きているということに気を付けてください。放っておくとOutOfMemoryで落ちてしまいます。その辺についてはまた別の機会に書こうと思います。表示する時の動作をチェックしていたら少し気になることを見つけました。先のエントリに載せたコードを動作させたときのログが以下です。等を使うことがよくあります。どのように呼ばれるのか、気になったので調べてみました。作り、実際に動作させた結果を見てみます。ダウンロードしてくることが出来るようになったようです。これまでは、repoでソースコードを取ってきて、必要なファイルだけ抜き出して...といったような作業が必要だったのですが、これで大分楽ちんになりました。前のSDKをベースにして開発する場合は、自分でソースをとってこないといけません)ただ、このソースコード、インストールするだけではEclipseから参照することができない状態です。(そのうち改善されると思いますが)これでは宝の持ち腐れなので、参照できるようにしてあげようと思います。