Add support for field naming policies about auto-value-gson HOT 20 CLOSED

We finally got around to releasing Gson 2.7... 🎉

from auto-value-gson.

For now I'm overriding AutoValue's abstract generated methods and using @SerializedName annotation. It's ugly and adds unnecessary code lines, but it works until this issue is fixed

 @Override
 @SerializedName("full_name")
 public abstract String fullName();

from auto-value-gson.

I agree this, in addition to the date format, etc, would be useful to have automatically handled in the generated TypeAdapterFactory.

Unfortunately, the FieldNamingPolicy that's set in the GsonBuilder is not available, so I think the only real option we have is to add an optional constructor to the generated TypeAdapterFactory that takes these settings, or a config object containing them.

Gson gson = new GsonBuilder()
  .setFieldNamingPolicy(FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES)
 .registerTypeAdapterFactory(
    Foo.typeAdapterFactory(FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES))))
  .build();

This, obviously, can get quite unweildy, but could be reduced by the solution in issue #19.

from auto-value-gson.

@rharter have you tried that solution? I can't make it work

This is my TypeAdapterFactory

public <T> TypeAdapter<T> create(Gson gson, TypeToken<T> type) {
    Class<? super T> rawType = type.getRawType();
    if (rawType.equals(Foo.class)) {
      return (TypeAdapter<T>) Foo.typeAdapter(new GsonBuilder()
.setFieldNamingPolicy(FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES)
.create());
    }
    return null;
  }

I've checked the Gson object the TypeAdapter uses and I do see the FieldNamingPolicy in Gson.factories, but I don't see where it should be invoked, and jsonReader.nextName() still returns the lowercase name instead of camelCase.

Thanks!

from auto-value-gson.

Yeah, the one in Gson.factories is used internally, but isn't available to custom TypeAdapters, IIRC. Even if it was, we'd have to update the generated TypeAdapter to use it.

from auto-value-gson.

Then there's no way to use a custom FieldNamingPolicy? That's a blocking issue for those of us that do need it.

Thanks anyway for your time, I'll keep an eye on this issue hoping that it gets fixed soon.

from auto-value-gson.

@Maragues I just submitted a PR to Gson to support this.

from auto-value-gson.

Wow, that was quick! Let's see how that works out.

from auto-value-gson.

@rharter I assume this is blocked until Gson publishes a new stable release. Will it be fixed easily once they do?

I've been avoiding the issue up until now, but I guess I'll need to fork the repo and force the fieldNamingPolicy

from auto-value-gson.

yeah, should be fairly straightforward once that's up

from auto-value-gson.

No news about a fix for this issue ?

from auto-value-gson.

What will the generated code for this look like? FieldNamingPolicy expects java.lang.reflect.Fields, so will the generated code have to look up the fields reflectively and keep track of the mapping at runtime?

It'd be nice if there was a way to configure the policy statically, and preserve the current string switch code.

from auto-value-gson.

Just wondering if there has been any progress on this issue?

from auto-value-gson.

Any news? It feels like auto value is not so great after all...

from auto-value-gson.

Maragues' answer is the correct one IMO, sans overriding (not sure what you mean?). Just annotate the property in your AutoValue class. I don't see why auto-value-gson needs to take an opinion on this.

from auto-value-gson.

ICYMI: I opened #124 as a proposal to add this feature, appreciate any feedback.

Biggest limitation (or feature?) is that it doesn't use reflection, so can't handle arbitrary FieldNameStrategys, but it does support all the built in FieldNamePolicys that Gson provides.

from auto-value-gson.

@rharter seems your PR to google/gson has been merged to 2.8.1. When can the impl for TypedAdapter be made to enable setting field name strategy?

from auto-value-gson.

I'm pretty against av-gson taking an opinion here when you can just annotate parameters. This feature of gson in general was always a bit weird to me since it's pretty best effort

from auto-value-gson.

hzsweers it is a convenient tool for auto mapping the names instead of writing serialized annotations, which makes the class less readable i think.

from auto-value-gson.

why not have your backend send you nicer keys? Also - the only thing you need to read are your methods when using the model code from elsewhere, the annotations are an implementation detail, I don't know what readability has to do with it

from auto-value-gson.