The best way is to create a new plugin that is based off file transfer and just implement it. We could consider pulling it into the core plugin in the future. Please file an issue at: http://issues.apache.org/jira/browse/CB
... so it can be tracked and evaluated by the devs, and you can be notified (and it won't get lost in the ML) Sign up here: https://issues.apache.org/jira/secure/Signup!default.jspa Thanks! On Thu, Feb 12, 2015 at 5:20 PM, Mike Dawson <[email protected]> wrote: > Hi, > > This has been discussed briefly before: > > http://mail-archives.apache.org/mod_mbox/cordova-dev/201311.mbox/%3CCAK_TSX+dKpLr7vCCacN9kMv1d0=wn2z1dfapheyeam3r_dv...@mail.gmail.com%3E > > Problem is when using the FileTransfer plugin to download a file, if the > file is interrupted it will get automatically deleted. This is what happens > on Android (FileTransfer.java line 948): > > // Remove incomplete download. > if (!cached && result.getStatus() != PluginResult.Status.OK.ordinal() && > file != null) { > file.delete(); > } > > This will make it impossible to resume from where the file left off, and on > many networks/situations for a lot of people in countries / areas where the > networks are not so good the probability of ever succeeding at downloading a > sizeable (e.g. 30MB+) file will be very low and it would waste a lot of > bandwidth. > > It is true that resume is a complex business and perhaps out of the scope of > such a plugin (what happens when file changes, how many retries, etc). If > we had just an option like keepIncompleteDownload which would default to > false this (ie. keep the current behaviour) would allow developers to > implement their own logic in Javascript to handle resume if they wish to - > e.g. try the download again, sending a range header, to another file and at > the end concatenate all the file pieces together. > > I have to make a working version of this behaviour for an app we currently > develop just for Android; so I can write that behaviour there. I don't see > any tests that describe the desired behaviour in this scenario. > > Would be interested to see if anyone else has any alternative suggestions. > > Regards, > > -Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
