incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: [WP7] Passing more complex objects over the bridge
Date Wed, 20 Jun 2012 00:38:27 GMT
"We" is us, collectively cordova - I didnĀ¹t want to say "YOU" and point
fingers at who wrote the "failing" code.

Totally could pass it as URL-encoded string, didn't even think of that.
Deciding on one way or another is all that matters to me. If we do change
it to url-encdoed string we would need all platforms to change the native

As for what do the params do, great question. A deep dive uncovered a lot
of shit...

The "headers" key from the object is assumed to be an object. This
key:values inside the "headers" sub-object are then added as headers to
the HTTP request [1].
All other non-"headers" keys from the params object are tacked on to the
HTTP request body like so:

extraParams += "Content-Disposition: form-data; name=\"" +  key.toString()
+ "\";";
                      extraParams += LINE_END + LINE_END;
                      extraParams += params.getString(key.toString());

Does the same thing re content-disposition to the HTTP body, but does NOT
do the "headers" stuff [2].

Magical "__cookie" property name gets tacked onto the HTTP request's
Cookie header [3]. 
Other than that does the content-disposition stuff.

-- SO --

I would say Windows Phone should JUST do the content-disposition
song-n-dance, and not worry about the headers/cookies. The reason for this
is the same reason we recently axed larger changes slated for Media, since
we are deprecating that API after 2.0. This is apparently going to happen
to FileTransfer as well, so IMO should not put too much effort into it.

All of that said, the issue of passing dynamic JSON objects that we cannot
model ahead of time over the WP7 bridge still exists. Want to keep this
thread on track. 


On 6/19/12 4:49 PM, "Jesse" <> wrote:

>Where is this conversation coming from? it appears to be pasted from
>somewhere, who is 'we'?
>params is only allowed to be one level deep anyway so it should simply be
>url-encoded string.
>How is the params value passed to the server on other platforms?
>The documentation simply states:
>*params:* A set of optional key/value pairs to be passed along in the HTTP
>request. (Object)
>Does it become headers? post data? consistently across other devices?
>I have reassigned the issue [3] to myself, and will address it shortly.
>On Tue, Jun 19, 2012 at 3:51 PM, Filip Maj <> wrote:
>> ... Currently won't work. Basically the DataContractJsonSerializer .NET
>> object that we employ to parse JSON on the native side can't parse
>> objects in JSON. The DataContract stuff is supposed to make it easy to
>> cast the various JSON values to .NET types. In the case of a nested
>> with dynamic keys, that you can't model ahead of time, we tried using a
>> Dictionary type on the native side. This won't work [1].
>> This came up when deserializing FileTransfer upload options because they
>> have a nested "params" object that house dynamic &key=value URL
>> to send with the HTTP request. Not sure if it happens in other spots.
>> Anywho, one potential solution is to explicitly convert nested objects
>> such as these to a dumber structure. In the SO thread [1] they suggest
>> having an array of {key:"known1",value:"foo"} pairs replace the objects.
>> The native side could parse that.
>> Another option is to use the library [2]. MIT license. 300-ish
>> .dll.
>> The stock System.Json namespace that is available in .NET and has better
>> capabilities is not available on Windows Phone.
>> Any other solutions/ideas/comments/thoughts?
>> [1]
>> [2]

View raw message