I believe there's not API to insert this early for Android / iOS other than in the new WKWebView.
On Thu, Dec 11, 2014 at 3:23 PM, Jesse <purplecabb...@gmail.com> wrote: > The native side knows the browser capabilities long before it's > loaded, or even created, compile time even. They will never change > after the app is built. > On WP8 the scripts are injected right before DOMContentLoaded fires, > and before any js code in the page is run. I realize other platforms > may not be able to catch the browser load events early enough to be > effective though. Anyone know the native side event flow for > iOS+Android? > > > On Dec 11, 2014, at 10:54 AM, Andrew Grieve <agri...@chromium.org> > wrote: > > > > Let's start a new thread for browserify. > > > > Jesse - def. like the idea of injecting polyfills when they are not there > > but are required. In practice though, I think it ends up pretty much the > > same anyways: > > - On start-up you need to feature-detect Promise via JS > > - If it's not there, you need to inject it. > > > > Whether the injection occurs via the native side shoving it in, or by > > cordova.js require()'ing a module is a matter of whether we check in > > es6-promise.js into each platform separately, or into cordova-js. > > > > > >> On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux <b...@brian.io> wrote: > >> > >> we should move browserify to main and drop that insane concat code > >> > >> its not heavyweight at all. it creates a hash in iife with deps mapped > >> in…as to why dep mgmt is better than concatenating…I don't think we > need to > >> waste our time talking about that! > >> > >> On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve <agri...@chromium.org> > >> wrote: > >> > >>> There's something implemented behind a --browserify flag, but not sure > >> what > >>> it does. > >>> > >>> Totally in favour of having CLI / plugman concatenate plugin JS with > >>> cordova.js, but not convinced that browserify is the right tool for > this, > >>> as it seems quite heavy-weight for just concatenating things. If > someone > >> is > >>> going to resume work on it, would love to hear a summary of what > problems > >>> it's solving (if more than concatenation), and why something more > >>> light-weight wouldn't be better. > >>> > >>>> On Wed, Dec 10, 2014 at 4:22 PM, Michal Mocny <mmo...@chromium.org> > >>> wrote: > >>> > >>>> We haven't worked on it, also curious. Anis, perhaps? > >>>> > >>>>> On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux <b...@brian.io> wrote: > >>>>> > >>>>> def think we should support those specs in our great and fabled api > >>>>> audit…had not considered the load order issue > >>>>> > >>>>> not insurmountable and probably should be a feature/fix for the > >> plugin > >>>>> loader load order …but also sort of scary… reminds me of script tags > >>> hell > >>>>> > >>>>> on that note: we need to make browserify thing first class. whats the > >>>> hold > >>>>> up on that front? > >>>>> > >>>>> On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny <mmo...@chromium.org> > >>>>> wrote: > >>>>> > >>>>>> Do we prefer to invent new cordova-specific apis, or prefer to > >> match > >>>>>> standard browser apis? When there is no browser spec to match then > >>>>> design > >>>>>> comes down to aesthetics and personal preference (as you say). But > >>>> often > >>>>>> there is an existing browser spec, and then it comes down to match > >> or > >>>>>> fork. I'm in the camp of preferring to match, and was under the > >>>>> assumption > >>>>>> others here were too. > >>>>>> > >>>>>> Given the upcoming specs mentioned earlier (sockets, file, > >>> filesystem, > >>>>>> permissions, service worker, fetch), seems that fighting the > >> adoption > >>>> of > >>>>>> promises in core apis implies opposing the adoption of modern web > >>>> specs. > >>>>>> e.g. I'm assuming Andrew was referring to > >>>>>> http://www.w3.org/TR/battery-status/, since matching that spec > >>> *would* > >>>>>> require promises. > >>>>>> > >>>>>> > >>>>>> Now, as I understand, you are not saying you are opposed to > >> adoption > >>> of > >>>>>> promises in Cordova, but that you are simply against the inclusion > >>> of a > >>>>>> polyfill directly inside cordova-js. I think that a > >>> promises-polyfill > >>>>>> plugin alternative has some technical downsides [1], but they seem > >>> not > >>>> so > >>>>>> insurmountable that we shouldn't just get passed this debate and do > >>>> that. > >>>>>> > >>>>>> In my opinion, we should prefer to create a common plugin (at least > >>>> until > >>>>>> browserify), since I really hope we don't tell devs to just include > >>>> their > >>>>>> own polyfill with each plugin. > >>>>>> > >>>>>> [1]: > >>>>>> - Can't rely on a polyfill plugin for cordova-js itself. There > >> are a > >>>> few > >>>>>> places where that may have been useful. > >>>>>> - We don't currently load plugins in an order that respects plugin > >>>>>> dependencies, so every plugin relying on promises-polyfill will > >> have > >>> to > >>>>>> require() it at runtime before using and forgetting to do so > >>>>>> may-or-may-not lead to an error. Maybe we just fix this in our > >>> plugin > >>>>>> loader. > >>>>>> - It seems odd that window.Promise will exist depending on which > >>>> plugins > >>>>>> you have installed. While this technically isn't different than > >> with > >>>> any > >>>>>> plugin modifying global symbols, it seems odd-er when applied to a > >>>>>> dependant platform feature. > >>>>>> > >>>>>> -Michal > >>>>>> > >>>>>> On Wed, Dec 10, 2014 at 1:56 PM, Jesse <purplecabb...@gmail.com> > >>>> wrote: > >>>>>> > >>>>>>> Why does battery-status 'require' promises? > >>>>>>> > >>>>>>> I agree that promises are here to stay, but I am unclear why it > >>> would > >>>>> be > >>>>>> a > >>>>>>> good idea to go and change/rewrite/break our apis to use them? > >>>>>>> > >>>>>>> Most of the windows plugins use promises all over the place, the > >>>> entire > >>>>>>> async windows js api is promise based, but this has zero impact > >> on > >>>> what > >>>>>> our > >>>>>>> core-api looks like to a user. The same should apply to any > >> plugin > >>>> that > >>>>>>> wants to depend on promises, just depend on a promise plugin, > >> which > >>>> may > >>>>>> or > >>>>>>> may not add polyfil code to the dom. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> @purplecabbage > >>>>>>> risingj.com > >>>>>>> > >>>>>>> On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux <b...@brian.io> > >> wrote: > >>>>>>> > >>>>>>>> - no technical benefit (but aesthetics, sure) > >>>>>>>> - adds weight (payload and runtime) > >>>>>>>> - might interfere with userland polly > >>>>>>>> > >>>>>>>> -1 > >>>>>>>> > >>>>>>>> On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve < > >>>> agri...@chromium.org > >>>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> One specific spot in core I'd like to use it is to address > >> this > >>>>> TODO > >>>>>> in > >>>>>>>>> Android's exec bridge: > >> > https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263 > >>>>>>>>> > >>>>>>>>> The actual need is for a setImmediate polyfill, but Promise > >>> does > >>>>> the > >>>>>>> same > >>>>>>>>> thing (with an extra object creation). > >>>>>>>>> > >>>>>>>>> On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland < > >>>>>> iclell...@chromium.org > >>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve < > >>>>>>> agri...@chromium.org> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> userland means that plugins won't be able to use them > >>> unless > >>>>>> every > >>>>>>>>> plugin > >>>>>>>>>>> also includes a copy of the polyfill within it. > >>>>>>>>>>> > >>>>>>>>>>> Looking at our core APIs, seems maybe it's just > >>>> battery-status > >>>>>> that > >>>>>>>>> will > >>>>>>>>>>> require it. Should we have battery-status include the > >>>> polyfill > >>>>>>> within > >>>>>>>>>> it? I > >>>>>>>>>>> hope not. I'd hate to get to where several plugins in my > >>> app > >>>>> all > >>>>>>>> bundle > >>>>>>>>>> the > >>>>>>>>>>> same polyfill. > >>>>>>>>>> > >>>>>>>>>> I believe that Mozilla's new File API, which I think we're > >>>>> planning > >>>>>>> to > >>>>>>>>>> implement, and which should be as core as File is now, is > >>> also > >>>>>>> heavily > >>>>>>>>>> promises-based. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> If we move to having the entire cordova.js built using > >>>>> browserify > >>>>>>>> where > >>>>>>>>>>> every plugin gets to contribute to the JS that goes into > >>> it - > >>>>>> yes I > >>>>>>>> can > >>>>>>>>>> see > >>>>>>>>>>> this solving this use-case as well. But that also seems > >> to > >>> me > >>>>>> like > >>>>>>> a > >>>>>>>>> much > >>>>>>>>>>> larger and much more controversial change. > >>>>>>>>>>> > >>>>>>>>>>> Whether you are for or against promises - they are > >> already > >>>>> here. > >>>>>>> They > >>>>>>>>>>> exists natively on most latest mobile webviews, and every > >>>>> vendor > >>>>>>> has > >>>>>>>>>>> committed to adding them. And they are being used in > >> *most* > >>>> new > >>>>>>> specs > >>>>>>>>>> that > >>>>>>>>>>> I've seen (sockets, filesystem, permissions, service > >>> worker, > >>>>>> fetch) > >>>>>>>>>>> > >>>>>>>>>>> Are there any concrete downsides to putting Promises > >>> polyfill > >>>>>> right > >>>>>>>> in > >>>>>>>>>>> cordova-js? > >>>>>>>>>> > >>>>>>>>>> As long as the promise doesn't clobber the native > >>>> implementation, > >>>>>> if > >>>>>>> it > >>>>>>>>>> exists, and we can remove it completely from platforms when > >>>> they > >>>>>>> don't > >>>>>>>>> need > >>>>>>>>>> it anymore, it seems to me like a small price for having > >> this > >>>>>>> available > >>>>>>>>> to > >>>>>>>>>> all platforms. (Other opinions vary, I'm sure, though) > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser < > >>>> bows...@gmail.com> > >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> +1 to userland. I see other approaches causing more > >>>> problems. > >>>>>>>>>>>> > >>>>>>>>>>>> BTW: The only time I use promises is when the platform > >>>>>> explicitly > >>>>>>>>>>> requires > >>>>>>>>>>>> it, and right now that's just MozillaView. While I > >> think > >>>> it > >>>>>>> looks > >>>>>>>>>>> awesome, > >>>>>>>>>>>> I view Promises as a luxury right now and not a > >> standard > >>>>>> feature > >>>>>>> as > >>>>>>>>> of > >>>>>>>>>>> yet. > >>>>>>>>>>>> > >>>>>>>>>>>> I also really wish specs wouldn't rely on code that > >> only > >>>>> exists > >>>>>>> on > >>>>>>>>> the > >>>>>>>>>>> very > >>>>>>>>>>>> latest browsers. It just makes life harder on people > >> who > >>>> have > >>>>>> to > >>>>>>>>>>> implement > >>>>>>>>>>>> stuff. > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
