```LifecycleStartEffect { //start thing ...

# compose-android

[Colton Idle]

LifecycleStartEffect {
//start thing
            onStopOrDispose {
//stop thing
            }
        }

is now deprecated to use without a key on the effect. My thought was that this is roughly an equivallent to activity's onStart. So what would the right key here be?

Is LifecycleEventEffect(Lifecycle.Even.ON_START) the better equivallent?

[Jonathan]

Wouldn’t a key of Unit or whatever object you’re enacting inside of the effect be good?

[Ian Lake]

Do you DisposableEffect(Unit) a lot too? Same thing applies here

[Ian Lake]

You really don't want to be // stop thing on a different instance than you // start thing on. By using it as a key, you ensure that whenever the key changes, the old instance is `onStopOrDispose`'d and then the new instance is `// start thing`'d

[Colton Idle]

Do you DisposableEffect(Unit) a lot too? Same thing applies here

Nope. I try not to use side effects, and can't say I remember the last time I used DisposableEffect.

In a typical use case of using hilt + nav3 + VMs would you suspect that a "Screen" level Composable would have a LifecycleStartEffect with the VM as the key?

[Ian Lake]

Like Jonathan said, the key should be whatever you are acting on inside the effect

[Ian Lake]

If you are calling VM methods in the start and stop, yes, the VM would be an appropriate key

[Colton Idle]

Yeah. that makes sense. i guess to me im just drawing parallels to Activities and fragments and their lifecycle methods.

now in a compose first world with nav3 I was just a little intrigued to see that I couldn't just do LifecycleStartEffect { (omitting a key)

[Ian Lake]

It is really more about forcing you to think about what is happening in between the start and the stop. If the objects you operate never change between the start and the stop, then it doesn't matter if they are keys or not. But if any of them are mutable or have a shorter lifetime, then you can't do the onStart on one instance and an onStop on a completely different instance. Keys make sure that the two events are always a pair, always operating on the exact same set of keys for both operations

[Ian Lake]

That's precisely why it isn't called onStop, but onStopOrDispose - that callback fires when the keys change or when the whole effect leaves composition too so you can guarantee that the cleanup actually happens

[Ian Lake]

If you don't have operations that need to be paired like that, then LifecycleEventEffect is much more likely to be the tool you should actually be reaching for and exactly why we offer the unpaired effect API at all

[Colton Idle]

thanks Ian! that was extremely helpful!