Parse JSON into Java objects instead of JSONObject

[b95505017]

There are some of libraries e.g. Gson, Moshi, will help us parse json string into java object.

If public void call(Object... args) { could return the java object instead of JSONObject, I think it will be more convenient.

For example, in Retrofit, we could define the response java object, after response returned, it will call converters to help parsing the response string into java object, then we could use them directly instead of get the value one by one from JSONObject.

Encoder could also use Gson/Moshi to convert java object into json string automatically and send it.

[nkzawa]

Related to #184, I have a thought to add an adapter which you can implement your own JSON parser, though it's still an idea and actually, it might be a bit difficult to support.

Alternatively, I think you would be able to use a mapper library like https://github.com/FasterXML/jackson-datatype-json-org for now.

Let me know if you have any ideas how we should support the feature.

[emanuelet]

+1. Do you think it will be possible (and feasible) to port what Retrofit2 is doing with adapters?
As far as I saw, they declare an interface in the main package and then they declare the different adapters.

[b95505017]

The easiest way is just output as String, then we could use any json convert library to transform our model, or passing into JsonObject for who still want to use old way.

[emanuelet]

For that matter I already doing that:

 private Emitter.Listener onReceived = new Emitter.Listener() {
        @Override
        public void call(final Object... args) {
            ObjectMapper mapper = new ObjectMapper();
            RtmMessageJks msg = null;
            try {
                msg = mapper.readValue(args[0].toString(), RtmMessageJks.class);
            } catch (IOException e) {
                e.printStackTrace();
            }
            String type = msg.getRtmType();
        }
    };

Also for some reasons that are not very clear to me I've been forced to convert the object with jackson to avoid memory freezes of gson.

I think anyhow, that having an adapter will be more efficient and clean in terms of implementation.

[JackieKu]

I think ideally it should decouple from any particular JSON implementation and let the client to choose their favorite.
And org.json just sucks.

[engineers-bojan]

Is there any update on this proposed enhancement/feature? Socket-io client could really benefit by enabling us to easily integrate gson, jackson or some other json libraries for parsing POJO's..

[Minikloon]

I think just updating the dependency to the latest org.json would be good. The version packaged right now doesn't implement Iterable on JSONArray.

[emanuelet]

I agree, that will be a quick fix (considering that is running on version 20090211 that is 7 years old), but still I reckon the decoupling the implementation will be the way to go

[nkzawa]

@Minikloon @emanuelet The reason we use the old version of org.json is for Android.

[emanuelet]

what do you mean? the newer version doesn't work with Android?

[nkzawa]

@emanuelet no, it's incompatible.

[ksv510]

I believe that would be great if you add an opportunity to get raw data, I mean byte[] or String etc. Then there will be a possibility to create an adapter with any serializer.