Skip to content
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

Closed
rharter opened this issue Mar 28, 2016 · 13 comments
Closed

Comments

@rharter
Copy link
Owner

rharter commented Mar 28, 2016

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 single AutoValueTypeAdapterFactory for all applicable classes.

This would reduce the code needed to configure your Gson instance to the following:

Gson gson = new GsonBuilder()
  .registerTypeAdapterFactory(new AutoValueTypeAdapterFactory())
  .build();
@outlying
Copy link

Are you working on this issue ? I would like to implement this feature.

@rharter
Copy link
Owner Author

rharter commented Apr 15, 2016

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 AutoValueGsonTypeAdapter. It's a mouthful, but we need to play nice with other extensions.

@outlying
Copy link

Thanks, I did not know whether you are working on it or not. I will start next week.

@m6s
Copy link

m6s commented Apr 16, 2016

This does something similar:
https://github.com/evant/gsonvalue/blob/master/gsonvalue/src/main/java/me/tatarka/gsonvalue/ValueTypeAdapterFactory.java
The lookup of the generated TypeAdapters is via reflection, though.

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.

@rharter
Copy link
Owner Author

rharter commented Apr 16, 2016

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.

@m6s
Copy link

m6s commented Apr 17, 2016

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.

@rharter
Copy link
Owner Author

rharter commented Apr 17, 2016

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).

@m6s
Copy link

m6s commented Apr 17, 2016

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.

@outlying
Copy link

@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.

@rharter
Copy link
Owner Author

rharter commented Apr 28, 2016

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 applicable() method so that logic is shared.

@outlying
Copy link

outlying commented Apr 28, 2016

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

@dimsuz
Copy link

dimsuz commented May 11, 2016

Wow, that's great! Can't wait for release now, to drop my huge and boilerplate-ish adapter factory :)

@rharter
Copy link
Owner Author

rharter commented May 11, 2016

Released as 0.3.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants