adibfara / lives Goto Github PK

I implemented RxJava's scan operator for LiveData like this.

Consider adding it to this library. If you are open to it I could create a PR.

lib version: 1.0.1
arch components libs version: 2.0.0

I'm having some weird issues for anyone who is trying to clone my branch and build it themselves, even CI fails to build the app, however on my machine everything is working fine.

I'm getting the following error when trying to build via CI:

Unresolved reference. None of the following candidates is applicable because of receiver type mismatch

specifically in this line: https://github.com/k0shk0sh/FastHub/blob/fasthub/fasthub-v5/data/src/main/java/com/fastaccess/data/repository/NotificationRepositoryProvider.kt#L17

I went and changed that line to use the Transformations.map() and that fun passed however i'm doing more of map & switchMap in https://github.com/k0shk0sh/FastHub/blob/fasthub%2Ffasthub-v5/app/src/main/java/com/fastaccess/github/ui/modules/main/fragment/viewmodel/MainFragmentViewModel.kt#L36 which causes more related issues.

the full log:

e: /bitrise/src/data/src/main/java/com/fastaccess/data/repository/NotificationRepositoryProvider.kt: (17, 10): Unresolved reference. None of the following candidates is applicable because of receiver type mismatch: 
public fun <T, O> LiveData<List<NotificationModel>>.map(function: MapperFunction<List<NotificationModel>, ???> /* = (List<NotificationModel>) -> ??? */): LiveData<???> defined in com.snakydesign.livedataextensions

i'm not sure if this is a kotlin limitation or something i'm missing.

Thanks

Library's dependencies should be updated to the AndroidX ones in the new version.

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

Not sure if opening an issue is the best place to ask this, but here it goes:

Why are some operations synchronised? Seeing that we can only observe LiveData in the MainThread aren't all operations performed in an Observer already synchronised by nature seeing that they are running on a single thread?

Steps to reproduce...
If I use a nonNull operator,
observe the nonnull Livedata, the data that is not null is emitted
Pause app
Resume app
Data is no longer emitted

My fix for this was to...
restart the observer onActive.

In doing so I could not see a usecase for the init anymore?

Also... Is it ok to use ObserveForever in a livedata? I thought that was a no no.

class NonNullLiveData<T>(private val liveData: LiveData<T>) : LiveData<T>() {
    private val mediatorLiveData = MediatorLiveData<T>()
    private val mediatorObserver = Observer<T> {
        it?.let {
            [email protected] = it
        }
    }

//    init {
//        mediatorLiveData.observeForever(mediatorObserver)
//        mediatorLiveData.addSource(liveData, mediatorObserver)
//    }

    override fun onInactive() {
        super.onInactive()
        mediatorLiveData.removeObserver(mediatorObserver)
    }

    override fun onActive() {
        super.onActive()
        mediatorLiveData.observeForever(mediatorObserver)
        mediatorLiveData.addSource(liveData, mediatorObserver)
    }

}

Hi! This is not really an issue, but rather a potential minor improvement. Would it make sense to slightly modify take like so?

fun <T> LiveData<T>.take(count: Int): LiveData<T> {
    val mutableLiveData: MediatorLiveData<T> = MediatorLiveData()
    var takenCount = 0
    mutableLiveData.addSource(this) {
        if (takenCount < count) {
            mutableLiveData.value = it
            takenCount++

            if (takenCount == count) mutableLiveData.removeSource(this) // <- here
        }
    }
    return mutableLiveData
}

We remove the source when we reach the desired count, instead of continuing to listen to it but ignoring the values. I'm not 100% positive this won't break something that's why I prefer to ask your opinion first. Thoughts?

Hi, it would be nice to have a rx like api for unit testing LiveData...
something like

val testObserver = vm.liveData.test()

// do test setup stuff

testObserver.assertValues(listOf("A", "B"))
.assertNoValues()
.dispose()

I see that minSDK can be set to 15 without any compatibility issues. If you feel it can then I can send a PR.

The implementation of zip and combineLatest assume that the posted value is never null:

However, this is not true:

val x = MutableLiveData<Int?>()
val y = MutableLiveData<Int>()
val r = zip(x, y).observeForever { }
x.value = null
y.value = 42 // CRASH due to null value!

I am preparing a PR to fix that.

In the main README.md file, the imports seem a bit odd:

AndroidX Version

implementation 'com.snakydesign.livedataextensions:lives:1.3.0'
implementation 'android.arch.lifecycle:extensions:x.x.x' // If you are using the AndroidX version, that's fine too, as the Jetifier will take care of the conversion.

Non AndroidX Version

implementation 'com.snakydesign.livedataextensions:lives:1.2.1'
implementation 'androidx.lifecycle:lifecycle-livedata:x.x.x' 

Unless I'm mistaken, there's an inversion. The Non AndroidX Version should not import an androidx API.
Furthermore, shouldn't "androidx.lifecycle:lifecycle-livedata" read "androidx.lifecycle:lifecycle-livedata-ktx"? (not sure about this one, as I'm not sure I understand the reason behind those imports)

Currently the implementation of just checks that the initial value passed in is not null and only then it sets the initial value to the LiveData. This means the following code will result in no emissions and hence the observer will never be called. The expected behavior is for the observer to be called with a null value.

just(null).observeForever(observer)

The "solution" is to remove that null-check. I could submit a PR along with tests for this. But before I do that I would like to know whether there is a reason that null-check is there? Is it intentional?

If the source emits a null as its first emission, distinctUntilChanged operator will filter that emission and will not emit it because the initial value of latestValue will be the same as the emission.

Google's official Transformations package already includes this method, it would be better if distinctUntilChanged called the Transformations instead.

The current implementation of combineLatest only emits if all the two LiveData objects have emitted at least once. I think this is because of the check in this line

I think the check on that line should be a || instead of &&
I need to confirm that I'm not wrong.

Feedback will be appreciated

Hi, would it be possible a combineLatest implementation?

It is perfectly legal to set livedata value to null so null assertion should not be used here.