Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable AdjustPan and AdjustResize behavior for iOS as well as Android #11979

Open
Tracked by #16799 ...
PureWeen opened this issue Dec 8, 2022 · 2 comments
Open
Tracked by #16799 ...

Comments

@PureWeen
Copy link
Member

PureWeen commented Dec 8, 2022

Description

Currently we have a platform specific for WindowSoftInputModeAdjust that maps directly to Android level properties.

For the most part, we replicate (or are in the process of replicating) a lot of the keyboard interaction that Android provides out of the box to iOS so this API will help round that out.

This will be a way to toggle between the behavior implemented here here that will "Scroll" your content into view vs just "resizing" the view window.

This property should be available at the Window/Shell level

AdjustPan example and why AdjustResize is relevant on Android. You'll notice I can't get back to the top Entry field. This is very annoying if you're trying to implement a chat app.

2022-12-08_15-14-24

Still to investigate

  • This property is a bit more relevant on Android because AdjustPan shifts the entire window up when the SoftKeyBoard opens. This makes it so fields at the top of your screen are unreachable. If you have content in a ScrollView and your window gets panned from the keyboard opening, then you are unable to reach any of the content at the top of your screen. Think about how annoying the current behavior is if someone is implementing a Chat App.

  • On iOS we aren't going to be panning the entire window, so the relevance of this property does need to be investigated a little bit more. Is it useful on iOS to resize the view pane vs just scroll the scroll view? Is this scenario mainly relevant if the user doesn't have a ScrollView? What's our solution going to be on iOS if user doesn't have a ScrollView (currently on Xamarin.Forms scrolling the entry into view only works on iOS if your content is inside a ScrollView)

  • Is there overlap here with Safe Areas? For example, when the soft keyboard opens does that influence safe area insets at all and we should more be approaching this from a Safe Area standpoint?

  • Is this the wrong approach completely and we should just add some properties to ScrollView. We could add a property to ScrollView to indicate that it should just adjust its insets based on the presence of the keyboard.

(Public) API Changes

Move current WindowSoftInputModeAdjust platform specific to an attached property that's available to everyone!

Usage Scenarios

Window Attached Property

Window property (maybe)

    window.WindowSoftInputModeAdjust="AdjustPan"

Non-Shell Scenarios (also should work if using shell)

<ContentPage Window.WindowSoftInputModeAdjust="AdjustPan">

Shell property

Shell has these types of properties already so for consistency we should expose this through a shell attached property as well

<ContentPage Shell.WindowSoftInputModeAdjust="AdjustPan">

TextInput property?

Maybe this is a property you'd want to configure on each input field?

<Entry Window.WindowSoftInputModeAdjust="AdjustPan">

Backward Compatibility

N/A

Difficulty

Medium

@PureWeen
Copy link
Member Author

Related #16398

@samhouts samhouts added backport/approved After some discussion or review, this PR or change was approved to be backported. platform/android 🤖 and removed legacy-area-controls Label, Button, CheckBox, Slider, Stepper, Switch, Picker, Entry, Editor backport/approved After some discussion or review, this PR or change was approved to be backported. labels Jan 31, 2024
@tj-devel709
Copy link
Member

tj-devel709 commented Sep 9, 2024

One way we can do this, in the case where we have a non-scrollView at the top of the ContentPage, is to replace the ContentPage's Subview with a scrollview that has the size of the original ContentPage's Subview minus the size of the keyboard. In my example, the animations may be able to be improved as it looks pretty choppy, but functional:

Screen.Recording.2024-09-09.at.2.53.58.PM.mov

By doing this, we are able to still access the full page including that top label and still access things below the editor.

Branch with these changes - https://github.com/dotnet/maui/tree/dev/TJ/keyboardScroll-Inset-Improvements_1_AdjustResize

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants