「イベントリスナー」と「イベントハンドラー」て分かってるようで分かってないような。

特に, 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
}

プロジェクトごとにどちらかに統一するのが良いでしょう。とな。

イベントハンドラとラムダ

Programmer dictionary: Event listener vs event handler

関連ワード:  Android・Kotlin・おすすめ・開発