incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Johnson <>
Subject Re: Change to Plugins introduced in Android
Date Mon, 21 Nov 2011 21:47:48 GMT
I like the idea of a messaging API but the first thing that came to my
mind was that we should be using a generic mechanism like web intents
for this.

On Android we have the ability configure a plugin such that the
onOverrideUrlLoading(String url) method is called (handleOpenUrl I
think on iOS) when a URL is loaded that matches (could be regex or
whatever) one that is listed in the plugin configuration xml / plist.

This is also a common way to communicate on most platforms. iOS of
course supports the handling of specific URIs and intents on Android
are pretty much the same thing.



On Mon, Nov 21, 2011 at 1:06 PM, Filip Maj <> wrote:
> On 11-11-16 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
>>> 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".
> Agree with this. Keep it to the Plugin interface and name it postMessage.
>>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
>>that onMessage() invocations are blocking the main thread, so shouldn't do
>>long-running tasks.
> Conceptually I think this is no different than making a call into plugins
> from JS. I would lean towards async mechanics. Some plugins may need to do
> long-running tasks when handling messages. This kind of reminds me of the
> discussion we had initially about plugins, whether they are sync/async. We
> quickly realized that async is the way to go. The project in incubation is
> called callback, after all ;)
>>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.
> +1; set this to false as default and then plugin authors can change +
> implement onMessage/postMessage when they need 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.
> Good enough for now, maybe something that should be discussed once we get
> into plugin packaging.
>>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.
> A bit more verbose, not a big deal I think. Either way works IMO.
>>Patrick Mueller

View raw message