Closed vanniktech closed 8 years ago
Thats an interesting consideration. I hadn't considered that you might want to serialize and deserialize differently, meaning you can't serialize the object and get the same object back. I have a few reservations about this.
First, I think the proposed terminology could be better. The JSON serialization doesn't really have anything to do with sending or receiving data, so I think that would be better as @SerializeOnly
and @DeserializeOnly
.
Secondly, I'm wondering whose job this is. Should this be supported in auto-value-moshi or Moshi itself. I'm hesitant to change the expectations of Moshi in the extension. I wonder if @jakewharton or @swankjesse have any thoughts on the matter.
@rharter there's also an issue over at moshi https://github.com/square/moshi/issues/141
One solution is to think of these as independent types: ReadableValue and WriteableValue.
I agree with your proposed terminology. Yours is a lot better. About your second concern I'm happy to send a PR to either repository as I'd like to move away from Jackson and use Moshi instead.
Do you need to send a PR? For your example I’m proposing this:
@AutoValue
public abstract class SendableValue {
@Json(name = "name") String name();
@Json(name = "foo") String foo();
}
@AutoValue
public abstract class ReceivableValue {
@Json(name = "name") String name();
@Json(name = "bar") String bar();
}
This way I'd have three classes which I'd need to potentially change if there's a new property. SendableValue
, ReceivableValue
and also my Model
class. Every time I want to send my model to the server, I'd also need to create an instance of SendableValue
class and for receiving it a ReceivableValue
and then afterwards transform it back to my Model
class.
With having the above mentioned feature I'd only need to make changes to my model class. Plus I'd save the complete transforming part.
I also have the same issue.
@vanniktech Did you find a better workaround or are you currently using what @swankjesse suggested?
Nope I didn't find a better workaround yet though this has become less of a priority for me otherwise I probably would have pushed a version with #41 out as a fork.
Closing since Lazy Adapters are providing custom Adapters for these cases which also work nicely with this project.
Unfortunately we have a backend which is very restrictive. We are only allowed to send certain fields. Also there are fields which the server sends us but we're not allowed to send them back. On top of that we can't request a backend change.
API proposal:
The annotations need to be defined from the consumers and the processor will just check for name equality. (Same way auto-value-redacted works)
If you're open for this, I'm more than happy to send a PR for this.