Composing-Clocks VS Sesame

Also, in compose I use a savedStateHandle wrapper where this could be avoided by removing the setter, or throwing if set is done on a key that is being tracked.

Some headlines for the app: - MVVM with flow, and with no fragments, no AAC-ViewModels, and no AppCompatActivity - config changes handled manually - UI adapts to landscape or multi-window (with a simple animation) - ViewModels scoped to a screen, nav sub-graph, or the whole app - Koin DI with scopes bound to nav destinations - it saves state - custom view (clock)

If you are looking for a paging library take a look at https://github.com/aartikov/Sesame/tree/master/sesame-loading

I use property delegate that wraps MutableStateFlow. This solution results in minimum of boilerplate code:

My Sesame-property is inspired by MobX. It provides observable mutable properties for core state and observable computed properties for derived state.

My library Sesame Activable works exactly as you described.

Sesame has a navigation component. But this one is supposed to be minimalistic. While Alligator has all the navigation implementation out of the box (passing screen arguments, controlling fragment backstack, animations and so on) Sesame provides only a way to deliver navigation messages. Both approaches has cons and pros. I personally will start my new project with Sesame navigation and copy-pasting some simple navigator like that FragmentNavigator.kt

Hi. I have developed a library called Sesame.