You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2018/07/03 03:35:16 UTC
Re: Roadmap for next major versions
Thanks Darryl,
I'll be working on getting the WKWebView plugin up to snuff this week (read
the comment thread in your doc).
1. Review and resolve all existing PRs
2. Integrate the WKWebView plugin into the cordova-ios repo
3. Turn on WKWebView support via a feature flag (eventually this will be
the default)
I think no. 3 is a good way for interim testing versus having long-lived
branches that might get out of sync. I don't think this will get into the
same situation like `browserify` feature flag that was forgotten, since we
intend to bake this in for sure.
[CDVWebViewEngineProtocol support](
https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h)
so we can swap in any webview engine will remain unchanged.
On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue <da...@dpogue.ca> wrote:
> Hi folks,
>
> As we've been discussing dropping node 4 support and how that requires
> a major version bump, we should review what had already been on the
> pile for next majors and what we want on the pile.
>
> I've started a Google Doc scratchpad to loosely organize high-level
> goals for the various modules, and then we can start breaking them
> down into JIRA tasks and putting them on the sprint boards:
>
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
>
> We know that iOS 12 and Android P are both likely coming in the fall,
> so it might make sense to target our release to line up around that
> time and make sure we support both of the new platform versions. I
> don't love the idea of waiting that long, but let's be realistic about
> what we can try to achieve.
>
> ~Darryl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Roadmap for next major versions
Posted by Niklas Merz <ni...@rhoen.de>.
I think this PR
https://github.com/apache/cordova-plugin-inappbrowser/pull/271 should
basically do what needs to be done to support both webviews. I haven´t
tested this version yet, but it looks like Dave has done a great job
for supporting WKwebview alongside UIWebview.
The main issues we had in our app with WKwebview were CORS, the lack
of cookie sharing and frame bridge/WKScriptMessageHandler bridge.
Some discussion around IAB and WKwebview was taking place in this
issue https://issues.apache.org/jira/browse/CB-7179.
Quoting Shazron <sh...@gmail.com>:
> Thanks Niklas,
> Since you know what needs to be done or has been done with respect to
> InAppBrowser - can you highlight any specific tasks or PRs that need to be
> pulled in for IAB? I probably can't focus on getting anything except
> WKWebView support for InAppBrowser this week (if I have the bandwidth, but
> perhaps next week for a bit).
>
> On Tue, Jul 3, 2018 at 1:30 PM Niklas Merz <ni...@rhoen.de> wrote:
>
>> That sounds great. Please don't forget InAppBrowser. I worked in getting
>> WKwebview running in InAppBrowser a while ago and I happy to help, review
>> and test these changes . Dave Alden did a good pull request on this.
>>
>> I flag like this sounds like a good way to test this in our app.
>>
>> Am 3. Juli 2018, 06:39, um 06:39, Shazron <sh...@gmail.com> schrieb:
>> >I was thinking that the feature flag is just a convenience feature for
>> >setting/removing (depends on if the flag is set/omitted):
>> ><preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
>> >in
>> >config.xml
>> >
>> >So something like this:
>> >`cordova platform add ios --wkwebview` or something to that effect.
>> >
>> >My thinking is -- this would make manual testing easier, and remove
>> >friction for testers in the interim, not to mention automated CI
>> >setups. If
>> >it's easier to test, perhaps more people would test it, at least that's
>> >what I hope...
>> >
>> >Yeah the custom scheme thing, since it's iOS 11, we might have to
>> >tackle
>> >that once we drop iOS 10 support I suppose.
>> >
>> >On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue <dv...@gmail.com>
>> >wrote:
>> >
>> >> Thanks Shazron!
>> >>
>> >> Regarding point 3 on your list, does that need to be a feature flag
>> >> since the WebView engine is already controlled via a preference in
>> >> config.xml? People should be able to opt-in that way just by adding a
>> >> preference, and then in a future release we just change the default
>> >> value for that preference, correct?
>> >>
>> >> From the Apple side, it sounds like they're very heavily encouraging
>> >> the use of custom schemes instead of file:/// URLs for apps serving
>> >> local files, but I think that wasn't introduced until iOS 11 which
>> >> might be an issue for us.
>> >>
>> >> On Mon, Jul 2, 2018 at 8:36 PM Shazron <sh...@gmail.com> wrote:
>> >> >
>> >> > Thanks Darryl,
>> >> > I'll be working on getting the WKWebView plugin up to snuff this
>> >week
>> >> (read
>> >> > the comment thread in your doc).
>> >> > 1. Review and resolve all existing PRs
>> >> > 2. Integrate the WKWebView plugin into the cordova-ios repo
>> >> > 3. Turn on WKWebView support via a feature flag (eventually this
>> >will be
>> >> > the default)
>> >> >
>> >> > I think no. 3 is a good way for interim testing versus having
>> >long-lived
>> >> > branches that might get out of sync. I don't think this will get
>> >into the
>> >> > same situation like `browserify` feature flag that was forgotten,
>> >since
>> >> we
>> >> > intend to bake this in for sure.
>> >> >
>> >> > [CDVWebViewEngineProtocol support](
>> >> >
>> >>
>> >
>> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
>> >> )
>> >> > so we can swap in any webview engine will remain unchanged.
>> >> >
>> >> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue <da...@dpogue.ca>
>> >wrote:
>> >> >
>> >> > > Hi folks,
>> >> > >
>> >> > > As we've been discussing dropping node 4 support and how that
>> >requires
>> >> > > a major version bump, we should review what had already been on
>> >the
>> >> > > pile for next majors and what we want on the pile.
>> >> > >
>> >> > > I've started a Google Doc scratchpad to loosely organize
>> >high-level
>> >> > > goals for the various modules, and then we can start breaking
>> >them
>> >> > > down into JIRA tasks and putting them on the sprint boards:
>> >> > >
>> >> > >
>> >>
>> >
>> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
>> >> > >
>> >> > > We know that iOS 12 and Android P are both likely coming in the
>> >fall,
>> >> > > so it might make sense to target our release to line up around
>> >that
>> >> > > time and make sure we support both of the new platform versions.
>> >I
>> >> > > don't love the idea of waiting that long, but let's be realistic
>> >about
>> >> > > what we can try to achieve.
>> >> > >
>> >> > > ~Darryl
>> >> > >
>> >> > >
>> >---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >> > > For additional commands, e-mail: dev-help@cordova.apache.org
>> >> > >
>> >> > >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>
>> >>
>>
Re: Roadmap for next major versions
Posted by Shazron <sh...@gmail.com>.
Thanks Niklas,
Since you know what needs to be done or has been done with respect to
InAppBrowser - can you highlight any specific tasks or PRs that need to be
pulled in for IAB? I probably can't focus on getting anything except
WKWebView support for InAppBrowser this week (if I have the bandwidth, but
perhaps next week for a bit).
On Tue, Jul 3, 2018 at 1:30 PM Niklas Merz <ni...@rhoen.de> wrote:
> That sounds great. Please don't forget InAppBrowser. I worked in getting
> WKwebview running in InAppBrowser a while ago and I happy to help, review
> and test these changes . Dave Alden did a good pull request on this.
>
> I flag like this sounds like a good way to test this in our app.
>
> Am 3. Juli 2018, 06:39, um 06:39, Shazron <sh...@gmail.com> schrieb:
> >I was thinking that the feature flag is just a convenience feature for
> >setting/removing (depends on if the flag is set/omitted):
> ><preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
> >in
> >config.xml
> >
> >So something like this:
> >`cordova platform add ios --wkwebview` or something to that effect.
> >
> >My thinking is -- this would make manual testing easier, and remove
> >friction for testers in the interim, not to mention automated CI
> >setups. If
> >it's easier to test, perhaps more people would test it, at least that's
> >what I hope...
> >
> >Yeah the custom scheme thing, since it's iOS 11, we might have to
> >tackle
> >that once we drop iOS 10 support I suppose.
> >
> >On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue <dv...@gmail.com>
> >wrote:
> >
> >> Thanks Shazron!
> >>
> >> Regarding point 3 on your list, does that need to be a feature flag
> >> since the WebView engine is already controlled via a preference in
> >> config.xml? People should be able to opt-in that way just by adding a
> >> preference, and then in a future release we just change the default
> >> value for that preference, correct?
> >>
> >> From the Apple side, it sounds like they're very heavily encouraging
> >> the use of custom schemes instead of file:/// URLs for apps serving
> >> local files, but I think that wasn't introduced until iOS 11 which
> >> might be an issue for us.
> >>
> >> On Mon, Jul 2, 2018 at 8:36 PM Shazron <sh...@gmail.com> wrote:
> >> >
> >> > Thanks Darryl,
> >> > I'll be working on getting the WKWebView plugin up to snuff this
> >week
> >> (read
> >> > the comment thread in your doc).
> >> > 1. Review and resolve all existing PRs
> >> > 2. Integrate the WKWebView plugin into the cordova-ios repo
> >> > 3. Turn on WKWebView support via a feature flag (eventually this
> >will be
> >> > the default)
> >> >
> >> > I think no. 3 is a good way for interim testing versus having
> >long-lived
> >> > branches that might get out of sync. I don't think this will get
> >into the
> >> > same situation like `browserify` feature flag that was forgotten,
> >since
> >> we
> >> > intend to bake this in for sure.
> >> >
> >> > [CDVWebViewEngineProtocol support](
> >> >
> >>
> >
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
> >> )
> >> > so we can swap in any webview engine will remain unchanged.
> >> >
> >> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue <da...@dpogue.ca>
> >wrote:
> >> >
> >> > > Hi folks,
> >> > >
> >> > > As we've been discussing dropping node 4 support and how that
> >requires
> >> > > a major version bump, we should review what had already been on
> >the
> >> > > pile for next majors and what we want on the pile.
> >> > >
> >> > > I've started a Google Doc scratchpad to loosely organize
> >high-level
> >> > > goals for the various modules, and then we can start breaking
> >them
> >> > > down into JIRA tasks and putting them on the sprint boards:
> >> > >
> >> > >
> >>
> >
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
> >> > >
> >> > > We know that iOS 12 and Android P are both likely coming in the
> >fall,
> >> > > so it might make sense to target our release to line up around
> >that
> >> > > time and make sure we support both of the new platform versions.
> >I
> >> > > don't love the idea of waiting that long, but let's be realistic
> >about
> >> > > what we can try to achieve.
> >> > >
> >> > > ~Darryl
> >> > >
> >> > >
> >---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > > For additional commands, e-mail: dev-help@cordova.apache.org
> >> > >
> >> > >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
Re: Roadmap for next major versions
Posted by Niklas Merz <ni...@rhoen.de>.
That sounds great. Please don't forget InAppBrowser. I worked in getting WKwebview running in InAppBrowser a while ago and I happy to help, review and test these changes . Dave Alden did a good pull request on this.
I flag like this sounds like a good way to test this in our app.
Am 3. Juli 2018, 06:39, um 06:39, Shazron <sh...@gmail.com> schrieb:
>I was thinking that the feature flag is just a convenience feature for
>setting/removing (depends on if the flag is set/omitted):
><preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
>in
>config.xml
>
>So something like this:
>`cordova platform add ios --wkwebview` or something to that effect.
>
>My thinking is -- this would make manual testing easier, and remove
>friction for testers in the interim, not to mention automated CI
>setups. If
>it's easier to test, perhaps more people would test it, at least that's
>what I hope...
>
>Yeah the custom scheme thing, since it's iOS 11, we might have to
>tackle
>that once we drop iOS 10 support I suppose.
>
>On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue <dv...@gmail.com>
>wrote:
>
>> Thanks Shazron!
>>
>> Regarding point 3 on your list, does that need to be a feature flag
>> since the WebView engine is already controlled via a preference in
>> config.xml? People should be able to opt-in that way just by adding a
>> preference, and then in a future release we just change the default
>> value for that preference, correct?
>>
>> From the Apple side, it sounds like they're very heavily encouraging
>> the use of custom schemes instead of file:/// URLs for apps serving
>> local files, but I think that wasn't introduced until iOS 11 which
>> might be an issue for us.
>>
>> On Mon, Jul 2, 2018 at 8:36 PM Shazron <sh...@gmail.com> wrote:
>> >
>> > Thanks Darryl,
>> > I'll be working on getting the WKWebView plugin up to snuff this
>week
>> (read
>> > the comment thread in your doc).
>> > 1. Review and resolve all existing PRs
>> > 2. Integrate the WKWebView plugin into the cordova-ios repo
>> > 3. Turn on WKWebView support via a feature flag (eventually this
>will be
>> > the default)
>> >
>> > I think no. 3 is a good way for interim testing versus having
>long-lived
>> > branches that might get out of sync. I don't think this will get
>into the
>> > same situation like `browserify` feature flag that was forgotten,
>since
>> we
>> > intend to bake this in for sure.
>> >
>> > [CDVWebViewEngineProtocol support](
>> >
>>
>https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
>> )
>> > so we can swap in any webview engine will remain unchanged.
>> >
>> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue <da...@dpogue.ca>
>wrote:
>> >
>> > > Hi folks,
>> > >
>> > > As we've been discussing dropping node 4 support and how that
>requires
>> > > a major version bump, we should review what had already been on
>the
>> > > pile for next majors and what we want on the pile.
>> > >
>> > > I've started a Google Doc scratchpad to loosely organize
>high-level
>> > > goals for the various modules, and then we can start breaking
>them
>> > > down into JIRA tasks and putting them on the sprint boards:
>> > >
>> > >
>>
>https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
>> > >
>> > > We know that iOS 12 and Android P are both likely coming in the
>fall,
>> > > so it might make sense to target our release to line up around
>that
>> > > time and make sure we support both of the new platform versions.
>I
>> > > don't love the idea of waiting that long, but let's be realistic
>about
>> > > what we can try to achieve.
>> > >
>> > > ~Darryl
>> > >
>> > >
>---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > > For additional commands, e-mail: dev-help@cordova.apache.org
>> > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
Re: Roadmap for next major versions
Posted by Shazron <sh...@gmail.com>.
I was thinking that the feature flag is just a convenience feature for
setting/removing (depends on if the flag is set/omitted):
<preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" /> in
config.xml
So something like this:
`cordova platform add ios --wkwebview` or something to that effect.
My thinking is -- this would make manual testing easier, and remove
friction for testers in the interim, not to mention automated CI setups. If
it's easier to test, perhaps more people would test it, at least that's
what I hope...
Yeah the custom scheme thing, since it's iOS 11, we might have to tackle
that once we drop iOS 10 support I suppose.
On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue <dv...@gmail.com> wrote:
> Thanks Shazron!
>
> Regarding point 3 on your list, does that need to be a feature flag
> since the WebView engine is already controlled via a preference in
> config.xml? People should be able to opt-in that way just by adding a
> preference, and then in a future release we just change the default
> value for that preference, correct?
>
> From the Apple side, it sounds like they're very heavily encouraging
> the use of custom schemes instead of file:/// URLs for apps serving
> local files, but I think that wasn't introduced until iOS 11 which
> might be an issue for us.
>
> On Mon, Jul 2, 2018 at 8:36 PM Shazron <sh...@gmail.com> wrote:
> >
> > Thanks Darryl,
> > I'll be working on getting the WKWebView plugin up to snuff this week
> (read
> > the comment thread in your doc).
> > 1. Review and resolve all existing PRs
> > 2. Integrate the WKWebView plugin into the cordova-ios repo
> > 3. Turn on WKWebView support via a feature flag (eventually this will be
> > the default)
> >
> > I think no. 3 is a good way for interim testing versus having long-lived
> > branches that might get out of sync. I don't think this will get into the
> > same situation like `browserify` feature flag that was forgotten, since
> we
> > intend to bake this in for sure.
> >
> > [CDVWebViewEngineProtocol support](
> >
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
> )
> > so we can swap in any webview engine will remain unchanged.
> >
> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue <da...@dpogue.ca> wrote:
> >
> > > Hi folks,
> > >
> > > As we've been discussing dropping node 4 support and how that requires
> > > a major version bump, we should review what had already been on the
> > > pile for next majors and what we want on the pile.
> > >
> > > I've started a Google Doc scratchpad to loosely organize high-level
> > > goals for the various modules, and then we can start breaking them
> > > down into JIRA tasks and putting them on the sprint boards:
> > >
> > >
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
> > >
> > > We know that iOS 12 and Android P are both likely coming in the fall,
> > > so it might make sense to target our release to line up around that
> > > time and make sure we support both of the new platform versions. I
> > > don't love the idea of waiting that long, but let's be realistic about
> > > what we can try to achieve.
> > >
> > > ~Darryl
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Roadmap for next major versions
Posted by Darryl Pogue <dv...@gmail.com>.
Thanks Shazron!
Regarding point 3 on your list, does that need to be a feature flag
since the WebView engine is already controlled via a preference in
config.xml? People should be able to opt-in that way just by adding a
preference, and then in a future release we just change the default
value for that preference, correct?
From the Apple side, it sounds like they're very heavily encouraging
the use of custom schemes instead of file:/// URLs for apps serving
local files, but I think that wasn't introduced until iOS 11 which
might be an issue for us.
On Mon, Jul 2, 2018 at 8:36 PM Shazron <sh...@gmail.com> wrote:
>
> Thanks Darryl,
> I'll be working on getting the WKWebView plugin up to snuff this week (read
> the comment thread in your doc).
> 1. Review and resolve all existing PRs
> 2. Integrate the WKWebView plugin into the cordova-ios repo
> 3. Turn on WKWebView support via a feature flag (eventually this will be
> the default)
>
> I think no. 3 is a good way for interim testing versus having long-lived
> branches that might get out of sync. I don't think this will get into the
> same situation like `browserify` feature flag that was forgotten, since we
> intend to bake this in for sure.
>
> [CDVWebViewEngineProtocol support](
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h)
> so we can swap in any webview engine will remain unchanged.
>
> On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue <da...@dpogue.ca> wrote:
>
> > Hi folks,
> >
> > As we've been discussing dropping node 4 support and how that requires
> > a major version bump, we should review what had already been on the
> > pile for next majors and what we want on the pile.
> >
> > I've started a Google Doc scratchpad to loosely organize high-level
> > goals for the various modules, and then we can start breaking them
> > down into JIRA tasks and putting them on the sprint boards:
> >
> > https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
> >
> > We know that iOS 12 and Android P are both likely coming in the fall,
> > so it might make sense to target our release to line up around that
> > time and make sure we support both of the new platform versions. I
> > don't love the idea of waiting that long, but let's be realistic about
> > what we can try to achieve.
> >
> > ~Darryl
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org