Converting livedata to stateflow

Question

Android, Kotlin

I have the following livedata in my datasource class, I cannot change this to StateFlow, so need to convert it to StateFlow in my viewModel

val trackingCatalogInitialLoadLiveData: LiveData<Pair<CatalogTracking, Int>> by lazy {
    instantSearchDataSourceLiveData.switchMap { instantSearchDataSource ->
        instantSearchDataSource.initialLoadLiveData
    }
}

In My ViewModel I have the following, and this is the part I am not sure about if this is the correct way to convert LiveData to StateFlow:

 val trackingCatalogInitialLoadStateFlow: StateFlow<Pair<CatalogTracking, Int>> by lazy {
        instantSearchDataSourceFactory.trackingCatalogInitialLoadLiveData.asFlow()
            .stateIn(viewModelScope, SharingStarted.Lazily, Pair(CatalogTracking(), 0))
    }

Then in my fragment I just collect the results

coroutineScope.launch {
        mInstantSearchViewModel.trackingCatalogInitialLoadStateFlow.collect { trackingPair ->
           // code here
    }

Is this the best practice to convert LiveData to StateFlow? Anything I should be looking out for?

I haven't done Android dev in a while, so I can't really say for sure about best practices in this respect. I just wanted to mention that you should be careful with `SharingStarted.Lazily` in `stateIn` - AFAIR it doesn't start the coroutine that updates the state of the stateflow until `collect {}` is called on it. This means that if you only access `stateFlow.value`, it will stay on the initial value forever. Of course it doesn't seem to be your case right here because you do call `collect`, but just something to keep in mind if you're looking for general pitfalls. — Joffrey, Feb 22 '22 at 15:10
You didn't ask about it in your question, but you need to be careful collecting flows in arbitrary coroutine scopes rather than using the `viewLifecycle.lifecycleScope` to be sure you aren't leaking views or trying to update views after they have potentially already been destroyed. — Tenfour04, Feb 22 '22 at 15:47

score 1 · Answer 1 · answered Feb 22 '22 at 15:42

You don't need to use by lazy. asFlow() and stateIn() both create simple wrappers, so they are trivial to call directly in the property initializer.

As @Joffrey said, if you use SharingStarted.Lazily, inspecting the flow's value before it has any collectors will incorrectly show your provided initial value. Since LiveData is hot, starting your StateFlow lazily doesn't buy you a lot. The underlying coroutine that transfers LiveData values to the StateFlow is doing a trivial amount of work.

If you don't need to inspect the value (in most cases you probably don't), then it should be fine to leave it as a cold Flow. Even though the Flow from asFlow() is cold, the underlying LiveData is still hot, so when collectors of the flow collect it, they'll always get the latest value. The main behavior difference would be if your data source does not provide a guaranteed initial value for the LiveData, then a StateFlow gives you the opportunity to emit your provided default initially without waiting for the LiveData to publish its first value.

Converting livedata to stateflow

1 Answers1