* PhoneGap Native Bridge

Posted on August 13th, 2010 by Dave Johnson. Filed under JavaScript, mobile, phonegap.


The “native bridge” is the secret sauce of PhoneGap and is what allows JavaScript in an embedded browser talk to native code and vice-versa.

On every platform we do this differently depending on what features that native browser has. Here is the list of platforms and how we do it.

iPhone: To communicate from JavaScript to native we call window.location = “gap://Class.method/args” and then intercept the url in native code and parse our the parameters. The class / method is then dynamically loaded / called. To call JavaScript from native we use UIWebView.stringByEvaluatingJavaScriptFromString.

Android: Communication from JavaScript to native takes advantage of the native WebView.addJavascriptInterface to expose Java objects directly to JavaScript. To call JavaScript from native we currently use WebView.loadUrl(”javascript:…”) but that has some problems so we are soon moving over to polling a Java message queue calling a local HTTP server via a long-lived XHR connection.

BlackBerry 4.x: document.cookie is the only way to talk between JavaScript and native. JavaScript sets the cookie for native to read and JavaScript polls the cookie for messages from native. Fucking elegant!

BlackBerry Widgets: Astoundingly the new BlackBerry Widgets SDK is pretty damn nice. You can expose Java objects to JavaScript with ScriptEngine.addExtension and you can call JavaScript from native with ScriptEngine.executeScript. The context for the JavaScript execution can even be specified. Seriously great work there.

QT: This one is not quite ready but it will use the QWebFrame.addToJavaScriptWindowObject to expose native objects to JavaScript and will likely use polling of those exposed native objects to get data back into JavaScript - much like the Android approach

Windows Phone 7: There is something called window.external.Notify in the browser (mapped to a native object through the ScriptNotify event) on Windows Phone 7 that we use to send messages into native code. Going the other way there is WebBrowser.InvokeScript.

webOS, WRT: The platforms that are just JavaScript don’t have any native code. Well, we might look into the native side of webOS one day but no time soon.

In an attempt to clean up the PhoneGap JavaScript API a bit, I have isolated all the places that we communicate from JavaScript to native code and put it into a single PhoneGap class. I am now in the process of converting over all the JavaScript to use this new PhoneGap interface and then most of the PhoneGap JavaScript will be completely cross platform. Any call to native code now has to go through the PhoneGap.exec() JavaScript method. The new code is up on Github and with any luck all the platforms will be using it soon!

Image by hb2

Tags: , ,



5 Responses to “PhoneGap Native Bridge”

  1. Dan Mayer Says:

    Very cool. I look forward to everything being a bit more uniform.

    Getting everything on the same page, should make it a bit easier to follow common conventions to adding additional features. Since IPhone has some cool iPhone only stuff, following a convention for say a image that is used during app bootup, etc.

  2. JJ Rohrer Says:

    Nice summary which is very helpful for those of us interested in extending phonegap. I like knowing what I’m getting myself Into.

  3. links for 2010-08-16 at adam hoyle presents suckmypixel Says:

    [...] null is not an object » Blog Archive » PhoneGap Native Bridge The “native bridge” is the secret sauce of PhoneGap and is what allows JavaScript in an embedded browser talk to native code and vice-versa. On every platform we do this differently depending on what features that native browser has. Here is the list of platforms and how we do it. (tags: phonegap iphone android javascript objective-c) [...]

  4. kahaan Says:

    Hi,

    You described about implementation on android as below:

    “… To call JavaScript from native we currently use WebView.loadUrl(”javascript:…”) but that has some problems so we are soon moving over to polling a Java message queue calling a local HTTP server via a long-lived XHR connection.”

    May I know what exactly is/are the problem(s) you are talking about?

  5. Dave Johnson Says:

    @kahaan loadUrl causes the browser, and therefore form fields in etc in your app, to lose focus.

Trackback URI | Comments RSS

Leave a Reply