06-28-2012 05:50 PM
So you've got it sending to the service fine, right? So the most recent patch pulls the binary data into base64 correctly.
The download part needs some tricks to get the binary data into base64 properly and then to pass into stringToBlob.
Since you're familiar with webOS, you'll probably appreciate a sample with Enyo code. I created an Enyo sample that downloads a binary file to the file system and posted it here: https://github.com/timwindsor/EnyoJS-on-BlackBerry
It uses a small library to convert arraybuffer response types to binary without losing the binary data.
06-28-2012 05:57 PM
The downloading of files is not the problem. That's working fine on PlayBook and on webOS.
So I don't understand why the string length is not the same than the file size?
06-28-2012 06:02 PM
It's not the downloading, it's the conversion of pure binary to base64. The script I used does that well. When you do the conversion the size will be different because base64 takes more space than binary.
I can take a look at a small sample if you want to send it to me: firstname.lastname@example.org
06-28-2012 06:09 PM
Okay, let's forget about the file size in bytes, you are right, that does not matter. What matters is the size of the encoded string that I have to send to the webservice.
So I think we both agree that the file encoded as base64 string should have the same length, no matter if it's on the PlayBook or on webOS, right? So this does also not happen, because the binary size of the encoded string on the PlayBook is bigger (736667 compared to the working webOS value of 727100).
Where does the difference come from? And why is the file send from the PlayBook corrupt and cannot be opened after re-downloading it from the webservice?
I can send you the js function I use to encode the data to base64 ob webOS. Is that something that would help?
06-28-2012 06:13 PM
Yeah, those strings should be identical. Something is not getting converted right.
I tested with the following code which just read the file, turned it into base64 and then back and opened it (I didn't have a test server to bounce it off of).
06-28-2012 06:19 PM
I've just send you an email with me encoding function and the sample pdf file. In Germany it's right after midnight and I have to work in my main job in a few hours, so I will go to bed right now.
06-29-2012 02:48 PM
Any news on this topic? Would be great if I could complete the feature on this weekend, but I need your help.
06-29-2012 03:19 PM
Been looking at it just now.
My sample actually works with your file - the blob is turned into a base64 string by the updated blobToString(blob, 'binary') call and then I can convert that back to a blob and save it as a new file with the new stringToBlob(string, 'binary') method.
The result is a valid file because it opens in Adobe Reader on the device.
Where are you using the base64encode method? I don't think this one will work exactly right. It looks like others I tried and found problems with - that's why I used the one that works on arraybuffers.
06-29-2012 04:00 PM
So I have to use encoding "binary" to transform the blob to a base64 encoded string. But what the heck is encoding "base64" doing? And why is "base64" actually delivering length 0 strings? I'm sorry, but I'm really confused.
I use the base64encode method only on webOS, not on the PlayBook. And on webOS everything works fine... :-|
I will try what you do, I will transform the blob to string and transfer it back to blob. That result will be stored in the file system. When the file is okay and can be opened with the adobe reader, then there must be some problem connecting to the webservice (which actually does not exist the same time arround for webOS, would be strange too).
I will report back.
Thanks for your help and patience.
06-29-2012 04:15 PM
Oh, I agree, it's very confusing.
To my mind, the encoding property works backwards to what it should be doing. When you say stringToBlob(string, 'base64') it actually takes your "String" and converts it into a base64 string which can then be used with the blackberry.io methods. When you do blobToString(blob, 'base64'), it actually reads the blob as if it's base64 and decodes it before returning it to you.
The overall design seems to force use of String data only when interacting with the file system. That's why I added the 'binary' options.
So to take this step by step:
Make more sense now?