input: Split out InputEventJava into Motion and Key with Deref
#503
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When I implemented the `from_java()` constructors for `MotionEvent` and `KeyEvent` in #456, I used a single `InputEventJava` wrapper since that could wrap the existing `enum InputEvent` and only need a single destructor calling `AInputEvent_release()` (which must only be called when the input event was created from Java). This however requires existing callers to `MotionEvent::from_java()` and `KeyEvent::from_java()` to _unwrap_/unpack that nested `enum InputEvent` again in order to get access to the underlying native methods, despite already calling a specific constructor method (since Android makes a distinction between both types). Not that that is even reachable, since the nested `InputEvent` member was private and there was no `Deref` into `&InputEvent` anywhere making it impossible to use this API in any meaningful way. Solve both issues by splitting the `struct` into a `Motion` and `Key` variant, and implement `Deref` on both to their respective type. No wrapper `InputEventJava` remains since there does not appear to be any reason to pass both of these types into a single API.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #502
When I implemented the
from_java()constructors forMotionEventandKeyEventin #456, I used a singleInputEventJavawrapper since that could wrap the existingenum InputEventand only need a single destructor callingAInputEvent_release()(which must only be called when the input event was created from Java).This however requires existing callers to
MotionEvent::from_java()andKeyEvent::from_java()to unwrap/unpack that nestedenum InputEventagain in order to get access to the underlying native methods, despite already calling a specific constructor method (since Android makes a distinction between both types).Not that that is even reachable, since the nested
InputEventmember was private and there was noDerefinto&InputEventanywhere making it impossible to use this API in any meaningful way.Solve both issues by splitting the
structinto aMotionandKeyvariant, and implementDerefon both to their respective type. No wrapperInputEventJavaremains since there does not appear to be any reason to pass both of these types into a single API.