Generalize HideSoftInputOnTapped on Android and iOS to support 3rd party input controls

[albyrock87]

Description of Change

Generalize recognition of text inputs in HideSoftInputOnTappedChangedManager so that 3rd party libraries with native handlers can leverage this new feature of ContentPage by simply adding a mapper the same way InputView does.

internal static void MapIsFocused(IViewHandler handler, IView view)
{
	handler
		?.GetService<HideSoftInputOnTappedChangedManager>()
		?.UpdateFocusForView(iv);
}

Unfortunately HideSoftInputOnTappedChangedManager is internal, but they can still use it via reflection.

I know it's suboptimal but I didn't want to change public API.

See more at: https://supportcenter.devexpress.com/ticket/details/t1201718/the-keyboard-remains-visible-on-a-click-outside-editors-even-if-the-contentpage

[ghost]

Hey there @albyrock87! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[PureWeen]

Can you add tests for this?

We have some existing tests for this here.

maui/src/Controls/samples/Controls.Sample.UITests/Issues/HideSoftInputOnTappedPage.cs

Line 9 in 4091224

public class HideSoftInputOnTappedPage : TestContentPage

[albyrock87]

@PureWeen I think existing unit tests already cover this for the following reasons:

• iOS => UISearchBar is generally a UIView which contains an UITextField first responder
• Android => SearchView is a ViewGroup which contains an EditText control
• existing unit tests cover the search bar control

Therefore, the fact that I removed specific reference to UISearchBar and SearchView and everything still works proofs implicitly that:

• Search bar still works
• Generalization works

I don't see what other kind of unit test I should add given that search bar is already an example of a native control which contains a text editor.

[jurganson]

Bump!

[AlexGoOn]

Hello,
We are working on DevExpress .NET MAUI components, and functionality in our editors depend on this pull request. Could you kindly provide information on whether there are plans to incorporate it into .NET 8? This clarification is crucial for our ongoing work, as it will help us determine whether we can afford to wait for an update or if we should proceed with implementing a temporary workaround.

[albyrock87]

@AlexGoOn have you seen the workaround I proposed here?
This is fully working and probably covers even more uses cases than what could be achieved with what I proposed here.
I would like to help the "DevExpress Community" but your support center makes it impossible to comment on other tickets.

I will try to propose a different PR here with that strategy (which is completely different but more effective).
But considering the type of change, I guess it'll eventually end up in .NET 9.

[AlexGoOn]

@albyrock87, thank you very much for your contribution! Yes, we've seen the workaround, and it can definitely be used as a temporary solution by our customers. We've mentioned this technique in the following thread: The Keyboard remains visible on a click outside editors even if the ContentPage.HideSoftInputOnTapped property is enabled

However, the workaround requires overriding a MauiAppCompatActivity method, but we would like to fix the issue on our side so that our customers can get a working solution in the default configuration. That's why we are hoping that this PR will be introduced in .NET. However, .NET 9 is too far away, and I'm afraid too many customers may face the issue until a new version is available.

[albyrock87]

@AlexGoOn if you want to avoid that, you can probably use reflection to add that part of my workaround here:

maui/src/Controls/src/Core/Window/Window.Android.cs

Line 41 in a01e1ee

internal event EventHandler<MotionEvent?>? DispatchTouchEvent;

[PureWeen]

/rebase

[PureWeen]

https://dev.azure.com/xamarin/public/_build/results?buildId=110133&view=results

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

Failing tests are unrelated