Add bindView implementation and tests

[ZacSweers]

Also updated a couple dependencies along the way

[ZacSweers]

@dlew let me know if you want me to add tests for OnSubscribeViewDetachedFromWindowFirst. I wasn't sure how necessary it is since it's a fairly simple class.

[dlew]

Was this mostly taken from the old RxAndroid repo?

I think it looks good, but I'd like to take it a slightly different direction (implementation-wise). Right now it's lacking a bit in two ways:

1. We have ViewEvent.ATTACH but never actually emit it.
2. Our OnSubscribe has a bunch of logic in it that can be replicated from other operators.

I'd like it if we had a solution that's composed of two steps:

1. An RxBinding-esque way to get Observable<ViewEvent> from a View, completely separate from anything else. (Perhaps maybe even just in RxBinding itself, then we can make this depend on that library).
2. Combine that with takeUntil to automatically unsubscribe after detachment.

[ZacSweers]

Yup, mostly taken from there. If you're open to depending on RxBinding though, I
can definitely do the latter part. RxBinding doesn't have attach/detach
events yet, but Jake says he wants it so I could pull request that over
there first and then update this.

That's also be nice because then there wouldn't be any overlap between view
event implementations.
On Sat, Aug 8, 2015 at 10:23 AM Daniel Lew notifications@github.com wrote:

Was this mostly taken from the old RxAndroid repo?

I think it looks good, but I'd like to take it a slightly different
direction (implementation-wise). Right now it's lacking a bit in two ways:

1. We have ViewEvent.ATTACH but never actually emit it.
2. Our OnSubscribe has a bunch of logic in it that can be replicated
   from other operators.

I'd like it if we had a solution that's composed of two steps:

An RxBinding-esque way to get Observable from a View,
completely separate from anything else. (Perhaps maybe even just in
RxBinding itself, then we can make this depend on that library).
2.

Combine that with takeUntil to automatically unsubscribe after
detachment.

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

[dlew]

I don't mind depending on RxBinding for now. Worst-case scenario we could always spit it out as another module later. But honestly I think most people using RxAndroid will want RxBinding anyways.

[ZacSweers]

Agreed. Opened a PR there for attach events: JakeWharton/RxBinding#76

[ZacSweers]

That PR is in RxBinding now, so I'll update this after its next release! Should I close it for now or just leave it open until then?

[dlew]

Whatever you want to do. It doesn't much matter to me.

[ZacSweers]

Alright, I'll leave it open for now
On Mon, Aug 10, 2015 at 6:17 AM Daniel Lew notifications@github.com wrote:

Whatever you want to do. It doesn't much matter to me.

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

[dlew]

Now that there's a new version of RxBinding out, would this be possible to do?

[ZacSweers]

Yup, I'll update it when I get the chance today or tomorrow.

On Sun, Aug 23, 2015, 7:52 AM Daniel Lew notifications@github.com wrote:

Now that there's a new version of RxBinding out, would this be possible to
do?

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

[ZacSweers]

@dlew rebased and updated with use of RxBinding.detaches()

[dlew]

Nit: Extra newlines.

[ZacSweers]

You want more newlines or to remove this? I was just matching the pattern I thought other functions were using here

[dlew]

Remove - the others don't have an extra newline.

[ZacSweers]

Gah, fixed in b4c72bb

I misread code above it and thought there was a space:

[dlew]

We should add a sample at some point, doesn't have to be here, but if not here then we'll create an issue to track.

[dlew]

Should this be <E> or <? extends E>? I only ask because we're sort of copying takeUntil and that's what they do (again, not exactly sure why since I suck at generics).

[SleeplessByte]

Mimic Observable#takeUntil and use <? extends E>.

Btw, this is the difference between the three:

• Observable<E> an Observable that only outputs E and exactly that.
• Observable<? extends E> an Observable that outputs anything with an upperbound of E (so any descendant of E or E itself).
• Observable<?> an Observable that outputs anything, can't use that here because the Operator (Transformer) expects a type!

[ZacSweers]

Done in e8fdbdb

[SleeplessByte]

👍