Method to convert JSON flavored string to Lang.Dictionary

I am new to Monkey C, but could not find (in the API docs and the forums) a way to convert a JSON flavored string to a Monkey C dictionary.

The string I have is in the following format: '{"val1": 123, "val2": 456, "val3": 789}'

Is there a way to convert this to a Lang.Dictionary?

Top Replies

jim_m_58 over 4 years ago +2 suggested

if when you do the makeWebRequest, you have :responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_JSON,

when you get it, it's a dictionary.

if you USE HTTP_REPONSE_CONTEXT_TYPE_PLAIN_TEXT, your app needs…

All Replies

0 jim_m_58 over 4 years ago

if when you do the makeWebRequest, you have :responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_JSON,

when you get it, it's a dictionary.

if you USE HTTP_REPONSE_CONTEXT_TYPE_PLAIN_TEXT, your app needs to do the parsing/conversion. There's no simple call you can call.

0 5623528 over 4 years ago in reply to jim_m_58

Thank you for the quick response!

Actually the JSON flavored string is one dictionary entry in a http-response, so I think I have to do the parsing / conversion in the app.

Is there any suggested methods, or simply "bruteforce" via "find()" and "substrtring()"?

0 FlowState over 4 years ago in reply to 5623528

Are you saying that you have a JSON-encoded string within an HTTP json response?

e.g.

{
  "foo": "{\"val1\": 123, \"val2\": 456, \"val3\": 789}",
  "bar": 5
}

If that's the case, do you have any control over the server? Seems like it would be better to decode the nested response on the server side and make it part of the response as actual JSON.

e.g.

{
  "foo": { "val1": 123, "val2": 456, "val3": 789 },
  "bar": 5
}

Or you could write a proxy to do so with something like Google App Engine.

The complexity of your parsing code probably depends on whether you have to handle arbitrary keys/datatypes or whether you know the structure of the data in advance. Given the small amount of RAM available to CIQ apps, I think writing a general-purpose JSON parser probably isn't an optimal solution here, just because of the amount of code you'd have to write.