I have ViewModel, those are driven by Scope of

Dispatcher.Main

ViewModel has state, and therefore State (

MutableStateFlow<State>

) should only be set on main thread -- to avoid synchronization Is there a way I can assert Scope is on main thread without an android reference? (

Looper.myLooper() != Looper.getMainLooper()

) (To keep my viewmodels KMP ready) Or, should I just not care and read-write (reduce) to StateFlow within a synchronization block?

MutableStateFlow writes are thread-safe, you can do them from anywhere

Yea I know but I reduce them with current value, like this

fun <T> MutableStateFlow<T>.set(reduce: T.() -> T) {
    synchronized(this) {
        value = value.reduce()
    }
}

fun ViewModel.someButtonClick() {
	setState {    
	    copy(counter = counter + 1)
	}
}

you could do it that way, or you could use a compareAndSet loop, which MutableStateFlow also supports. You could also submit change request messages to a single actor responsible for applying changes. Lots of ways to approach it, all of them have various pros/cons/performance implications

as to avoid the synchr. block? because I have looked at compareAndSet before and it does use synchronization within, so not sure what the point of it tbh

private fun updateState(expectedState: Any?, newState: Any): Boolean {
        var curSequence = 0
        var curSlots: Array<StateFlowSlot?>? = this.slots // benign race, we will not use it
        synchronized(this) {
            val oldState = _state.value
            if (expectedState != null && oldState != expectedState) return false // CAS support
            ...

or is that its just a "little bit" of synchronization so its okay?

Depends on how your algorithm is set up. There's nothing particularly wrong with using synchronized in cases like this, but you have to use it consistently anywhere that might write to the object.

Hm, well, react folks told me as to never synchronize on main thread in UI level contstructs, and also unnecessary since main thread has a looper But I wanted the make the Dispatcher.Main a ctor param, as to test easily, but then I need @VisibleForTesting to disable the assertMainThread, which is ughh So, youre saying this is fine on android?

fun ViewModel.someButtonClick() {
	synchronized(this) {
		val currentValue = _state.value
        _state.value = currentValue.copy(counter = counter + 1)
    }
}

Or only if

synchronized

swapped for CAS?

synchronized is fine and android does a ton of it internally where needed, but it's also not magic. Don't do expensive work in synchronized blocks if you can help it. If you synchronize in one place, you have to make sure you synchronize in all of the other places needed to ensure consistency.

Right, thanks! But that brings me back to my first point, I should not synchronize setState in viewModels since 1) not needed because android main thread looper 2) as you said, its potential a foot gun

getting into pure opinion at this point, but I tend to regard imposing main thread requirements on other code as a smell. As you've noted, it's a pain to isolate and test. Sometimes you're working with a framework or library that requires it, (e.g. Android views attached to a window requiring UI thread access, the androidx.lifecycle libraries) and you work around it locally there, but imo when writing an abstraction for use elsewhere, either make it entirely thread-safe, or document that it's not thread-safe and requires callers to use some form of external synchronization. Accessing something only from a single thread is one form of external synchronization, but it's up to the caller at that point.

Interesting. I actually have a sort of a mini framework my self, where I have

Scoped

types, which means such type has lifecycle (init, close) and holds state In this sense viewmodel is just a common name for such Scoped subclass which just happens to be close to the ui And the whole app is just a composition of Scoped instances (Lego bricks) However one thing, why I mandated the main thread state access in viewmodels, was that, people seem to prefer imperatively accessing state like this

fun buttonClick() {
	val state = _state.value

	if (state.whatever) return
	if (state.somethingElse) {
		...
	}
}

Which is nice and readable and very natural for most people. Same reason why I migrated of rx to coroutines -- to give me the language constructs as the api

yeah that's also why Compose's snapshot state works the way it does

If I were to preventively synchronize, it would be either big synchronized blocks, which is not great, or buy into some framework again, actors as you said, MVI or whatever, kind of defeating my point of migrating (edited) 😕