[Resolved] More Android weirdness

I have a plain text file created in Apple TextEdit (it’s plain text, not RTF) that I have uploaded to my game server. I can hit it with the URL and view it’s plain textness in my web browser. It’s downloading just fine.

In the simulator and on iOS devices, it’s successfully downloads to the system.CachesDirectory and I can open it, read it in one line at time, parse each line and shove it into my table and life is good. But on Android (both a Google Nexus 7 and my Kindle Fire) I get total garbage, like this:

[code]
I/Corona (14078): ***downloading card text file
I/Corona (14078): d?n?
I/Corona (14078): t[1] d?n?
I/Corona (14078): Z?m^???u??{fHI3*px!!!EQ?>?0???|z???)???u???oi??|
???3?ypgkJ?Ò?
I/Corona (14078): t[1] Z?m^???u??{fHI3*px!!!EQ?>?0???
I/Corona (14078): t[2] z???)???u???oi??
I/Corona (14078): t[3]
???3?ypgkJ?Ò?
I/Corona (14078): #cards 1
I/Corona (14078): Cards Z?m^???u??{fHI3*px!!!EQ?>?0??? z???)???u???oi??
???3?ypgkJ?Ò?
I/Corona (14078): ?jt??>/??+tk?-?a??(? ?A??s?(@?? [import]uid: 19626 topic_id: 32391 reply_id: 332391[/import]

This sounds like an HTTP header issue. You may need to set the ACCEPT-ENCODING header.

I know the Apple operating systems (OS X and iOS) automatically add the following headers to all network requests if you do not set them…
[lua] ACCEPT: */*
ACCEPT-LANGUAGE: en-us
ACCEPT-ENCODING: gzip, deflate[/lua]

Windows and Android do not automatically add any headers, because the above might be a bad assumption. My recommendation is for you to add the above headers to your network.download() function call and see if that changes the encoding of the received file.
[import]uid: 32256 topic_id: 32391 reply_id: 128846[/import]

 local headers = {}  
 headers["ACCEPT"] = "\*/\*"  
 headers["ACCEPT-LANGUAGE"] = "en-us"  
 headers["ACCEPT-ENCODING"] = "gzip, deflate"  
  
 local params = {}  
 params.headers = headers  
 network.download(URL, "GET", checkCards, params, "cards.txt", system.CachesDirectory)  

did not have any effect. I even tried to do:

 local headers = {}  
 headers["Accept"] = "\*/\*"  
 headers["Accept-Language"] = "en-US"  
 headers["Accept-Encoding"] = "gzip, deflate"  
  
 local params = {}  
 params.headers = headers  
 network.download(URL, "GET", checkCards, params, "cards.txt", system.CachesDirectory)  

in case there were any case sensitivity issues. According to Firefox, when I do a View Page Info on the text file, it says:

Type: text/plain
Encoding: ISO-8859-1

[import]uid: 19626 topic_id: 32391 reply_id: 128847[/import]

Well, I’ve ““SOLVED”” this… sort of. Instead of downloading the text file and dealing with what looks like GZIP, I dropped in a simple PHP script (modified an existing script for the client to upload the text file and check for errors) to spew out JSON and then I switched to network.request() rather than network.download() and just json.decode the output into my table. Problem solved.

Thought it doesn’t fix the underlying cause of the problem. But at least for me, I can go on to other things.

[import]uid: 19626 topic_id: 32391 reply_id: 128890[/import]

This sounds like an HTTP header issue. You may need to set the ACCEPT-ENCODING header.

I know the Apple operating systems (OS X and iOS) automatically add the following headers to all network requests if you do not set them…
[lua] ACCEPT: */*
ACCEPT-LANGUAGE: en-us
ACCEPT-ENCODING: gzip, deflate[/lua]

Windows and Android do not automatically add any headers, because the above might be a bad assumption. My recommendation is for you to add the above headers to your network.download() function call and see if that changes the encoding of the received file.
[import]uid: 32256 topic_id: 32391 reply_id: 128846[/import]

 local headers = {}  
 headers["ACCEPT"] = "\*/\*"  
 headers["ACCEPT-LANGUAGE"] = "en-us"  
 headers["ACCEPT-ENCODING"] = "gzip, deflate"  
  
 local params = {}  
 params.headers = headers  
 network.download(URL, "GET", checkCards, params, "cards.txt", system.CachesDirectory)  

did not have any effect. I even tried to do:

 local headers = {}  
 headers["Accept"] = "\*/\*"  
 headers["Accept-Language"] = "en-US"  
 headers["Accept-Encoding"] = "gzip, deflate"  
  
 local params = {}  
 params.headers = headers  
 network.download(URL, "GET", checkCards, params, "cards.txt", system.CachesDirectory)  

in case there were any case sensitivity issues. According to Firefox, when I do a View Page Info on the text file, it says:

Type: text/plain
Encoding: ISO-8859-1

[import]uid: 19626 topic_id: 32391 reply_id: 128847[/import]

Well, I’ve ““SOLVED”” this… sort of. Instead of downloading the text file and dealing with what looks like GZIP, I dropped in a simple PHP script (modified an existing script for the client to upload the text file and check for errors) to spew out JSON and then I switched to network.request() rather than network.download() and just json.decode the output into my table. Problem solved.

Thought it doesn’t fix the underlying cause of the problem. But at least for me, I can go on to other things.

[import]uid: 19626 topic_id: 32391 reply_id: 128890[/import]

Glad you got it working!

Come to think of it, I’m pretty sure the Android version of our network request/download APIs do not automatically decompress the received data. I doubt our Windows version of the Corona Simulator does this as well. I could write that up as a feature request. We would probably have to support the famous ones, gzip and deflate. More details here…
http://en.wikipedia.org/wiki/HTTP_compression

But that said, if you do not have an “Accept-Encoding” header in your HTTP request, then I would expect the server to deliver an uncompressed response. It sounds like your server is not doing that. I hate to say it, but that sounds like a bug on your server. [import]uid: 32256 topic_id: 32391 reply_id: 129113[/import]

Glad you got it working!

Come to think of it, I’m pretty sure the Android version of our network request/download APIs do not automatically decompress the received data. I doubt our Windows version of the Corona Simulator does this as well. I could write that up as a feature request. We would probably have to support the famous ones, gzip and deflate. More details here…
http://en.wikipedia.org/wiki/HTTP_compression

But that said, if you do not have an “Accept-Encoding” header in your HTTP request, then I would expect the server to deliver an uncompressed response. It sounds like your server is not doing that. I hate to say it, but that sounds like a bug on your server. [import]uid: 32256 topic_id: 32391 reply_id: 129113[/import]