LifecycleObservable.bindActivityLifecycle without inheritance

[nhachicha]

A companion method to LifecycleObservable.bindActivityLifecycle that uses activity lifecycle callbacks provided in API 14 to avoid inheritance

[dlew]

I've always thought it would be cool to have the Subject output all events, then use Observable.filter() to limit which ones you care about. Would get rid of all the == checks throughout the rest of this class.

[nhachicha]

Hi @dlew @JakeWharton
I updated the PR

• Using a filter for LifecycleObservable.bindActivityLifecycle without inheritance #152 (diff)
• Removing boolean LifecycleObservable.bindActivityLifecycle without inheritance #152 (comment)
• Using OnSubscribes LifecycleObservable.bindActivityLifecycle without inheritance #152 (comment)
• Removed author LifecycleObservable.bindActivityLifecycle without inheritance #152 (comment) & useless else LifecycleObservable.bindActivityLifecycle without inheritance #152 (comment)
• Fixed behaviour in LifecycleObservable.bindActivityLifecycle without inheritance #152 (comment)
  We can't rely on Application.ActivityLifecycleCallbacks to detect precisely the first event ex:

    @Override
    protected void onResume() {
        subscription =
                LifecycleObservable.bindActivityLifecycle(this,
                        ViewObservable.clicks(button),
                        LifecycleEvent.START)
                        .subscribe(new Action1<OnClickEvent>() {
                            @Override
                            public void call(OnClickEvent onClickEvent) {
                                Toast.makeText(LifecycleObservableActivityComposition.this,
                                        "Clicked button!",
                                        Toast.LENGTH_SHORT)
                                        .show();
                            }
                        });
         // LifecycleCallbacks will catch this event
        super.onResume();
    }

In this case the first event is onResume which is correct (no need to use booleans or BehaviorSubject.hasValue() to adjust the first event). Now imagine this use case

    @Override
    protected void onResume() {
         // LifecycleCallbacks will not catch this event
        super.onResume();
        subscription =
                LifecycleObservable.bindActivityLifecycle(this,
                        ViewObservable.clicks(button),
                        LifecycleEvent.START)
                        .subscribe(new Action1<OnClickEvent>() {
                            @Override
                            public void call(OnClickEvent onClickEvent) {
                                Toast.makeText(LifecycleObservableActivityComposition.this,
                                        "Clicked button!",
                                        Toast.LENGTH_SHORT)
                                        .show();
                            }
                        });
    }

From a LifecycleCallbacks we don't know what was the first event the user used to bind (could be onCreate could be onStart) in order to apply a correction (i.e emitting previous events).

This is why the method accept this now as a parameter from the user (like LifecycleObservable#bindUntilLifecycleEvent()).

• Add unit tests

[JakeWharton]

Using an Observable in all these callbacks is wasteful in both allocation and performance. I don't see any advantage over

if (activity == activityToMonitor) {
  subscriber.onNext(LifecycleEvent.CREATE);
}

which is allocation-free.

[nhachicha]

Spot on! changed to bindActivityUntilLifecycle

[nhachicha]

@JakeWharton updated PR
Cheers,

[nhachicha]

Ready/Waiting for review @JakeWharton @dlew :)

[JakeWharton]

As part of #172 LifecycleObservable has been removed from future releases. While something like it may come back (and not favoring inheritance) we are focused on making a 1.0 of a core that's fundamental to all users of RxJava on Android.