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.
coronaWindowMovesWhenKeyboardAppears should be CoronaWindowMovesWhenKeyboardAppears when inside the iphone->plist table. The lower case version is for the Android table. Everything in the iphone->plist is “Pascal cased”, that its it starts with a capital letter. Android uses camelCase where the first letter is lower cased.
Rob
I don’t understand. When Corona can move the whole window up to exact Y location above keyboard, it means Corona is able to know the keyboard height, and make the adjustment accordingly. But why can’t Corona open up that API to let everyone know the keyboard height?
Correct me if I am wrong, because I don’t know about the very details.
On Android, you cannot fetch the keyboard height. We’ve discussed this at the beginning of this thread (page 1). Instead, you tell the Android operating system to move your app for you via its “adjustPan” feature.
So as Josh noted, there is some awkwardness in obtaining the keyboard height. It’s not the same as getting the screen width/height because there is no API on Android as far as we can tell, and on iOS, that value is indirectly available when the OS notifies the app that the keyboard is about to be shown, i.e. the user has to take an action that shows the keyboard in order for Corona to be able to pass those values to you, so it’s not that helpful.
It seems what people really want is the following: when a native textfield/textbox is selected and causes a keyboard to appear, the window will shift upward (all Corona content shifts upward) so that the textfield you just selected won’t be obscured by the keyboard.
That’s basically Josh’s option #1 from above, so that’s what we’ll be looking into.
Walter,
Thanks for thinking this through. I think moving Corona content blindly upwards as much as the keyboard height will not work as the entry field might be at the top of the screen and get obscured if you do this. We would need to move the screen upwards only when the entry field is on the lower part of the screen and is about to be obscured by the keyboard. This is why normally we would want to know the keyboard height and move the screen as needed and then back downwards once entry is completed. if Corona SDK is going to do it for us then it needs to be a little more clever than moving the whole screen up at all times.
Lets think this through and find a solution that will work. Thanks much!!!
Regards,
Kerem
Indeed, that is our intention.
Super!!! This is great news. Thanks much.
If corona could offer the height rather than animating everything when the keyboard is about to show, since that is really the only time we need to know of the value, that would be perfect as it would make things infinitely easier and give us control of what to do. We for example only want to animate one group when the keyboard is about to show, being able to access the keyboard height value would eliminate all issues associated with that value.
Thanks tons for adding this!!
Ah just saw the fix added in the latest daily. While it technically works now it still doesn’t work very well with textfields that don’t have a background set and that we provided a custom background for which exceeds the top/bottom boundaries of the text.
I still think the best solution would just be to give us access to the actual keyboard height and then we can do whatever we choose with it as the possibilities are all there, the only thing we are lacking is knowing the exact value. I’m not to keen on these forced animations and forced behaviours that we have no control over as it forces us to ‘esthetically’ animate our app in certain ways even if it doesn’t suit the behaviour of our app at all, and it feels like it doesn’t benefit the Corona SDK either to force certain animatinos on users, it only takes more work for the engineers to implement and even then some users might not want it. Why not just give the devs the tools and then they can create the animations themselves using simple transitions and whatnot 
While the fix currently works for us, it still doesn’t work that well because sure, the user now might see what he/she is typing, but they still wont see the full background we deisgned for the textfield and things still look buggy, and I just hope this isn’t the final version of this feature that we’ll get as we’re otherwise stuck with a bug that is considered “fixed” in Coronas eyes and getting a fix for this implement will take us forever from here on.
Sorry for the long post, but I just want to see this get done right as we’ve waited for it for so long and now that it’s finally here it’s going to work half-ok for no good reason. I think the best way to go about doing it is to just let us access the keyboard height and we’ll be able to animate things in any way, shape or form we need
And what about Android? How to cater for the same need on Android devices?
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.
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.