Hey everyone! In Android land I write a lot of int...

# getting-started

[Colton Idle]

Hey everyone! In Android land I write a lot of interfaces in kotlin that have one method. A SAM is what I think they call em. Something like this

interface SaveListener {
    fun onSave(name: String)
 }

MY ISSUE: When I try to create the listener, it makes me write out the whole thing. I thought there was a way around this in Kotlin? Probably missing something basic.

So I have to write this

myController.listener = object : SaveListener {
    override fun onSave(name: String) {
        //do thing
    }
}

But with kotlin I thought I'd be able to do this

myController.listener = SaveListener { //do thing }

[Matthieu Esnault]

It’s only available for Java interfaces currently
See https://youtrack.jetbrains.com/issue/KT-7770

[Adam Powell]

Usually you'll use (String) -> Unit as the type for something like your example instead of declaring an interface for it

[tjohnn]

Using higher order functions is a better way to deal with these use cases

[Vishnu Haridas]

Agree with @tosinbot and @Adam Powell. One of the most helpful thing after switching to Kotlin was higher-order functions. Very helpful in RecyclerView adapters.

// pseudo-code
class ProductsAdapter(List): Adapter() {

    var onItemClick: ((Item) -> Unit)? = null
    var onAddToCart: ((Item) -> Unit)? = null
    var onBuyNow: ((Item) -> Unit)? = null
    var onWishList: ((Item) -> Unit)? = null
    ...// other methods, 

    fun onBind(item){
        val view = inflate(...)
        view.addOnClickListener {
              onItemClick?.invoke(item) 
        }
        view.button_buy_now.addOnClickListener {
              onBuyNow?.invoke(item) 
        }
}

...and later when creating the Adapter,

val adapter = ProductsAdapter(myProducts)

adapter.onAddToCart = { item ->
    // process the item
}

adapter.onBuyNow = { item ->
    // proceed to buy
}

[ibraiz_teamo]

if I put these functions in constructor, it would also work but what is the better approach here?

[Vishnu Haridas]

@ibraiz_teamo It depends. For a limited number of functions, the constructor is a good place, but if there are too many functions, or if there's a chance to add more functions in future, keeping them as properties and accessing them will be more maintainable.

[ibraiz_teamo]

makes sense, thanks

[Colton Idle]

@Adam Powell interesting. Thank you!

What's the name for that pattern though? If I need a listener (in java land) I immediately think "Oh hey I need an interface". Is it what I'm creating now just going to be a "function"?

[Colton Idle]

Just read the rest of the comments. So these are just called "higher order functions"?

Like if I wanted to explain to a teammate in java that we should write an interface for this new listener, we would understand each other. What is the kotlin speak for this?

[Vishnu Haridas]

A "higher-order function" is a function that takes functions as parameters, or returns a function. Functions are first-class citizens in Kotlin. That means, you can reference functions just like any other variable / object, pass as parameters, or return functions from other functions.

When the project is 100% Kotlin, instead of writing a SAM (an interface with a Single Abstract Method) we can use higher order functions (or references).

https://kotlinlang.org/docs/reference/lambdas.html

[Colton Idle]

Thanks! Appreciate the help @Vishnu Haridas @tjohnn and @Adam Powell