We intended to add automatic panning on Android too because it is literally a 1 line code change, but we ran into bugs on Google’s end that causes rendering glitches on Android 4.0 and older devices. We’re pulling our hair out trying to find a work-around. Especially since this is really the only solution on Android since you cannot fetch the keyboard height on Android.
Joshua, sorry to hear about the hair! 
Thanks for persevering. I hope you can find the workaround or that Google fixes that bug soon. I’m curious though, if you can’t get the keyboard height on Android then how would you know by how much to pan the screen up? Can’t get my mind around this somehow.
Yeah, it’s tough. I’m sure Android’s built-in panning would work fine if it was a pure business app;without OpenGL. But native UI and Google’s GLSurfaceView apparently do not play nice together. We’re seeing rendering glitches with Android’s text views and not with Corona’s OpenGL rendering. I honestly don’t know how to get past that since we can’t fix Android’s native UI rendering. The only other thing I can think of is to somehow pan the screen manually ourselves, which is tough if you’re unable to fetch the keyboard height. We may have to dig deep down in the bowels of Android’s open source code on GitHub for a solution.
And for your info, most native Android developers would set up their app to be resized between the top status bar and the bottom navigation bar or keyboard. By doing this, the top and bottom panels are never overlaid on top of the app so that they don’t have to worry about fetching their heights. While this solution would work well for a business app using a scrolling view, it’s not a good solution for a fixed OpenGL screen such as what Corona uses because most Corona developers would not want their display to be resized/squished to a teeny tiny landscape window while their app is in portrait mode with the keyboard displayed. Especially when coming from the iOS world where the app window always has a fixed size.
Apple is allowing third-party keyboards for the first time in iOS 8 and Swype, SwiftKey, Fleksy and TouchPal will be releasing the first ‘iconless’ apps for the iPhone and iPad today. I wonder if all these 3rd party keyboards will match the native keyboard in height and width. If not we will have a new challenge on our hands…
Joshua, please don’t tell me this is the final solution we are getting for iOS? Why can’t we just get the keyboard height returned when a textfield is activated in a Runtime event maybe or in the began-phase of the textfield listener or something? ANYTHING would do we can take care of the rest from there.
Our textfield sitting on top of the keyboard will just not work for us since we are using a custom background and the keyboard will STILL cover that background and things will look buggy and not 100% finished. And if we are satisfied with THIS fix, this unfinished look in our apps will never be fixed either… So please help us get this right while it’s being worked on.
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.
Do the keyboards just get to customize the default keyboards appearance? Or can they be completely customized like on android?
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