Our engineers have tested it in the office and can’t duplicate the problem Hopefully Google will have an answer for it soon.
Hey Naomi, is this only happening on a Nexus 7 and/or an Android 4.3 device?
One of my testers and I both have a Nexus 7 running 4.3 and both randomly get network.request errors with and error of -1. I never had this issue with my other Android devices (Nook HD, Kindle Fire (1st gen), Toshiba Thrive). I have been testing the other devices for 2 days and they never error.
This only started when updating to 4.3 so I am beginning to wonder if this is a bug with 4.3 and/or Corona with 4.3. Can you share more information on your circumstances?
One added note, my network code is designed to retry bad requests and they usually go through on the second call. It’s just random when it will fail. However it has errored 3 tries in a row also tonight.
Hey, Anderoth, I was testing on Nexus 7 with Android version 4.2 – so updating to 4.3 in itself didn’t trigger it.
3 errors in a row is worrisome, though. When you get the error -1, does the network request fail for you?
I have GPGS multiplayer mode where users will need to exchange initial settings, and if the error can cause the network communication to fail, it could potentially hang the app for one player while the other player starts playing…
Naomi
Is your code printing the value? Or is it coming from the GPGS plugin?
An HTTP 503 error is “Service Not Available” which means you have successfully contacted the web server, but the service you want isn’t there. So our network.request’s .isError would be false, but the status code of 503 would indicate a problem. I suspect the -1 is a failure to actually talk to the web server, a timeout, or a connection rejection. That would make sense. In that case I would expect that the .isError would be true.
If you are not generating those errors and they are coming from GPGS, then I would say they indicate the service is well… (don’t smack me) “unavailable”.
How you deal with that condition is of course, up to you 
I have been thinking of attempting to downgrade my Nexus to 4.2 and then 4.1.2 to do more tests but I havn’t yet found any concrete tutorials on how. Everything I find shows different instructions from the last. I don’t feel like bricking the device (if it’s possible).
For me the isError is true and the event.status is -1, all other fields of the event are nil. When it happens it’s instant (right when I hit the send button), as if the device is reporting no internet connection to Corona, when there is one.
My Toshiba Thrive is running 4.1.2 and doesn’t exhibit this issue. Nook and Kindle running 2.3 doesn’t either.
I could just do as I am, retry until it goes through but not notifiy the user. However I was more worried it could be a bug that may cause more and worse issues down the road. So I want to identify what is really going on.
If the remote webserver closes the socket connection immediately you will experience this behavior.
Why would the webserver do that only for a Nexus 7 and none of my other devices? Forcing a retry when this happens can work but does this not worry anyone else?
Ah well, I will work around it and move on.
I will report back if anything else odd happens concerning this.
Thanks for the responses Rob!
Unfortunately I don’t fully understand all the of the things going on under the hood with GPGS. The Google Play app is involved. There are OS differences. There are hardware differences. Perhaps there is some combination of the three that’s creating the issue.
About the “Network error!”, I do not print it. It’s sent to the device and gets logged on terminal. I suppose my listener could look for it and handle it where it’s critical. It’s just that I only noticed it yesterday, and unlike Anderoth, I have not been looking for it closely, so I have to see if it really would cause real issue for my app.
Thank you for sharing your thoughts on this, Rob and Anderoth.
Naomi
Ok I didn’t convey this earlier, my fault. My situation does not involve GPGS. I am making calls to Parse.com using https network.requests and getting only a -1 event.status, the rest of the event is nil.
Naomi did mention having this issue with ads also so I believed this to be an overall networking issue with network requests. Because I am not seeing this with other hardware/OS versions I still can’t determine if it’s the Nexus itself or 4.2-4.3 issue.
My sister I believe has a Galaxy Note 3 with 4.3. I think I will have her try the app and see the results.
Hi, yes I’ve seen the same error when I call to show a ad form chartboost and submit scores to GPGS on a you guessed it Nexus 7 with the latest android os & a very young daily build. Seemed to me that the nexus 7 can only handle one socket at a time… So I blame ASUS /android & Corona sdk. For not cola berating on this one out 2.7k devices compatible…jk
No seriously: this was extremely frustrating to me since I was beta testing for chartboost. My contact there reported to me that my Apk ran fine on many other devices without any errors.
So what I did was setup the calls to not over lap. You can rather listen to the banner close. I had to go with putting the GPGS call in the exit scene.
Hope this helps.
I’ll just follow up by saying I never found someone within my testing circle, friends nor co-workers who had a device newer than 4.1.2. So I just worked around it in code by retrying the connection a couple times. Seemed to solve the problem for me.
I had to avoid it in my case because the cb would hang the app when their sdk got this -1 error
I had to avoid it in my case because the cb would hang the app when their sdk got this -1 error
I had to avoid it in my case because the cb would hang the app when their sdk got this -1 error
Your earlier explanation of the web server closing the socket immediately could be the culprit. However the event should still have populated fields containing the information from the originating network.request call and it does not. I think Corona is failing in this situation and the problem could go deeper then what we think at first glance.
… basically all plugins that use internet could be affected by this. That’s concerning and no matter where the bug may be, I think this is something Corona needs to solve or many things could fail unexpectedly that use networking. I just wish I could determine if it’s the Nexus hardware or something with 4.2/4.3 android.
Sorry @Anderoth, I’m being a bit dense today. what fields would you expect to be populated if we cannot reach the web server?
Hi Guys,
I’ve been experiencing this problem too (isError = true and status = -1), it only happens on my Nexus 4 with an Android version 4.3. I didn’t have any problems before updating it.
I’ve tested my app on Android 4.0.2 and 4.1.2 (a Samsung S2 and Motorola Razor) and it works fine on both versions.
I’ve seen that this happens only to the requests that have some sort of post data and just like Anderoth I’ve seen that retrying fixes the problem.
Here’s a code fragment:
local postData = "type=1" local params = {} params.body = postData local headers = {} headers["Content-Type"] = "application/x-www-form-urlencoded" headers["Cookie"] = "PASS=rg1rlvnm4oc85jtbmce2lkg820;" -- I send a valid cookie, params.headers = headers -- send the request to proper server network.request( "http://www.tod.com/api" ,"POST", eventHandlerFunction, params)
As you can see it doesn’t involve any of Corona’s plugins and it’s just a simple call to my own web server.
As Anderoth had suggested I added a few lines of code to automatically retry upon failure and now everything seems to be working (after one failure).
Here’s what I’ve used in case it proves useful to others:
function defaultResponseHandler (event, url, method, listener, params, requestName, retryCount, failureCallback, caller) local count = retryCount or 0 if ( event.isError ) then print( "Network error! Checking for retry") if event.status == -1 then if count \< 3 then count = count + 1 return request(url, method, listener, params, requestName, count, failureCallback, caller) end end print("\*!\* Network error occured and unable to retry",url,requestName,event.status,"\*!\*") if failureCallback ~= nil then failureCallback(caller, "Base network error "..event.status); else -- since a callback hasn't been provided we'll assume that this is a legacy call and so the listener knows how to handle errors, so we pass the event on. print("There was no failure callback provided, event will be passed to listener") listener(event) end else -- everything is in order so go ahead and do your thing. listener(event) end end plainNetworkRequest = \_G.network.request function request (url, method, listener, params, requestName, retryCount, failureCallback, caller) plainNetworkRequest(url, method, function (event) defaultResponseHandler(event, url, method, listener, params, requestName, retryCount, failureCallback, caller) end , params) end -- add this functions to the corona network library \_G.network.request = request
By adding the above code somewhere that it gets run before all of your other requests, ‘network.request’ will automatically retry if the status is ‘-1’ and you wouldn’t need to change any other part of your code. Also please note that I’ve written this code in a module which is why I haven’t marked the functions as ‘local’ and have used ‘_G’ to access Corona’s network library.
I too have had no further problems with my own requests since coding my retry solution.
At this time I don’t expect Corona to code around what I feel is a bug with Google’s devices and Android 4.3 (maybe 4.2 also). Hopefully Google will fix it sooner rather than later.