iOS already has this support since 1.0 - it receives system events and can register observe any other events that it wants to know about: https://github.com/callback/callback-ios/blob/master/PhoneGapLib/Classes/PGPlugin.m (see the init function)
The event names are just constant strings. On Wed, Nov 16, 2011 at 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". > > 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. > > 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. > > 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. > > 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. > > -- > Patrick Mueller > http://muellerware.org >
