the difference in timing between

DisposableEffect

and

LaunchedEffect

comes from coroutine dispatch.

LaunchedEffect

is doing a

CoroutineScope.launch

in response to

onRemembered

, and it doesn't start running immediately, it runs once the associated dispatcher schedules and runs it. On Android that means on the main thread after the current frame is done being processed

the launched

Job

is `cancel()`ed in

onForgotten

, just as

onDispose

runs in

onForgotten

you noted that recomposition is what computes what left and entered the composition and then those are resolved after recomposition is complete in a footnote but imo that's kind of an important part of the mental model; pitching it as a strange behavior that you just have to memorize in the takeaway sections is kind of a disservice, I think, since it's that mental model of, "compute changes, then apply changes" that leads to the ordering: forget all outgoing things in LIFO order to provide deterministic destruction semantics, initialize all incoming things in FIFO order to provide deterministic init semantics, then run side effects to apply changes to anything fully initialized by RememberObservers

and you can create nested chains of them:

val inner = remember { InnerObject() }
DisposableEffect(inner) {
  inner.init()
  onDispose { inner.dispose() }
}
val outer = remember(inner) { OuterObject(inner) }
DisposableEffect(outer) {
  outer.init()
  onDispose { outer.dispose() }
}

since the

onForgotten

calls run in LIFO order,

outer

will be disposed before `inner`; if

outer.dispose()

requires

inner

to still be valid - a fairly common setup - then everything Just Works and survives refactor/extract function on the code above. The ordering is based on order in the composition, not within a single composable function.

as a consequence of that, the recommendation in the article to push effects to the end of a composable can be kind of dangerous, as it means your effects will be ordered to init after child composables you call and dispose before them

now one of the reasons we don't talk a lot about

RememberObserver

is that its semantics can be kind of unexpected if you aren't familiar with how other parts of compose works

in particular, RememberObservers are more or less refcounted within a single composition. Something gets

onRemember

when it is remembered in one or more places in a single composition, and

onForgotten

when it was previously remembered in a composition but no longer appears anywhere within it.

This gets affected by a few things: 1) it's not always clear to a developer where they're dealing with one composition or several. If the same object is remembered in multiple compositions, it will get multiple calls to

onRemembered

2) it's not always clear to a developer where compose is remembering something on their behalf, independent of specific

remember

calls. For example, compose internally remembers the parameters to composable function invocations - it has to, otherwise how would it be able to check new parameters vs. old to determine whether a composable can skip? This counts toward that refcount within a composition.

because this can get complicated, it's generally best practice not to let references to objects that implement

RememberObserver

escape from where they're deliberately `remember {}`ed. Especially on Android, developers are used to optimizing object allocations by having objects do multiple duties, implementing several interfaces, but passing a reference to one of those interfaces elsewhere. When working with

RememberObserver

that can have consequences.

If I have the following:

interface Thing {
  fun doStuff()
}

private class ThingImpl : Thing, RememberObserver {
  // ...
}

then as a developer, if I have a

Thing

I don't know that it's going to have some potentially strange behavior if I ever pass it as an argument to a composable function.

so we stick with, "probably don't do that unless you really, really know what you're doing" 🙂

and the intro guidance focuses on

DisposableEffect

and

LaunchedEffect

instead, since it's much harder to get into these cases when using those higher level APIs

(and we should probably put something about that more front and center on d.android.com too)

That suggestion is mainly for the first run of the code.