- Home /
What is the maximum byte length of Application.ExternalCall? (and oh yea, it doesn't escape strings correctly)
We've been experiencing problems transferring long chunks of data through the Application.ExternalCall method. it seems like there is a hard limit to the number of bytes that can be pushed to JavaScript. This is NOT a limitation on the JS side. We have successfully sent the same data to and from other embedded objects (ex: SWF to SWF). Our research has yielded a result of around 12560 bytes. I would like to know, if this is a known issue... and if so, what is the real limit?
and oh yea: The method doesn't properly escape the characters passed to it. It seems that it escapes quotes (" => \") as expected, but does not escape slashes and/or line breaks (\,\t,\n,\r,\f) which causes an unterminated string error on the JS side. Not to mention any text that already contains escaped characters breaks (example: \" => \\" should be: \" => \\\"). There are 2 (that we can think of) workarounds for this:
Escape them (the slashes and line breaks) ourselves (but NOT the quotes) before they get passed through the Application.ExternalCall or
Use the WWW.EscapeUrl method to URL encode the value and decode them on the other side
Both of these methods seem to work, but the url encoding adds a considerable amount more characters to what we are sending. Thus, reducing the amount of data we can actually send at one time.
Has anyone else dealt with this?
I have the same issue. I am trying to send the Base64 representation of a screenshot to Javascript to eventually send to the printer (print screen functionality from Unity3D). But I continue to received "unter$$anonymous$$ated string literal" errors in the Error Console in Firefox.
I'm sending a string of about 30,000 characters
I also encountered this problem when sending long arrays (> 30000 items). I worked around it by splitting up in multiple calls and assembling on the javascript side.
Answer by jonas-echterhoff · Feb 04, 2010 at 11:01 AM
I don't see any reason for there to be a limit, so this sounds like a bug to me. Can you file a bug report with an example script which shows the problem, and details on which platforms (browser, OS) you are experiencing the problem on?
$$anonymous$$y $$anonymous$$m has hit this same limitation (Unity 3.3) when sending lengthy JSON formatted strings to the browser, are there any new developments?
Answer by Jeroen 3 · Feb 01, 2011 at 12:26 AM
We have the same problems with a game we're creating, which passes fairly large JSON files from Javascript to Unity. Once they reach ~ 16KB, Unity chokes on it. (Un)escaping indeed is buggy too.
Same here... I'm trying to work with gamesparks to have a cloud save in JSON, one way works fine, when I save to the cloud, I get the string limit when I retrieve the remote data... Any workarounds ?
Answer by CHaNGeTe · Jul 11, 2013 at 12:28 PM
I can't test it now, but does it work if you use String.Format("{0}", aVarWithTheData) as argument for the externalcall?
I think there is a problem with object types cast. This maybe enforces it to send the data as a string.