The data lost is not the topic and I don’t think it’s our duty to avoid it
(but we have to document it and mention it on the release notes). For users
concerned about that, there are plugins available (will probably need some
changes because they were created for the ionic plugin).

There are a few more problems with the custom schemes, I don’t remember
them all, but it comes to my head that playing big video files in the video
tag takes a lot of memory and we can’t send the data in chunks because
there are no request headers (I reported it to Apple long ago and it’s not
fixed yet). That doesn’t happen when the video is served from file protocol.

El jueves, 21 de mayo de 2020, Norman Breau <nor...@normanbreau.com>
escribió:

> The only real advantage of using the file protocol is to maintain
> backwards compatibility I think. Other than that, it contains a lot of
> disadvantages, as the webview disables/restricts a lot of browser features
> while on the file protocol, including using XHR to fetch local resources,
> which makes using web frameworks hard to use, such as angular, which
> heavily uses XHR for fetching templates, and is a common source of
> wkwebview related bug reports.
>
> I've just recently migrated an app from UIWebView to the ionic webview,
> which included migrating local storage data that was extremely important
> for us to keep, and that wasn't too difficult to do. It was just simply
> renaming a sqlite database file. So if the primary concern is the protocol
> change causing lost of data (because change of origin), it might be
> possible to write migratory code. I don't know if migrating
> cookies/indexDB/other storage tech is as easy as migrating local storage
> though, I don't use that browser tech, didn't pay attention to it. This
> would obviously delay the cordova-ios@6 release, but would allow us to
> sunset the wkwebview-engine plugin.
>
> On 2020-05-21 1:45 p.m., Michael Gatto wrote:
>
>> Hi,
>>
>> What exactly are the advantages to serving with the file protocol if
>> Cordova doesn't need to?
>>
>> FWIW, I was never able to get WKWebView working without the additional
>> XHR plugin, so serving from file holds no obvious advantage for me, at
>> least.
>>
>> --
>> Michael Gatto
>>
>> ___
>> Michael Gatto · Senior Software Engineer · vinSUITE
>> o: 707-253-7400 e: mga...@vinsuite.com
>> vinsuite <https://www.vinsuite.com/> · twitter  <
>> https://twitter.com/vinsuite>· facebook  <https://www.facebook.com/vinS
>> UITEsoftware/>· linkedin <https://www.linkedin.com/company/vinsuite/>
>>   You sell wine. We make it easier.
>> Top 5 Tasting Room Survey Takeaways - Watch Now! <
>> https://go.vinsuite.com/watch-CellarPass-webinar>
>>
>> On 5/21/20, 9:18 AM, "julio cesar sanchez" <jcesarmob...@gmail.com>
>> wrote:
>>
>>      we should discuss about what's going to happen
>>      with cordova-plugin-wkwebview-engine
>>           cordova-ios 6 is coming soon and it uses WKWebView, but it uses
>> a custom
>>      scheme to serve the app content instead of serving from file
>> protocol.
>>      some people prefers file over the custom scheme,
>>      but cordova-plugin-wkwebview-engine will not work in cordova-ios 6
>> because
>>      of some breaking changes introduced.
>>           So, should we
>>           a) continue maintaining cordova-plugin-wkwebview-engine and
>> fix it to work
>>      on cordova-ios 6?
>>      b) modify cordova-ios 6 to allow both file and custom scheme and then
>>      sunset cordova-plugin-wkwebview-engine?
>>      c) do nothing and tell people who want to use file protocol to stick
>> with
>>      cordova-ios 5.1.1?
>>      d) other option I didn't think of (please, describe)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Reply via email to