私のAndroidアクティビティには、すべてOnClickListenerを必要とする複数のボタンが含まれています。これを行うには、次のようなさまざまな方法がたくさんあります。
私はそれぞれのアプローチの多くの例を見てきました。ただし、なぜ1つのアプローチが別のアプローチの代わりに使用されるのかは、はっきりしません。これらのアプローチの違いは文体的ですか、それとも1つのアプローチを改善する理由がありますか?
多くのことと同様に、正しいアプローチは、特定のボタンに対して何を実行しようとしているか、およびアクティビティに対して他に何を実行しているかによって異なります。
アクティビティクラスはインターフェイスを実装します:
これは、このリスナーが呼び出されたときに実行するタスクのタイプが1つしかない場合に適したオプションです。この例は、多数のフィールドと保存ボタンを備えた単純なフォームです。実際に何をする必要があるかを判断するために、イベントリスナーにイベントのソースをチェックさせないようにしています。これがスタイルだと言う人もいるかもしれませんが、リスナーがこのチェックを行う必要がないため、各イベントで何が呼び出されているかを正確に把握できるため、コードを追跡しやすくなります。
別のクラスがインターフェースを実装:
上記で述べたように、同じオプションを起動できる複数のアイテムがある場合は、このオプションを使用します。上記の例を拡張して、クリックリスナーも必要とするクリアボタンを追加しましょう。保存アクションを実行するリスナーを1つと、クリアアクションを実行するリスナーを1つ作成します。各リスナーは、そのアクションを生成するコンポーネントにのみ追加されます。
この実装には、気になる場合に利用できる追加の利点があります。利点は、他のクラスがアクティビティクラス内のイベントをトリガーしないようにすることです。インターフェースメソッドはパブリックでなければならないため、クラスへの参照を持つユーザーはだれでもイベントを発生させることができます。アプリケーションで何ができるかをきめ細かく制御したい場合は、別のクラスにより、アクティビティへの参照を持つユーザーがフォームをクリアまたは保存するのを防ぎます(または、リスナーがソースを利用している場合はコードを壊す可能性がありますが、悪い入力を処理しない)。
匿名の内部クラスはインターフェースを実装します:
これは実際には、実装として別のクラスを使用する2番目のオプションを構築する特定の方法にすぎません。他の誰もクラスのインスタンスを作成できないため、このオプションでは、イベントをトリガーするアクセス権を持つユーザーをさらに制限できます。ただし、2つのオプション間のより重要な要素は、どれだけの作業が行われているかです。いくつかのテキストフィールドをクリアすることは、単純明快な操作です。ただし、forを保存するプロセスには、入力を検証し(実行する必要があります)、データベースに書き込んで値を保存し、保存後のアクションをトリガーするという、多くのタスクが含まれる可能性があります。この場合、独自のファイルを使用して別のクラスを作成すると、入力フォームとデータ処理の間の明確な区別が提供されます。これにより、複数の内部クラスがネストされた大きなファイルではなく、フォームコードが保持されます。
4番目の方法は、レイアウトでonClick属性を設定することです。
<Button Android:onClick="clickHandlerForButtonX" />
アクティビティにこの対応するメソッドがあります:
public void clickHandlerForButtonX(View v) {
//Handle Button X here
}