incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: Change to Plugins introduced in Android
Date Wed, 16 Nov 2011 22:11:39 GMT
iOS already has this support since 1.0 - it receives system events and
can register observe any other events that it wants to know about:
(see the init function)

The event names are just constant strings.

On Wed, Nov 16, 2011 at 1:47 PM, Patrick Mueller <> wrote:
> On Thu, Nov 10, 2011 at 12:30, Filip Maj <> wrote:
>> The reason I'm posting this is because we want to keep our plugin
>> interfaces aligned across platforms. It would be great if the other
>> platforms implemented this as well. Also would love to hear what the rest
>> of the team thinks of this change.
> I like the concept, but think perhaps the API could be changed a bit.
> Suggest that Plugins can implement a method Plugin::onMessage(String id,
> Object data) as suggested, which will be invoked when a message is
> "posted".  In addition, Plugins implement (via superclass) a method
> Plugin::postMessage(String id, Object data).  Looks like it's currently
> called onMessage() and implemented on PluginManager.  Why expose another
> class (PluginManager) when we can put this in the Plugin itself?  And why
> call an API that sends a message "onMessage".
> We should agree on the synchroncity of postMessage() and onMessage()
> invocations and document them in the source comments.  Does postMessage()
> not return until all plugins are sent onMessage()?  Or are these
> asynchronous?  I think synchronous makes sense, and then we should document
> that onMessage() invocations are blocking the main thread, so shouldn't do
> long-running tasks.
> Rather than send every event to every plugin, perhaps plugins should
> indicate that they wish to receive events.  Another API perhaps:
> Plugin::listenForMessages(boolean).  Don't listen, we won't send messages.
>  Not sure it's worth it.
> We should consider how the id's should be namespaced.
> We should be documenting for each plugin which id's they send and respond
> to.  Doesn't need to be in the user docs (obviously), but does need to be
> documented somewhere.  I guess code comments will be good enough for now.
> In terms of the naming of the APIs themselves, there may be some confusion
> as folks may confuse these names with ones available in the DOM (eg,
> ).  My only
> suggestion, which I'm not immediately happy with, is to stuff the string
> "Plugin" into the APIs: onPluginMessage() and postPluginMessage().  I
> dunno, maybe not so horrible.
> --
> Patrick Mueller

View raw message