06-27-2012 03:55 AM - edited 06-27-2012 03:56 AM
I'm currently having some trouble with one of my apps. I'm trying to upload local files (binary) from the PlayBook to a webservice. I use readFile to get the blobData of the binary file and everything works fine until this point. But now I need to put that binary data into a string and this is where I fail, because the return string is way too short!
My binary file has 545323 bytes (blobData.length). When I convert to string the length of the string is 1960 with default encoding. When I change the decoding parameter of readFile then the size will differ, but only little. So overall it looks like only the first xxxx characters are transfered to the string and then it ends, but I don't know why?!
I really need this binary data as a string, so any help would be really much appreciated!
06-27-2012 08:25 AM
My colleague discovered and submitted a patch for the WebWorks-Tablet OS SDK that involved the blobToString method.
Check out the following pull request which contains the changes, to enable binary support for the blobToString:
Blog article here on patching the WebWorks SDK:
I wonder if this is a similar issue related to what you are experiencing?
06-27-2012 08:34 AM - edited 06-27-2012 08:35 AM
thanks for your feedback, but that's not what I'm looking for. Your colleague submitted a patch for stringToBlob and not to blobToString!
I need the blobToString. I have the blobData from the readFile method and I want to convert that blobData to a string (see me initial post).
The bugfix you mention is for saving binary data on the local file system, but I want to read binary data and post it as a string to a webservice! Hope you can help?
06-27-2012 08:57 AM - edited 06-27-2012 08:58 AM
> So overall it looks like only the first xxxx characters are transfered to the string and then it ends, but I don't know why?!
Usually something like character #23 (&h17) which in ASCII is the control character for "End of Transmission Block".
> to a webservice
Try to encode your blob directly to Base64 encoding the shortest possible route. Sending binary data over http is asking for trouble. You don't know what's done to it during transport. Packaging in a character set using only a-z, A-Z and 0-9 plus some other common characters is the only failsafe method available. You need to protect your data.
06-27-2012 09:03 AM - edited 06-27-2012 09:06 AM
Thanks for your help. I really tried a lot of different files and it did not change for any of them. Only the first 1000-2000 characters are converted to string. I can't believe that it depends on the data and on the characters.
My app support this functionality already on another platform for some time now, without any problems. So I just want to get it going on the PlayBook as well. And therefore i need the binary data as string and not as blob.
When there is a function available that's called blobToString than I expect it to work that way. As I mentioned I also already tried different kind of encodings for the function ("UTF-8", "BASE64", "BINARY"). No one delivers more than 1000-2000 characters, even if the blob has 500.000 bytes...
06-27-2012 10:55 AM
Yeah, this is the same problem (in reverse) from the stringToBlob issue. When the API reads the file, it expects it to be in some kind of string format. If you pass in 'base64' as the encoding, it will actually decode the result *from* base64.
Should be able to patch this with a few lines like I did with stringToBlob. Working on it now.
06-27-2012 12:18 PM
All right - pull request is updated. You'll need to grab the updated code for the blackberry.utils extension from GitHub. Here's the pull request if you want to see the commits:
06-27-2012 06:03 PM
Thank you very much!
Will try it when I'm back home from tomorrows BB10 Jam in Berlin! :-)
06-27-2012 07:30 PM
06-28-2012 05:20 PM
Yes, I knew. I met him today, that was a great experience, even if I was so nervous. He seems to be a really great person and he can really do his job.
But now back to topic. I've just downloaded and installed the new version of Utilities.as and it did not work the way I expect it. I'm using a pdf file to test it and I use the same pdf file on both platforms (BlackBerry PlayBook and webOS). The file size is 545323 bytes.
This is the way I do it on webOS:
1. load the file from the file system with:
xmlHTTP.open("GET", url, false); xmlHTTP.overrideMimeType('text\/plain; charset=x-user-defined'); xmlHTTP.send(null);
The length of the returned string (responseText) is: 545323 (matches the files size in bytes, as I expect it)
2. encode it to "base64" (new string length: 727100).
3. send to webservice.
4. file is transfered correctly and can be displayed on the webservice, everything is cool.
On the PlayBook the length of the blobData is also 545323 (as I expect it). When I now convert this blobData to string, I got mixed results, but no one delivers the exact amount of bytes as it is in the blobData:
Converting with encoding "base-64":
strData.length: 0 (did you broke something with your patch???)
Converting with encoding "binary":
Without encoding parameter:
So I don't know, but this looks really weird to me. But maybe I'm just confused and flashed from BB10 that I'm not able to understand this. I would expect that the length of the string is equal to the length of the blobData.
I could really need some more help...
I can also provide you the file I'm testing with, please send me a direct message or email.