I’m debugging `collectAsState()` vs `collectAsStat...

# compose

[ursus]

I’m debugging collectAsState() vs collectAsStateWithLifecycle() on a viewmodel state in a app where screens are fragments.

I found out, surprisingly, that they behave the same.

If I push a new fragment, then the current fragment’s view gets destroyed, therefore compose “instance” there dies, and nothing is collected (observed), so no need for the withLifecycle

Guess that is nice and ultimately expected.

However, what I found as well, is that the state collection stops as well when app goes to background (still using collectAsState, not the withLifecycle

How is this possible? Does compose have some implicit hooks into the Activity? Since in this case the fragment’s view does not get destroyed

[Manuel Vivo]

Recompositions stop when the app goes to the background (that’s why you don’t see updates on the screen or logs saying that the composable recomposed) but the underlying flow collection is kept active.

Flows still emit in the background when collectAsState is used. If you use collectAsStateWithLifecycle the flow collection stops until the app is in the foreground again

[ursus]

okay so the subscription is kept open, but there is some check downstream “naively” like this

collect {
	if (inForeground) {
		recompose(it)
	}
}

[ursus]

if so, does it really matter, when the backing flow is a mutablestateflow, which is hot, not cold?

[Manuel Vivo]

If the backing flow is hot, it doesn't matter which API is used. However, it might not be a good idea to rely on implementation details as those could change in the future

[ursus]

hmm, thats true

[ursus]

btw am I correct on the fragment transition assumption? that I don’t see recomposition due to the fragment view being destroyed when replacing the fragment with next one?

[Manuel Vivo]

Not sure how you're using withLifecycle but it's a good practice to use the fragment's view lifecycle when triggering coroutines

[ursus]

nn I mean when my app is still based on Fragments for screens, however now I’m turning the xml view definitions of a given Fragment to compose, i.e. compose is a impl detail of a FooFragment class

[ursus]

and when I push BarFragment (`fragmentManager.replace*), then I see recompositions stop as well, same way as if the app when to background, which we just discussed

[ursus]

so, am I correct in thinking, that this is due to FooFragment’s view being destoyed, due to using fragmentManager.replace,(as opposed to fragmentManager.add ?

[ursus]

also, how does compose know it’s on background? does it have som implicit hooks to Activity lifecycle? (lowercase L)

[Manuel Vivo]

Yes, it has some Android-specific hooks

[ursus]

do you know where exactly in compose source?

[ursus]

is it this?

[dazza5000]

hi manuel - i am having an issue where the state is being collected even though the lifecycle state is lower than minactive state

[dazza5000]

sample code below

[dazza5000]

val homeState by viewModel.homeState.collectAsStateWithLifecycle(
        viewLifecycleOwner,
        Lifecycle.State.RESUMED,
    )

    val context = LocalContext.current
    val nextScreen = homeState.nextScreen
    val fragmentManager = getFragmentManagerFromContext()

    Timber.i("lifecyclestate is ${viewLifecycleOwner.lifecycle.currentState}")
    Timber.i("home is $nextScreen")

[dazza5000]

these are the logs

[dazza5000]

2023-01-13 11:53:07.788 17057-17103 FA                      co.well.wellapp.debug                V  Activity paused, time: 6877042
2023-01-13 11:53:07.928 17057-17057 HomeFragmentKt          co.well.wellapp.debug                I  lifecyclestate is CREATED
2023-01-13 11:53:07.929 17057-17057 HomeFragmentKt          co.well.wellapp.debug                I  home is Deeplink(deeplink=<wellapp://open/journeys>)

[dazza5000]

you can see that even though I have minActiveState set to RESUMED collection is occurring while lifecycle state is CREATED

[dazza5000]

unless I am misunderstanding fundamental about how collectAsStateWithLifecycle works

[dazza5000]

this is how I am calling the composable

class HomeFragment : BaseFragment() {

    override val eventScreenName: Event.Screen = Event.Screen.Home
    private val viewModel: HomeViewModel by viewModel()

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        viewModel.verifyNextScreen()
        return ComposeView(requireContext()).apply {
            setContent {
                HomeRoute(
                    viewModel = viewModel,
                    navController = findNavController()
                )
            }
        }
    }
}

[ursus]

dude

[dazza5000]

yea - am i misunderstanding things?

[ursus]

make your own thread, and, youre not supposed to tag team members

[dazza5000]

think its because the initial value is always emitted regardless of minActiveState - sorry for the noise ❤️ 🍕 🦜