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 > >
