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 <[email protected]>wrote: > Put it behind a compile-time flag? Implement it as a plugin? > > > On Tue, Apr 22, 2014 at 1:56 PM, Michal Mocny <[email protected]> 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 <[email protected] > > >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 <[email protected]> > > 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 <[email protected]> > > > 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 <[email protected]> > 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 < > > [email protected]> > > > > >> 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 <[email protected]> > wrote: > > > > >>> > > > > >>>> This is awesome. > > > > >>>> On Apr 18, 2014 12:02 PM, "Shazron" <[email protected]> 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 > > > > >>>>> > > > > >>>> > > > > >>> > > > > >> > > > > > > > > > > > > > >
