ContentResolver query Observable about rxandroid HOT 14 CLOSED

Speaking of emitting cursor rows, what do u think of wrapping the cursor with Iterable<Cursor>, then just call Observable.from(new IterableCursor(cursor). The IterableCursor looks like this https://gist.github.com/thuytrinh/0cec49eabac5b7f13f78.

from rxandroid.

Seems like a needless allocation. It also doesn't handle closing.
On Nov 21, 2014 8:15 PM, "Thuy Trinh" [email protected] wrote:

Speaking of emitting cursor rows, what do u think of wrapping the cursor
with Iterable, then just call Observable.from(new
IterableCursor(cursor). The IterableCursor looks like this
https://gist.github.com/thuytrinh/0cec49eabac5b7f13f78.

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

from rxandroid.

I think the Iterator wrapper for Cursor is great. That's what we do in
Propeller. We do auto close cursors too. There's a bunch of reasons why
this is preferable to plain cursors (duality with observables and thus a
symmetric API for sync and async, interface parity with Java collections so
you can for instance apply Guava functions to Cursors)

from rxandroid.

How about something like https://gist.github.com/pieces029/076ddfe7122fd78da5a3?

from rxandroid.

So basically we want an Observable that emits an Iterable once and before completing closes the Cursor?

from rxandroid.

No it's just an adapter. As per the duality principle, anything that's
Iterable is also observable out of the box. That's how observables were
designed... Of course you could also write the iteration code yourself.
Actually, probably that is simpler here since we never need the properties
of Iterable but would just use it to piggy back the cursor.

from rxandroid.

@mttkay then if we do that then something like Observable.from(new IterableCursor(cursor)) will emit the Cursor already while it has next. With that said, all we need to do is close the cursor with something like:

Observable.from(new IterableCursor(cursor))
        .doOnCompleted(new Action0() {
            @Override
            public void call() {
                cursor.close();
            }
        });

Same for error so we always close the Cursor... Did I follow you correctly?

I guess our ContentObservables.query(..) could compose the Observable and add the closing cursor part there?

from rxandroid.

At Venmo we worked on an IterableCursor library, feel free to check it out https://github.com/venmo/cursor-utils. It works well with Rx, as it will emit regular T objects instead of just the cursor again. We could probably create a CursorObservable.from(IterableCursor) which calls the appropriate method (doOnTerminate() I think) to close the cursor.

from rxandroid.

@ronshapiro nice, I wrote almost the exact same thing for our storage abstraction

from rxandroid.

Shouldn't the examples above use Subscription to close the cursor?

from rxandroid.

This has been removed as part of #172 for a future release. Consider building on SqlBrite's ability to query a content resolver (not that I'm biased...).

from rxandroid.

I'm wondering if BackpressureBufferLastOperator from SqlBrite would make sense to include in RxAndroid. Nothing about it seems specific to SqlBrite. No?

from rxandroid.

Nothing about BackpressureBufferLastOperator is specific to Android either.

from rxandroid.

Nothing about BackpressureBufferLastOperator is specific to Android either.

Yeah, I was thinking that too. Add it to RxJava?

from rxandroid.