Hi all,
Bug 1307820 and bug 1317604 introduced some big changes to
EventDispatcher recently. I talked about these topics at the Taipei work
week, but haven't sent out an email about these changes yet.
EventDispatcher is now fully unified across Gecko and Java, meaning not
only can you dispatch events Gecko => Java and Java => Java like before,
but you can also dispatch events Java => Gecko and Gecko => Gecko, with
full callback support. "Java" here means Java code running on the
Gecko/UI/background thread, and "Gecko" here means JS/native code
running on the Gecko thread.
Previously, the only good way to interact with JS from Java is to use
XPCOM observers and GeckoAppShell.notifyObservers. Now you can use the
same EventDispatcher.dispatch call on the Java side to dispatch events
to JS. On the JS side, Messaging.jsm now exports `EventDispatcher`,
which is an analog of the Java EventDispatcher. For example, use
`EventDispatcher.instance.registerListener` and `.unregisterListener` to
register/unregister listeners on the JS side.
As part of this change, BundleEventListener is now the only supported
event listener type in Java, and GeckoEventListener and
NativeEventListener are both deprecated. BundleEventListener now uses
org.mozilla.gecko.util.GeckoBundle instead of Bundle. GeckoBundle has
mostly the same interface as Bundle, but fixes several pitfalls when
using Bundle to represent JS objects [1].
In addition to the global EventDispatcher (accessible through
`EventDispatcher.getInstance` in Java and `EventDispatcher.instance` in
JS), each GeckoView instance now has its own independent EventDispatcher
(accessible through `GeckoView.getEventDispatcher` in Java and
`EventDispatcher.for` in JS [2]). Having a per-GeckoView EventDispatcher
makes it a lot easier to support multiple GeckoView instances. Note that
the various EventDispatcher instances are totally separate from each
other, and don't interact with each other in any way.
For Fennec Java code, anything in GeckoApp or included from GeckoApp
should now use the per-GeckoView EventDispatcher [3]. Everything else,
including BrowserApp, should continue to use the global EventDispatcher,
because the majority of existing code only cope well with the global
instance.
For Fennec JS code, use `GlobalEventDispatcher` and
`WindowEventDispatcher` as shortcuts if you're inside browser.js or a
script included from browser.js. Outside of browser.js, use
Messaging.jsm directly, or find the browser window first [4].
My slides from the Taipei work week [5] include some more explanations
of the new EventDispatcher, along with code samples in Java and JS. Feel
free to contact me if you have further questions. Thanks!
Cheers,
Jim
[1] e.g. Bundle distinguishes between int and double, whereas a JS
object doesn't; GeckoBundle will automatically convert between int and
double if necessary to avoid type mismatching.
[2] `EventDispatcher.for` accepts a `window` argument, which should be a
global window object in a chrome JS script.
[3] GeckoApp exposes the per-GeckoView EventDispatcher through
GeckoApp.getAppEventDispatcher (instance method for when you have a
GeckoApp instance) or GeckoApp.getEventDispatcher (static method for
when you don't have a direct GeckoApp instance).
[4] e.g. `let win =
Services.wm.getMostRecentWindow("navigator:browser");` and then use
`win.GlobalEventDispatcher` or `win.WindowEventDispatcher`.
[5]
https://docs.google.com/presentation/d/1u9KtHjio34BOagGaDNqA7lWhTY5PEpMQ-ztl_oLn-48/edit?usp=sharing#slide=id.g194a71d8b9_1_113
_______________________________________________
mobile-firefox-dev mailing list
mobile-firefox-dev@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
