When thinking about Compose it& #39;s good to notice that Composables don& #39;t yield actual UI, but "emit" changes to the in-memory structure managed by the runtime (slot table) via the Composer.

That representation has to be interpreted later on to "materialize" UI from it https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="Thread" aria-label="Emoji: Thread">
Emitting these changes takes place via the compile time injected Composer, and it happens when the composable function is executed. That is during composition https://abs.twimg.com/emoji/v2/... draggable="false" alt="⚙️" title="Zahnrad" aria-label="Emoji: Zahnrad">
Layout fixes generic type T to be ComposeUiNode, which is ultimately LayoutNode. In other words compose-ui decides what type of node to use Compose for https://abs.twimg.com/emoji/v2/... draggable="false" alt="💡" title="Elektrische Glühbirne" aria-label="Emoji: Elektrische Glühbirne">
This separation between the in-memory representation of the graph and how it is interpreted allows to integrate with other libraries that use different types of nodes, making it possible to write libraries for desktop, web, or non UI related nodes.
The expectation is Composable functions are fast and restartable, so they simply schedule changes instead of building real UI. Composition traverses the https://abs.twimg.com/emoji/v2/... draggable="false" alt="🌲" title="Immergrüner Baum" aria-label="Emoji: Immergrüner Baum"> executing all Composable funcs to make them emit, ultimately filling up the table. It optimizes & prioritizes the process.
Recomposition happens multiple times and for different reasons, one of them being that the data being read by some elements on the tree has varied. That will make those functions to execute again (restart), and therefore emit again and update the table.
Once composition is done its time for materializing the changes from the table. The runtime delegates this to the "Applier", which is an interface implemented by compose-ui. It traverses the structure interpreting and materializing all nodes https://abs.twimg.com/emoji/v2/... draggable="false" alt="🌲" title="Immergrüner Baum" aria-label="Emoji: Immergrüner Baum">
“Materialize” is the verb used in Compose internals to refer to the action of interpreting the tree of changes to finally yield whatever output we are using Compose for. That is UI in the case of Android. The runtime is agnostic of the Applier& #39;s implementation.
The UiApplier implementation for Android delegates all actions to insert, move, remove or replace nodes to the node itself, a LayoutNode. LayoutNode is part of the UI library and provides the implementation details on how to materialize itself https://abs.twimg.com/emoji/v2/... draggable="false" alt="✏️" title="Bleistift" aria-label="Emoji: Bleistift">

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/node/UiApplier.android.kt;l=22?q=UiApplier&sq=&ss=androidx">https://cs.android.com/androidx/...
This is where setContent becomes relevant. It adds an AndroidComposeView to the top level window decor view which draws all the Compose LayoutNodes to its own canvas. It sets itself as the owner of all the nodes, which is how it connects them with the View system https://abs.twimg.com/emoji/v2/... draggable="false" alt="🔗" title="Link Symbol" aria-label="Emoji: Link Symbol">
Here is where the relevant Android stuff like config, Context, LifecycleOwner, savedStateRegistryOwner, saveableStateRegistry & the actual owner view is linked and provided down the Composable tree via a CompositionLocalProvider, so you can access those things while coding https://abs.twimg.com/emoji/v2/... draggable="false" alt="👩‍💻" title="Technikerin" aria-label="Emoji: Technikerin">
The ultimate result of applying all the changes is that LayoutNodes are drawn to the AndroidComposeView Canvas whenever it receives the dispatchDraw() order, given it is an Android ViewGroup. https://abs.twimg.com/emoji/v2/... draggable="false" alt="✅" title="Fettes weißes Häkchen" aria-label="Emoji: Fettes weißes Häkchen">
Small disclaimer: If you read this https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="Thread" aria-label="Emoji: Thread"> keep in mind all links are pointing to current indexed version in http://cs.android.com"> http://cs.android.com  and that will likely vary over time since it’s all implementation details. That said, the overall spirit and concepts will remain.
I recommend reading this other thread as a continuation of this one. It clarifies the difference between the change list and the slot table. I was not able to dive that deep yet. Thanks @chuckjaz https://abs.twimg.com/emoji/v2/... draggable="false" alt="👏" title="Applaus-Zeichen" aria-label="Emoji: Applaus-Zeichen"> https://twitter.com/chuckjaz/status/1391047032719040514">https://twitter.com/chuckjaz/...
You can follow @JorgeCastilloPr.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: