Allow multiple find/count operations on queries. Expose fromNetwork and isRunning

[natario1]

This:

• Fixes Publicize ParseQuery.fromNetwork() & allow multiple find()/count() #6
• Exposes query.fromNetwork() so users can mimic cache policies when LDS is enabled
• Allows one query to perform multiple find() / count() operations concurrently
• Exposes query.isRunning() (this is a new API, if you think it’s not needed I can remove that)

[codecov]

Codecov Report

Merging #661 into master will decrease coverage by 0.32%.
The diff coverage is 74.07%.

@@             Coverage Diff              @@
##             master     #661      +/-   ##
============================================
- Coverage     52.88%   52.56%   -0.33%     
+ Complexity     1676     1673       -3     
============================================
  Files           131      131              
  Lines         10150    10106      -44     
  Branches       1408     1405       -3     
============================================
- Hits           5368     5312      -56     
- Misses         4340     4353      +13     
+ Partials        442      441       -1

Impacted Files	Coverage Δ	Complexity Δ
Parse/src/main/java/com/parse/ParseQuery.java	73.92% <74.07%> (-3.85%)	80 <9> (-3)
...se/src/main/java/com/parse/ParseKeyValueCache.java	45% <0%> (-2%)	16% <0%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff7c712...9f4083a. Read the comment docs.

[natario1]

Any thoughts about this?

[Jawnnypoo]

So, fromNetwork is just the opposite of fromPin?

[natario1]

Yes! Before this being exposed, if you had a ParseQuery and called query.fromPin() or query.fromLocalDatastore() there was no way to switch back to network from the same query object. This PR allows that and also allows calling find() multiple times from the same object.

[Jawnnypoo]

Should we do what this comment suggests? Deprecate and replace with cancellation tokens?

[natario1]

I don’t know what that means.. We should overload the signature of find, findInBackground, count & countInBackground to allow a CancellationToken ?

[Jawnnypoo]

I think we would have it where each of those operations would return a cancellation token, which you could then use with .cancel(token) which would cancel that specific call. But, I think that goes beyond the scope here and can be addressed in a different PR if desired. 👍

[natario1]

I get your point, but find / count operations already have a return type, how would we pass back a CancellationToken the moment one calls find?

[hermanliang]

Now the cancellation is handled by the SDK itself. I think this suggestion means using the CancellationTokenSource/CancellationToken to transfer the cancellation handler to Bolt. But it is a big work, bunch of related files need to be modified. Another PR to do this job is preferred.

https://github.com/BoltsFramework/Bolts-Android#cancelling-tasks

[natario1]

On top of that , if they wanted to deprecate query.cancel(), they probably meant to have the developer get / pass a CancellationToken and call source.cancel() so the token is notified. See also the comment here.

The same comment is left in ParseFile e.g. here. We might set up a PR that addresses this in both classes. But the only way I see this possible is overloading methods, like

CancellationTokenSource source = new CancellationTokenSource();
query.findInBackground(callback, /* nullable */ source.getToken());
// At any moment..
source.cancel();

It would be useful because ParseFile and with this PR ParseQuery allow multiple concurrent operations, so passing a token to each lets the developer cancel only one operation. If you think it’s needed I’m going to work on it (separately), with the plan

• overload methods to accept a token
• deprecate cancel() and have it fallback to cancelAll()
• create cancelAll() that cancels all currently running task

So the developer either passes a cancellation token to a single operation or uses cancelAll if he doesn’t care.

[hermanliang]

I think it should be implemented internally first, and keep the developer's original behavior. Replace the Task<Void> cancellationToken in ParseQueryController with CancellationToken cancellationToken.

https://github.com/parse-community/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseQueryController.java

interface ParseQueryController {
  <T extends ParseObject> Task<List<T>> findAsync(ParseQuery.State<T> state, ParseUser user,
      CancellationToken cancellationToken);
  <T extends ParseObject> Task<Integer> countAsync(ParseQuery.State<T> state, ParseUser user,
      CancellationToken cancellationToken);
  <T extends ParseObject> Task<T> getFirstAsync(ParseQuery.State<T> state, ParseUser user,
      CancellationToken cancellationToken);
}

Then re-implement all the relevant files and pass cancellationToken to Bolt Task methods (ex. onSuccessTask).

[natario1]

OK, I’ll do that just internally for queries and files then. 👍 going to open a separate PR though, do you think this can be merged?

[natario1]

I made this consistent with ParseFile so it will be easy if later we want to implement CancellationTokens.

[hermanliang]

Does ParseQuery need a method to reset constraints (ex. query.reset())?
Because some query constraints are nonreversible (ex. whereEqualTo(key, value)).
It probably helpful when multiple find queries using different constraints.

[natario1]

That should clear all constraints (order, where etc.) just like new ParseQuery() ? It would be great to have it per-key, reset(key) to undo a key constraint (maybe revert like parse object) but I’m not sure it’s possible. I’ll take a look.

[hermanliang]

Yeah, I just think about the concept of "query group". Developers can use a single ParseQuery instance to do multiple query tasks with different constraints concurrently. Then, they can cancel all tasks using query.cancel() at specific app life cycle (ex. onPause).