ContentResolver query Observable

[dpsm]

This is a proposal to implement an Observable that emits a Cursor while the Cursor has next and then closes the Cursor upon completion or failure.

This sounds like something useful that I can contribute with and I would like to hear thoughts before putting something together?

Something like:

ContentObservables.query(PROJECTION, SELECTION, ...).subscribe(
...
onNext(Cursor c) { // Calls once for each position in the cursor };
...
);

[thuytrinh]

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.

[JakeWharton]

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).

[mttkay]

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)

[AndrewReitz]

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

[dpsm]

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

[mttkay]

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.

[dpsm]

@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?

[ronshapiro]

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.

[mttkay]

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

[naixx]

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

[JakeWharton]

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...).

[djensen47]

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

[f2prateek]

Nothing about BackpressureBufferLastOperator is specific to Android either.

[djensen47]

Nothing about BackpressureBufferLastOperator is specific to Android either.

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