But for 2, there is a chance of port collision still of course, nothing we can do about that. The ideal way is to get a random port, but this requires more Cordova integration which I am trying to avoid (since we need to specify the URL in the content tag, we need to know the port as well)
On Wed, Oct 8, 2014 at 11:51 AM, Shazron <shaz...@gmail.com> wrote: > 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 <shaz...@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 <purplecabb...@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 <shaz...@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 <agri...@chromium.org >>> > >>> > wrote: >>> > >> >>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <shaz...@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. >>> > >> >>> > >>> >> >> >
