incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Change to Plugins introduced in Android
Date Mon, 21 Nov 2011 22:12:24 GMT
Sounds like we are trying to write cross-device native plugins. IMO
The 'mechanism' that we use will likely differ from platform to platform,
as it should.

I think that simply defining the fact that native plugins need to listen
for 'interuptionEvents' or 'eventNotifications' or explicit calls to
their 'onMessage'
method should be enough. ( generally I prefer a subscriber model though )

I think it is more important to define the types of
interruptions/events that can occur, and make sure they are all handled.
 ie.
MemoryLow, BatteryLow, DisplayOff, IncomingCall, ...

I am still not completely sold on having this go through our own global
dispatcher.  All platforms already have this mechanism at some level, so it
should already be available to native code in the plugin.

Dave, doesn't the url overloading stuff really just ends being a
declarative interface to the same code. ie, first write the programmatic
interface, then wrap/map the declarative interface to it?

On Mon, Nov 21, 2011 at 1:50 PM, Filip Maj <fil@adobe.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message