Jorge Castillo
@jorgecastillo.dev
Android at Disney+. Author of Jetpack Compose internals.
👨🏫 Compose course composeinternals.com
📖 Compose book jorgecastillo.dev/book
👨🏫 Compose course composeinternals.com
📖 Compose book jorgecastillo.dev/book
Reposted by Jorge Castillo
The important bit is how data/state is handled (with Views its your responsibility to keep the data held in the app and in the widgets in sync).
September 6, 2025 at 9:14 PM
The important bit is how data/state is handled (with Views its your responsibility to keep the data held in the app and in the widgets in sync).
Agree, but the way I was looking at it:
In most common architecture patterns with Views we ended up rebinding the complete UI every time a ViewModel emitted UI state.
In Compose the data update triggers a selective UI update so it’s the framework deciding what parts of the UI to update, by design.
In most common architecture patterns with Views we ended up rebinding the complete UI every time a ViewModel emitted UI state.
In Compose the data update triggers a selective UI update so it’s the framework deciding what parts of the UI to update, by design.
September 6, 2025 at 9:05 PM
Agree, but the way I was looking at it:
In most common architecture patterns with Views we ended up rebinding the complete UI every time a ViewModel emitted UI state.
In Compose the data update triggers a selective UI update so it’s the framework deciding what parts of the UI to update, by design.
In most common architecture patterns with Views we ended up rebinding the complete UI every time a ViewModel emitted UI state.
In Compose the data update triggers a selective UI update so it’s the framework deciding what parts of the UI to update, by design.