`[Flow + LiveData]` Hi, we have been adopting `Flo...

# android

[alex.tavella]

[Flow + LiveData] Hi, we have been adopting Flow on our app and there are still some behaviors that we want to achieve that are a bit unclear. So, our presentation architecture basically consists on archictecture component’s ViewModel producing state in a ViewState class that has its properties exposed as LiveData , which are observed by the View layer. We have a case similar to the following:

internal class HomeViewModel constructor(
    observeSessionAddress: GetSessionAddressFlowUseCase,
    getHome: GetHomeUseCase,
) : ViewModel {
    private val addressStream = observeSessionAddress()
        .distinctUntilChanged()
        .shareIn(viewModelScope, SharingStarted.Lazily, replay = 1)

    private val homeStream = addressStream
        .map { getHome(it.lat, it.lon) }
        .shareIn(viewModelScope, SharingStarted.Lazily, replay = 1)

    val viewState = HomeViewState(
        addressStream.asLiveData(),
        homeStream.asLiveData()
    )
}

internal class HomeFragment : Fragment() {
...
    override fun onViewCreated(
        view: View,
        savedInstanceState: Bundle?,
    ) {
        super.onViewCreated(view, savedInstanceState)
        ...
        with (viewModel.viewState) {
            address.observe(viewLifecycleOwner, ::updateAddress)
            home.observe(viewLifecycleOwner, ::updateHome)
        }
    }
}

The class GetSessionAddressFlowUseCase returns a Flow.
The code works fine, when Fragment is firstly created, it starts observing the address and fetches home content appropriately and also when navigating forward and getting back, we get the previous value without actually triggering getHome again.

The only problem is: by using shareIn I just made homeStream and addressStream hot flows, and after leaving HomeFragment by navigating forward (we replace this fragment and keep in the backstack, so only onDestroyView is called), the hot flow will still be live since HomeViewModel is still alive and hence if we change address on another screen, the getHome use case will still trigger. That may seem harmless at first, but if other devs start following this approach, we might trigger a bunch of expensive operations even if that info is not important to the user at that moment. One alternative is to keep these streams as cold, but after navigating back to the Fragment would trigger getHome again, which is an expensive operation, so that is out of the question.

Any ideas/suggestions?

[Luke]

Try SharingStarted.WhileSubscribed() instead of SharingStarted.Lazily

[alex.tavella]

Wouldn’t that trigger the upstream after resubscribing to the livedata?

[Luke]

I'm not sure I fully understand when you want getHome to be called. I'm thinking maybe you want a StateFlow (using .stateIn() instead)? When subscribing, you get the stored value, and subsequent values. You would need to give an initial value though

[Adam Powell]

try using this operator from the latest androidx.lifecycle alphas: https://developer.android.com/reference/kotlin/androidx/lifecycle/package-summary#flowwithlifecycle

[Adam Powell]

specifically, use it when you're observing the data from your UI contexts. It cancels the upstream subscription when you're out of lifecycle and restart when you come back in, which will in turn give you the expected behavior from SharingStarted.WhileSubscribed

[alex.tavella]

@Luke getHome should be called only if address changes and if there is a subscriber. If the user gets back to the screen and address hasn’t change, getHome should not be called because it probably will yield in the same results obtained previously, therefore calling it again would waste resources.

[alex.tavella]

@Adam Powell as I understood, I could use from Fragment as:

lifecycleScope.launch { 
    viewModel.viewState.home
        .flowWithLifecycle(viewLifecycle, Lifecycle.State.CREATED)
        .collect { updateHome(it) }
}

But after Fragment view lifecycle goes from DESTROYED to CREATED again, the upstream will be triggered again, right?

[Adam Powell]

viewLifecycle will never go back to CREATED from DESTROYED, DESTROYED is terminal and the fragment gets a new view lifecycle instance.

[Adam Powell]

Use viewLifecycleScope.launch { for the initial launch instead, and launch in onViewCreated

[alex.tavella]

Ok, but that wouldn’t trigger my upstream (getHome) every time on onViewCreated ?

[Adam Powell]

tune your usage of SharingStarted/distinctUntilChanged as needed from there; the code in the OP that observes the existing LiveData runs whenever onViewCreated runs already

[alex.tavella]

OP?

[Adam Powell]

original post; the first post in this thread

[Adam Powell]

where HomeFragment observes livedatas

[alex.tavella]

Actually, by doing this, the behavior is exactly as I want:

private val addressStream = observeSessionAddress()
        .distinctUntilChanged()
        .onEach { addressState.value = it }
        .shareIn(viewModelScope, SharingStarted.WhileSubscribed(), replay = 1)

    private val addressState = MutableStateFlow<Address?>(null)

    private val homeStream = addressState
        .map { getHome(it.lat, it.lon) }
        .shareIn(viewModelScope, SharingStarted.Lazily, replay = 1)

Will still keep trying to tune parameters tho