I don't know. I like easy to create messages. Creating a calss for all
message types is Java's way of adding coupling back into an event bus.
Boooo Java!
Agreed. However, I prefer annotated methods over a generic single method
interface: i.e. the event bus should do the routing to the method that
does the work, rather than devs adding yet another else if in a
handleMessage() method.
Indeed. Message (event) buses are for messages (events) and not to
replicate functions. If you find yourself creating a "return" message
(event) you might be using the wrong tool.
I think the time we considered sendMessageToJava and sendEventToGecko as
a message bus passed has long since passed. :)
On 5/7/14, 5:07 AM, Mark Finkle wrote:
Message Bus or Event Bus or Publish / Subscribe or Subject / Observer
Great for decoupling code. Gecko implements this in nsIObserverService
and we have our own messaging system for JS <-> Java. It works well.
We fall down when dealing with Java-only communication. We created a
multi-listener in Tabs.java with the OnTabsChangedListener and it's
not as nice as we'd like:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/Tabs.java#535
------------------------------------------------------------------------
My initial response that any generalization of Event Listening is
indistinguishable from an EventBus.
Agreed
I'm generally in favour of EventBuses, but would raise two points
which have bitten me in the past:
* if the event bus / generalized listener manager is does not
handle threading, then this leads to a class of threading bugs. I
ding Otto for this reason (here's a PR implementing that behaviour
<https://github.com/square/otto/pull/72>).
* keeping the wiring separate and away from the implementation.
* some careful thought needs to go into making sure we're not
chucking around undifferentiated/untyped message or data objects.
Otto is pretty good for this, but probably a bit too simple.
I don't know. I like easy to create messages. Creating a calss for all
message types is Java's way of adding coupling back into an event bus.
Boooo Java!
perhaps it's time to start thinking about consistent use of messaging
for inter-component communication.
The new NativeJSObject stuff in the new sendMessageToJava is a
good start, though there is too much registering, deregistering
and switching for my tastes.
My f2f discussions with mfinkle would indicate he's not impressed
by more RPC type implementations.
Indeed. Message (event) buses are for messages (events) and not to
replicate functions. If you find yourself creating a "return" message
(event) you might be using the wrong tool.
That said, I'm OK with look into a message bus for the Java-only code.
Use moderation. If we see messages (events) being used willy-nilly, we
should clamp down. Don't throw away actual valid uses for OO
encapsulation, there are so few of them to begin with.
_______________________________________________
mobile-firefox-dev mailing list
mobile-firefox-dev@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
