A consistent listener implementation

James Hugman jhugman at mozilla.com
Wed May 7 14:43:34 PDT 2014


> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/mobile-firefox-dev/attachments/20140507/6047397b/attachment.html>


More information about the mobile-firefox-dev mailing list