cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From purplecabbage <>
Subject Re: Plugin Hooks on Android
Date Thu, 09 Jan 2014 05:40:24 GMT
I'm with Joe. 
Stay flexible, and future friendly. 
The messages that are posted probably just need to be better documented, or we need to point
plugin devs towards Android's docs. 

Sent from my iPhone

> On Jan 8, 2014, at 9:11 PM, Joe Bowser <> wrote:
>> 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
> more.
>> 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