incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Change to Plugins introduced in Android
Date Mon, 21 Nov 2011 21:50:46 GMT
So what would be required in that? Just a specification for the data
object that is passed to onMessage ?

On 11-11-21 1:47 PM, "Dave Johnson" <> wrote:

>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
>>>call an API that sends a message "onMessage".
>> Agree with this. Keep it to the Plugin interface and name it
>>>We should agree on the synchroncity of postMessage() and onMessage()
>>>invocations and document them in the source comments.  Does
>>>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
>>>long-running tasks.
>> Conceptually I think this is no different than making a call into
>> from JS. I would lean towards async mechanics. Some plugins may need to
>> long-running tasks when handling messages. This kind of reminds me of
>> discussion we had initially about plugins, whether they are sync/async.
>> quickly realized that async is the way to go. The project in incubation
>> 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
>>> 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
>>>to.  Doesn't need to be in the user docs (obviously), but does need to
>>>documented somewhere.  I guess code comments will be good enough for
>> Good enough for now, maybe something that should be discussed once we
>> into plugin packaging.
>>>In terms of the naming of the APIs themselves, there may be some
>>>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