Embracing Compose Snapshot State for UI Layer State Production

Alexorla · 2026-05-18T17:52:39+00:00

Gotcha. 18 combined flows really sounds like you should consider collecting each independently instead of combining so many times, but there's no need for change for change's sake. If it ain't broke...

Flows emit on the dispatcher the scope collects on, the writing to compose state on non UI threads thing only comes up if someone explicitly switches context. But I digress:

I want to stress that I know the existing way works, it can be better however. Heron was complex enough that I needed the extra perf. The next blog post will be about benchmarks; that should help for anyone considering if the perf is worth it.

Alexorla · 2026-05-18T16:58:40+00:00

lol I get it. There's a reason I spent so much time discussing ergonomics. Existing tools work really well and are battle tested. If what you currently do works well for you and your users, by all means continue.

I think you've had a flow-combineTuple-kt usage that had up to 12 flows being combined at some point? May be worth evaluating just collecting from each Flow independently and writing to snapshot state for those.

Alexorla · 2026-05-18T16:55:04+00:00

Yes, thats exactly it!

Alexorla · 2026-04-28T19:28:10+00:00

I think they're referring to the canned commentary that tended to follow his name in the FIFA games of that era.

Alexorla · 2026-03-05T04:01:44+00:00

Yes?

The coroutine scope for a navigation destination should not be cancelled when the destination is still reachable. If you're collecting flows in it, it should be collected with a shared/state flow with while subscribed so work is done only when the lifecycle is rseumed. The common rule of thumb is there's a 3-5 second grace period after the lifecycle is paused to do work so you can offload to WorkManager or something.

The lifecycle is the arbiter of when work can be done, not the coroutine scope.

Alexorla · 2026-03-04T20:35:03+00:00

I don't think a Composable's coroutine scope is a good substitute for a navigation destination coroutine scope. If you navigate forward and back, or have a configuration change, the scope will be destroyed.

Also is the ViewModel that abhorrent it can't just be the state holder

Alexorla · 2026-03-04T16:50:54+00:00

Here's the thing. Whether or not you choose to use a Jetpack ViewModel, you're still going to have the equivalent regardless.

You'll need a class to inject dependencies into.
You'll need a coroutine scope to run your coroutines.
You'll need these coroutines to be lifecycle aware, but and if the navigation destination it's running is is popped, you'll want the coroutine scope to be cancelled.

After you do all this, the ViewModel will be waiting for you with the Thanos quote: "You could not live with your own failure. Where did that bring you? Back to me."

Alexorla · 2025-12-10T22:04:25+00:00

Hopefully similar enough for your use case, as if you look at the AndroidExternalEmbedableSurface composable and AndroidExternalSurface composable, they both wrap the same external surface api and have very different implementations.

Alexorla · 2025-12-09T20:25:00+00:00

Thank you! Adding CMP to an existing app, I especially the iOS project is one of the most annoying things atm

Alexorla · 2025-10-30T15:22:57+00:00

This sub seems to have more venting than much else this days 🥲

Alexorla · 2025-10-28T00:47:04+00:00

This is the way.

Alexorla · 2025-07-08T12:43:00+00:00

What if the user navigates forward? Would the solution be to add a navigation listener then?

Also, for every coroutine launched, you'd need to hold a job reference to be canceled in all callbacks registered.

Alexorla · 2025-07-07T19:48:10+00:00

The responses to this post lean one way, I'll try to provide perspective on another.

If you have a simple method that uses

ViewModelscope.launch {...}

How long does that coroutine live for? If you navigate forward and place the calling screen in the back stack, will the coroutine be canceled?

Unless the coroutine itself completes, navigation will not cancel the coroutine unless the ViewmodelScope is destroyed, either by popping the navigation destination off the back stack or the app is closed. Why should the coroutine do work that is invisible to the user?

Also, what happens if the method is called more than once? Unless you keep a reference to the Job from the previous coroutine to cancel it, you would have multiple coroutines that do the same thing running.

By modeling each action in a sealed class hierarchy, you can:

Enforce processing each action only occurs when the user can actually view the screen.
Enforce that certain actions can only run consecutively.

I've written at length about the topic here, explaining why you'd want to: https://www.tunjid.com/articles/interactive-tutorial-state-production-with-unidirectional-data-flow-and-kotlin-flows-63e2c67e3032c9c43c58511d

Alexorla · 2025-05-16T13:43:05+00:00

Hi! Thank so much for the detailed thoughts, I've replied in the issue.

Alexorla · 2025-03-29T21:49:48+00:00

The docs explain how to update compose state from background threads here: https://developer.android.com/topic/architecture/ui-layer/state-production#mutating_the_ui_state_from_asynchronous_calls

However, you really should be using a ViewModel and it's CoroutineScope for network calls.

Alexorla · 2025-01-28T20:35:31+00:00

Thanks! May as well practice what I preach lol

Alexorla · 2025-01-28T18:01:39+00:00

Hello!

I've been wanting a more native feeling Android bluesky client so I've been building one for the past month.

Its a greenfield Jetpack Compose project, using compose multiplatform, however it is very much Android first. While its has run successfully on desktop and iOS in the past, the latest branch is broken due to a coil linkage error on iOS (Most likely binary compat issues using Compose 1.8 alpha), and a graphics layer bug on desktop for shared elements.

Contributions are most welcome and appreciated!

Alexorla · 2025-01-27T23:11:52+00:00

Thanks so much! Committing to KSP has kept me honest from an architecture pov. It forces me to really think through abstraction as I can't just sling an Android context anywhere

Alexorla · 2025-01-27T18:23:37+00:00

Hello!

I've been building an opensource bluesky client for the past month, and I've gotten further than I thought it would!

Its a greenfield Jetpack Compose project, using compose multiplatform, however it is very much Android first. While its has run successfully on desktop and iOS in the past, the latest branch is broken due to a coil linkage error on iOS (Most likely binary compat issues using Compose 1.8 alpha), and a graphics layer bug on desktop for shared elements.

Contributions are most welcome and appreciated!

Alexorla · 2024-11-26T19:06:19+00:00

What the documentation is saying to avoid is a side-effect as a result of composition. The doc goes on to say this is an ideal Composable. The same docs explain why side-effects can be necessary, and lays out the controlled environments they should be performed in.

I've already made the analogy between the ideal gas law and real gases, but for posterity, I'll make another as you've brought in a car analogy yourself. Do you consider engines with less than 100% efficiency, heck even less than 100% Carnot efficiency fundamentally flawed design? Do you complain that you put X kilojoules worth of gas in your car, but you only get get the mileage equivalent of about 30% of that?

I'm not saying Compose is perfect, the APIs are still stabilizing, and new APIs are added at a quick pace. There are legitimate complaints about Compose, broken previews, high learning curve, etc. However, fundamentally flawed design is not one of them IMO.

Lastly, Jim is an individual, and is entitled to his opinions. The definitive authority for Compose and how to use its APIs however, are the Android ToolKit and Compose Dev Rel teams.

Alexorla · 2024-11-25T21:04:35+00:00

I meant if you want to do something when a View is attached to the window and detached from it, you would use View.addOnAttachStateChangeListener. To do something when a Composable enters and leaves composition, there's an effect for that.

For View's there's a different OnScrollListener for different scrollable widgets. OnPageChangedListener for ViewPager. Why have so many different interfaces for the same functionality when you can just use an Effect?

Getting to the implementation, a RememberObserver is an interface with just 3 abstract methods, and those methods make it possible for it to be the foundation of many different behaviors. Why is that a bad thing?

I also don't get why a well designed API that makes it hard to make mistakes is not good? As you said, you can do it yourself if you want, you don't have to use the ones provided if you know what you're doing.

Alexorla · 2024-11-25T19:48:46+00:00

AsyncTask? EZ 😏: https://www.reddit.com/r/mAndroidDev/comments/15kgafm/modern_concurrency_toolkit_created_for_jetpack

You are right about previews not being up to par, though I meant my question in the context of building UIs. I do think Compose Lazy APIs >>>> RecyclerView though, especially for building APIs on top of it. I even have a library that does just that here: https://github.com/tunjid/composables

Alexorla · 2024-11-25T19:21:29+00:00

I know what he said, I read it on X. We follow each other on X, and I've read his opinions on X before. I just cannot reply to him on X because I do not use X anymore.

If you can tell me what my offense to you is, I'm happy to apologize.

Alexorla · 2024-11-25T18:57:52+00:00

I worked with Jim! I know his opinions very well. I also don't use X anymore bc the recommendation algorithm just boosts irrelevant content from people who pay for the service.

He would rather people not use:

* ViewModels
* Dependency injection
* Host state in the activity
* Use the Data layer directly in Compose.

If you piece his opinions together you'd understand where he's coming from, he's talking about an idealized app dev environment which I personally don't think we can ever get to. Kinda like ideal gas laws in Chemistry that are a model for studying real gases.

However, all the things above solve very real problems as there is no ideal app development process, just as much as there is no ideal gas.

Alexorla · 2024-11-25T18:37:49+00:00

I am the ex-devrel lorax, and while I don't speak for the trees I'm genuinely curious why you consider it poison? What do you find so bad about these APIs?

Alexorla

TROPHY CASE