Hi, I just came across this where we are extending context with a toast function: <https://github.co...

# android

[Pascal How]

Hi, I just came across this where we are extending context with a toast function: https://github.com/android/android-ktx/pull/290
The call to toast becomes a lot nicer because we can just do toast(...) without worrying about show() etc
My issue is whether this is actually a form of abuse on the extension function mechanism because Toast is not really an extension of context.
Similarly, I have come across several examples where extension functions have been used to simply shave off a parameter from the original method call. Any opinions?

[miszmaniac]

IMAO this method should be called showToast() just to make it clear what it actually does

[Pascal How]

Possibly but I am more concerned about whether extending Context is the right thing to do because extension functions were originally meant to augment/enhance a class and in this example it looks like Context and Toast are not related

[miszmaniac]

I see your point here. But this extension actually is helpful 🙂

[Pascal How]

I totally agree! The end result is lovely but it feels controversial

[leosan]

seems more like a problem of the Context itself being required for everything… but since we have this god object, makes sense these extensions for this context

[miszmaniac]

exactly:) It’s how android works:)

[gildor]

I don't think that this is abuse and I don't think that this extension is controversial.
It's completely valid and convenient way to use extensions. To bring some additions features to particular scope

[gildor]

In this case scope of context.
Context also has a lot of things, for example resources, and I don't see any particular reason why toast shouldn't be used as extension for context

[Pascal How]

Hmm ok

[Pascal How]

And how about this one:

fun Context.loadImageCenterCrop(url: String, imageView: ImageView) {
  Picasso.withContext(this)
    .load(url)
    .centerCrop()
    .fit()
    .into(imageView)
}

// Elsewhere
context.loadImageCenterCrop("<http://example.com/image.jpg>", myImageView)

[miszmaniac]

Why not do that on ImageView?:)

[leosan]

this could be an extension of the imageView itself and would be better to get the context from the imageView

[Pascal How]

Yes exactly! A better way is this

fun ImageView.loadImageCenterCrop(url: String) {
  Picasso.withContext(this.getContext())
    .load(url)
    .centerCrop()
    .fit()
    .into(this)
}

[Pascal How]

Hence why I got a bit uneasy on things that extend Context

[leosan]

yes, but with the toast would be weird making an extension of String

[miszmaniac]

We do that this way:

fun ImageView.picassoLoad(url: String, callback: ((requestCreator: RequestCreator) -> Unit)? = null) {
    this.context.picasso.load(url).apply {
        callback?.invoke(this)
    }.into(this)
}

[miszmaniac]

and yes… picasso is added to context:D

[julioyg]

I get the context from the imageView, if that makes sense

[miszmaniac]

me too.. picasso is added to context which is inside view:)

[Pascal How]

Yea definitely. That’s like in the second example I showed where I am extending ImageView instead 🙂
But saying that, the first example is still an extension function but used in the wrong way

[Pascal How]

My point was that even though both

fun Context.loadImageCenterCrop(url: String, imageView: ImageView) {
  Picasso.withContext(this)
    .load(url)
    .centerCrop()
    .fit()
    .into(imageView)
}

// Elsewhere
context.loadImageCenterCrop("<http://example.com/image.jpg>", myImageView)

and

fun ImageView.loadImageCenterCrop(url: String) {
  Picasso.withContext(this.getContext())
    .load(url)
    .centerCrop()
    .fit()
    .into(this)
}

both make your code more concise and both use the extension function mechanism, the first approach is bad because context has nothing to do with loadImageCenterCrop

[miszmaniac]

yea, i just use:

val Context.picasso: Picasso
    get() = Picasso.with(this)

Context works as service locator anyway, so no harm done here:)

[gildor]

Don't like this solution, also you create an instance of Picasso for each call

[miszmaniac]

It does not. We’ve used Picasso.setSingletonInstance() in application, and this method is just returning this instance

[gildor]

Okay, I see

[Makoto]

Anko does this:
https://github.com/Kotlin/anko/wiki/Anko-Commons-%E2%80%93-Dialogs

[Makoto]

toast("Hi there!")
toast(R.string.message)
longToast("Wow, such duration")

[Pascal How]

Thanks all for your input 👍
So I guess the conclusion is that for Toast it is fine to extend Context because it is like bringing new additions to the scope and it is convenient but in the case of

fun Context.loadImageCenterCrop(url: String, imageView: ImageView) {
  Picasso.withContext(this)
    .load(url)
    .centerCrop()
    .fit()
    .into(imageView)
}

Even though essentially, it is doing the same thing as extending Context with Toast, it is not fine because it is better to extend ImageView?

[gildor]

Yes, also each view already contains context, no need to pass context and ImageView separately.
Also it's just looks more natural to have such method on imageView