Support single TypeAdapterFactory for all AutoValue generated type adapters.

[rharter]

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]

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

[rharter]

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]

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

[m6s]

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]

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]

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]

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]

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]

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

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]

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]

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

[rharter]

Released as 0.3.0