cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: Plugin Hooks on Android
Date Thu, 09 Jan 2014 05:11:17 GMT
On Wed, Jan 8, 2014 at 6:58 PM, Andrew Grieve <> wrote:
> Breaking out a discussion Joe & I started on
> Some plugin hooks on Android are made available as functions on the
> CordovaPlugin class. If you are interested in the hook, you override
> the function.
> Some hooks are made available through the onMessage(String name,
> Object obj) function. Examples that I could find:
> postMessage("spinner", "stop");
> postMessage("exit", null);
> postMessage("splashscreen", "show");
> postMessage("onScrollChanged", myEvent); <-- data is a custom class
> postMessage("onPageFinished", url);
> postMessage("onPageStarted", url);
> postMessage("onReceivedError", data); <-- data is a JSONObject
> postMessage("onCreateOptionsMenu", menu); <-- a Menu object
> postMessage("onPrepareOptionsMenu", menu);  <-- a Menu object
> postMessage("onOptionsItemSelected", item); <-- a MenuItem object
> The split seems about 50/50.
> Now, what I'd like to propose is that we do away with postMessage
> pattern. Reasons:
> 1. It will make what hooks exist much more discoverable
>   - Right now there's no list of what postMessages exist within

I disagree!  I personally prefer this pattern and think that we should
keep this pattern instead of adding hundreds of hooks that do the same
thing, because it's easier to test postMessage than it is to test the
possibly hundreds of hooks.  Does every plugin need it's own special
hook, or can plugins that extend activities take advantage of
postMessage and onMessage?  I think that this reduces the API's
flexibility.  Forcing people to have to request a special hook for
their plugin is going to suck.  For example, right now the author of
this issue can work around not having onOptionsMenu working by adding
the postMessages to his custom activity, and it's a relatively small,
non-intrusive amount of code.  If we were doing plugin hooks, they'd
have to change plugin and it could break all the plugins.

I do think all the messages being posted need to be documented, but I
do think that this is a far more flexible solution than adding tons of
hooks to and making plugin developers lives suck even

> 2. It will make hook parameters typed
>   - Right now you need to cast the second parameter of postMessage to
> use it (e.g. to Menu, MenuItem, ScrollEvent, String, JSONObject).

Why do they need to be typed?  The plugin author should know what
they're expecting back if they're listening to the message that's
being passed.  Also, how do you deal with multiple plugins that do the
same thing?

> 3. Hooks can have multiple parameters
>   - This would make sense for onScrollChanged and onReceivedError,
> which use a custom object and a JSONObject to pass multiple params.

I don't think this is a compelling argument, since this will be things
that I'll have to write tests for.

> I actually didn't know half of these hooks existed, so I think even
> just #1 is really compelling. We'd obviously need to keep delivering
> these message for backwards-compatibility (except for maybe scroll -
> it's pretty new)

Honestly, I think that onMessage and postMessage are more flexible and
are better than the alternative, which is to create hooks for
everything, which will all have to have their own tests, and which
will mean even more changes to plugins, which could break plugins and
make the lives of the people who have to write APIs with our stuff
suck even more.  This is at least another ten hooks that we're looking
to add here, perhaps more.  It also means that if someone wants to
extend this, they'll have to file another issue to get a hook added
instead of just using postMessage and onMessage.  That's why I think
this change is bad for the plugin developer, since this makes us even
more of a bottleneck than we are now.

View raw message