+1 to test first. Any other path is risky IMHO. Sent from my iPhone
> On Apr 22, 2014, at 11:27 AM, Shazron <shaz...@gmail.com> wrote: > > I've always thought of it as a conditional compilation option (#ifdef > DEBUG). > A plugin is a good idea, that way it is isolated. The plugin would be an > implementation of CDVCommandDelegate > and would clobber > https://github.com/apache/cordova-ios/blob/e7537107f02d6bc22a6dc8d68ea8685d2fd5cb8a/CordovaLib/Classes/CDVViewController.h#L50 > > > On Tue, Apr 22, 2014 at 11:16 AM, Andrew Grieve <agri...@chromium.org>wrote: > >> Put it behind a compile-time flag? Implement it as a plugin? >> >> >>> On Tue, Apr 22, 2014 at 1:56 PM, Michal Mocny <mmo...@chromium.org> wrote: >>> >>> Anyone have an app up on the ios app store that is willing to run a quick >>> experiment? >>> >>> >>> On Tue, Apr 22, 2014 at 1:43 PM, Ian Clelland <iclell...@chromium.org >>>> wrote: >>> >>>> We would need to be careful -- including it as a bridge option might >> mean >>>> bundling the native support code with everyone's app builds. >>>> >>>> Apple has been suspected of doing static analysis of all submitted >>>> binaries, looking specifically for use of undocumented messages / >>> features. >>>> Just having the code in there that could potentially handle this bridge >>>> might be poison for people submitting apps to the store. >>>> >>>> Ian >>>> >>>> >>>>> On Tue, Apr 22, 2014 at 1:38 PM, James Jong <wjamesj...@gmail.com> >>>> wrote: >>>> >>>>> Pretty neat stuff there. We would have to be careful in adding it to >>>> core >>>>> for app submissions. Perhaps a new target that includes it? >>>>> -James Jong >>>>> >>>>>> On Apr 22, 2014, at 12:13 PM, Andrew Grieve <agri...@chromium.org> >>>>> wrote: >>>>> >>>>>> Like it! Also - in the linked blog post they show how to capture >>>>>> console.log. Would be another good DEBUG-only option. >>>>>> >>>>>> >>>>>> On Tue, Apr 22, 2014 at 11:48 AM, Shazron <shaz...@gmail.com> >> wrote: >>>>>> >>>>>>> Yup, thats what I was thinking as well :) >>>>>>> >>>>>>> Another thing to add through this new method is to catch all JS >>>>> exceptions >>>>>>> and NSLog them natively, but there is already window.onerror, but >>> not >>>>>>> everyone uses it (or knows about it)...could be a DEBUG only >> option >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 22, 2014 at 8:43 AM, Andrew Grieve < >>> agri...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks for pointing this out! Very cool! Would allow for a much >>> more >>>>>>>> performance bridge on iOS. >>>>>>>> >>>>>>>> Maybe we could add it is as an optional bridge mode and let users >>>> that >>>>>>> want >>>>>>>> a faster bridge test the AppStore waters? >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 18, 2014 at 9:38 PM, Brian LeRoux <b...@brian.io> >> wrote: >>>>>>>> >>>>>>>>> This is awesome. >>>>>>>>>> On Apr 18, 2014 12:02 PM, "Shazron" <shaz...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Note: iOS 7 only. >>>>>>>>>> >>>>>>>>>> Two ways to grab the JSContext: >>>>>>>>>> 1. Through KVC of the UIWebView object and key >>>>>>>>>> "documentView.webView.mainFrame.javaScriptContext" [1] >>>>>>>>>> 2. Create a NSObject category for selector >>>>>>>>>> "webView:didCreateJavaScriptContext:forFrame:" [2] >>>>>>>>>> >>>>>>>>>> Usual caveats apply to whether any of these methods is >> acceptable >>>> for >>>>>>>> the >>>>>>>>>> App Store. >>>>>>>>>> >>>>>>>>>> [1] >> http://blog.impathic.com/post/64171814244/true-javascript-uiwebview-integration-in-ios7 >>>>>>>>>> [2] https://github.com/TomSwift/UIWebView-TS_JavaScriptContext >>
