-
Notifications
You must be signed in to change notification settings - Fork 25
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
Pass on method annotations to moshi when requesting adapters #83
Comments
Sounds like a reasonable idea. Does Moshi have an API for requesting adapters by type and annotation? |
So there's two ways I'd see this working:
I'm going to explore the second option a bit as I think that would be the ideal case. |
Hmm, looks like there's no way around this without doing some reflection unless we want to create a ton of boilerplate anonymous Annotation classes to simulate instances. AutoValue is cute by basically recording a stringified version of the annotations and writing them in directly, but that unfortunately doesn't help us. Some ideas
|
Alternative idea - borrow AutoValue's trick, but inline the generated annotations onto generated getters or fields for the adapters. Then we at least have a deterministic model for pulling their information. Getters (uglier, but guaranteed to work with annotations since they must be able to target methods) public static final class MoshiJsonAdapter extends JsonAdapter<WithJsonQualifierAnnotationsObject> {
private final JsonAdapter<String> aAdapter;
private final JsonAdapter<List<String>> bAdapter;
public MoshiJsonAdapter(Moshi moshi) {
this.aAdapter = moshi.adapter(String.class,
new LinkedHashSet<Annotation>(getClass().getDeclaredMethod("aAnnotationsHolder")
.getAnnotations()));
this.bAdapter = adapter(moshi, "b");
}
@ReverseList void aAnnotationsHolder() {
}
} Or setters (might be iffy if the target annotation doesn't work with fields for some reason, but no empty placeholder methods!) public static final class MoshiJsonAdapter extends JsonAdapter<WithJsonQualifierAnnotationsObject> {
@ReverseList private final JsonAdapter<String> aAdapter;
private final JsonAdapter<List<String>> bAdapter;
public MoshiJsonAdapter(Moshi moshi) {
this.aAdapter = moshi.adapter(String.class,
new LinkedHashSet<Annotation>(getClass().getDeclaredField("aAnnotationsHolder")
.getAnnotations()));
this.bAdapter = adapter(moshi, "b");
}
} Both could potentially be smarter by accessing the known index directly (e.g. |
I'm leaning toward this:
@swankjesse would be curious to hear your thoughts on all this too |
WAIT this already appears to exist 😨 #24 SoooOoOoOo I guess the question now becomes - is it worth optimizing further per the above? (excuse me while I get this egg off my face) |
I think we can do this the way we do in moshi code gen - require field site target support and bolt them on to the adapter property. We would need to borrow these rules if we can't just rely on moshi's embedded rules directly https://github.com/square/moshi/blob/master/moshi/src/main/resources/META-INF/proguard/moshi.pro#L31-L61 |
Not sure how this would work, but it would alleviate a ton of feature requests for features that this library probably shouldn't have to worry about by deferring to the moshi instance. Similar to how retrofit passes on annotations as well. This should make something like @serj-lotutovici's lazy adapters work with av models
@rharter thoughts? Might not be trivial, but I think it'd be a worthwhile endeavor
The text was updated successfully, but these errors were encountered: