A couple of changes to this API just landed in bug 989098: 1) EventDispatcher#sendResponse and EventDispatcher#sendError now accept a regular Object instead of a JSONObject. That means it's now valid to send a response that is null, a String, a JSONArray, etc. -- any of the types supported by JSONObject#put (http://developer.android.com/reference/org/json/JSONObject.html#put%28java.lang.String,%20java.lang.Object%29).
2) On the Gecko side, the sendMessageToJava callback is now given the JS type equivalent, so it is no longer a JSON string. In other words, you don't have to call JSON.parse() on the response data; you can just use the data directly. Brian On Fri, Feb 14, 2014 at 11:10 AM, Wesley Johnston <[email protected]> wrote: > I finally landed patches today to kill off the GeckoEventResponder class in > Java. You can no longer synchronously return values from the Java UI to the > JS frontend. This is part of a bigger effort to move all of the Java event > handling off of the Gecko thread. It also adds some facilities for error > handling that isn't used yet, but is available if you want/need it. > > === Details === > > You could previously write code in Javascript that looked something like: > > var data = sendMessageToJava({}); > // data is a string of response information > > These patches remove the return value you could receive from this function. > Since sendMesageToJava is something we'd defined in multiples through the > tree. I also moved it into its own helper .jsm called Messaging.jsm. It now > takes an optional second callback argument. i.e. the above code would be > written: > > Cu.import("resource://gre/modules/Messaging.jsm"); > sendMessageToJava({}, (data, error) => { > // if successful data is a JSON string of response information. Otherwise > data is null > // if failed, error is a JSON string of response information. Otherwise > error is null > }); > > If you love promises, you can still use them, but you'll have to wrap them > yourself. On the Java side, return values are sent using a static > sendResponse method in EventDispatcher.java that takes the original message > (so that it knows who to respond to), and a second object with data to send > back to the caller. i.e. a flow might look like: > > public MyClass implements GeckoEventListener { > > @Override > public void handleMessage(String event, JSONObject message) { > try { > JSONObject ret = new JSONObject(); > // add whatever you want to return to the ret object > EventDispatcher.sendResponse(message, ret); > } catch(Exception ex) { > try { > JSONObject err = new JSONObject(); > // fill in error details > EventDispatcher.sendError(message, err); > } catch(Exception ex) { } > } > } > > } > > Note, as part of this I also moved EventDispatcher out of the > org.mozilla.gecko.utils package and into the org.mozilla.gecko one. You can > (currently) still access and make calls into it through > GeckoAppShell.getEventDispatcher() (although I'd like to remove that at some > point). There are probably still a few places in the codebase where we've > reimplemented asynchronous response handlers. It would be nice to move them > all to the new system if can. If you know of anything, please file bugs and > cc me. > > Thanks, > - Wes > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
