Code from https://github.com/Shopify/livedata-ktx/blob/master/livedata-ktx/src/main/java/com/shopify/livedataktx/PublishLiveDataKtx.kt:

   override fun observe(owner: LifecycleOwner, observer: Observer<in T>) {
        val observeSinceVersion = version
        val wrapper = observerWrappers.getOrElse(observer, Observer {
            if (!isPublish || version > observeSinceVersion) {
                observer.onChanged(it)
            }
        })
        observerWrappers.putIfAbsent(observer, wrapper)
        super.observe(owner, wrapper)
    }

    override fun observeForever(observer: Observer<in T>) {
        val observeSinceVersion = version
        val wrapper = observerWrappers.getOrElse(observer, Observer {
            if (!isPublish || version > observeSinceVersion) {
                observer.onChanged(it)
            }
        })
        observerWrappers.putIfAbsent(observer, wrapper)
        super.observeForever(wrapper)
    }

    override fun removeObserver(observer: Observer<in T>) {
        observerWrappers.get(observer)?.let { super.removeObserver(it) }
        observerWrappers.removeIfPresent(observer)
    }

When we call observeForever(), all looks good and calling removeObserver() with same Observer working as expected.

But if we call observe() and later lifecycle move to Destroyed state, system call removeObserver() with wrapped Observer, and we try to find it in observedWrappers among non-wrapped observers. Pair instances with weak references to observers just accumulated in array until livedata instance not GCed.

I don't know clear solution of this problem, suppose we can check wrapped and non-wrapped observers both when removing.

Hi, I want to remove the @Suppress("DEPRECATION") at LiveData.kt

I want to know why deprication of SupportMediatorLiveData#observe() is suppressed.

I think It's better that showing an depricated warning when using the methods above, because Removable has a method removeObserver() to remove an observer but that does not work since removable has a different observer from the one actually observing.

And I also want to confirm that the reason you are depricating the method is what I mentioned above.

thank you in advance.

Overload resolution ambiguity all this function match

fun <T, R> LiveData.map(mapper: (T?) -> R?): LiveData = createMediator(this, MapExt<T, R>(mapper))
fun <T, R> SupportMediatorLiveData.map(mapper: (T) -> R): SupportMediatorLiveData = createMediator(this, MapExt<T, R>({
return@MapExt mapper(it!!)!!
}))

Shows error on using map extension function chaos in choosing map function .

There are places where MutableLiveData is required, for example in two way data binding. It may be better to make MutableLiveDataKtx a subtype of MutableLiveData as these dependencies are hard to change. Downside of this will be code duplication and the fact that MutableLiveDataKtx would not be subtype of LiveDataKtx anymore. I can make a pull request if you consider this as a good idea.

Just curious if 19 is a requirement for this lib. If not, mind lowering it to 16 to reach ~5% more people?

No worries if you'd rather not, I think I should be OK with a fork.

Thanks for the lib!

The LiveData<T>.debounce(delayMillis: Long) extension relies on the Handler class, which makes view models difficult to test without Robolectric.

A possible solution is to wrap Handler with an interface and provide an API for overriding the default implementation. Something similar to RxJavaPlugins

Hi

• 1) what improvement has version 3.0.0?

• 2) why need MutableLiveDataKtx instead MutableLiveData?

• 3) In version 2.0 we has great extension observe without Observer

livedata.observe(this) {it ->

}

In version 3.0 observe without Observer is gone =(
We have now only ugly

.observe(lifecycleOwner, Observer { result ->

})

• 4)

In version 2.0 I has unpleasant bug in android studio,
My breakpoint is skipped by android studio in extension observe, but code in worked

livedata.observe(this) {it ->
// here breakpoint
}

but common way work fine
.observe(lifecycleOwner, Observer { result ->
// result is non-null and always true
})

Failing test:

    @Test
    fun `single reattach`() {
        val liveData = SingleLiveData<Int>()
        val actual = mutableListOf<Int?>()
        val observer: (t: Int?) -> Unit = { actual.add(it) }
        
        liveData.observe(this, observer)
        liveData.value = 1
        liveData.removeObserver(observer)
        actual.clear()
        liveData.observe(this, observer)
        liveData.value = 2
        
        val expected = listOf(2)
        assertEquals(expected, actual) // ERROR: actual is [2, 2]
    }

The same test is passed by the original SingleLiveEvent: https://github.com/googlesamples/android-architecture/blob/dev-todo-mvvm-live/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/SingleLiveEvent.java

Common use-case that leads to this:

1. The view is subscribed to SingleLiveData and gets an event
2. The view is resubscribed (navigate to a different screen and come back)
3. The next event is received twice.

Create a combineWith operator as follows:

• Should accept 2 source LiveDatas
• Should accept a mapper function, such that f(X?, Y?) -> Z?, where X and Y are the types emitted by the sources
• Should return a LiveData<Z?>

Supertypes of the following classes cannot be resolved. Please make sure you have the required dependencies in the classpath:

class com.shopify.livedataktx.SupportMediatorLiveData, unresolved supertypes: androidx.lifecycle.MediatorLiveData

What is wrong?

From the definition of extension function LiveData<T>.nonNull() the result type will be SupportMediatorLiveData<T>:MediatorLiveData<T>:MutableLiveData<T> that seems wrong as initial LiveData was immutable.

First of all, nice work on this. I started doing something similar and came across your work.

I have some questions about some of your implementation details.

I noticed you use a nullable value in MediatorObserver:
https://github.com/henrytao-me/livedata-ktx/blob/bebbc7c3d18702d0e074e0643895d80d55d8fe29/livedata-ktx/src/main/java/me/henrytao/livedataktx/LiveData.kt#L148

I don't think this is necessary. My guess is you did this because of this line:
https://github.com/henrytao-me/livedata-ktx/blob/bebbc7c3d18702d0e074e0643895d80d55d8fe29/livedata-ktx/src/main/java/me/henrytao/livedataktx/LiveData.kt#L159

The compiler would otherwise complain because of the Observer interface function argument is annotated with @NonNull. Because this is coming from java this is needed. Seeing you are using Kotlin here we could just cast to IN (in this case). Like this:

mediator.addSource(source, Observer { observer.run(source, mediator, it as IN) })

We can do this because the type we pas in from Kotlin is already nullable so you don't have to check for non-null in the calling code.

this replaces the following:

val liveData = MutableLiveData<Int>
val mapped = liveData.map { it?.let{ it.toString() } }

with:

val liveData = MutableLiveData<Int>
val mapped = liveData.map { it.toString() }

This should still work fine if you have nullable types in Kotlin:

val liveData = MutableLiveData<Int?>
// val mapped = liveData.map { it.toString() } <-- this wouldn't work
val mapped = liveData.map { it?.let{ it.toString() } }

What's your thoughts?

Edit:
I've went a head and created a PR with these changes for you to take a look at.