+1

On 26 August 2015 at 07:20:18, Shazron ([email protected]) wrote:

I'm going to move onto the 2 plugin idea if there are no objections. This 
will preserve the existing plugin into a newly named plugin. 

On Mon, Aug 24, 2015 at 3:24 PM, Carlos Santana <[email protected]> 
wrote: 

> I like much better your naming suggestions for the plugins 
> 
> - Carlos 
> Sent from my iPhone 
> 
> > On Aug 24, 2015, at 4:17 PM, Shazron <[email protected]> wrote: 
> > 
> > I like the two plugin idea. 
> > 
> > Using file:// would be the recommended and default, iOS 9 only -- and 
> this 
> > should be wkwebview-engine 
> > Using the local webserver -- and this could be 
> > wkwebview-engine-local-webserver 
> > 
> > 
> > On Thu, Aug 20, 2015 at 2:42 PM, Carlos Santana <[email protected]> 
> > wrote: 
> > 
> >> 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] 
> >> 
> >> 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: [email protected] 
> For additional commands, e-mail: [email protected] 
> 
> 

Reply via email to