uber / AutoDispose

Automatic binding+disposal of RxJava streams.

Home Page:https://uber.github.io/AutoDispose/

Repository from Github https://github.comuber/AutoDisposeRepository from Github https://github.comuber/AutoDispose

Unsubscribe to ON_PAUSE

dmytroivanovv opened this issue · comments

Library version: 1.0.0

Repro steps or stacktrace:
I have an activity class and a Coordinator class. I passed instance of activity lifecycle through the constructor to coordinator. Then inside init function, i subscribed to lifecycle, when onStart method called. I supposed that this subscription will bind to onStart -> onStop, however it was bind to onResume -> onPause.
Here is a little bit an example from my app.

class Coordinator(
    private val lifecycle: Lifecycle // Activity lifecycle
) : LifecycleObserver {
    private val scope: ScopeProvider = AndroidLifecycleScopeProvider.from(lifecycle)

    init {
        lifecycle.addObserver(this)
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        // This subscription will dispose when onPause happen. But why? I am making 
        // subscribe inside ON_START event
        controller
            .watcher
            .rxProfile
            .autoDisposable(scope)
            .subscribe()
    }
}

Screenshot 2019-08-09 at 19 32 45

No, it is STARTED.

Probably the problem because of backfillEvents(), which set ON_RESUME event if the currentState is STARTED or RESUMED, class LifecycleEventsObservable. Isn't it?

void backfillEvents() {
    @Nullable Lifecycle.Event correspondingEvent;
    switch (lifecycle.getCurrentState()) {
      case INITIALIZED:
        correspondingEvent = ON_CREATE;
        break;
      case CREATED:
        correspondingEvent = ON_START;
        break;
      case STARTED:
      case RESUMED:
        correspondingEvent = ON_RESUME;
        break;
      case DESTROYED:
      default:
        correspondingEvent = ON_DESTROY;
        break;
    }
    eventsObservable.onNext(correspondingEvent);
  }

Could anyone give me feedback?

Can you provide a minimal repro project one of us could build and debug for ourselves?

Can you provide a minimal repro project one of us could build and debug for ourselves?

Sure, here is an example of issue. https://github.com/walker622/auto-dispose-issue

Hey @walker622 - just a bit of feedback, that project is using an old version of autodispose, and quite old versions of other tools. It makes it easier for use to test if we don't have to update the project to modern versions of things just to open it in the IDE. Advice for the future, I'm going to look at this soon

I'm actually unable to build that project as-is even with the build updates

FAILURE: Build failed with an exception.

* What went wrong:
buildOutput.apkData must not be null

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

In order for us to investigate this, please update the sample project to be buildable with the latest stable android studio, android gradle plugin plugin, autodispose version, and arch components versions. Please also supply a build command we can use and exact instructions for where to breakpoint and what to check to reproduce this problem.

I've been digging in separately, and the best answer I can come up with is this:

the current behavior is designed for onCreate(), onStart(), etc callbacks. Unfortunately with those callbacks, they're currently implemented in androidx such that the current lifecycle state is still the previous. That is - state during onCreate() is INITIALIZED, and during onStart() it's CREATED. In LifecycleObservers though, these report CREATED and STARTED during their event callbacks. I think this is an inconsistency in androidx.lifecycle, but unfortunately that's how it behaves right now. If we changed the behavior now, it would break for everyone binding in standard callbacks, so I'm unsure really want to do other than ask for more information from the androidx.lifecycle maintainers.

Closing this out as this is just a nuance of how the lifecycle observer APIs are