RFC WMP1: Recognising # of native WebView Touches

[Philzen]

Problem

Although WMP's aim for 1.0 is to provide a complete touch event implementation - so any browser app would virtually see exactly the same events than it would get on a tablet running 4.x for instance - under the given the performance-implications of a 2.x device it would be best, if not crucial, that WMP can sort-of disable itself when running on a phone that runs the number of touches the developer requires (by setting maxPolyfillTouches - a variable to be introduced and exposed via public getters/setters both in Java and JS API very soon).

Also WMP currently - with polyfillAllTouches set to true - can only assume that only the first touch was implemented, and has no means of deciding whether the device may already have two touches enabled on the WebView (which would mean one touch less to polyfill which in theory will be more efficient).

Questions

1. Is there any known DeviceInfo in Android that may be read in a reliable fashion in order to determine the number of simultaneous touch events that are enabled on a WebView? Beginning with API Level 5, such information is available - though it might be questionable that 100% of all phones have this set correctly by the manufacturer
2. Is there currently any w3c RFC, spec, draft or whatsoever out there which describes a method for HTML5 app developers to tell the client what input methods (i.e. that it needs multitouch)? Or - what about vice-versa (client tells app what input methods it supports, so app may dynamically adjust it's GUI interaction accordingly)? As i'm thinking about this i would be surprised if w3c or some of the big players hasn't at least done some draft on it. Following Question on Stackoverflow
3. Are there any other solution approaches (or even better, implementations) for this problem out there than the one outlined below?

Idea
Given that all of the above questions are dead ends, the proposal goes as follows

• The app enhanced by the WMP WebViewClient starts.
  Apart from checking the API Level (which means WMP disables itself completely if it finds it self on API Level >= 11), the WMP will not know anything about the # of touches to expect, therefore running with polyfillAllTouches set to false
• The injected WMP JS code will register touch event listeners on startup (as currently already does when polyfilling all touches is disabled)
• the event listeners will send back info to a javascript interface method in the WebViewClient whenever touch events occur, containing the identifiers of the touches they receive
• Now, the WebClient will could give the WebView either some time (e.g. 50ms) to answer with the point, or maybe longer, if the WebView was just too busy (now how would one determine that?)
• Each Touch not coming back to the WebViewClient within those defined limits will be "switched on" for polyfilling, until the value defined in maxPolyfillTouches is reached.
• Vice versa, as soon as the number of simultanous touches reaches maxPolyfillTouches, WMP will unregister all it's event handlers on the JS and the Java side to free up those cpu cycles.