I didn't want to pollute the discussion started in RxAndroid/#12 (https://github.com/ReactiveX/RxAndroid/issues/12), so I drafted a solution that collects some of the neat ideas showcased in there.

0. Auto unsubscribe facilities

// NOTE: `OperatorSubscribeUntil` class is borrowed from @dlew's PR (https://github.com/dlew/RxAndroid/blob/dlew/lifecycle-observable/rxandroid/src/main/java/rx/android/lifecycle/OperatorSubscribeUntil.java)

1. OperatorSubscribeUntil

package rx.android;

import rx.Observable;
import rx.Subscriber;
import rx.observers.SerializedSubscriber;

/**
 * Returns an Observable that emits the items from the source Observable until another Observable
 * emits an item.
 * <p>
 * Unlike takeUntil, this choose to unsubscribe the parent rather than calling onComplete().
 */
final class OperatorSubscribeUntil<T, R> implements Observable.Operator<T, T> {

    private final Observable<? extends R> other;

    public OperatorSubscribeUntil(final Observable<? extends R> other) {
        this.other = other;
    }

    @Override
    public Subscriber<? super T> call(final Subscriber<? super T> child) {
        final Subscriber<T> parent = new SerializedSubscriber<T>(child);

        other.unsafeSubscribe(new Subscriber<R>(child) {

            @Override
            public void onCompleted() {
                parent.unsubscribe();
            }

            @Override
            public void onError(Throwable e) {
                parent.onError(e);
            }

            @Override
            public void onNext(R t) {
                parent.unsubscribe();
            }

        });

        return parent;
    }
}

2. EventDrivenUnsubscriber

package rx.android;
 
import rx.Observable;
import rx.subjects.PublishSubject;
 
import java.util.HashMap;
import java.util.Map;
 
public class EventDrivenUnsubscriber<E extends EventDrivenUnsubscriber.Event> {
 
    private final Map<E, PublishSubject<E>> subjects;
 
    public EventDrivenUnsubscriber() {
        this.subjects = new HashMap<E, PublishSubject<E>>();
    }
 
    public <T> Operator<T, T> bindTo(E event) {
        PublishSubject<E> subject = subjects.get(event);
        if (subject == null) {
            subject = PublishSubject.create();
            subjects.put(event, subject);
        }
        return new OperatorSubscribeUntil<T, E>(subject);
    }
 
    public void unsubscribeAll(E event) {
        PublishSubject<E> subject = subjects.get(event);
        if (subject != null) {
            subject.onNext(event);
        }
    }
 
    static class Event {
 
        private final String name;
 
        protected Event(String name) {
            this.name = name;
        }
 
        @Override
        public boolean equals(Object o) {
            if (this == o) return true;
            if (!(o instanceof Event)) return false;
 
            Event event = (Event) o;
            return name.equals(event.name);
        }
 
        @Override
        public int hashCode() {
            return name.hashCode();
        }
 
    }
 
}

3. ActivityLifeCycleEvent

package rx.android;

public class ActivityLifeCycleEvent extends EventDrivenUnsubscriber.Event {

    public static final ActivityLifeCycleEvent ON_PAUSE = new ActivityLifeCycleEvent("onPause()");
    public static final ActivityLifeCycleEvent ON_RESUME = new ActivityLifeCycleEvent("onResume()");
    // TODO add other relevant events here...

    private ActivityLifeCycleEvent(String name) {
        super(name);
    }

}

4. FooActivity

package rx.android.samples;

import android.app.Activity;
import android.os.Bundle;
import rx.Observable;
import rx.android.ActivityLifeCycleEvent;
import rx.android.EventDrivenUnsubscriber;

public class FooActivity extends Activity {

    private final EventDrivenUnsubscriber<ActivityLifeCycleEvent> unsubscriber = new EventDrivenUnsubscriber<ActivityLifeCycleEvent>();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Observable.just("wut wut")
            .lift(unsubscriber.bindTo(ActivityLifeCycleEvent.ON_PAUSE))
            ...;
    }

    @Override
    protected void onPause() {
        super.onPause();
        unsubscriber.unsubscribeAll(ActivityLifeCycleEvent.ON_PAUSE);
    }

}

LoL, the discussion is going pretty serious here, I like it 😄

What I definitely wanted to "claim" is that the final user doesn't need to extend any RxFragment/RxAndroid to make it work, it just needs to delegate to an EventDrivenUnsubscriber<ActivityLifeCycleEvent> (as opposed to other examples in the main discussion showing abstract fragments/activities).

Also when I'm referring to 2 pieces this is exactly what I mean: a user needs to extend from RxFragment and use the LifecycleObservable. Because I reckon that in order to define an Observable<LifecycleEvent> you will eventually need to propose to extend a fragment/activity as part of your solution, because you want to minimise/hide the boilerplate code needed to track the component lifecycle and emit events accordingly. You can avoid it but then you end up with a lot of duplication. Or maybe you can wrap the boilerplate in a helper class, but you will still have 2 pieces.

So basically if a user doesn't want to extend any fragment at all there is no much choice I would say. And now maybe you can get better my point of view.

I'm not here to discuss how to apply SOLID to anyone's code, I perfectly understand how you ended up with an Observable<LifecycleEvent> and I agree that looks pretty neat. I'm not here to claim anything, just to discuss a solution that will be bundled in a library used by people with heterogeneous needs. I'm not even a maintainer, I just enjoy interesting discussions.

Delegating to EventDrivenUnsubscriber<LifecycleEvent> is exactly the same as delegating to Observable<LifecycleEvent>, since in both cases you need to write all the lifecycle handling code yourself... it's just that one is a base class of RxJava and the other is a wrapper that does the same thing.

Your solution still requires all the same extensions of fragment/activity to reduce boilerplate. Unless you're proposing that EventDrivenUnsubscriber requires people to write their own event system, at which point it's basically no better than not having any framework for this at all (e.g., why not just use a CompositeSubscription?).

If your biggest objection is having a single enum for both Activity and Fragment events, then there's a simple solution: two enums instead of one.

Or even better - just create ad-hoc enumeration via custom resource type annotations. Java enums are great, but this method avoids their overhead of using them when their class-based nature is redundant, and allows arbitrary number of new items to be appended from different places.