「イベントリスナー」と「イベントハンドラー」て分かってるようで分かってないような。
特に, Kotlin では混乱します。
一般的に「リスナー」と「ハンドラー」は定義として
「リスナーは起動するイベントを監視するもの」
「ハンドラーはイベントの処理を担当するもの」
混乱の原因として、同じオブジェクトをイベントのために監視(Listen)して処理(Handle)することがよくあります。
無名クラスをリスナーとしてセットして、それのメソッドがハンドラーのパターン。
cancelImage.setOnClickListener(object : View.OnClickListener { // 1
override fun onClick(v: View?) { // 2
dismiss()
}
})
// 1 -> リスナー
// 2 -> ハンドラー
また、以下のようにリスナーと名前をつけてクラスを作ることができます。
class OnCancelSnackListener(
val snackbar: Snackbar
): View.OnClickListener {
override fun onClick(v: View?) {
snackbar.dismiss()
}
}
使い方:
cancelImage.setOnClickListener(OnCancelSnackListener(this))
一般的に、リスナーは「***Listener」、ハンドラーは「On***」と命名されます。
問題なのはラムダ記述の場合です。
cancelImage.setOnClickListener { dismiss() }
どれが「リスナー」なのか「ハンドラー」なのか。
リスナーオブジェクトは、Kotlinでは隠れてしまいます。
これは、setOnClickHandler と書くべきではないのかと思えたります。
ExJSなどjavascriptライブラリでは以下のような記述があります。
handler: function() {
}
listeners: {
'click': function() {
}
}
これらのJavaや他の言語の接尾語「***Listener」を使う慣習は歴史的な理由なだけです。
Kotlin stdlib や JetBrains のコードからそのことを確認できます。
自信をもって以下のように書きましょう。
fun setOnLoadedListener(handler: () -> Unit) {
// Code
}
fun addOnFlingListener(handler: () -> Unit) {
// Code
}
これまでどおり以下のようにも書くことができます。
fun setOnLoadedListener(listener: () -> Unit) {
// Code
}
fun addOnFlingListener(listener: () -> Unit) {
// Code
}
プロジェクトごとにどちらかに統一するのが良いでしょう。とな。
