Reputation: 17884
I have a GAE/J server that communicates with my Android client via endpoints.
Sometimes I will send an instance to the client via GCM, rather then having the client request it via endpoints. In this case, I need to do the JSON serialize/de-serialize myself instead of letting endpoints do it for me.
This is particularly messy on the client. I want to deserialize into the class that was generated by endpoints, so that I can then use the same code to process the new data regardless of whether I received it via endpoints or via GCM.
I thought that one solution would be to add code to the generated class on the client (e.g. inherit from the generated class), but I find that the class is final and all members are private so working with it is awkward. I don't suppose there is anything I can set in the annotations that will change that?
The other solution would be to use the Google java client library to deserialize into the generated class, the same way that endpoints does. Unfortunately, it appears to me that that library is equally inflexible: I would have to get the GCM data into an HttpResponse object so I can call HttpResponse.parseAs( MyGeneratedClass.class ).
Is there a way to utilize the JSON de-serialzing code of Java client library (so as to deserialize into the generated class which has the @Key annotations) that is more detached from the HTTP request/response code?
Upvotes: 0
Views: 755
Reputation: 17884
Here's a summary of the possible solutions that have developed from this question.
I entered an issue against the Google API java client: "The Java classes generated by Google Cloud Endpoints should not be final" https://code.google.com/p/google-api-java-client/issues/detail?id=802
This has been accepted, targeting Version 1.16.0.
So one solution is to write a class that encapsulates the generated class, and then when 1.16 is released refactor my class into a subclass of the generated class.
Another solution came from @loosebazooka who pointed out that the Google API Client Library actually includes a copy of the GSON library - one which happens to work with the json annotations in the generated classes. This makes it a very convenient way to do my own JSON processing on the generated classes.
I think this is a good solution (so I marked it as accepted) but I'm hesitant to use it myself, because that would bring to 4 the number of different JSON libraries in my app. The 3 I'm already using are:
Maybe one could change the generated endpoints code to use the internal GSON such that adding it wouldn't increase the number of redundant libraries?
Upvotes: 0
Reputation: 2433
The generated client libraries are setup with annotations to use GsonFactory's fromString() function to de-serialize. Be careful with how you serialize on the server side so it is compatible with how deserialization is done on the client side with annotation (maybe use GsonFactory toString() with the same annotations on the server side)
Upvotes: 1