incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
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" <dave.c.johnson@gmail.com> 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.
>
>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