My use case is similar to Tim’s: I have a few lerge files that I need to download from my server and save to the file system (offline map and points of interest files) - total size of the files is 500Mb. Each file is between 100Mb and 300Mb. I can't split those files into smaller files because they are sqlite database files and splitting them would be a headache. When I download them using angular/ionic http client the file is loaded into memory before I can store it in the file system using the file-plugin. In some cases, specifically on iOS, this causes a "white screen of death". Somewhat related to this issue (see my comment at the end) https://github.com/apache/cordova-plugin-file/issues/364 When all I want to do is download a file and store it somewhere in the application's folders there's a problem in iOS and sometimes it fails when not using file-transfer-plugin. I think the problem is related to how much memory is used by the webview, not sure though… In any case, I don’t think there’s a proper solution without the mentioned plugin and I am too in favour of either reviving it or fix (not sure this is possible, maybe using chunking as mentioned in the linked issue) the http client. I can help testing this out if needed.
On 2020/07/23 15:50:17, Norman Breau <n...@normanbreau.com> wrote: > One of my apps logs GPS and acceleration data, and the user could be creating > these log sessions for hours. This can easily result in a JSON document size > of > 50MB. I don't receive memory issues uploading this document, but I have > a test log that I use to download to test large uploads. This document can be > found at https://staging.totalpave.com/uploads/datalog.test.json > (https://link.getmailspring.com/link/be0b03d8-c5e5-4149-9a60-51490cf7e...@getmailspring.com/0?redirect=https%3A%2F%2Fstaging.totalpave.com%2Fuploads%2Fdatalog.test.json&recipient=ZGV2QGNvcmRvdmEuYXBhY2hlLm9yZw%3D%3D)> > > > Particularly downloading a document of this size is problematic, because > using cordova-plugin-file to save this file fails for memory issues, at least > on Android. It's been awhile since I dug into this, but I believe it was > because cordova-android converts this data into a base64 encoded string, > which expands the data size by roughly 40%.> > But with that being said, isn't the goal of Cordova is bring web standards to > the webview?> > "Applications execute within wrappers targeted to each platform, and rely on > standards-compliant API bindings to access each device's capabilities such as > sensors, data, network status, etc."> > Perhaps this is still more suitable as a third-party plugin?> > Sent from Mailspring > (https://link.getmailspring.com/link/be0b03d8-c5e5-4149-9a60-51490cf7e...@getmailspring.com/1?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=ZGV2QGNvcmRvdmEuYXBhY2hlLm9yZw%3D%3D), > the best free email app for work> > On Jul 23 2020, at 6:23 am, Tim Brust <ti...@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>
