incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [WP7] Passing more complex objects over the bridge
Date Wed, 20 Jun 2012 00:50:04 GMT
Perfect, thanks for digging Fil.
I only asked the 'we' question because it seemed like the question was
pasted, and I thought 'we' was referring to someone else entirely.

I have assigned the FileUploadOptions.params issue to myself here:CB-668
and will revisit the passing dynamic JSON issue. However this will require
a re-write of many of the APIs.

Back on track...

On Tue, Jun 19, 2012 at 5:38 PM, Filip Maj <fil@adobe.com> wrote:

> "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
> side.
>
> As for what do the params do, great question. A deep dive uncovered a lot
> of shit...
>
> Android
> ---
> 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());
>
>
> BlackBerry
> ---
> Does the same thing re content-disposition to the HTTP body, but does NOT
> do the "headers" stuff [2].
>
> iOS
> ---
> 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.
>
> [1]
> https://github.com/apache/incubator-cordova-android/blob/master/framework/s
> rc/org/apache/cordova/FileTransfer.java#L180-L190
> [2]
> https://github.com/apache/incubator-cordova-blackberry-webworks/blob/master
> /framework/ext/src/org/apache/cordova/http/FileUploader.java#L254
> [3]
> https://github.com/apache/incubator-cordova-ios/blob/master/CordovaLib/Clas
> ses/CDVFileTransfer.m#L92
>
> On 6/19/12 4:49 PM, "Jesse" <purplecabbage@gmail.com> 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
> >a
> >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.
> >
> >[3] https://issues.apache.org/jira/browse/CB-668
> >
> >
> >On Tue, Jun 19, 2012 at 3:51 PM, Filip Maj <fil@adobe.com> wrote:
> >
> >> ... Currently won't work. Basically the DataContractJsonSerializer .NET
> >> object that we employ to parse JSON on the native side can't parse
> >>nested
> >> 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
> >>object
> >> 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
> >>parameters
> >> 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 JSON.net library [2]. MIT license. 300-ish
> >>kb
> >> .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]
> >>
> >>
> http://stackoverflow.com/questions/8064627/deserializing-json-object-with
> >>-u
> >>
> >>nknown-fields<
> http://stackoverflow.com/questions/8064627/deserializing-js
> >>on-object-with-unknown-fields>
> >> [2] http://json.codeplex.com/
> >>
> >>
> >
> >
> >--
> >@purplecabbage
> >risingj.com
>
>


-- 
@purplecabbage
risingj.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message