incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Johnson <dave.c.john...@gmail.com>
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.

Thoughts?

-dave


On Mon, Nov 21, 2011 at 1:06 PM, Filip Maj <fil@adobe.com> wrote:
>
>
> On 11-11-16 1:47 PM, "Patrick Mueller" <pmuellr@gmail.com> wrote:
>
>>On Thu, Nov 10, 2011 at 12:30, Filip Maj <fil@adobe.com> 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".
>
> 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
>>document
>>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,
>>https://developer.mozilla.org/en/DOM/window.postMessage ).  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
>>http://muellerware.org
>
>

Mime
View raw message