```LifecycleEventEffect(ON_START) { println("S...

# compose

[Marcin Wisniowski]

LifecycleEventEffect(ON_START) {
    println("Start")
}
LifecycleEventEffect(ON_CREATE) {
    println("Create")
}

With this code, "Start" will be printed before "Create" (it's ran in-place because the lifecycle is already past the started state), which can be problematic, and doesn't work the same way as the equivalent callbacks in an Android Activity. Code in the ON_START effect can depend on something in ON_CREATE being created.
What's the solution to this?
Ordering the code the other way around of course works, but is not always possible, and the effects may be defined a few functions deep in unrelated code.

[Ian Lake]

These are completely separate effects, so they have no coupling with one another - you'd see the exact same behavior if you add two LifecycleObservers in an activity after the activity is already started

[Marcin Wisniowski]

I get that, it makes sense, I'm just wondering if there is an existing solution/pattern in case the order is important to me.

[Stylianos Gakis]

Add one effect which reacts to all of the events you're interested in.
If they're separate effects, the order between them shouldn't matter this much. In which scenario is it that it matters yet you still can't make it one effect?

[Marcin Wisniowski]

I have a function which internally uses LifecycleEventEffect to send an analytics event. Sometimes it's placed next to other LifecycleEventEffects which sometimes also send unrelated analytics events, and depending on the order the events end up misordered (it looks like things happened before the screen was created).

[Stylianos Gakis]

The timestamp of them is still super close to each other right? Since you know these events come from lifecycle effects which can happen at the same time, is it a problem to infer that those two things happened "together" in those scenarios?

[Marcin Wisniowski]

Yeah, it's not a big deal, but it does add a little bit of confusion, and if someone creates a "show all X events after screen Y was created" search/counter it might miss them, etc.

[Stylianos Gakis]

If you log the "screen X was created" event as a route change listener on the NavController instead, is the order correct then?

[Ian Lake]

Maybe consider wrapping the composable destination we provide in your own wrapper that automatically adds your logging as the first LifecycleEventEffect before calling the content lambda - that's an easy way to guarantee the wrappers around each screen are in the order you want