I am trying to make an observable list, where I have a LiveData/StateFlow that emits the list whenev...

# getting-started

[Sam Stone]

I am trying to make an observable list, where I have a LiveData/StateFlow that emits the list whenever the list is mutated. I need the list to be iterable by multiple threads/coroutines. This is my signature:

class ObservableList<T>: MutableList<T> by Collections.synchronizedList(ArrayList()) {

But when I override a function, it gives an error: Abstract member cannot be accessed directly

override fun add(element: T): Boolean {
    val add = super.add(element)
    mObserver.postValue(this)
    return add
}

[Sam]

Sounds like this problem: https://stackoverflow.com/questions/47810973

[ephemient]

you want to delegate to the Collections.synchronizedList() value, not super

[Sam Stone]

@ephemient so this ?

[ephemient]

no, that just leads to recursion

class ObservableList<T>(private val delegate = Collections.synchronizedList(ArrayList())) : MutableList<T> by delegate {
    override fun add(element: T): Boolean {
        delegate.add(element)
    }
}

[Sam Stone]

Right. Thanks! And is `synchronizedList`the way to solve my issue?

[ephemient]

the values posted to the observer may be in a different order than the values added to the list

[Sam Stone]

What about in this class?

class Observable<T>() {
    constructor(initialValue: T) : this() {
        state.value = initialValue
    }

    private val state = MutableStateFlow<T?>(null)
    var value: T
        get() = state.value!!
        set(value) { state.value = value }

    private val observers = Collections.synchronizedList(mutableListOf<suspend (T) -> Unit>())
    fun observe(observer: suspend  (T) -> Unit) {
        val suspendNullable: suspend (T?) -> Unit = { it?.let { it1 -> observer(it1) } } //don't want to expose that we use nulls internally
        observers.add(suspendNullable)
        appScope.launch {
            state.collect(suspendNullable)
        }
    }

    fun removeObserver(observer: suspend (T) -> Unit) {
        observers.remove(observer)
    }
}

[ephemient]

you don't care about the order in that case

[Sam Stone]

What do you mean?

[ephemient]

thread 1:           thread 2:
observe(f) {        observe(g) {
  observers.add(f)
                      observers.add(g)
                      scope.launch()
  scope.launch()
}                   }

that can happen, the same as in your previous version (just the other way around)

[Sam Stone]

Is that a potential concern? If I am relying on the internal data structure to match what the observer was told, will the app potentially crash because of the discrepancy?

[ephemient]

I can't tell what your app logic will do with it. but hopefully you don't care about observer order

[Sam Stone]

I think I get it. So I shouldn’t rely on the current observer being reflective of what is stored in memory, because a new event might be published/the observer will soon be notified of a new change?

[sciack]

Maybe is better a CopyOnWriteArrayList