I too face the same issue. I have a large file - between 100 MB and 300MB which I need to download and save in the local file system (SQLite database file that I don't want to split). When using regular angular/ionic http client on iOS the app crashes to the "white screen of death". Using this plugin solves this issue and currently there's no replacement. More info can be found on an open issue here (which suggested the flie-transfer-plugin as a solution): https://github.com/apache/cordova-plugin-file/issues/364 It might be that solving this issue will allow to truly migrate out of file-transfer-plugin but until then I don't see a replacement so this plugin can't be deprecated. I guess there's also an option to facilitate this behavior in the file-plugin by adding another interface method to allow downloading a file directly to the file system without loading it into the webview memory, I don't know, your call I guess...
On 2020/07/23 09:23:38, Tim Brust <tim.br...@sinnerschrader.com.INVALID> wrote: > Hi there, > > I'd like to discuss the revival of the cordova-plugin-file-transfer plugin. > With the decision from 2017 it was sunsetted and the XHR/fetch alternative > was proposed. [1], [2] > > However, neither the plugin was deprecated on npm nor the GitHub repository > archived. > With the release of cordova-ios@6 it is no longer usable. [3] No surprise > given the fact no work as has been done on the plugin in the recent years. > > However, it seems that > 1. A lot of people are still relying on the plugin - the count of unique > users that commented, opened a duplicate issue or reacted to comments is > (IMHO) very high compared to other issues (and I read at least 90% of our > newly opened issues). [3] > 2. There are reasons to *not *use XHR/fetch. Personally, I've experienced > out of memory issues which resulted in white screens and page reloads on > iOS with big files. If it helps, I can try to provide an example app that > showcases the issues with XHR/fetch. > > We've created a fork at work and applied a lot of the recent fixes we did > for other plugins, too, such as removing deprecated platforms, migrating to > @cordova/eslint, cleaning up the package.json files and npmignore list. > I'm happy to contribute those commits back to the original plugin, as the > work is done anyways. > > The same discussion could be applied to other plugins, too. There is a > general tracking issue: [4], take a note at especially this comment [5] > I'll link this mailing thread to the issue [4], too, and ask affected users > to give some more input why they can't migrate to XHR/fetch, too. > > Looking forward to hearing from you and your opinions. > > Best, > Tim > > Links: > [1] - > https://cordova.apache.org/blog/2017/10/18/from-filetransfer-to-xhr2.html > [2] - https://issues.apache.org/jira/browse/CB-13052 > [3] - https://github.com/apache/cordova-plugin-file-transfer/issues/258 > [4] - https://github.com/apache/cordova/issues/185 > [5] - https://github.com/apache/cordova/issues/185#issuecomment-569979586 > -- > Tim Brust, Product Engineer > > tim.br...@sinnerschrader.com > > SinnerSchrader Deutschland GmbH | SinnerSchrader Group > Völckersstraße 38, 22765 Hamburg, Germany > > Amtsgericht Hamburg HRB-Nr. 63663 > Geschäftsführer: Matthias Schrader (Sprecher), > Jürgen Alker, Dr. Axel Averdung, Holger Blank, > Thomas Dyckhoff, Dr. Lars Finke, Martin Gassner, Peggy Hutchinson > > Büros: Berlin, Hamburg, Frankfurt a. M., München, Prag > > https://www.sinnerschrader.com | NEXT AGENCY > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
