incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brion Vibber <>
Subject Re: Progress callbacks for FileTransfer.upload/download: patch in progress
Date Tue, 10 Jul 2012 16:46:08 GMT
On Tue, Jul 10, 2012 at 12:26 PM, Filip Maj <> wrote:

> Thanks for taking a stab at this! I guess I shouldn't be surprised someone
> attempts to fix this judging by the amount of interest on IRC / the JIRA
> thread in this feature :)


> 1. I would add this feature as a top-level FileTransfer event callback.
> So, no matter if you fire off upload() or download(), you would get a
> progress event. In the spirit of other APIs like the File API, I would
> implement it so that users could do something like:
> var ft = new FileTransfer();
> ft.onprogress = function(evt) {
>     if (evt.type == 'upload') {
>     } else {
>     }
> };
> We could also reuse a lot of existing javascript in the cordova-js project
> [1], as we have an implementation of W3C's ProgressEvent [2]. That said,
> this would require a little bit of additional work. Each FileTransfer
> instance would need an ID (tie it into the callback ID?), to handle the
> case where multiple FileTransfer objects are instantiated and running at
> the same time. So, a bunch of effort would still need to go into the
> cordova-js project.

Can one FileTransfer object be used to run multiple uploads/downloads at
once? It looks ambiguous, at least the Android version looks like it might
let you do that even if you... maybe shouldn't. :)

If it's only expected to run one at a time, then a progress event on the
FileTransfer object makes sense, and should be pretty straightforward to
implement. I'll give it a whirl...

2. The Java code referenced in your implementation [3] would need a bit of
> rework with the above in mind.
> 3. Last but certainly not least: platform parity.

I can probably do iOS; looks like other platforms supporting FileTransfer
are Windows Phone 7 & Blackberry WebWorks which I'm less familiar with.

> With all of the above, I think it would be safe to try to slate this for
> after 2.0.

Awesome! I'll keep plugging at this.

-- brion vibber (brion @ / bvibber @

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