For further actions, you may consider blocking this person and/or reporting abuse
If you are wasting time trying to track down the cause of a crash, it’s time for a better solution. Get your crash rates to zero (or close to zero as possible) with less time and effort.
Try Sentry for more visibility into crashes, better workflow tools, and customizable alerts and reporting.
Read next

Understanding Open Source Developer Support Networks
Vitali Sorenko -

Unlocking Potential: The Benefits of Open Source Developer Patronage
JennyThomas498 -

Navigating the World of Open Source Licenses
ashu-commits -

Discover the Future of Tech: Trending GitHub Projects Revolutionizing AI and Development 🚀
Bruh Buh -
Top comments (4)
Thanks for great "deep dive" series! Applying to typical Android apps:
State tracking works when reads are initiated from
@Composable
functions (not from e.g.onClick
callbacks) and propagates through functions and computed properties, but not regular properties (e.g. adding backing field to_result
in your From push to pull example breaks tracking).Otherwise it's just a one-time read.
Is that understanding correct?
Looks convenient, but IMHO makes it harder to reason about code behavior. We can't say if a piece of code is "reactive" without looking above and below it in the call stack.
This is not a problem for UI code, but I'm thinking about using
State
in ViewModel & even deeper layers, so the call stack might be long.Yes.
That can be true, there are definitely trade offs to this vs expressing reactivity in your types.
Thank you for amazing post. I have a question about derivedState.
To understand more, I made a Conway Game of life with compose.
github.com/EaseTheWorld/game_of_li...
Which is simply,
State<Boolean>
MutableState<Boolean>
. It is toggled by user click.DerivedState<Boolean>
of prev gen's 9 cells.When I put one cell alive in gen0, I expected only gen1 is recalculated and gen2,3,4... are not
because their prev is caching and unchanged.(still dead)
But it turns out gen2,3,4... are all recalculated. I put log in
ChildCell.calculate()
Did I miss something about caching logic in DerivedState?
I ran your WorksheetImpl in android emulator(Pixel 5 API 29) and got same behavior.
I changed first row from 31.50 to 31.5 and expected no calculation for later rows.
but
evalResult
is recalculated for each rows...Any reply would be very helpful.
Thanks for your post!
I'm writing an article about side-effects and faced a question that I cannot answer.
What is difference between derivedStateOf and snapshotFlow.collectAsState?
Both of them observe states that they use. And both can help to reduce counts of recomposition