return webservice.getAllFacts()
    .also {
    coroutineScope {
        launch {
            catFactDao.insertAllFacts(it)
        }
    }
}

Code compiles, but is it a bad idea to use scope function on the return value (does it block even with the coroutine?)

Note that

coroutineScope { launch { suspendCall() }}

is equivalent to just

suspendCall()

, because

coroutineScope

waits for its child coroutines to finish before returning

I am trying to return the

list

while leaving the IO task (

insert the list into DB

) running by itself. The coroutine techniques I tried, like Dispatchers.IO for example, are still blocking the method from returning. the only way that worked was to create a new Thread.

suspend fun getAllFacts(): List<CatFact> { //TODO return Flow<List<CatFact>> instead
    if (allFactsLoaded) {
        return catFactDao.selectAllFacts()
    } else {
        val list: List<CatFact> = webservice.getAllFacts()

        //thread(start = true) {
        //    catFactDao.insertAllFacts(list)
        //}

        catFactDao.insertAllFacts(list)

        return list
    }
}

I am still reading the coroutines docs to see if there is anything else I can try.

The fact that launched coroutines shouldn't outlive a suspend function call is just a convention. It's a nice convention but if you're starting a thread you're already kinda breaking it anyway. If the behaviour you're looking for is really to have something concurrent that keeps going after the suspend function returns, then launching seems the appropriate thing to do. In order to do so, you'll need a coroutine scope that lives longer than your function call. It has to be provided in some way. For instance, it can be passed to

getAllFacts

either as argument or more conventionally as receiver (although we're already breaking conventions anyway 😄 ). So your function could look like this:

suspend fun CoroutineScope.getAllFacts(): List<CatFact> {
    if (allFactsLoaded) {
        return catFactDao.selectAllFacts()
    } else {
        val list: List<CatFact> = webservice.getAllFacts()
        launch {
            catFactDao.insertAllFacts(list)
        }
        return list
    }
}

You could also just have the scope somewhere in the class that declares this function, and simply use it to launch the coroutine:

suspend fun getAllFacts(): List<CatFact> {
    if (allFactsLoaded) {
        return catFactDao.selectAllFacts()
    } else {
        val list: List<CatFact> = webservice.getAllFacts()
        someScope.launch {
            catFactDao.insertAllFacts(list)
        }
        return list
    }
}

https://kotlinlang.slack.com/archives/C1CFAFJSK/p1631141393312100?thread_ts=1631130741.311600&cid=C1CFAFJSK Oh so the

coroutineScope { launch { suspendCall() }}

is useless because there is no non-returning code outside of the

coroutineScope

AND there is only one

launch

call? I swear I saw code written like this in the docs, but now I read it again, the call outside of the

coroutineScope

is a

println()

lol.

Basically

coroutineScope

suspends until all child coroutines are done, but if there is just one and no code running concurrently with it (inside

coroutineScope

), there is no point. It's like doing

async { suspendCall() }.await()

- starting a coroutine and immediately waiting for it

I also tested your theory of using a scope outside of the method, and it works. Yes I am using Android, and this method is inside a Repository class, so maybe there is some pre-made scope that I can access, but I will have to look that up. I created a local coroutine scope with this.

private val scope: CoroutineScope = CoroutineScope(EmptyCoroutineContext)

I am glad that you said using the outer coroutine breaks convention, which aligns with the Android docs from Google. I will take some more time to process your statements because I am quite a beginner in coroutines.

When you declare your own scope like this, it's important to think about its actual "scope" - its lifetime. Coroutine scopes help you avoid coroutine leaks, so you should try to cancel the scope when your component (Repository in this case) is not used anymore. This is probably more obvious with things like Activities or fragments because they have a clear lifecycle. I don't know much about Android so I don't know about Repository.