Слушатель событий и обработчик событий - это два термина, которые вызывают путаницу. Особенно в Котлине, где граница между ними была размыта. Здесь я пытаюсь упростить.

Общее определение слушателей и обработчиков намного шире, чем его использование в Android. Вот популярные определения:

прослушиватель следит за запуском события.

обработчик отвечает за обработку события.

Это может сбивать с толку, потому что часто один и тот же объект прослушивает события и обрабатывает их. Хотя обычно предполагается, что когда мы устанавливаем анонимный класс в качестве слушателя, его методы являются фактическими обработчиками:

cancelImage.setOnClickListener(object : View.OnClickListener { //1
    override fun onClick(v: View?) { // 2
        dismiss()
    }
})
  1. Анонимный класс здесь используется как слушатель
  2. Метод onClick находится здесь обработчик события

Мы можем использовать именованные классы в качестве слушателей:

class OnCancelSnackListener(
    val snackbar: Snackbar
): View.OnClickListener {
    override fun onClick(v: View?) {
        snackbar.dismiss()
    }
}

Использование:

cancelImage.setOnClickListener(OnCancelSnackListener(this))

Слушатели часто являются объектами, поэтому они обычно имеют суффикс Listener. Обработчики обычно не имеют суффикса, но вместо этого они чаще всего имеют префикс on (onClick, onSwipe и т. Д.). Обратите внимание, что это более проблематично, когда мы устанавливаем слушателя с использованием лямбда-выражения:

cancelImage.setOnClickListener { dismiss() }

Что это за лямбда-выражение? Слушатель или обработчик? Формально он определяет, как следует обрабатывать событие. Объект слушателя генерируется Kotlin под капотом. Означает ли это, что когда мы называем функцию, которая принимает обработчик, мы должны называть ее суффиксом Handler (например, setOnClickHandler)? Нисколько. Хотя вы можете найти такие подходы в некоторых JS-библиотеках, например ExJS:

handler: function() {
}
listeners: {
   'click': function() {
   }
}

Соглашение в Java, как и в большинстве других языков, заключается в использовании суффикса Listener по историческим причинам! Вы можете узнать в коде Kotlin stdlib и JetBrains Kotlin, что Kotlin также принимает это соглашение. Таким образом, вы можете с уверенностью определить следующие функции:

fun setOnLoadedListener(handler: ()->Unit) {
   // Code
}
fun addOnFlingListener(handler: ()->Unit) {
   // Code
}

Также вы можете определить следующие функции:

fun setOnLoadedListener(listener: ()->Unit) {
   // Code
}
fun addOnFlingListener(listener: ()->Unit) {
   // Code
}

Просто помните, что это хорошая практика - сформулировать одно соглашение для проекта и уважать его.

Этот пост является пятнадцатой частью словаря программистов Kotlin. Чтобы быть в курсе последних новостей, просто подпишитесь на этот канал или следите за мной в Твиттере. Если вам нужна помощь, помните, что Я открыт для консультации.

Если вам это нравится, не забудьте хлопать. Обратите внимание: если вы удерживаете кнопку хлопка, вы можете оставить больше хлопков.

Вот и другие части словаря программистов Kotlin: