Natively, it’s possible to get the keyboard height on iOS when the keyboard is about to be presented on screen. So your suggestion to dispatch a runtime event when this happens sounds feasible.
Yes, or in the began-phase of the textfield listener which is called when the textfield is activated and the keyboard is coming up.
I find knowing the keyboard height very interesting specially to communications app (where you set the textField position to be exactly above the keyboard).
@Skatan, in your case, can’t you just ignore the keyboard and move the activated textBox to be on the 1st half of the screen always? That way you will always guarantee that the textfield will be visible… (I know that this is not the best solution, but it is workaround that we are used to use when developing biz app using Corona)
Sure it would work, but it would look really buggy with a floating textfield in the center of the screen. We’ll have to go with a solution like that for the time being, but my fear is that this will be the final solution we will get for a long time as it will be deemed “fixed” in Corona’s eyes. Finally we get a fix for the keyboard issue that has been troubling us for so long, and all we get is a half-fix that replaces one issue with another.
We’re indeed being challenged with this problem for a communication feature we’ve got in our app.
When I say to set the position of textField to be above the 1st half of the screen, I mean moving the whole scene together, so you will not have the textField misplaced from its background position…
Another “work-around” for communication app (I used it once for an app) is to fix the textField on the top of the screen instead of above the keyboard. Again, it is not ideal, but it is what is possible…
I hear @Skatan’s concern and agree. Once its ticked off as fixed it will be very hard to bring this back to the front burner. In any case, I think whatever behavior is implemented should be controllable programmatically. As in, I can image at times we may not want the screen to move when keyboard pops up. So there should be a parameter to turn off this new feature that will be delivered soon.
Skatan, we’re implementing panning support because that’s the only cross-platform solution there is. On iOS, my understanding is that you can only fetch the keyboard height when it has just been displayed. On Android, there is zero means of fetching the keyboard height, which doesn’t help you from a cross-platform standpoint (the original poster attempted this and failed). So, this makes panning the winning solution. Especially since this is the solution that all native apps use on both iOS and Android anyways and is what Apple and Google recommend.
It would seem to me that if you’re already implementing a “move it above the keyboard” method, then that should still work. If the text field is above the keyboard it shouldn’t move it. Or am I mis-undertanding the problem?
Rob
But Joshua our app is only available on iOS right now… If we ever post it to Android we’d be more than happy to have a somewhat buggy design on there because there is no other possible option. But when this is obviously possible in iOS, why not just return it on iOS and return nil on Android for now (Until Google implements an API for this if they ever do)? Why restrict us to have to have a buggy iOS look and feel because the solution isn’t possible on Android?
Edit: Just want to make clear that I don’t mean drop the cross platform support, just to offer this value in addition to that so there is an awesome solution for all. My point is just when we can access this value on iOS, and it would make a massive difference for anyone using custom backgrounds on textfields, why not just let us be able to access it on iOS and whenever there is a solution for Android support Android as well. Why stifle it on iOS?
The problem is our textfields have custom backgrounds and this animation only moves the textfield on top of the keyboard, the background stays covered. If only we could get the keyboard height in the begin-phase of the textfield that is getting animated for example, we could do the animation by ourselves depending on the keyboard height. Having a forced animation do everything for us seems a bit unnecessary, even if it’s a good cross-platform solution at least for iOS exclusive apps we can obtain the keyboard height and make much better tailored animations.
If you wish to use your own method of scrolling fields into view, you can now include this key-value pair in your build.settings: settings->iphone->plist table:
CoronaWindowLockedWhenKeyboardAppears=true
and that will disable our attempts to move the window into view.
Rob
And then we’re back to square one.
Thanks for the flag to disable this. We already handle it manually in our own app, so that is helpful.
Just a heads up to everyone, there are some bugs with the implementation right now. It doesn’t understand or respect the current orientation with regards to how it adjust the window. See the screenshots below of portrait, landscape, and upside down portrait for an example. To reproduce, just simply install the project from SampleApps/Interface/NativeDisplayObjects on an iOS device and activate the keyboard. In my testing, it didn’t appear on every device or iOS version (maybe only limited to iOS 7 on iPad?).
We still need a bug report for it to help Engineering track it. Can you file one please? You can use the sample app as your example code.
Thanks
Rob
Actually, we already have one: 36831 (Native Textfield slides content incorrectly in Landscape mode).
This should be fixed in Daily build 2490.
Rob
Everyone,
The next daily build (#2495) will have app panning support on Android. As in the app window will automatically slide to reveal the TextField/Box that is currently being edited by the virtual keyboard into view. Like iOS, we’ve made this a “build.settings” option that you have to opt-in to for support. You can add support via the “build.settings” file like this…
settings = { android = { coronaWindowMovesWhenKeyboardAppears = true, } }
I’ve personally tested this feature with TextFields and TextBoxes, in portrait and landscape orientations, and verified that the app window pans correctly when switching orientations (portrait to landscape and vice-versa) while the virtual keyboard is shown. It all worked great during my testing. And we’ve also successfully worked-around the Android OS’ rendering bugs that I’ve mentioned earlier in this forum thread.
But please note that there is 1 caveat to using this feature on Android. If your app displays a status bar, then that status bar will no longer be overlaid on top of your app, meaning that your app window will be displayed under the status bar. Meaning that the pixel height of your app window will actually be shorter when using this feature. Unfortunately, this is a limitation of the Android operating system when setting up an app to automatically pan itself when the keyboard is shown and is by Google’s design. Another side-effect of this is that sometimes your app window’s pixel height might suddenly change when transitioning from another app that has a status bar to your app that doesn’t have a status bar (and the reverse is true too). This is actually normal for an Android app. But please note that Corona does correctly handle this situation, will trigger a Lua “resize” event, and will rescale your app (if you’re using content scaling) in this case. Just something to watch out for. Depending on how your app is set up, this side-effect may not affect you at all.
In any case, please give this feature a go and let us know how well you think it works.
Oh and I have one other alternate solution that’ll work on Android and iOS, if you’re willing to do it.
Instead of setting up your app to automatically slide/pan when the keyboard is shown via our new build.settings feature, you can instead add your native TextField and TextBoxes inside of a widget ScrollView. I’ve tested this on Android and the Mac Corona Simulator and confirmed that native UI objects will scroll within a ScrollView. However the big limitation here is that native UI cannot be masked by the ScrollView, nor can you show display objects on top of them, because native UI is always overlaid on top of Corona’s OpenGL scene. But that said, a solution to the masking problem would be to display the ScrollView fullscreen within your app to avoid that masking problem. So, the advantage of this solution is that you can code your ScrollView to scroll up to the TextField/Box that has the focus and it’s okay to make an assumption about the keyboard height, because the end-user has the ability to scroll the rest of the TextField/Box into view.
Awesome, thats for the info Joshua. I’ll give the Android version a go soon!
I am trying to use coronaWindowMovesWhenKeyboardAppears. It works in Android but not iOS. I added it to the plist. Does anyone have this working on iOS? Not sure what I could be doing wrong.