search

stride3d / stride

Stride Game Engine (formerly Xenko)
https://stride3d.net
MIT License
6.32k stars 917 forks source link

[Android] Fix and reimplement user input in EditText control #2302

Closed Basewq closed 2 weeks ago

Basewq commented 3 weeks ago

PR Details

This pull reimplements showing the Android EditText control when a user taps Stride's EditText.

Technical details are: Removed Game.axml - This was what should have been loaded, however in the transition to SDL, xen2 probably encountered some issues and just skipped over it. Based on ancient times when it worked, the native EditText control and the rendering view sat together with a common container, however now SDL sits as the main view and would be a little hacky to try to jimmy it into the Game.axml layout. This implementation avoids this completing by making the native EditText control live on its own layout and is displayed as a PopupWindow. This also has the benefit of not shifting up the rendering view when the soft input (on-screen keyboard) appears.

Old implementation: Emu_EditText_Old

New implementation (left): Emu_EditText_New

New changes include adding an OK button close the popup, however the player can also just tap anywhere on the screen to close it. There's quirk where selection/caret position from the native control is reflected back to Stride's control - this was in the original behavior and is still retained here. Personally I think Stride's control should disable rendering caret/selection in this case since the player should be looking at the native control. This could be a future enhancement. Another change is that when the keyboard shows up, it'll immediate select all the text. The original behavior would just set the caret at the beginning of the text - in my opinion this is the least logical expectation of a user. Probably another enhancement would be to change the behavior of what the initial state should be, eg. SelectAll | CaretAtBegining | CaretAtEnd

Due to SDL, Stride is running on a separate thread from Android UI thread, so most Android EditText method calls are done through its Post method, which ensures it's enqueue to call on the UI thread.

Resource.Designer.cs can now be removed. As of .NET8, the Xamarin build system will generate it all at once in the developer's project.

The stride_popup_edittext.xml lives in the Platforms\Android\ folder. At some point in the future I think all (or most?) platform specific code should be placed in Platforms\[PLATFORM]\, as this actually how .NET MAUI prefers organizing code/assets.

There is a breaking change to GameContextAndroid:

Changed the Android templates so some of the AndroidManifest settings can be moved to [Activity] in GAMENAMEActivity.cs Note that in the 'New implementation' image above, the left using the original/default theme Theme.NoTitleBar.Fullscreen I was tempted to change this to Theme.Material.Light.NoActionBar.Fullscreen (as seen in the right image) to make it look a bit more modern. This theme is only available on API 21 and above (which is already the project's minimum API level). I have withheld this temptation since this is changeable by the developer in their own project, but just pointing out the option is there.

While I have tested this as much as I could, I believe we should make an alpha build to properly test how it behaves as a proper nuget package, as I cannot replicate the entire cross-platform nuget build/packaging that the official system has. This also minimizes the 'it works on my machine' excuse.

A 'working' 4.2 Android project can be found here https://github.com/Basewq/BasewqStrideAndroidTests/tree/main/AndStrideGame

Related Issue

Fixes #2289

Types of changes

Checklist

Eideren commented 3 weeks ago

Building packages through https://teamcity.stride3d.net/buildConfiguration/Package_BuildPackage/25608?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildChangesSection=true you can find them in the artifacts tab once it's done

Basewq commented 3 weeks ago

Thanks for the new package/build, the main thing I was checking for is the stride_popup_edittext.xml to stay in the .aar file and not spill into the other platform's and thankfully it was ok.

I've had to add a new commit to lock a bunch of execution, as it turns out being on the Android UI thread is not safe as editText can be unset by the time it executes due to doing weird swiping actions on the phone.

Eideren commented 2 weeks ago

Thanks !