on question not sure if you know the reason so in android we

Question

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 lt T gt MutableStateFlow lt T gt readOnly get = this as StateFlow lt T gt ``` now I realised there is a function called asStateFlow but when you go into asStateFlow the function does something different ```public fun lt T gt MutableStateFlow lt T gt asStateFlow StateFlow lt T gt = ReadonlyStateFlow this null ```

mkrussel · Answer

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

Pedro Alberto · Answer

but the google docs they use a simple cast <https developer android com kotlin flow stateflow and sharedflow>

Pedro Alberto · Answer

what would you do < mkrussel> cast or asStateFlow

mkrussel · Answer

I would go with `asStateFlow`

Pedro Alberto · Answer

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 · Answer

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 · Answer

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

mkrussel · Answer

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

mkrussel · Answer

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

Pedro Alberto · Answer

thanks < mkrussel> really nice to share slightly smiling face have a nice day

Adam Powell · Answer

one object is tiny but no object is free slightly smiling face Tiny 1000 is not so tiny anymore 0 1000 is 0

Adam Powell · Answer

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 · Answer

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 · Answer

thanks < Adam Powell> for your opinion we actually decided to go with my simple extension function ```val lt T gt MutableStateFlow lt T gt readOnly get = this as StateFlow lt T gt ``` since we use sharedflow and sateflow everywhere and if we sum up it could have impact on a long run