1576883: Concurrent recomposition API | https://android-review.googlesource.com/c/platform/frameworks/support/+/1576883 Status:

Merged

. Does this tell us we will have multithreaded composition soon? ☺️

But memoisation (remember, etc.) is a side effect by definition, isn't it? It remembers into some sort of a scoped state.

Remember looks like a side effect, but it is an API internal to Compose, which means that mathematically it can be treated as a return value that Compose. That (along with the invocations of all other composable functions) could conceptually be rewritten by the compiler as a return value that tells Compose what should happen, very similar to the way Flutter and React return elements from their build/render functions respectively. We don't do that in practice for performance reasons, but that's an implementation detail, and we're able to manage the consistency guarantees around those APIs because they are mathematically equivalent. But this is a very subtle/nuanced difference, and it was one of my biggest misgivings about the remember API, because it's hard for most users to understand the difference. The real concern is about any side-effect that impacts data that Compose doesn't control. With regards to libraries that require access to the main thread - yeah, don't use those. If you're using those directly from a composable function, your composable function probably isn't a pure functional transform from data to UI, so you're really not following the rules anyway. All of this should become much better described once we actually have it all working and we can get DevRel to help with figuring out how to make the messaging more understandable, but in the mean time, anything you can do to reduce side-effects and thread-constraints will be a good thing and your future self will thank you.

what libraries can have main thread checks in constructors? I mean other than custom views I can't remember any.

MVICore, MVIKotlin. Plus due to multiplatform , you may want use shared ViewModel. And due to Kotlin Native memory model you will likely require main thread only access. Of course you can lift restrictions for non-native, but I believe it is better to keep the behaviour consistent across platforms.

you can update your libraries 😛

I don't want to update as of now. I think it is common use case to remember ViewModels inside Composable functions. And they may and will often have side effects in constructors. My opinion is that design decision is super error prone and will lead to same situation as with Kotlin Native memory model. When you often shooting you legs and it is very hard to debug.

So devs who will use such libswill simply disable multi-threaded composition :) multi-threaded composition was announced at very beginning. And it is super important feature.

Maybe there could be a solution to satisfy both cases?

What JB says? I heard they planned to rework KN memory model.

Yeah, JB's new memory model will open things up a lot, and you probably don't want to use ViewModels anyway because they aren't MPP, but these are all things that will become more clear once we have working prototypes.

They will rework the memory model but it will require a lot of time. Also people are using ViewModels in MPP already quite a lot. Because ViewModels are nothing more than just an interface with single

onCleared

method. There is

moko-mvvm

and others. Looking forward for multi-threaded composition, but also hope there will be a way to

remember

on main thread.

If you need to interface with main thread-only libraries, doing so from the

*Effect

APIs will continue to meet those expectations. We currently have no plans for a main thread-restricted

remember

, you'll need to

remember

a wrapper object that performs any main thread initialization either via

DisposableEffect

or by implementing

RememberObserver

.

I'm super new to compose, and jumping in a little late here, but just wanted to add that something feels really wrong by using AAC VMs inside of a composable. So far I've only built like 10 composables, but I always try to pass the data it needs into the composable from the viewModel and try not to give the composable a VM directly.

generally yes, but parameters passed have to come from somewhere. If that's some coarse-grained subcomponent of a screen that might be implemented as a fragment pre-compose, it's not necessarily strange to use an AAC VM for its object retention facilities in a composable function playing the same role as that kind of fragment, passing data from the VM down to the other composables it invokes as parameters.