What about 2 plugins? Maybe more clear for the developer can add one or the other
wkengine-file (only supported on iOS 9+) wkengine-webserver (only supported iOS8, iOS9 and higher) People that don't want to use the webserver might be annoyed to have dead code link. - Carlos Sent from my iPhone > On Aug 20, 2015, at 3:11 PM, Shazron <[email protected]> wrote: > > Ok re-capping the proposal, we need to move on this: > > 1. Recommend UIWebView usage on iOS 8 and below > 2. Recommend WKWebView usage on iOS 9 only (using file:// loading) and the > plugin will support this > 3. WKWebView usage using local web server supported through a preference > (will only work on iOS 8 and above) > > As a consequence of #3: > a) The local webserver plugin will always be installed when you install the > wkwebview-engine plugin > b) The local webserver plugin code will be always be linked into your app > executable, so the symbols will always be there. There will be no > runtime/memory impact if the pref is off > c) we can't make local-webserver dependency depend on iOS 8 only, some > would want to use #3 for iOS 8 and above, for example > > > On Wed, Aug 5, 2015 at 3:15 PM, julio cesar sanchez <[email protected]> > wrote: > >> You are right, sorry, I haven't looked into the pluggable webviews yet. >> >> After looking into the WKWebView engine plugin I've seen that the local >> webserver is a dependency, I thought it was included inside the plugin (as >> the one from Eddy). >> >> So, the way to go is remove the dependency and make it only available for >> iOS 9? and if the user want to use it on iOS 8 then he install the >> webserver plugin manually and maybe add a preference on the WKWebView >> engine plugin? or is there a way that the preference (or an install param) >> can install the webserver plugin with a hook or something? >> >> >> 2015-08-05 8:30 GMT+02:00 Shazron <[email protected]>: >> >>> I don't think that is a good idea. The reason why WKWebView is a plugin >> is >>> the faster update cycle. This is the total point of the new 4.x release: >>> pluggable webviews. If the current UIWebView implementation is buggy, >>> someone could *potentially* update that also. >>> >>> On Wed, Aug 5, 2015 at 1:44 PM, julio cesar sanchez < >>> [email protected]> >>> wrote: >>> >>>> My idea: >>>> >>>> Make iOS 9 use WKWebView as default without plugin and iOS 8 and >> previous >>>> use UIWebView, then if people want WKWebView on iOS 8 they install the >>>> existing plugin with the webserver >>>> >>>> 2015-08-05 5:54 GMT+02:00 Shazron <[email protected]>: >>>> >>>>> +1 Carlos >>>>> >>>>>> On Wednesday, August 5, 2015, Carlos Santana <[email protected]> >>>>> wrote: >>>>> >>>>>> I would like to see by default or configuration setting be able to >>> have >>>>>> that combination "WKWebView plugin only works on iOS 9 and older >>> iOSes >>>>>> fallback to UIWebView" >>>>>> >>>>>> I can already hear customers asking too many questions about >> running >>> a >>>>>> webserver inside their app (i.e. security, energy, old hacks on >>> their >>>>> own >>>>>> custom plugins, etc). I prefer to have the option to tell them >> it's a >>>>>> choice it's very easy to select to not have a webserver at all. >>>>>> >>>>>> - Carlos >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Aug 4, 2015, at 8:16 PM, Shazron <[email protected] >>>> <javascript:;>> >>>>>> wrote: >>>>>>> >>>>>>> My thinking -- It'll be a hybrid approach - iOS 8 uses local-web >>>>> server, >>>>>>> iOS 9 doesn't. We'll have to support both if the dev deploys to >> an >>>>> older >>>>>>> target (the final fallback is UIWebView) >>>>>>> >>>>>>> Either that or WKWebView plugin only works on iOS 9 and older >> iOSes >>>>>>> fallback to UIWebView. >>>>>>> >>>>>>>> On Wednesday, August 5, 2015, Edna Y Morales < >> [email protected] >>>>>> <javascript:;>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Since the file:// url loading bug was fixed for WKWebView in iOS >>> 9, >>>>> are >>>>>> we >>>>>>>> going to move away from the local webserver solution? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Edna Morales >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>> <javascript:;> >>>>>> For additional commands, e-mail: [email protected] >>>>>> <javascript:;> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
