Add support for rx.Single

[dalewking]

Single is the alternate version of Observable and should be supported to automatically unsubscribe based on Lifecycle events as well.

[dlew]

Seems reasonable to me.

BTW, you know that you misspelled "boycott", right?

[JakeWharton]

Also "GitHub"

[dalewking]

Note that it will be slightly more difficult because Single does not actually have a takeUntil operator so you will have to build that support yourself. Not sure how you will differentiate Observable vs. Single because you can't have a type implement both Observable.Transformer and Single.Transformer. You probably either have to have separate methods or your return value from bind methods is an object that has another method to get a Single version.

The workaround for now is do toObservable before the compose call and toSingle after it.

[dlew]

After pondering this for a while, it seems to me that instead of having two different versions - one for Single and another for Observable - that people should just use Single.toObservable() once they want to use compose(RxLifecycle) on a sequence.

Justifications:

1. Single.toObservable() is simple and doesn't have any negative side effects.
2. Often times you'll end up using compose(RxLifecycle) near the end of your chain, at which point it probably would've turned into an Observable by then anyways.
3. Supporting both means two different method names for each, which will be confusing.
4. The lack of takeUntil support in Single seems to be an oversight IMO. That indicates to me that Single isn't fully supported yet.

Any counterarguments?

[bensandee]

+1.

If you're following RxJava 2.x dev discussions it was suggested just today that Single is half-baked in 1.x (it is in fact marked as @Experimental). In 2.x it has more comprehensive support (e.g. a complete list of operators) and when migrating to support that it might be a nice time to revisit this.

[JakeWharton]

migrating to support

Migrating to 2.x means no longer doing Android as it'll be years if Android
ever sees the APIs required to run 2.x.

On Tue, Sep 29, 2015 at 6:26 PM Ben Sandee notifications@github.com wrote:

+1.

If you're following RxJava 2.x dev discussions it was suggested just today
that Single is half-baked in 1.x (it is in fact marked as @experimental).
In 2.x it has more comprehensive support (e.g. a complete list of
operators) and when migrating to support that it might be a nice time to
revisit this.

—
Reply to this email directly or view it on GitHub
#39 (comment).

[dalewking]

Regarding your points:

1. It would likely be a chain of .toObservable().compose(...).toSingle()
2. Oddly I tend to do the compose at the beginning of the chain since I want to stop the chain as early as possible.
3. As I said it wouldn't be easy.
4. I'll agree it is experimental in 1.x as others have said.

[phajduk]

Update: Single has been updated to public API (more precisely to the @Beta) in RxJava 1.1.0.

The lack of takeUntil support in Single seems to be an oversight IMO. That indicates to me that Single isn't fully supported yet.

I believe it's not oversight as there is lack of more features (like retry).
Additionally, are you sure that we should expect takeUntil operator in Single? Single emits only either one value or error. Taking values until some predicate is true have no sense as there will be always one value.

[dlew]

@phajduk If a Single has a significantly delayed emission (as is the case with a network call) then you could takeUntil zero values have been emitted (which is essentially what this library does).

[phajduk]

@dlew You're right. I meant that there is no reason to implement takeUntil(predicate) not takeUntil(observable) which one is of course used in RxLifecycle. There could be also variant takeUntil(single) but it's RxJava issue.

Then 👍 from my side for using Single.toObservable().

[ZacSweers]

I just added takeUntil support to Single with an eye toward this. It'll now emit a CancellationException downstream if it's unsubscribed due to takeUntil, which would allow us to resume if necessary. See ReactiveX/RxJava#3712

Completable is easy, just Completable.amb(other). There's a bug that will be fixed in the next version that currently prevents it from being usable here though. ReactiveX/RxJava#3707

[dlew]

Awesome, we'll get those integrated once they're released.

[ZacSweers]

RxJava 1.1.2 is out and should work for both Single and Completable.

I have a branch open right now that does this, but wanted to get feedback on the API design. Specifically, we can't have overloads of bind that return Single.Transformer and Completable.CompletableTransformer since they still shared the same signature. Options are:

A. Make overrides specifically named (bind -> bindObservable, bindActivity -> bindObservableToActivity, etc).

B. Make separate classes for Single and Completable with the same API. RxLifecycle, RxSingleLifecycle, RxCompletableLifecycle.

---

Open to suggestions. B seems like the cleaner approach, and much of the shared logic can be pulled out into package-local internals.

[dalewking]

I think it would be bad to change any of the existing method names. Another alternative (an A.5) would be to not change existing calls, but add versions of the methods with Single and Completable in the name.

But I agree that B seems the best choice.

[ZacSweers]

A sort of moonshot option C:

generic return type and have the method take a Class to indicate which type it needs. Then create the appropriate transformer and (cast) return it. Loses type safety, but avoids all the duplicate code.