Frames have been replaced by snapshots What does this mean I

Question

Frames have been replaced by snapshots What does this mean I didn t see anything about this in the release notes

Adam Powell · Answer

basically a refactoring of how we track transitively observable state and how we do global snapshots of all such state so that we can observe a consistent state of the world across threads

Adam Powell · Answer

the most immediately relevant effect of this is that the not in a frame exception is gone feel free to read write MutableState objects whenever and wherever you like

Leland Richardson [G] · Answer

Also you re right this wasn t mentioned in release notes It looks like < Chuck Jazdzewski G > s notes in the commit got missed because he added an s to `Relnote `

Leland Richardson [G] · Answer

His relnote was ``` The androidx compose frames package has been renamed to androidx compose snapshots The entire API has been redesigned to be mores consistent and more documentation has been added The parts of the API that are likely to still change have been marked experimental State objects returned by `mutableStateOf` and `state` no longer require a snapshot or frame to read from or write to them The Not in a frame exception has been removed State objects can be read from and written to from any thread A snapshot can be taken in any thread that preserves the value of all state objects at the moment the snapshot was taken A mutable snapshot can also be take than allows a snapshot consistent reads and writes of state objects Applying a mutable snapshot is an atomic operation and all threads will see all changes made in the snapshot simultaneously Mutable snapshot can be disposed with being applied A changes made in a disposed mutable snapshot that has not been applied are not visible to any thread Both mutable and read only snapshots can be nested where changes to a nested snapshot are applied atomically to its parent snapshot Collections have been revised to use immutable collections internally and implement more of the MutableList and MutableMap APIs Snapshot collections are created by calling `mutableStateListOf ` and `mutableStateMapOf ` ```

Fudge · Answer

``` Collections have been revised to use immutable collections internally and implement more of the MutableList and MutableMap APIs``` Doesn t that make mutating operations on collections extremely slow And what is the point of implementing with immutable collections if the api is mutable api anyway

Leland Richardson [G] · Answer

This is an implementation detail Both Frames and Snapshot utilized persistent immutable data structures in order to implement the ModelList and mutabelStateList classes The difference now is we are using kotlinx collections immutable instead of our own hand rolled version Immutable collections aren t necessarily slow Some operations can be quite fast and it really depends on what you re comparing it to because different list data structures are going to perform differently for different operations For instance an insertAt 0 on an ArrayList mutable is likely O n but an insert on a LinkedList will be O 1 Both are mutable different tradeoffs Similarly for an immutable list using a persisted data structure many operations like insert push will likely be O 1 The promises that a Snapshotted list takes makes implementing them with an immutable list under the hood the easiest and safest way to provide a mutable interface to that object inside of a snapshot The overall point is to provide the consumer developer with a mutable list API that has all of the snapshot guarantees What its implemented with under the hood shouldn t be of primary concern though secondary definitely