FileTransfer deletes partially downloaded files on abort() -- there is a test in Mobile Spec for this behaviour. You could certainly start the download again, but it wouldn't resume; it would start again at the beginning :(
I don't know if there is a universal way to do this -- the way that makes sense to me would be to include a Range header in the request, and look for a 206 response code. A 200 would mean that the server didn't support it, and that we should start writing from the beginning. I have no idea if this is how resuming download clients actually implement this in practise, though, or if there is some other protocol used. If we add this, we would need to make specific pause() and resume() methods, I think -- it's important on mobile devices to remove unneeded files, as the user generally can't do it by themselves (and space is very limited). Similarly, if you were to call download() with a file in place already, we'd have no way to know if that was due to a partial download, or whether it was an old version that needs to be replaced. (There's an additional issue of how to handle resources that may have changed in the meantime -- there's a dance we can do with If-Range headers and Etags, but it starts getting complicated quickly, and we're not storing any of that info right now.) Ian On Thu, Nov 21, 2013 at 2:27 PM, Nick Burka <n...@silverorange.com> wrote: > I’m working on an iOS Cordova app. Is it possible to pause a download and > then resume it using FileTransfer? Does the abort() command delete the > partially-downloaded file, or is it possible to resume the download by > calling download() a second time using the same file path? Has anyone else > done this? > > Thanks! > - Nick
