Not sure if I'm using flow + collectAsState correc...

# compose

[Colton Idle]

Not sure if I'm using flow + collectAsState correctly (it's my first time using a Flow, but a library I'm using exposes a flow, so I suppose it makes sense to use it)

Code in thread

[Colton Idle]

My ViewModel

val happy: Flow<Boolean> = prefs.data
    .map { preferences ->
        preferences[isHappy] ?: false
    }

and then I show it via

Text(text = "happy: " + vm.happy.collectAsState(false).value)

The problem is that even after I save to prefs after setting happy to true, when I restart the app I see, for a split second that the text says "happy: false" even though the flowable is actually true.

I think what I'm really after is maybe NOT using a flowable in this case, because happy is critical to my application (think logged in state bool or something) and so I guess I don't actually want this as a flowable? I want my application to wait until I have that first value.

Any help is appreciated!

[K Merle]

You'll have to retrieve default value synchronously or replace DataStore with SharedPreference and use some kind of hot flow lib to handle the actual flow.

[Colton Idle]

Interesting. This seems pretty "bad" but it works!

My ViewModel

val happy: Flow<Boolean> = prefs.data
    .map { preferences ->
        preferences[isHappy] ?: false
    }

val happySynchronous: Boolean = runBlocking {
        prefs.data
    .map { preferences ->
        preferences[isHappy] ?: false
    }
}

Text(text = "happy: " + vm.happy.collectAsState(vm.happySynchronous).value)

[rajesh]

Reading from data store should be pretty fast, even without one notice it. In my app, I use StateFlow with default value which fetch data from datastore.

[Colton Idle]

The problem that this is what I use for "loggedIn" state, and so when the app thinks it's logged out it launches the login screen, even though I'm logged in.

In most cases, yes it would be fast enough, but since I react to it with a navigational event, that's giving me issues.

[rajesh]

That's the same case that I use (tracking loggedIn state) without any problem. And app launches main screen correctly when user is logged in.

[Francesc]

Using runBlocking defeats the purpose of using data store. Data store is meant to avoid the pitfalls of shared preferences, and this gets us back to square one.

[K Merle]

Yea, I had same problem @Colton Idle, seen that runBlocking solution, but as @Francesc said.

[Nikola Drljaca]

@Colton Idle Perhaps you could use stateIn() to convert the flow into a state(hot) flow. Or maybe since the value is boolean you could use .first() on the flow to retrieve one value. Its a terminal operator so it should give you the value right away.

[Michael Paus]

I don’t understand why you provide an initial state on the view side. To my opinion the model should know its initial state and provide it to the view and not vice versa.

[K Merle]

@Michael Paus DataStore also has default value, which is usually hardcoded. So having default value false and flow returning true makes bad UX sometimes.

[Michael Paus]

You can call collectAsState without initializer and let the model provide the initial state. That’s what I normally do.

[Oleksandr Balan]

@Michael Paus I guess you can call collectAsState without init value only on the StateFlow. So you have to use stateIn to convert Flow from DataStore to the StateFlow. But stateIn requires an inital value.

[Michael Paus]

Ahh yes, I do use `StateFlow`s.

[Javier]

There is a stateIn which doesn’t need an initial value

[Oleksandr Balan]

@Javier stateIn without initial value is suspend method, thus it may be not be possible to use when defining a property baked by flow from DataStore.

@Colton Idle I would say in such case the third state should by used and set as initial value. Either null or convert boolean from DataStore to some 3-state enum: unknown / happy / unhappy 🤷

[Javier]

I don’t see the problem, you can just use suspend fun in your repositories and pass the scope

[Javier]

same that you can do with retrofit or ktor requests

[Colton Idle]

Oh. Maybe I should convert to state flow

[Oleksandr Balan]

@Javier Sure, but in the end you want a StateFlow as a property in ViewModel so in Compose you can covert it to the State.

But in property definition (val happy: StateFlow = ...) you cannot use suspend functions.

[Javier]

you can have a stateFlow property in the viewModel, and collect the data store flow without problems, as MVI approach is doing

[Javier]

you can just collect the flow in some vm function and emit in the stateflow for example

[rajesh]

I'm sharing the approach that i use in my app (I'm observing isLoggedIn StateFlow in main activity as it should decide which compose screen to display, but you can use similar in compose screen)

Inside viewmodel

val isLoggedIn = preferenceManager.isLoggedIn.stateIn(
    scope = viewModelScope,
    started = SharingStarted.WhileSubscribed(),
    initialValue = null
)

Inside activity

lifecycleScope.launchWhenCreated {
    mainViewModel.isLoggedIn.collect {
        it?.apply {
            if (this) {
                setContent {
                    MainScreen()
                }
            } else {
                setContent {
                    AuthScreen()
                }
            }
        }
    }
}

[Ian Lake]

Maybe what you actually want is a tri-state - Loading, LoggedIn, and LoggedOut - you really don't want to ever be blocking the UI thread on disk access (and any persisted data is, by definition, disk access, at some level). That way you can delay your UI until you're out of the Loading state

[Colton Idle]

Yeah, that's true. Although, with some of the guidance given by the android 12 splash screen documentation it seems like have "some" small piece of user preference retrieval in the critical path is "fine". Even like just trying to fetch "theme_preference" would bring me right back to this same problem because my designers want to keep showing the splash screen until we know the theme that the user has chosen for our app.