RxJava Support

[BraunreutherA]

Would it be an option to provide RxJava support? Out there is https://github.com/yongjhih/RxParse but it would be really nice to have this directly in the main sdk.

[grantland]

This is highly unlikely, since doing so will cause a hard dependency on RxJava which would complicate things for developers who do not wish to use RxJava and will be forced to do so.

[BraunreutherA]

It's not to make it mandatory for the user, more as an optional feature. It's like retrofit provides callbacks and Observables.

[grantland]

If done similarly to how it's done in Retrofit, we'd gladly accept a PR, but it's not a priority for us to implement.

[BraunreutherA]

Okay keep the issue open I'll work on it. Just need some review.

[grantland]

Sounds good! Might be good to discuss implementation details first, so that we can agree on the direction before diving into implementation.

[BraunreutherA]

I would do it in a similar aproach as this library does.

public class ParseObservable {

    public static <R extends ParseObject> Observable<R> find(ParseQuery<R> query) {
      ...
    }
}

// use like this:

Observable<ParseUser> users = ParseObservable.find(ParseUser.getQuery());
users.subscribe(user -> System.out.println(user.getObjectId()));

This way all internal functionality of queries stays the same and gets wrapped into an observable on execution.

Another way to do it would be to execute a query as we know and it automatically returns an Observable. This is for sure more work due to overloading all query functions.

[BraunreutherA]

When I think about this, personally the second option would be the better one I think.

[BraunreutherA]

Operations Todo on query would be:

• findInBackground
• getInBackground
• firstInBackground
• countInBackground

Opersations Todo on Object would be: (Don't know how often it's used and if that would be necessary.)

• fetchInBackground
• pinInBackground
• saveInBackground
• deleteInBackground

Operations Todo for LiveQueries

if there are more please comment, I'll add them in this comment

Would have to give them another name -> Eg. findAsObservable, getAsObservable, ...

[BraunreutherA]

Another option would be to extend the Task<TResult> in the Bolts Framework and add a function asObservable() so the excution would look like this:

ParseQuery<ParseObject> query = ParseQuery.getQuery("GameScore");
query
    .findInBackground()
    .asObservable()
    .subscribeOn(Schedulers.io()) // use your own scheduler etc...
    .subscribe(new Subscriber() {
        ...
    });

@grantland Do have an opinion towards this?

[BraunreutherA]

I created a PR at BoltsFramework/Bolts-Android#121

Could you please review it? @grantland

[grantland]

BoltsFramework/Bolts-Android#121 Adds RxJava as a hard dependency to Bolts-Android, which will transitively cause RxJava to be a hard dependency to Parse-SDK-Android.

Would you be able to explain why you'd want RxJava support? Parse doesn't supply any responses in stream format, which is one reason why we use and expose the Task pattern instead of the Observable pattern as Tasks are asynchronous single results and Observables are asynchronous streams of results.

If you're looking to easily integrate Parse with your RxJava streams, it might be better to implement TaskObservableExtensions to easily convert between Task and Observables externally to both libraries to prevent any additional hard dependencies.

[BraunreutherA]

Hi, thanks for the review. I think RxJava adds a nice unified interface for network calls. If there are for example calls that are giving a stream response it's nice to have every response as observable, especially with the new single and completable options.

I implemented my own layer now so I think you can close the issue. Thanks!

[grantland]

Normal network calls are asynchronous single results, which is why we chose to use the Task pattern over the Observable pattern.

Since you've resolved this on your own, I'll be closing this task.