Hi, I started reading the ‘Foundation’ articles an...
# composeg
gitai
06/14/2021, 10:31 AMHi, I started reading the ‘Foundation’ articles and I’m having some difficulties in understanding how things build up from source code to runtime execution. Specifically, consider the following quotes:
“In Compose's declarative approach, widgets are relatively stateless and do not expose setter or getter functions. In fact, ***widgets are not exposed as objects.***”
“Composition: a description of the UI built by Jetpack Compose when it executes composables.”
“remember (composable) stores objects in the Composition, and forgets the object when the ***composable*** that called remember is removed from the Composition.”
What exactly does the Compose compiler produce when parsing a @Composable annotated function ? Does it generate a class for each function that gets instantiated at runtime as node in the UI object tree ?
Filip Wiesner
06/14/2021, 10:35 AMBut basically the compiler adds "Composer" parameter which holds the node hierarchy
g
gitai
06/15/2021, 1:50 PM@Filip Wiesner Thanks for suggesting this Awesome presentation!! Watching it really cleared things up though two things where brought up that I should probably kindly ask @Leland Richardson [G] to comment on. 1) Just before the last slide, you pointed out that the compiler may generate code that cause user calls to composable to execute on different threads. This suggests to me that each composable function state (or “virtual stack frame” offset if you will) may ultimately get recorded (e.g applied) in the Slot Table starting at some arbitrary index.. How then does a composable function restore its state on second run ? like what maps a composable function to it’s starting offset in the Slot Table (e.g currentIndex) which is said to be allocated linearly if the composable functions execution order is non-deterministic ? 2) What code does the compiler generate to allow a child composable such as Button to communicate state with a parent like Row or vice-versa ? I’m not quite sure how actual widget rendering works, but it seems clear the must be some form of cooperation between the two. So Row calls a composable lambda that just returns a Unit and Button is not defined as an extension on RowScope so the only thing I “see” that gets passed post compilation is a reference to the composer along with key, but that in itself does not explain how one “uses” the other.
3 Views