Support single TypeAdapterFactory for all AutoValue generated type adapters. about auto-value-gson HOT 13 CLOSED

Released as 0.3.0

from auto-value-gson.

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.

from auto-value-gson.

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

from auto-value-gson.

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.

from auto-value-gson.

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

from auto-value-gson.

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.

from auto-value-gson.

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.

from auto-value-gson.

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.

from auto-value-gson.

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

from auto-value-gson.

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.

from auto-value-gson.

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

from auto-value-gson.

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

from auto-value-gson.

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

from auto-value-gson.