Support mechanism to exclude some classes about auto-value-gson HOT 17 CLOSED

I prefer @gson over @nogson

from auto-value-gson.

I've just found another reason for this. The gson and moshi extensions don't support generics in AutoValue classes and generate code that won't compile for those. So without opt-in/out you either can't use generics or can't use the gson/moshi extension.

from auto-value-gson.

So I've been thinking about how to do this cleanly, and I think it aligns with something I've been wanting to add for a while.

The approach would basically be to require the annotated class to include a public static method returning TypeAdapter. If that exists, then we generate the TypeAdapter, otherwise we don't.

This means to include the class in the gson extension you'd need something like this:

@AutoValue public abstract class Foo {
  public abstract String a();
  public abstract String b();

  public static TypeAdapter typeAdapter() {
    return new AutoValue_Foo.TypeAdapter();
  }
}

This will also open up the opportunity to generate a single TypeAdapterFactory that will return the appropriate TypeAdapter for any auto-value-gson generated class.

I'm curious to hear any feedback on this idea.

from auto-value-gson.

@rharter do you have any idea for this feature? is it good? I'm happy to make a PR. But wanna discuss with you first. Cheers!

from auto-value-gson.

I do think this is a good idea, I'm just trying to come up with a good way to handle it. We need to play nice with other extensions, so I'd love it if there was a way to include/exclude classes without the need for another extension, but I'm not sure there is.

Are you suggesting an explicit @Gson annotation for inclusion?

@AutoValue @Gson public abstract class Foo {

}

from auto-value-gson.

Yes, it is exactly what I propose. I'd like to add a runtime Module for @Gson annotation only. On main extension library, it should start generate code only if a class has @Gson annotation.

from auto-value-gson.

I think there are two completely different usage scenarios. You either want it to run on all and exclude few or the opposite. Adding @Gson to all your classes can get very annoying and using the static TypeAdapterFactory method as opt-in signal won't work with auto-registration.

What do you think of having two separate artifacts? One works like the current one and has a @NoGson annotation to opt-out. The other one requires explicit opt-in by adding the static TypeAdapterFactory method or adding @Gson.

from auto-value-gson.

First of all, there's no need for a runtime module, as even if there was a @Gson annotation, it would only need source retention and not be needed at runtime.

That being said, @gabrielittner's points are exactly my concerns. In your case, you want to exclude most classed, but explicitly include certain ones. Most of my cases are the opposite, in which most of my classes, benefit from having TypeAdapters. The challenge is that making things easier for one case makes them harder for the other.

As for the idea of having multiple artifacts, that sounds like a management headache and would be confusing to users, so I'm not a big fan of that idea.

from auto-value-gson.

I think two atifacts for two scenarios is quite strange. And it's hard to maintain two different codebases.

I still prefer @gson annotation option because it makes our code clearer, we have to explicit what classes are support Gson. Option 2, with @nogson anntation, adds magic to our code si nce it automatically adds suppoting Gson. And we can forget to add @gson easily when we adding new no gson classes.

from auto-value-gson.

I don't think managing would be a problem, one shared abstract base class and the two implementations would just have to implement applicable(). But you're right that it's probably too confusing.

from auto-value-gson.

There is only one problem with no runtime module is Android Studio cannot understand @Gson annotation when we use it with apt plugin. So we have to include the library with apt and provided. Something like this:

// Do not compile AutoValue dependencies to the app.
apt libraries.autoValue
// Make AutoValue annotation visible to the compiler.
provided libraries.autoValue

But I think it's IDE bug, so it may not effect to our decision.

from auto-value-gson.

It is not an IDE bug. Annotations should be separate from their compilers.

On Wed, Mar 30, 2016 at 11:23 PM Thanh Le [email protected] wrote:

There is only one problem with no runtime module is Android Studio cannot
understand @gson annotation when we use it with apt plugin. So we have to
include the library with apt and provided. Something like this:

// Do not compile AutoValue dependencies to the app.
apt libraries.autoValue
// Make AutoValue annotation visible to the compiler.
provided libraries.autoValue

But I think it's IDE bug, so it may not effect to our decision.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#17 (comment)

from auto-value-gson.

Thanks @JakeWharton for correting my mistake.

from auto-value-gson.

Hm, idk but I'd like to explicitly mark something with @Gson/etc to generate gson mapping. We have a lot of immutable classes and only some part of them needs json serialization.

Imagine you're reading a class and not even realizing that it's going to be jsonable.

from auto-value-gson.

Would also love to see @Moshi :)

from auto-value-gson.

File a bug on https://github.com/rharter/auto-value-moshi/

from auto-value-gson.

I think it is a good idea. It explicit Gson type without adding another annotation.

from auto-value-gson.