Other request events will be added?

[wasteCleaner]

Hello! Thanks for plugin, it's really help me.
But I want to make uploading images from my ionic app. I make a big post request (with base64 encoded image) and I need to listen events 'progress', but they doesn't fired.
Are you plan to add this events?

[gvanmat]

The onprogress events are simulated for upload request and response but don't reflect partial delivery. The plugin makes a single request to the native layer that returns a single response. It delivers the full payload from both request and response so there isn't a progress to report other than the complete uploaded request or delivered response.

The request and response body data marshaled between the javascript context and iOS is converted into an binary string that is base64 encoded. You might be able to reduce the payload if you just send binary data so it's not double encoded.

[wasteCleaner]

gvanmat, thank you for your answer!
But I think, that I don't understand, what are you mean. If I will send binary data (without double encoding) I might get onprogress events?

[gvanmat]

No, the behavior of the progress event will be the same. In the code fragment below, you would only see two progress events fired. The first would be from the upload. The native JavaScript XMLHttpRequest could fire many progress events. The implementation for this plugin will only fire one event. This is just before sending the request to the iOS Layer (single atomic request versus partial). The response onprogress event will also fire just once as it gets the entire response from the plugin.

var xhr = new XMLHttpRequest();
xhr.upload.onprogress = function (event)
{
   console.log("upload:" + event.type);
});

xhr.onprogress = function (event)
{
   console.log("response:" + event.type);
});
xhr.open("POST", "https://myendpoint");
xhr.responseType = "text";
xhr.send(base64EncodeStringImage);

My comment was that you could send your image as binary data (arraybuffer or Blob). This plugin creates a XMLHttpRequest wapper. It packages up everything about the request and sends it to the iOS layer where the browsers (WKWebView) CORS handing is bypassed. The body data for the request and response has similar conversion to a binary string that is base64 encode. That was my point regarding double encoding.

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send

[wasteCleaner]

@gvanmat, thank you for detail answer!
Maybe in the future plugin will get supporting of firing many events?

[gvanmat]

I have doubt it would be feasible. There is inherent overhead in how the plugin works. The mechanism for communicating outside the javascript context to iOS is as efficient as it gets in comparison to the other webview platform offerings but the way the native layer communicates back into the webview is by invoking javascript. This means that all data has be be converted into a string and passed to a javascript function.

The PSR numbers tested by sending the same request three times with a send/recieve payload starting at 1MB to 5MB uncovered on average the plugin is a half second (0.6231582556 ms) slower than a native JS context request doing the same work. This doesn't sound too bad but the other factor is the plugin eliminates the preflight options request that negotiates the CORS handling which would be required from the JS context.

What I'm getting at is that intercepting all xhr traffic, packaging up and sending to the iOS layer and back is not for free. There is overhead to bypass the browsers CORS handling. The atomic single payload from the JS context to the iOS layer and back is what we believe is the most efficient implementations but it's not without limitations.

[gvanmat]

Closing this issue as not feasible to fix at this time.