feat: Android adapter #500
Open
Conversation
This file contains 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
…_winit Android backend
…tangle. But NativeActivity seems to be sabotaging this.
…k text traversal problem, which now appears to be a bug in TalkBack. But also be more consistent about only exposing text selection when the node is focused, because that does seem to be what TalkBack expects.
… design rationale
…ot trying to work with NativeActivity
…n't try to make the examples runnable on Android using cargo-apk
…ger than I remembered; update the documentation to reflect that
… Windows problem with 0.30.6 and 0.30.7. And update wayland-cursor to get the Linux build working.
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.
I think the Android adapter is now complete enough to start reviewing.
My current main test case and demo for this adapter is this sample project, which uses a slightly modified version of
GameActivity: https://github.com/[mwcampbell/xilem-to-do-mvc-android](https://github.com/mwcampbell/xilem-to-do-mvc-android)We may debate the division of responsibilities between the native and Java code. Perhaps it would be better if more things were implemented on the native side. To some extent, I just implemented things on the Java side when it was more convenient to write them in Java because of the number of Java method calls required. But I think there's also some logic to my decisions. For example, the current Java implementations of the various event-sending methods post asynchronous requests to the UI thread, but one could imagine an alternate implementation that assumes it's being called on the UI thread and sends the events synchronously. The lower-level
Adaptertype is designed to support such alternate implementations, as mentioned in that types documentation, though no such implementations exist yet (as they'd require a different Android activity class and using something other than winit). I also thought it made sense to store Android-specific state, such as the accessibility focus and current hover (explore-by-touch) node, on the Java side, but am willing to revisit that.I guess we should have CI tasks to verify the Java code formatting and check that the prebuilt
.dexfile matches the source code. I included the script I'm using to build the.dex. It works on my Mac with my particular Android SDK installation. I don't know if it's really necessary to target Java 7, but I remembered reading that Java 8 and above required some tools for desugaring lambdas and possibly other newer features, and I didn't want to try to figure out how to make that work outside of a typical Gradle project. As for whether we should actually use a typical Gradle project, I don't know if that can build a.dexoutside the context of a full Android application.