on question not sure if you know the reason: so in android we use StateFlow and usually we use Muta...

# coroutines

[Pedro Alberto]

on question not sure if you know the reason:
so in android we use StateFlow
and usually we use MutableStateFlow
but the fragment only has the readonly
so we created a function like this

val <T> MutableStateFlow<T>.readOnly
    get() = this as StateFlow<T>

now I realised there is a function called asStateFlow()
but when you go into asStateFlow the function does something different

public fun <T> MutableStateFlow<T>.asStateFlow(): StateFlow<T> =
    ReadonlyStateFlow(this, null)

[mkrussel]

The ReadonlyStateFlow is so consumers of the flow cannot cast back to MutableStateFlow and change the values. Similar to unmodifiableList in Java.

[Pedro Alberto]

but the google docs they use a simple cast
https://developer.android.com/kotlin/flow/stateflow-and-sharedflow

[Pedro Alberto]

what would you do @mkrussel? cast or asStateFlow

[mkrussel]

I would go with asStateFlow

[Pedro Alberto]

ok it’s funny cus there docs also have comments like

// Backing property to avoid state updates from other classes
    private val _uiState = MutableStateFlow(LatestNewsUiState.Success(emptyList()))

[mkrussel]

But the cast would be a bit more performant and if you trust the consumers not to cast back then it would be just as safe

[Pedro Alberto]

that’s why I’m asking cus the thing is per state and shareflow we would create an extra object

[mkrussel]

The backing property is needed for both solutions. One is more paranoid then the other, but both accomplish the desired goal.

[mkrussel]

My thought is one object is tiny, but others are more conservative about memory.

[Pedro Alberto]

thanks @mkrussel really nice to share 🙂 have a nice day

[Adam Powell]

"one object is tiny" but no object is free. 🙂 Tiny * 1000 is not so tiny anymore. 0 * 1000 is 0.

[Adam Powell]

On mobile, "little" CPU cores execute instructions in order. Indirection is a lot more expensive than it looks. Performance death by a thousand cuts because all of your code is just a little bit inefficient is very real.

[Adam Powell]

When doing the more efficient thing is no more cumbersome than being inefficient, there's no good reason not to form and exercise good habits.

[Pedro Alberto]

thanks @Adam Powell for your opinion we actually decided to go with my simple extension function

val <T> MutableStateFlow<T>.readOnly
    get() = this as StateFlow<T>

since we use sharedflow and sateflow everywhere and if we sum up it could have impact on a long run.