-
Notifications
You must be signed in to change notification settings - Fork 432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Add support for custom Gson instances #645
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we don't have anything particularly to against this, this obviously also does the job. But what do you think about what we have done in the
fuel-moshi
extension?Here is the link to the master version
https://github.com/kittinunf/fuel/blob/master/fuel-moshi/src/main/kotlin/com/github/kittinunf/fuel/moshi/FuelMoshi.kt#L15
In short, in
Moshi
extension, we just expose theMoshi.Builder()
directly. What do you think about it (exposing theGsonBuilder
)? I think it might be just easier and consistent to do the same thing?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't
Moshi.Builder()
mutable? I'm afraid users can end messing things up, ex: you may want to decode same type from different APIs with different formats, I usually prefer to not expose unsafe APIs, but completely support you about consistencyOf course both options may be provided - shared mutable builder and explicit argument.
Also users may fallback to using
gsonDeserializer(Gson)
directly, in this case that function is not needed.This is how my temporary solution currently looks:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true, I think you are right. While we are exposing the mutable builder, it provides the ease of use (with the power of users can mess things up of course). But what you said is correct about exposing the safe API is usually a better choice.
I think it depends on how much compromisation we would love to make. I think maybe exposing 2 APIs options also makes sense and giving flexibility.
As you are obviously one of the users! 😄, WDYT? In whatever way, we come to the conclusion, I will open a PR for
moshi
to standardize this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote for having explicit arguments for
responseObject()
functions and this will be consistent with FuelJackson implementation.I would strongly discourage using shared builder, but ... :) - to keep it consistent - or need to add it to
fuel-gson
also, or deprecate it from other implementations - which is a breaking change: so this is more a decision for project owner, my view on the project is very limited.We can keep it as is for now and it may be added later, when somebody request it: not giving it now - is ok ... but giving it now and getting it back later - will be a breaking change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's good to:
In that case we can communicate to set the default options once and once only -- and we create a new builder each time --
it still has the issue that someone might mutate defaultOptions as the go, but that would be on them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do that then? @lostintime would you mind doing us a favor of providing both options? It could be in separated PR though. We will be taking care of some other extensions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, (was a bit busy these days :)
So, just to confirm - do you want me to add a
val defaultGson = GsonBuilder()
instance and mark it as deprecated from the beginning? or just add default value togsonDeserializer(gson = Gson())
function, and use it everywhere needed?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I meant this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've moved Gson() instance to gsonDeserializer agrument.
I've also changed
gsonDeserializerOf
to:It seemed redundant to me and there was one ore
Gson
instance used, but I'm not sure this is right, or maybe add one more gson argument here also, with default value?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that sounds great with a default value. But I think I am happy to see this getting in. 🎉