Well, I don’t know to much of iOS yet but yes, what you said seems to be the right approach. Maybe when you get into it again, you can find a way too to control the text fields in order to be able to, for example, show a general loading screen over the text fields and other things like that =).
If I remember any other way of doing that, I will post here ^^.
Hi again =)
I searched a little about iOS and saw that there are many people controlling the opengl view manually when using a uiscrollview. Isn’t it possible to make “widget.newScrollView” use that approach and let we use native elements inside of it? That way, I think that’s possible to resize the content when keyboard appears on iOS right?
And just a last question. As I said, I don’t know to much of iOS programming but, isn’t it possible to have 2 opengl views? That way, things like overlaying menu or loading could appear above native elements right?
The only problem with trying to handle this ourselves is that we have no way to know how tall the virtual keyboard is. The OS just doesn’t provide a reliable means of fetching it. So, to do this right, we have no choice but to let the OS handle it for us. The only solution that I can think of is to assume that the top portion of the screen will always be visible when a text field receives the focus, which “should” be the case on all devices.
By the way, I’ve written this up as a task to be re-investigated so that this won’t be forgotten.
So iOS doesn’t have a way to get the height of the keyboard? I thought it could be achieved with something like that: https://developer.appcelerator.com/question/155519/how-to-get-the-height-of-ios-keyboard
Thanks for all the help Joshua =)
I just talked to one of our iOS developers now. He said it is actually possible to get the keyboard height on that platform. So, I stand corrected. It’s just not possible on Android. However, it looks like making iOS automatically scroll the OpenGL view and its text field together is what’s problematic… which happens to be easy on Android. So, it looks like we’re dealing with 2 platforms having totally different ways of handling this. *sigh*
Ah ok, So in order to make it work, one of them must be done manually =S
Yeah. I’m thinking that we would have to slide the iOS view ourselves. Since the keyboard height is known on iOS, this should be possible. On Android, we should be able to have the OS do it automatically. This seems to be the best cross-platform way to handle it. The only possible issue that I can think of here is that it might not be enough to slide the text field into view. You might want a label above the text field to be visible as well. Something that might describe what type of text that field expects. Or perhaps I’m overthinking it. Perhaps a “placeholder text” in the text field might serve the same purpose.
I definitely second this as it is a great draw back for business apps. The way native apps do this is to reposition the content so the text field sits on top of the keyboard with the added option of placing a button bar between the keyboard and text field. In landscape however the text field is extended to fill the available space with a done button on the right. Either way pressing the back button (or dismiss I imagine) reverts everything to the original state. This is what we need as currently we have only two options both of which are bad.
Don’t do anything and the user can’t see what he is typing if the text field is behind the keyboard
Custom handle the positioning and in the event the user cancels the keyboard (with back or dismiss) the user is left with the content repositioned until he presses something else.
My current fix to this is wrapper for the text field. I have my own newtextfield function that handles everything in the background. By the default it is a custom drawn text field which is just a display group (added bonus you can put it in a scroll view) and when it’s clicked it hides the parent which was provided in the newtextfield function (I actualy hide the whole scene except background) creates a real textfield without background and drawn exactly the same as the placeholder display group, but it’s placed at the top of the screen with a post button on the right side. Optionaly it takes a label (or any other object) with it if it was provided in the new function and places the textfield below it. If a user then cancels the input with a back or dismiss button they are left with nothing but the text field (optional label above it) and the post button. Pressing the post button (or done on keyboard if it’s still active or, if handled in app another back button press) returns everything to it’s original state and updates the placeholder display group with the text entered. It also manages width if it’s too big to fit next to the button and provides hint functionality when the text is empty, handles secure (password) input (hint possible), keyboard type, … If there will be interest I will post the code but it is currently tied in to some other util units I use, so I would have to peel it out. It’s not ideal but it’s definitely better than covering the input with the keyboard or showing displaced content on keyboard dismiss. Still hoping for a native solution.
Cheers.
“If your intent is to ensure that the text field is visible when the virtual keyboard is shown”
That’s exactly what we’re trying to do. It’s just a bad user experience if they can’t see the field they are typing into.
“the best solution is to have the OS slide the view to a position where it is visible, because only the OS knows the actual height of the keyboard.”
So how do we tell the OS to do this from a Corona app?
“Unfortunately, Corona apps do not have this ability.”
So you are suggesting something that we can’t actually do?
I definitely second this as it is a great draw back for business apps. The way native apps do this is to reposition the content so the text field sits on top of the keyboard with the added option of placing a button bar between the keyboard and text field. In landscape however the text field is extended to fill the available space with a done button on the right. Either way pressing the back button (or dismiss I imagine) reverts everything to the original state. This is what we need as currently we have only two options both of which are bad.
Don’t do anything and the user can’t see what he is typing if the text field is behind the keyboard
Custom handle the positioning and in the event the user cancels the keyboard (with back or dismiss) the user is left with the content repositioned until he presses something else.
My current fix to this is wrapper for the text field. I have my own newtextfield function that handles everything in the background. By the default it is a custom drawn text field which is just a display group (added bonus you can put it in a scroll view) and when it’s clicked it hides the parent which was provided in the newtextfield function (I actualy hide the whole scene except background) creates a real textfield without background and drawn exactly the same as the placeholder display group, but it’s placed at the top of the screen with a post button on the right side. Optionaly it takes a label (or any other object) with it if it was provided in the new function and places the textfield below it. If a user then cancels the input with a back or dismiss button they are left with nothing but the text field (optional label above it) and the post button. Pressing the post button (or done on keyboard if it’s still active or, if handled in app another back button press) returns everything to it’s original state and updates the placeholder display group with the text entered. It also manages width if it’s too big to fit next to the button and provides hint functionality when the text is empty, handles secure (password) input (hint possible), keyboard type, … If there will be interest I will post the code but it is currently tied in to some other util units I use, so I would have to peel it out. It’s not ideal but it’s definitely better than covering the input with the keyboard or showing displaced content on keyboard dismiss. Still hoping for a native solution.
Cheers.
“If your intent is to ensure that the text field is visible when the virtual keyboard is shown”
That’s exactly what we’re trying to do. It’s just a bad user experience if they can’t see the field they are typing into.
“the best solution is to have the OS slide the view to a position where it is visible, because only the OS knows the actual height of the keyboard.”
So how do we tell the OS to do this from a Corona app?
“Unfortunately, Corona apps do not have this ability.”
So you are suggesting something that we can’t actually do?
I’m having the same problem. This problem has not been solved?
No. There are only ways to mitigate the problem. You can present an input screen that hides the content behind it and position the text field on the top part off the screen to make sure the keyboard does not cover it and provide a submit button or something for when the user cancels the keyboard but you need a placeholder for the input field in that case or leave the content offset until the user presses something else.
That I can, but it does not solve the problem. If the User does not “tap” something other, textfield remains out of place. Thanks for help
I’m having the same problem. This problem has not been solved?
No. There are only ways to mitigate the problem. You can present an input screen that hides the content behind it and position the text field on the top part off the screen to make sure the keyboard does not cover it and provide a submit button or something for when the user cancels the keyboard but you need a placeholder for the input field in that case or leave the content offset until the user presses something else.
That I can, but it does not solve the problem. If the User does not “tap” something other, textfield remains out of place. Thanks for help
Hi
The correct input field position is very basic requirement for a normal non-game app, if Corona SDK cannot provide their owned widget input in Android at this moment, as least SDK can provide as much key response as possible.
The keyboard dismissed or not is very important for programmer to put textfield or textbox in right position. Corona SDK should sent back the key response as much as possible.
There are several ways to dismiss keyboard such as : “Back” key, “V” key or like HTC series’ “square key” in HTC soft keyboard. (which can be found in attached image with red circle.)
I can get “Back” key response by [[Runtime:addEventListener( “key”, onKeyEvent )]], but I failed to get other key response.
According Google Android SDK seem to have solution for this issue, but it still need Coron Lab to implement it in corona sdk.
=============================================================================
public boolean onKeyPreIme (int keyCode, KeyEvent event)
Added in API level 3
Handle a key event before it is processed by any input method associated with the view hierarchy. This can be used to intercept key events in special situations before the IME consumes them; a typical example would be handling the BACK key to update the application’s UI instead of allowing the IME to see it and close itself.
Parameters keyCode The value in event.getKeyCode(). event Description of the key event.
Returns
If you handled the event, return true. If you want to allow the event to be handled by the next receiver, return false.