Thread
#compose
    Fudge

    Fudge

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

    Adam Powell

    2 years ago
    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
    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
    l

    Leland Richardson [G]

    2 years ago
    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
    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

    Fudge

    2 years ago
    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?
    l

    Leland Richardson [G]

    2 years ago
    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).