I guess if it isn't running in the background then a collision is effectively impossible anyhow.
On Wed, Oct 8, 2014 at 11:53 AM, Shazron <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>>> > >>>> 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 <[email protected]> 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 < >>>> [email protected]> >>>> > wrote: >>>> > >> >>>> > >>> On Fri, Sep 5, 2014 at 2:40 PM, Shazron <[email protected]> >>>> 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. >>>> > >> >>>> > >>>> >>> >>> >> >
