Never use this anti-pattern is the solution

# coroutines

[gildor]

Never use this anti-pattern is the solution

[Mark]

Okay, thanks. Any pointer to some likely alternative?

[gildor]

What is your use case for this?

[Mark]

Various, but the most common one is needing a (application) context in a singleton.

[wbertan]

Should not DI solve that?

[Mark]

I’ve been holding off DI up until now, because the landscape seems to be changing a lot.

[Mark]

I mean the decision of whether to use Dagger 2, Kodein, Koin etc

[wbertan]

You already did some decisions, your architecture, your framework, your language, that is one of those decisions, where good or bad, will not be eternal (as some years back people choosing Java and now migrating to Kotlin).

[wbertan]

Either way, as @gildor said, Never use this anti-pattern, but I believe this could achieve what you want (I think the Asas2 is what you want)

class TestAsas {
    object Asas : (String) -> String {
        override fun invoke(p1: String): String = "Welcome $p1!"
    }

    @Test
    fun asas() {
        val result = Asas("Me")

        Assert.assertEquals("Welcome Me!", result)
    }

    object Asas2 : (String) -> () -> String {
        lateinit var INSTANCE: () -> String

        override fun invoke(p1: String): () -> String {
            if(!::INSTANCE.isInitialized){
                { "Welcome $p1!" }.also { INSTANCE = it }
            }
            return INSTANCE
        }
    }

    @Test
    fun asas2() {
        Asas2("Me")

        val result1 = Asas2.INSTANCE()
        Assert.assertEquals("Welcome Me!", result1)

        val result2 = Asas2.INSTANCE()
        Assert.assertEquals("Welcome Me!", result2)
    }
}

[wbertan]

It also prevent other initialisation:

@Test
    fun asas3() {
        Asas2("Me")

        val result1 = Asas2.INSTANCE()
        Assert.assertEquals("Welcome Me!", result1)

        Asas2("Other")

        val result2 = Asas2.INSTANCE()
        Assert.assertEquals("Welcome Me!", result2)
    }

[louiscad]

If you need applicationContext, I already solved the problem with the little library Splitties App Context that gives you a top level appCtx property.

[Mark]

Yes, I saw that thanks. Although sometimes, I need something other than the context.

[gildor]

“Context” case and “something other” are completely different things

[gildor]

Get application context is easy, just use Louis’ code or just write top level property and set it on Application onCreate/onBaseContextAttaches

[gildor]

not perfect, but much better than use singleton with params

[gildor]

I need something other than the context.

Yes, most probably you need DI

[Dico]

I think it's a misconception that you need library to follow DI pattern

[Dico]

Just pass all dependencies to constructor

[gildor]

even without using any framework, just create some dependencies graph and make it available globally, as just super simple solution

[Dico]

In Kotlin it's ridiculously easy, since it removes a bunch of boilerplate

[gildor]

or use common Android pattern with service locator based on retrieving dependencies from Application context

[Mark]

yes, this more or less how I currently do it

[gildor]

Just pass all dependencies to constructor

But because you cannot do this for Android components, instead you can do this by getting from Application context

[Mark]

To better describe the problem: Suppose a MyApplication object (Application subclass) has a property myImmutableConfig and there is a singleton (by intention) class that can be instantiated by suspend fun createMySingleton(myImmutableConfig): MySingleton and I want to be able to access MySingleton from a suspending function. If accessed from a blocking function, then presumably it would potentially block the main thread.

[Mark]

My first thoughts are something like this, using lateinit, similar to @wbertan suggestion earlier. But this way isn’t thread safe by the looks of it:

private lateinit var INSTANCE: MySingleton

suspend fun getInstance(): MySingleton {
    if(!::INSTANCE.isInitialized){
        INSTANCE = createMySingleton(myApplication.myImmutableConfig)
    }
    return INSTANCE
}

fun getInstanceBlocking(): MySingleton {
    if(!::INSTANCE.isInitialized) {
        runBlocking { 
            return@runBlocking getInstance()
        }
    }
    return INSTANCE
}

[gildor]

No need to use all those isInitialized or singeltons, if we talking just about caching of value in property in a suspend way, just use async

[gildor]

val myConfig: Deferred<MyConfig> = GlobalScope.async(start = Lazy) {
   createMyConfig(myApplication.myImmutableConfig)
}

And to use just myConfig.await()

[Mark]

Using GlobalScope?

[Mark]

ah ok

[gildor]

Any scope what you want

[gildor]

depends on case

[gildor]

if this a property in a class, use scope of this class etc

[gildor]

but your example above looks more like some global property, so up to you

[gildor]

you even can get rid of Deferred by wrapping to suspend function:

private val myConfig: Deferred<MyConfig> = ...

suspend fun myConfig(): MyConfig = myConfig.await()

[gildor]

But in general, because you use this on Application level GlobalScope is fine

[Mark]

So much nicer, thanks!

private val INSTANCE_DEFERRED = GlobalScope.async(start = CoroutineStart.LAZY) {
    createMySingleton(myApplication.myImmutableConfig)
}
suspend fun getInstance() = INSTANCE_DEFERRED.await()

[gildor]

as you can see, there is no singletons with params, just some global/application state (which has own problems, but not more than for example common singleton)

[gildor]

also it’s not blocking

[Mark]

I see, yes. Although the instance can only be accessed from a suspending function.

[Mark]

And then from non-suspending code:

fun getInstanceBlocking() = if (INSTANCE_DEFERRED.isCompleted) {
	INSTANCE_DEFERRED.getCompleted()
} else {
    runBlocking {
        getInstance()
    }
}

[gildor]

Of course, from suspending, because it's asyncronous

[gildor]

For blocking version of this function I wouldn't check for completed, just wrap to runBlockimg

[Mark]

ok, thanks

[gildor]

Also, I wouldn't introduce blocking version, just because it makes all this code not so safe and potentially you can accidentally block main thread

[gildor]

Blocking version maybe useful only for some very special use cases, but in this case I would just use runBlocking on call site

[Mark]

Right, then it’s more explicit