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" <[email protected]> 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 <[email protected]> wrote: >> >> >> On 11-11-16 1:47 PM, "Patrick Mueller" <[email protected]> wrote: >> >>>On Thu, Nov 10, 2011 at 12:30, Filip Maj <[email protected]> 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 >> >>
