search

nickffox / KeyboardObserving

⌨️A Combine-based way to observe and adjust for Keyboard notifications in SwiftUI
MIT License
482 stars 36 forks source link

Adds flexible offset parameter #9

Closed JulianKahnert closed 4 years ago

JulianKahnert commented 4 years ago

Hi @nickffox, thank you for this project. 🙂 Your solution is so simple and elegant! I need a bit more flexibility and added an offset variable. What do you think about it?

nickffox commented 4 years ago

Hey @JulianKahnert thanks for the contribution!

Can you help me understand why you would like this added to the framework? Is there a use case where the current implementation isn't working for you?

JulianKahnert commented 4 years ago

Hi @nickffox , Thanks for your response. 😊 I am currently using this, because otherwise the inputView above the keyboard is directly under TextField, which looks a little squashed to me. That’s why I wanted a bit more flexibility. I added this without breaking the current api.

Sent with GitHawk

nickffox commented 4 years ago

@JulianKahnert can you share a screenshot of your issue?

My stance has been that the role of this library should be to adjust the size of the content view so that it's not obscured by the keyboard. Adjusting the way content is arranged in that content view should be the responsibility of the view being presented.

Take a look at this gist for an example: https://gist.github.com/nickffox/7606965ff9737deab80fd3e0dbba27c4

JulianKahnert commented 4 years ago

Hi, your example works perfectly, but I still have this issue. It seems to be a problem when multiple UIViewRepresentable view are in one VStack, like here. CustomTextField and PDFCustomView and two UIViewRepresentables and suddenly the keyboard input view overlaps the CustomTextField. If I use the CustomTextField in your example, everything gets layouted correclty until I add another UIViewRepresentable. Now I am not sure if this is a problem with the current state of SwiftUI or my fault. 🤨🤔

nickffox commented 4 years ago

Thanks for providing the code sample! I’ll take a look tonight or tomorrow. I want to verify your issue, check the layout frames in the view inspector, and make sure the issue isn’t caused by my choice to ignore safe area rather than subtract it from the keyboard height.

Assuming my findings match yours, I’ll merge this PR since this isn’t the first time this has been requested (see #4) and I prefer the default value proposed in this PR.

Thanks again for this work, and for collaborating with me as I try to understand your motivation for the change!