-
-
Save mr-archano/0d1c5885229229bed637 to your computer and use it in GitHub Desktop.
// 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) |
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; | |
} | |
} |
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(); | |
} | |
} | |
} |
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); | |
} | |
} |
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.
Here I was mostly objecting to you claiming that your solution uses composition over inheritance, where there is clearly inheritance baked into your solution. In my solution there is no inheritance necessary, in fact (in the library; naturally you must extend
Activity
orFragment
in your app, but you do that anyways for normal app development). Which one is relying more on inheritance?If your biggest objection is having a single enum for both
Activity
andFragment
events, then there's a simple solution: two enums instead of one. Then there can be no mixing of the two, but it introduces a bit of code duplication (but just as an implementation detail).Your
EventDrivenUnsubscriber
is keeping track of all the lifecycle events that have subscribers which need to be unsubscribed. I'd call that storing state.If you switch to just having a single
PublishSubject
that filters all the lifecycle events... then you've come up with my solution again, only you've wrapped it inEventDrivenUnsubscriber
.Compare either of those with
Observable<LifecycleEvent>
, which doesn't give a crap about who is using it. It just exists to be consumed.But you can avoid making it harder. With just an
Observable
then it's the commononNext()
paradigm that RxJava users are used to. WithEventDrivenUnsubscriber
you're forced to learn a second paradigm.I think this is at the root of our disagreement. I believe in encapsulation and separation of concerns where possible. I think this is one of those cases, and I consider it simpler than the two pieces combined.