-
Notifications
You must be signed in to change notification settings - Fork 103
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
Support single TypeAdapterFactory for all AutoValue generated type adapters. #19
Comments
Are you working on this issue ? I would like to implement this feature. |
I haven't gotten tarted on this yet, so you're welcome to take it. I appreciate it. Only update I would make is calling itban |
Thanks, I did not know whether you are working on it or not. I will start next week. |
This does something similar: Is there a reason why two projects that combine GSON with AutoValue exist (this one and gsonvalue)? Just asking, because I'm undecided which one to choose, and the single type adapter factory seemed to be the difference up until now. Btw +1 for supporting field naming policies. |
That project is a fork, not an extension, so it won't work with other extensions, or new versions of AutoValue. As for that example, a better approach (no reflection) is to add a second annotation processor that gathers all AutoValue annotated classes and statically generates a aTypeAdapterFactory containing them. |
I believe you are confusing it with https://github.com/evant/auto-parcel-gson. It isn't an extension in the AutoValue sense, but I don't think it needs to be in order to play nice with other extensions or new versions. Anyway, I agree that a statically generated TypeAdapterFactory would be a better solution. Looking forward to that. |
Ahh, you're right. Looking close at that one (on my phone as I'm travelling) are you sure it's using AutoValue? It looks like it's a separate annotation processor entirely that processes a separate annotation (@GsonConstructor/@GsonBuilder). |
It isn't using AutoValue directly. As in hooking into AutoValue's extensions mechanism. It compliments AutoValue by using the same rule set (accessor naming, builder pattern variant). At least that's what I understand. |
@rharter I have small working example https://github.com/outlying/auto-value-gson/tree/feature/AnnotationProcessor Some minor edge cases might not work but I added 'sample' module to present working example of annotation processing. Processor will try to figure out with static method has proper signature (for TypeAdapter) so we don't need method naming convention. |
This looks pretty good to me. I implemented it, largely based on yours, in auto-value-moshi, with a few changes I would suggest for yours. You can check it out here: rharter/auto-value-moshi#30 Biggest difference is using the extension's |
Thanks, I didn't have much time to polish my code, but I am glad I could help in some way. Only question why Moshi ? I respect Square libraries but this is not very common Json lib |
Wow, that's great! Can't wait for release now, to drop my huge and boilerplate-ish adapter factory :) |
Released as 0.3.0 |
The currently TypeAdapterFactory mechanism requires users to add each individual TypeAdapterFactory to each Gson instance in order to de/serialize objects. This can be cumbersome, especially when you have a large number of model objects.
As long as we're already generating code, we could alleviate this by generating a single
AutoValueTypeAdapterFactory
that will serve as TypeAdapterFactory for all AutoValue: Gson generated type adapters. This can use the standard TypeAdapterFactory mechanism to check the class type and delegate the request to the appropriate TypeAdapter.The challenge I see here is that the AutoValue Extension mechanism processes classes serially, meaning this would require an additional annotation process that processes the same
@AutoValue
annotation, checks applicability, and generates a singleAutoValueTypeAdapterFactory
for all applicable classes.This would reduce the code needed to configure your Gson instance to the following:
The text was updated successfully, but these errors were encountered: