A thought that MotionEventSynthesizer can be refactored into a better (or I would say more intuitive?) form dawned on me while trying to remove its dependency on ContentViewCore.
What caught my attention is that we don't have a proper interface for it even though there is an embedder that uses it (VrShell for non-native page). Java object (which is an implementation detail) is exposed directly to embedder. It is used by native, but is created in Java layer and passed as an Java object. That makes the way native side (AndroidUiTarget/SyntheticGestureTarget) uses it a bit odd. i.e. callsites have to use JNI interface directly i.e. Java_MotionEventSynthesizer_setPointer(), etc.
I think this can be improved by following changes:
- Introduce a public interface on native side (content/public/browser/[android/] motion_event_synthesizer.h with a static factory method) so that the object can be created entirely on native side, and keep the rest (the Java and native impl class) implementation details. Maybe possible to move out to ui/.
- It is dependent on CVC/VrShell java layer to be able to access WindowAndroid (eventually to get the right scale factor). Native can handle it better by translating the coordinate to device-dependent physical pixel unit right before passing relevant parameters to Java layer. This helps eliminate the dependency, therefore will allow for the instantiation in the native side.
Any inputs are welcome.
Comment 1 by boliu@chromium.org
, Jun 26 2017