JSON parser class mapper

[GoogleCodeExporter]

All Environments

I wanted to move over to use google http client. However, there are a few 
things that aren't implemented or maybe I just haven't figured out how this 
works.

1) Is there any way to do parseAs(MyType.class) without requiring the use of 
@Key on the objects? I'm trying to use our entity objects from a server side 
common package on my Android app, but they aren't tagged with @Key. This 
currently works for me using Gson so I'm wondering if this is possible or if it 
will be possible in the future.

2) Is there a way to deserialize polymorphic types? The JSON from the server 
comes back as
"message" : { "discriminator" : "PM" } // picture messages
"message" : { "discriminator" : "GM" } // group messages
I currently do this with Gson and custom deserializer that I register with Gson.

3) All responses from the server come back with a key. For example, if I issue 
a GET to /messages/somemessageid/

I will get back 

{ "message" : { / * all properties of the message object here */ } }

or if I issue a GET to /users/someuserid/

I will get back

{ "user" : { /* all properties for the user object here */ } }

It would be nice if I could specify this mapping so I can still use the 
response.parseAs(User.class)

Perhaps giving a mapping config to json parser/object mapper where you can tell 
it "anything with the key user shoudl be deserialized as User.class"

Maybe this could be some annotation at the class level? For example,

@KeyPath("user")
public class User {

}

Those are just a few ideas. I'm just wondering if you guys are planning on any 
of this in the future before I continue because I'd really like to use the http 
client for this Android app.

Original issue reported on code.google.com by oGL...@gmail.com on 18 Jan 2013 at 10:30

• Merged into: #164

[GoogleCodeExporter]

Thanks for the feedback.

1)
We are not currently considering using properties without @Key.  But it is 
worth filing a feature request on the HTTP project:
http://code.google.com/p/google-http-java-client/issues/entry?template=Request%2
0a%20feature

I'm not sure if we want to support it though, because then you need an 
annotation to specify what you want to exclude, and then you are back to the 
same problem.  But I suppose that for the simple use case where you just want 
to serialize all fields, it would be sufficient.

2)
We are actually investigating the possibility of polymorphic types here:
http://code.google.com/p/google-http-java-client/issues/detail?id=173

3)
I am not sure I understand your request.  Normally you'd just do something like:

class Response {
  @Key User user;
  @Key Message message;
}

Would that suffice?

Original comment by yan...@google.com on 19 Jan 2013 at 2:54

• Added labels: Component-JSON

[GoogleCodeExporter]

Thanks for the response.

1)  Honestly, the Key annotation is not a huge deal for me. I was just 
wondering if you guys were thinking about it. I do agree that not having them 
would essentially yield the same problem.

2) Great. I've worked with both approaches (gson style on Android) and the 
jackson JsonTypeInfo on the the server rest api so either of these approaches 
will work well.

3) So this is exactly what I was thinking. I had to do this in order to get the 
lib to parse our responses. I simply wanted to avoid having to write a bunch of 
response classes for all the different objects that are returned from the API. 
Right now, I'd have to write about 35 response classes to use the parseAs 
method. It would be nice if you could configure this somehow without having to 
write classes for it. This might even be done with annotations or a builder 
type of pattern:

// ignore the bad naming ... mental block at the moment
ex. 

@Key("user")
public class User { @Key private UUID id; /* more stuff here */ }

Then the parser might look parse keys the way it does for @Key on properties 
and know to parse and json objects with key "user" using User.class

The other approach might be

JsonFactory jsonFactory = new JacksonFactory()
    .withClassForKey(User.class, "user")
    .withClassForKey(AccountSettings.class, "accountSettings")
    .withParserForKey(new PolymorphicMessageParser(), "message");

That's just a rough idea, but I'm sure you guys have better solutions.

Thanks for your time

<adrian />

Original comment by adr...@teamhallo.com on 22 Jan 2013 at 7:47

[GoogleCodeExporter]

If you don't mind, I'll drop #1 only because it is something we had debated 
early on when we first designed the system and came to the conclusion that 
requiring @Key was the best way to go.

So I'll narrow down scope of this feature request to #3.  I'm still not clear 
on what you are trying to achieve.  Is this perhaps a case of data wrapping 
that is perhaps best solved with this:

https://code.google.com/p/google-http-java-client/issues/detail?id=164

Original comment by yan...@google.com on 24 Jan 2013 at 2:05

• Changed title: JSON parser class mapper
• Changed state: RequestedFeedback

[GoogleCodeExporter]

Yes I have no problem with dropping #1. I just looked at issue 164 and that's 
definitely what I wanted. Wrapped data like that makes it really easy for iOS 
and Mac apps to consume with Key-Value Coding as seen here 
https://github.com/RestKit/RestKit/wiki/Object-mapping and eliminates the need 
to create a lot of wrapper classes. Thanks for you help and I'm looking forward 
to this!

Original comment by adr...@teamhallo.com on 24 Jan 2013 at 8:19

[GoogleCodeExporter]

Thanks for the feedback!

Original comment by yan...@google.com on 26 Jan 2013 at 5:12

• Changed state: Duplicate