The point is, if it is certain to not pass review, why do any work at all?
Lets just hack this into one project (heck, if they are using static
analysis, it doesn't even need to implement the bridge, just issue the
calls), and see what they say.
-Michal
On Tue, Apr 22, 2014 at 2:43 PM, Shazron
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
+1 to test first.
Any other path is risky IMHO.
Sent from my iPhone
> On Apr 22, 2014, at 11:27 AM, Shazron 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
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 wrote:
> Put it behind a compile-time flag? Implement it as a plugin?
>
>
> On Tue, Apr 22, 2014 at 1:56 PM, Michal Mocny wrote:
>
> > Anyone have an app up on the
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/CordovaLi
Put it behind a compile-time flag? Implement it as a plugin?
On Tue, Apr 22, 2014 at 1:56 PM, Michal Mocny 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 >wrote:
>
> > We would need to be care
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 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
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
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 wrote:
> Like it! Also - in the linked blog post they show how to capture
> console.log. Would be anoth
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 wrote:
> Yup, thats what I was thinking as well :)
>
> Another thing to add through this new method is to catch all JS exceptions
> an
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 G
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 wrote:
> This is awesome.
> On Apr
This is awesome.
On Apr 18, 2014 12:02 PM, "Shazron" 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:didCreateJavaScript
13 matches
Mail list logo
