You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Tim Brust <ti...@sinnerschrader.com.INVALID> on 2020/07/23 09:23:38 UTC
[DISCUSS] Revive/Undeprecate cordova-plugin-file-transfer
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.brust@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
Re: [DISCUSS] Revive/Undeprecate cordova-plugin-file-transfer
Posted by Tomas Potok <to...@gmail.com>.
Hi, we'd appreciate this for simple cost reasons. We're using the plugin because it works and migrating away would add to the huge pile of effort of keeping our app from falling apart with every new iOS, XCode, Cordova, etc. release...
Best regards,
Tomas Potok
On 2020/07/23 09:23:38, 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.brust@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] Revive/Undeprecate cordova-plugin-file-transfer
Posted by Harel Mazor <ha...@gmail.com>.
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 <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.brust@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [DISCUSS] Revive/Undeprecate cordova-plugin-file-transfer
Posted by Norman Breau <no...@normanbreau.com>.
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-51490CF7E23D@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-51490CF7E23D@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.brust@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