Breaking out a discussion Joe & I started on
https://issues.apache.org/jira/browse/CB-5351.
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
CordovaPlugin.java
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).
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 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)
