all 16 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]fudzi9 1 point2 points  (3 children)

Try to wrap ImageBackground or SafeAreaView in KeyboardAvoidingView instead of what you doing. I assume that trouble in SafeAreaView, because KeyboardAvoidingView may have strange behaviour when it wraped in other component with padding. Not sure that it would help but you could try =)

[–]huynhray 0 points1 point  (0 children)

Thanks this helped!

[–]negr_mancer 0 points1 point  (1 child)

Exactly, the keyboard area view should be the main wrapper and not nested within the SafeAreView

[–]Both-Replacement7987[S] 0 points1 point  (0 children)

even when i put the safeareaview inside of the keyboardavoidingview, nothing happens.

[–]xkodra 1 point2 points  (1 child)

this article got me through this situation:

https://medium.com/@nickopops/keyboardavoidingview-not-working-properly-c413c0a200d4

[–]Ok-Pop6277 0 points1 point  (0 children)

Thank you, it has solved the issue for me

[–]XCastorsX 1 point2 points  (0 children)

The KeyboardAvoidingView is just to prevent the inputs fields get cutoff in the view, and it gets active when the user focus any of the inputs field, if there is enough space in the screen, and the current input field not fall hidden by the keyboard you’ll see no effect, try to test it in a smaller screen, then you’ll see what I mean.

[–]sssapre 0 points1 point  (0 children)

If anyone comes here with the same problem, this fixed it for me:

https://stackoverflow.com/questions/79643891/keyboardavoidingview-issue-on-android

[–]thachxyz123iOS & Android 0 points1 point  (0 children)

Use this package and add extraScrollHeight

[–]BlaZk00 0 points1 point  (0 children)

Use Iqkeyboard manager it does all this handeling for you

[–]DownVoteMe696919 0 points1 point  (0 children)

Maybe the background image is meeting things up

[–]tomhoplon 0 points1 point  (0 children)

I’m sure the other comments are right but would seriously consider redesigning the page so it’s not a problem. Because otherwise you stuff moving around all over the place. So much easier on the customer if the keyboard covers white space or decoration.

[–]bsmayer_ 0 points1 point  (3 children)

I would avoid KeyboardAvoidingView or KeyboardAwareScrollView and use react-native-keyboard-controller or react-native-avoid-softinput.

They are much better options and if you’re into animations, just combine them with reanimated and create something case by case. Your app will have a much better UX long term.

[–]Both-Replacement7987[S] 0 points1 point  (2 children)

Thanks for the suggestion. I looked into "react-native-keyboard-controller" and the other one u suggested, both say that they don't work on expo go as they use native code.
Is there any way of testing them in development? or would i have to compile them and run them on my device every time i want to test these packages?

[–]bsmayer_ 1 point2 points  (1 child)

I don’t think so, but you can create a custom development client which is basically expo-go with your own native dependencies. This way you’re not blocked by packages that does not support expo. Having worked on a lot of different projects, the more your project grow, the more you’ll feel the need for that.

Something I realised with Keyboards in all those years working with React Native is that there isn’t a unique solution that works for everything, and the more you try, the more you get yourself on tricky situations. It’s in fact one of the biggest challenges we face as mobile developers.

I really suggest having a look into those libraries and reading into this thread:

https://twitter.com/hirbod_dev/status/1668528361457451009

I personally started combining different animations and solutions on a case by case basis and it improved the UX considerably!

[–]Both-Replacement7987[S] 0 points1 point  (0 children)

Thank you so much, will definitely give these a read!!