For the phonegap-nfc plugin I send binary data between native and
javascript as a byte array in JSON.
static JSONArray byteArrayToJSON(byte[] bytes) {
JSONArray json = new JSONArray();
for (int i = 0; i < bytes.length; i++) {
json.put(bytes[i]);
}
return json;
}
On Wed, Jan 9, 2013 at 3:00 PM, Andrew Grieve <[email protected]> wrote:
>
> On Wed, Jan 9, 2013 at 10:15 AM, Michal Mocny <[email protected]> wrote:
>
> > On Tue, Jan 8, 2013 at 10:22 PM, Andrew Grieve <[email protected]>
> > wrote:
> >
> > > Rather than "binary data", I think we should focus strictly on
> > > "ArrayBuffer". I think the only other binary data concept is Blob, and
> > Blob
> > > is easy to create from an ArrayBuffer.
> > >
> > > As for how to have one of these show up in a JSON object, I think it will
> > > be tough to make this work. Most platforms assume that you can paste the
> > > JSON into an eval / JSON.parse, and it will come out correctly. That
> > can't
> > > be the case for ArrayBuffers. Maybe we should just not support this. The
> > > use-case here is being able to pass multiple values to callbacks. For
> > > ArrayBuffers, maybe we can passing the usual payload plus an optional
> > > ArrayBuffer as an additional parameter. I don't think it would be
> > necessary
> > > to have multiple ArrayBuffers for a single callback...
> > >
> >
> > To understand correct, does this mean that you propose a single ArrayBuffer
> > instead of an arguments list, or, to add a 6th parameter to exec which is
> > the one and only ArrayBuffer?
> >
> > I propose yet another option, maybe you can any number of ArrayBuffers in
> > the arguments list, but not embedded in any subobject. Thus, semantically
> > the arguments array stops being JSON serializable, and the individual
> > arguments are either ArrayBuffers or json-serializable (this also leaves
> > door open to add more types in the future).
> >
>
> Hmm, I wasn't even thinking about the JS->native case actually. I was only
> thinking about native->JS.
> What you propose sounds good for JS->Native.
>
>
> >
> >
> > >
> > >
> > > My ideas for transferring this over the bridge on iOS include:
> >
> > - an array of numbers
> > > - a string of shorts encoded as chars with unicode chars encoded as
> > \uXXXX
> > > - a URL that the client can fetch via XHR and we can return the binary
> > data
> > > via CDVURLProtocol (advantage here is that XHR2 can request the payload
> > as
> > > an ArrayBuffer instead of having to construct the ArrayBuffer
> > > after-the-fact
> > >
> > interesting idea!
> >
> >
> > >
> > > For Android, the string of short-encoded chars is probably the best bet
> > > since the bridge natively supports transferring strings without having to
> > > parse them as JS literals.
> > >
> > >
> > >
> > > On Tue, Jan 8, 2013 at 4:05 PM, Michal Mocny <[email protected]> wrote:
> > >
> > > > Created https://issues.apache.org/jira/browse/CB-2173
> > > >
> > > >
> > > > On Tue, Jan 8, 2013 at 3:52 PM, Michal Mocny <[email protected]>
> > wrote:
> > > >
> > > > > Background: I've been working on implementing chrome.socket [1] for
> > > > mobile
> > > > > chrome apps [2] and porting circ (an irc chrome app) [3]. Teaser
> > > video:
> > > > > https://docs.google.com/open?id=0B0UdPHoQPXheTzhTZXZHUlpGWHM (this
> > is
> > > > > still in its infancy, and I certainly do plan to submit a version of
> > > the
> > > > > socket api that will work in cordova without any mobile chrome app
> > > > magic).
> > > > >
> > > > > As part of doing that, I had to implement sending binary data across
> > > the
> > > > > exec bridge (on ios for now), and I think it may be a good idea to
> > just
> > > > add
> > > > > that functionality to cordova core. My current implementation is
> > > > certainly
> > > > > not the best, so I will extend the exec bridge echo benchmarks to
> > test
> > > > > binary transfer speeds and we can improve over time.
> > > > >
> > > > > My first step would be to implement helpers in js/ios/android which
> > > > plugin
> > > > > devs can call manually to serialize/deserialize binary data into/from
> > > > > whatever magical form is most efficient.
> > > > >
> > > > > Next, I would try to automate these helpers from within the exec call
> > > > > (e.g. iterate arguments looking for ArrayBuffer/Blob/etc types before
> > > > json
> > > > > serialization). As part of doing this, I would need to add "hints"
> > > about
> > > > > the underlying argument types/some clever way to encode semantic
> > > > > information about the arguments list, which we currently do not do.
> > > > >
> > > > > If anyone has any suggestions or objections please let me know!
> > > > >
> > > > > -Michal
> > > > >
> > > > > [1] http://developer.chrome.com/apps/socket.html
> > > > > [2]
> > > > >
> > > >
> > >
> > https://github.com/MobileChromeApps/chrome-cordova/blob/master/api/chrome/socket.jsand
> > > > >
> > https://github.com/MobileChromeApps/chrome-cordova/tree/master/plugins
> > > > > [3] https://github.com/flackr/circ
> > > > >
> > > >
> > >
> >
