Refactor the client's generic type parameters #27
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
March 24, 2017 16:33
Ensures that we are able to subscribe to multiple ParseQuery, regardless
of class.
The current tests work fine, because the client is declared as
ParseLiveQueryClient<ParseObject>, so subclasses are accepted. But many
method parameters have to be cast to more specific (or in some cases, less
specific) class types.
The problem with this approach is that you are forced to use the top-level
`ParseLiveQueryClient<ParseObject>` type parameter, which means all other
type parameters must match `ParseObject`, including `ParseQuery<ParseObject>`,
and the callback events all have to take `ParseObject` and then it would have
to be cast to the desired heterogeneous types.
The goal would be that the type parameter is only enforced during subscription,
not at the Client declaration level:
ParseLiveQueryClient client = ...
handle1 = client.subscribe(ParseQuery.getQuery(Subclass1.class));
handle2 = client.subscribe(ParseQuery.getQuery(Subclass2.class));
In its current state, `handle1` and `handle2` would be forced to use an event
callback locked to `<ParseObject>`, and cast the objects to `Subclass1` and
`Subclass2`. OR the only other option is to create two separate
ParseLiveQueryClient objects (which therefore requires multiple websocket
connections).
The way it was written, a single client could only ever be used for a single `<T extends ParseObject>` type parameter. That means to have multiple LiveQuery objects for multiple ParseObject classes, we're forced to create multiple ParseLiveQueryClient objects, each with its own `<T>` type parameter. Since the client itself does not actually require being locked to a single type, we can move those type parameters to individual methods instead.
|
cool this sounds like the right approach =) |
|
Can you update the README docs too? :) |
rogerhu
approved these changes
Mar 25, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The way it was written, a single client could only ever be used for a single
<T extends ParseObject>type parameter. That means to have multipleLiveQuery objects for multiple ParseObject classes, we're forced to create
multiple ParseLiveQueryClient objects, each with its own
<T>type parameter.Since the client itself does not actually require being locked to a single
type, we can move those type parameters to individual methods instead.
The unit test does not fail before or after the test, but this is more of a change of convenience.