"Frames have been replaced by snapshots" What does...

# compose

[Fudge]

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

[Adam Powell]

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]

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]]

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:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1326201

[Leland Richardson [G]]

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]

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]]

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).