Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of shazron@gmail.com designates
 209.85.192.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADVgkyNT4VnPrBBSE=OO27w5YxH9LiCrx43Y_AudZLbsqif9mA@mail.gmail.com>
References: 
 <CAE6O_-axWrCTm5HFXSD=CzFTgzPOgsjU5fAbbeU1ona8e_F1Tg@mail.gmail.com>
 <CABiQX1Ue-=dkOGNKTviP_--x2cSjdWfQr1GWaJZdxaGbRiGfyg@mail.gmail.com>
 <CAE6O_-a5n=o_H2EO0_uoCZyVTf20GPfvEQaynvpsr3TpOhR-hw@mail.gmail.com>
 <543574e1.4a14450a.279e.19aa@mx.google.com>
 <CAE6O_-ZQ68c4mJiQ2dTXu3KSmfx462Y8zb7Nm38fPyJPynVD2A@mail.gmail.com>
 <CADVgkyNT4VnPrBBSE=OO27w5YxH9LiCrx43Y_AudZLbsqif9mA@mail.gmail.com>
From: Shazron <shazron@gmail.com>
Date: Wed, 8 Oct 2014 11:51:50 -0700
Message-ID: 
 <CAE6O_-btQcJ-uF0P8qa7fudfKZvtH+7g01FFT6UON7fQDieEsQ@mail.gmail.com>
Subject: Re: [iOS 8] Status of WKWebView work
To: Brian LeRoux <b@brian.io>
Cc: purplecabbage <purplecabbage@gmail.com>,
 Andrew Grieve <agrieve@chromium.org>,
	dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2a3f86838910504edd184

--001a11c2a3f86838910504edd184
Content-Type: text/plain; charset=UTF-8

1. Does it run in the background? No. Unless we put up some variables in
Info.plist, which are reserved for certain types of apps (navigation apps,
etc)
2. Local web server port collision? This will be specified in the plugin in
a preference.

On Wed, Oct 8, 2014 at 11:46 AM, Brian LeRoux <b@brian.io> wrote:

> I have some questions! What happens when you background / does it keep
> running? Since you're running localhost, how do you deal with >1 app
> (random port collision possible?)
>
> On Wed, Oct 8, 2014 at 10:33 AM, Shazron <shazron@gmail.com> wrote:
>
>> Not sure if it's only bound to local requests from localhost. Since it's
>> for experimental reasons, I'm not too concerned for security. I'm still
>> opting for the WKWebView loadFileURL way as the option we use for our
>> users, once that is out.
>>
>> On Wed, Oct 8, 2014 at 10:31 AM, purplecabbage <purplecabbage@gmail.com>
>> wrote:
>>
>> > What about other requests from the network? Is the server accessible to
>> > network peers?
>> >
>> > Sent from my iPhone
>> >
>> > > On Oct 8, 2014, at 10:26 AM, Shazron <shazron@gmail.com> wrote:
>> > >
>> > > I'll release the local webserver soon as a plugin, it was just a
>> proof of
>> > > concept. It should work with existing Cordova versions as well, but
>> will
>> > > not have a way to secure access to the local web server from other
>> > > (background) running apps.
>> > >
>> > >> On Wed, Oct 8, 2014 at 4:10 AM, Andrew Grieve <agrieve@chromium.org>
>> > wrote:
>> > >>
>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <shazron@gmail.com> wrote:
>> > >>>
>> > >>> I figure I will write this all up before the official release of
>> iOS 8
>> > >> next
>> > >>> week (probability high) and everyone asking about support.
>> > >>>
>> > >>> It has stalled because the WKWebView cannot load files using the
>> > file://
>> > >>> protocol since iOS 8 beta 4.
>> > >>>
>> > >>> This bug has been filed with Apple weeks ago:
>> > >>> http://www.openradar.me/radar?id=5839348817723392
>> > >>>
>> > >>> I even checked WebKit check-ins if there was any progress, so far,
>> no:
>> > >>
>> >
>> http://trac.webkit.org/browser/trunk/Source/WebKit2/UIProcess/API/Cocoa?order=date&desc=1
>> > >>> (but it's entirely possible the loading code is in another part of
>> the
>> > >>> tree).
>> > >>>
>> > >>> The alternative is to run a local web server, which works great.
>> > However,
>> > >>> this will open up a can of worms possibly with Apple, I'm not sure.
>> > >>
>> > >> Shaz, did you implement a prototype with a local web server? Would be
>> > >> useful to see how the code for this works.
>> > >>
>> > >>
>> > >>
>> > >>>
>> > >>> The other interesting tidbit is, with WKWebView, for locally loaded
>> > files
>> > >>> using the file:// protocol, cross-domain restrictions now apply,
>> unlike
>> > >>> UIWebView's behaviour. To have the same behaviour as UIWebView, we
>> > would
>> > >>> need to proxy these requests (modify xhr.open to go to our proxy,
>> which
>> > >>> requires the local web server).
>> > >>>
>> > >>> The bridge works great, and plugins work great.
>> > >>
>> >
>>
>
>

--001a11c2a3f86838910504edd184--