Using the default echo scripts, I’m not getting an event.response in the client. The event return table is completely empty, but I can print out the post information in the server logs so I know it’s getting up there. I’ve tried a couple of installations in case I did something wrong. Any thoughts?
Have u tested the api on postman,
Are you sure you are hitting the correct api url with correct method type.
Can u share the api url & request params with method, so that I can test it.
Assif
I’ve not used postman because I don’t know javascript - using Coronium because it’s all Lua 
I am certain I am hitting the correct API url because I can print out the data (posted from the client) in the server side logs, so I know the post is getting TO the correct URL, it just doesn’t seem to be getting back. I am using the default echo test script included when a new api gets created within Coronium Core, and also using the example script copied from the Coronium docs to test on the client side.
Here is the client side code, is that what you were asking for?
[lua]
local function apiResponse(evt)
if evt.error then
print(evt.error)
else
print(evt.response.name) – Jimmy
end
end
core.api.test({name=“Jimmy”}, apiResponse)
[/lua]
Can you have a look at the answer that I gave on this post, I hope things will hlp u to findout issue.https://forums.coronalabs.com/topic/71597-parsing-api-data/
Unfortunately it is a different issue. In the case you link to, the op was able to print the returning event.response, he was just having an issue with scope. In my case the return table (evt) is completely empty, and if I try to print the response (evt.response.name in my example above) I get an error that I am trying to print a nil value.
But as I say I know the data is getting to the server because I can print it on the server to the server logs.
I recommend you do this:
local function apiResponse(evt) print( json.prettify( evt )) if evt.error then print(evt.error) else print(evt.response.name) -- Jimmy end end
And see what data is in the evt table.
Rob
Hi,
Sorry for the delay.
Coronium overrides the default network handler, you should be looking for the result key.
https://develephant.github.io/coronium-core-docs/client/guide/#response-events
local function onApiResponse( event ) if event.error then print(event.error) else local res = event.result end end
To easily debug your event (kind of like @Rob was pointing out) you can use the core.debug method.
https://develephant.github.io/coronium-core-docs/client/modules/core/#debug
local function onApiResponse( event ) core.debug(event) end
And that will print out a nice result tree in the Corona console.
If that doesn’t solve your problem, let me know.
-dev
Yes, looking for the event.result did it! Just a heads up, the CC documentation includes a client side example of the listener which references an evt.response instead of evt.result, on this page: https://develephant.github.io/coronium-core-docs/server/modules/api/ and that’s what had me looking int he wrong spot. Might cause hiccups for others, though most are probably cleverer than I :)
Hi,
Doh! That’s a super blunder on my end, I’ll fix that ASAP. Thanks for reporting, and my apologies! :unsure:
-dev
Have u tested the api on postman,
Are you sure you are hitting the correct api url with correct method type.
Can u share the api url & request params with method, so that I can test it.
Assif
I’ve not used postman because I don’t know javascript - using Coronium because it’s all Lua
I am certain I am hitting the correct API url because I can print out the data (posted from the client) in the server side logs, so I know the post is getting TO the correct URL, it just doesn’t seem to be getting back. I am using the default echo test script included when a new api gets created within Coronium Core, and also using the example script copied from the Coronium docs to test on the client side.
Here is the client side code, is that what you were asking for?
[lua]
local function apiResponse(evt)
if evt.error then
print(evt.error)
else
print(evt.response.name) – Jimmy
end
end
core.api.test({name=“Jimmy”}, apiResponse)
[/lua]
Can you have a look at the answer that I gave on this post, I hope things will hlp u to findout issue.https://forums.coronalabs.com/topic/71597-parsing-api-data/
Unfortunately it is a different issue. In the case you link to, the op was able to print the returning event.response, he was just having an issue with scope. In my case the return table (evt) is completely empty, and if I try to print the response (evt.response.name in my example above) I get an error that I am trying to print a nil value.
But as I say I know the data is getting to the server because I can print it on the server to the server logs.
I recommend you do this:
local function apiResponse(evt) print( json.prettify( evt )) if evt.error then print(evt.error) else print(evt.response.name) -- Jimmy end end
And see what data is in the evt table.
Rob
Hi,
Sorry for the delay.
Coronium overrides the default network handler, you should be looking for the result key.
https://develephant.github.io/coronium-core-docs/client/guide/#response-events
local function onApiResponse( event ) if event.error then print(event.error) else local res = event.result end end
To easily debug your event (kind of like @Rob was pointing out) you can use the core.debug method.
https://develephant.github.io/coronium-core-docs/client/modules/core/#debug
local function onApiResponse( event ) core.debug(event) end
And that will print out a nice result tree in the Corona console.
If that doesn’t solve your problem, let me know.
-dev
Yes, looking for the event.result did it! Just a heads up, the CC documentation includes a client side example of the listener which references an evt.response instead of evt.result, on this page: https://develephant.github.io/coronium-core-docs/server/modules/api/ and that’s what had me looking int he wrong spot. Might cause hiccups for others, though most are probably cleverer than I :)
Hi,
Doh! That’s a super blunder on my end, I’ll fix that ASAP. Thanks for reporting, and my apologies! :unsure:
-dev