Brian - Yes they can, as I have theoretically proposed - but that property I showed is readonly, but this being Objective-C and the ability to use KVC, that won't stop us... Jesse - testing is a given, there shouldn't be any other way - isolating it as a plugin would give us this so it won't be in the core (labs?).
On Tue, Apr 22, 2014 at 11:35 AM, Brian LeRoux <b...@brian.io> wrote: > can bridges be plugins? (if not: they totally should be / what an awesome > feature) > > > 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 > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > > >