Do people feel that

StateFlow

is a good replacement for

LiveData

on Android? There is often a noticeable delay in updates, which leads to the UI to represent incorrect information when it first shows up. That never happened to me with

LiveData

.

I keep making this mistake:

CoroutineScope.launch {
    stateFlowA.collect {
        foo()
    }
    stateFlowB.collect {
        bar()
    }
}

And wondering why bar() isn't called. (It's because stateFlowA never completes, as it's a StateFlow). I think I'm just tempted to declare both suspend functions inside the one

CoroutineScope.launch { }

block out of convenience. Anyway, the simple solution is to just not make this mistake. But I wonder if I'm doing this because there's a problem with my mental model. I think maybe this comes about because

launch{}

is the only operator I ever use to kick-off a suspend fun (I rarely consider

async

, and I'm not sure if there are others. I don't have a specific question, just wanted to discuss this and see if anyone else has the same problem. I'm hoping the discussion will help correct my mental model.

Room will use different Dispatchers for transactions and queries. These are derived from the executors you provide when building your Database or by default will use the Architecture Components IO executor. This is the same executor that would be used by LiveData to do background work.

Does that mean if I use

withContext(<http://Dispatchers.IO|Dispatchers.IO>) { //db calls }

then likelihood is that Room merges this with whatever

Architecture Components IO executor

it uses internally? Or would

<http://Dispatchers.IO|Dispatchers.IO>

overwrite Room's default dispatcher. As far as I understand

Default

means

main

in Android.

I've got a couple of 

StateFlows

 the second depends on the first. But, the second is not emitting when I expect it to..

I guess more of a design pattern problem. If I have a view model on Android that has 3 flows that it needs to collect from when the view opens, but the flows may need to be restarted based on an event, what is the standard safe way to do this?

Question about unit tests. I got a repo which I would like to test. It has an ApiService dependency which I mock with mockk. I would like to test, that when I call a suspending function of the repo it calls a certain api function on the correct dispatcher. I know how to verify the api call but have no idea how to make sure the correct dispatcher is used. Is this possible?

if i run this code:

suspend fun main() {
    val executorService = Executors.newWorkStealingPool(1000)
    withContext(executorService.asCoroutineDispatcher()) {
        repeat(1000) {
            async {
                delay(1000)
            }
        }
    }
    println(executorService)
}

at the end the executor service has one task left:

java.util.concurrent.ForkJoinPool@5079ec1[Running, parallelism = 1000, size = 70, active = 1, running = 1, steals = 2000, tasks = 0, submissions = 0]

why is that. if i do runBlocking instead of withContext the executor service is empty as expected.

Does it make sense to have a

flow

that inside does an

async{}

call? For instance

flow<List<Foo>>{
  val list = getFromApi()
  val one = async(<http://Dispatchers.IO|Dispatchers.IO>)
  val two = async(<http://Dispatchers.IO|Dispatchers.IO>)
  val correctList = one.await() + two.await()
  emit(correctList)
}

Or it's better to use async without flow here? That's pseudo because to do

async

I need a

coroutineScope

is there any way to get it from the

flow

?

What would be the best way to launch a coroutine in a

RecyclerView.ViewHolder

(I need to load an image, and offload that to a background thread) Not sure if this channel, or #android is better....

Is there a flatMap variant which drops upstream emits when body is not completed yet Is overriding concurrency to 1 in flatMapMerge okay or should I have a custom operator

Hi! I've already asked this in #ktor, but seeing how this is related to coroutines, maybe someone could help here? I'm a bit frustrated, so in one part of my program the coroutine that a ktor websocket is running on becomes inactive (before I open the websocket the coroutine is active), so I'm wondering if anyone knows why 🙂 Code where it doesn't work: https://github.com/dkim19375/Tag/blob/master/src/main/kotlin/me/dkim19375/tag/multiplayer/ClientManager.kt#L43-L107 Code where it does work with almost the same code: https://github.com/dkim19375/Tag/blob/master/src/main/kotlin/me/dkim19375/tag/util/Testing.kt Image with the first code snippet hiding the comments is below. Since the coroutine isn't active, the websocket won't work 😞 Ktor: 

1.6.0

Kotlin: 

1.5.10

 (JVM) All dependencies: https://github.com/dkim19375/Tag/blob/master/build.gradle Server log: https://paste.helpch.at/eruzihulol.sql Client log: https://paste.helpch.at/bedemiyihi.sql Note that for both logs I'm using TornadoFX, and in my test class, I'm not using TornadoFX, and this is the log:

program
test 1, is active: true
test 2, is active: true

Is this an issue towards what I'm doing with ktor or is it something with coroutines? (I'm not sure so I'm asking both channels) EDIT: Figured it out

I find that DelicateCoroutinesApi opt in a little useless. I am purposely using a GlobalScope in one place and what I want to do here is to add a suppress at the place where it's used with a comment. But with the opt in system I need to enable it for the whole module which makes the warning in other places go a away 😕

Usually when I want to launch a banch of coroutines but also want to wait for all them to finish, I do something like this:

val jobs = arrayListOf<Job>()
aListOfStuff.forEach {
  jobs.add(launch { something(it) })
}

jobs.joinAll()
println("All jobs completed!")

Recently I discovered I can do something similar with

supervisorScope

, like so:

supervisorScope {
  aListOfStuff.forEach {
    launch { something(it) }
  }
}

println("All jobs completed!")

Does it completely mimics the behavior I intented the first part to have though? Are there be any mihaps I should be aware of?

This message was deleted.

Would buffered flows be the current best way of fanning out a number of (comparatively) long running http requests and aggregating the results?

It’s failing with this output

expected: Thread[test,5,main]
but was : Thread[main @coroutine#1,5,main]

Hi there! This message is for those who are interested in the opportunity to write their view models in a much simpler way and keep them at the multiplatform level. As you may know,

StateFlow

is a really convenient thing for implementing reactive view models, but there is a big problem - when you combine them (with

combine(...)

or

map(...)

operators) they turn into

Flow

that is not so convenient.

val firstField: StateFlow<String>
val secondField: StateFlow<Int>

val canDoSomethingScary: Flow<Boolean> = combine(firstField, secondField) { first, second ->
    first.isNotBlank() && second > 0 && second < 10
}

// method has to be suspended :(
suspend fun doSomethingScary1() {
    // had to have coroutineScope here :(
    if (!canDoSomethingScary.stateIn(coroutineScope).value) return
    // do something scary
}

There is a proposal on GitHub about having an opportunity to combine

StateFlows

and get

StateFlow

. There are also examples why getting

Flow

is not convenient and working code snippets with the solution, using which one will be able to write much clearer code and keep their view models at the multiplatform level right now. Like this

val firstField: StateFlow<String>
val secondField: StateFlow<Int>

val canDoSomethingScary: StateFlow<Boolean> = combineStates(firstField, secondField) { first, second ->
    first.isNotBlank() && second > 0 && second < 10
}

// method doesn't have to be suspended :)
fun doSomethingScary() {
    if (!canDoSomethingScary.value) return
    // do something scary
}

Please vote and discuss the proposal there to induce the Kotlin team to include it (or a better solution) in the

kotlinx.coroutines

in the following releases. https://github.com/Kotlin/kotlinx.coroutines/issues/2631

Does it make sense that a

Deferred

inside a

supervisorJob

continues to report as active until all the co-routines are complete? I was expecting the child jobs move to a completed state once they themselves finished, instead of only transitioning to completed when all have done so.

interface RestApi {
    fun get()
    fun post()
    fun put()
    fun delete()
}
interface NewRestApi {
    suspend fun get()
    suspend fun post()
    suspend fun put()
    suspend fun delete()
}

I am adding a feature in my rest client library to support suspend functions. What is the recommended prefix for suspend method names? I need something to differentiate between the non-suspend functions, to avoid misunderstanding. Any ideas are welcome, I suck at naming.

I was reading that

stateflow

never completes, so by this reasoning, we should never start collecting on a stateflow from within

suspend

function correct?

I have some doubts regarding context of coroutines. In @elizarov article Coroutine Context and Scope there is an image showing how context and coroutines creation is handled. What I have understood from it is during launch{} inside a scope, 3 coroutine context are there. One coming from scope(called scope context), another intermediate Parent context(which will be lost since there won’t be any reference to it) and final child context(with a job inside it). Am I correct? I have read coroutines over and over still get confused. If anyone can give me an explanation, it will be huge help. Thanks.

Is using runBlocking correct way to interface with blocking world when using MutableStateFlow?

class PermissionManager() {
    private val manualTrigger = MutableSharedFlow<Unit>()
    
    ...

    fun notifyPermissionChanged() {
        runBlocking { <---------------------
            manualTrigger.emit(Unit)
        }
    }
}

class Activity {
	override fun onRequestPermissionsResult(
        requestCode: Int,
        permissions: Array<out String>,
        grantResults: IntArray
    ) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults)
        permissionManager.notifyPermissionChanged()
    }
}

tryEmit never does anything

What's difference between CoroutineScope(Dispatchers.IO) + Job() and CoroutineScope(Dispatchers.IO+ Job())

Hi everyone, how do I convert a

List<Flow<T>>

to a

Flow<List<T>>

? Sounds simple enough but it's bugging my brain 😅

I'm confused on

trySend

vs

trySendBlocking

in

callbackFlow

. I presume it's about backpressure right? If so, to mimic rxjava Observable, I want

trySendBlocking

right?

trying to understand what happens when a coroutine is launched in an IO dispatcher (to help in code review). my co-worker has code that launches in an IO dispatcher with code that has no suspend functions (mostly to conform to a previous interface, but lets hand wave that part). since there are no suspend functions, does calling this method always start a new thread? i’m not familiar with the IO dispatcher internals and even though its well documented code there is a lot of it to look through

while investigating coroutines

Flow

API a colleague noticed that there are several operators (e.g.

mapLatest

) still experimental. What would be your recommendation about those? Is it safe to adopt them? Is there typically a migration supported in case of deprecation?

Is it safe to adopt them? Well, the official recommendation would say no. But the unofficial and more reasonable one would say yes, it is safe. The recommended migration will be explained if it comes to that for sure

Hi! I'm trying to understand how to use coroutines in a non-coroutines JS frameworks without using GlobalScope a lot. Today I tried to rewrite application using one GlobalScope and nested

launch

methods so coroutine hierarchy will be structured. But. How to deal with callbacks?

fun main() {
    GlobalScope.launch {
        launch {
            root("main") { div("Hello KVision!") }
        }
        launch {
            root("extras") {
                button {...}.onClick {
                    this@launch.launch {
                        ktorClient.get("/api/users/current") {...} // will not be called
                    }
                }
            }
        }
    }
}

Should I use GlobalScope in case of event listeners like onClick and so on?