Well, yes. Right now I’m doing something similar to that but mannually. So basically, I want an effect on Android like what this line does:
android:windowSoftInputMode="adjustResize"
But I believe that this wouldn’t be easy to do for iOS right? And it would go against the way that Corona works?
Yeah, that’s the Android setting we would have to enable in order for it to slide the text field into view. We currently have it disabled in code because we ran into other issues with it at the time (that might no longer be an issue anymore), but that’s the right approach in my opinion. The real trick is finding a way to get iOS to do this. Normally you do it via a UISlideView, but we have to get it to cooperate with the OpenGL view that we’re using so that the text fields and OpenGL view move together. It’s been a couple years since we’ve last looked into this, but that was thing that I remember that was blocking us.
Right now we’re focusing on finishing graphics 2.0 and getting it into the next release. I know the team has refactored the iOS view/controller code. So, it might be worth looking into this again after the release.
If you can think of any other ideas, then I’d love to hear it.
Thanks for looking into it Rob. My response to this would be to ask how other apps listen for this key being pressed? The first app I just tried on my phone, “Viber” which is a messaging app, responds to this key bring pressed in the exact way we need it to, i.e. keyboard drops down, then the screen is repositioned
Hi Rob,
Thanks for you response, but how could i solve my problem?
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.
I’m continuing the conversation. While that key may not generate an event, there might be other ways to attack this, so lets see what they have to say.
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.
So, is there any news about this? Because I need to scroll my app up just like @development64 and I would like to know if there’s already a way to get that key event in order to push the app down when they press the “V” key.
The Android OS does not provide any means of knowing when the virtual keyboard has been cleared. There is no event. Not even at the native Android API level.
The closest alternative that I can think of that would allow you to “guess” when the keyboard is cleared is when the text field loses the focus. In Corona, you can detect this via the “userInput” event’s “ended” phase.
http://docs.coronalabs.com/daily/api/event/userInput/phase.html
But that said, be warned that this is a complete guess on your part. If the end-user is using a physical keyboard, then a virtual keyboard won’t be displayed at all. The Android OS does not provide any means of detecting if the virtual keyboard or physical keyboard is being used.
Well, for the virtual keyboard, I saw a trick using “ViewTreeObserver”. Here’s the link of what I’m saying: http://stackoverflow.com/questions/2150078/how-to-check-visibility-of-software-keyboard-in-android
It could not be the best but would be interesting to solve major of the problems with Soft Keyboard visible/hidden and with it’s height.
That “trick” on stackoverflow won’t work. The reason is because the Corona activity is set up to have the virtual keyboard and status bar overlaid on top. That trick involves setting up the activity to be resized between the status bar and virtual keyboard. In which case, you can guess at the height of the bottom keyboard when the height of your activity window changes. But it’s not helpful because if your app is set up to be resized when the keyboard is shown, then the height is useless because the virtual keyboard is not overlaid on top. In fact, it can make things worse because you might not have enough vertical height to show your app’s contents. Particularly for landscape apps… in which case the default fullscreen editor for text fields makes more sense, which is the default behavior now. Another problem with that stackoverflow solution is that it makes an assumption that when the height of the activity changes, that it is coming from the keyboard at the bottom, because there is really no way to tell. In may just be the stop status bar or bottom navigation bar popping in.
Ah ok, I see… So that’s why there are people overriding the EditText class to make their own “dismiss” event like in this post: http://boltingupandroid.wordpress.com/2013/02/22/detect-dismissal-of-the-soft-keyboard/
That’s too bad that Android doesn’t have it by default =S.
Oh, that’s interesting. What that guy is doing is intercepting the Back key before it is sent to the virtual keyboard. So, that’ll work when the end-user dismisses the keyboard via the back key, but not for the case where there is a dismiss key on the virtual keyboard.
If your intent is to ensure that the text field is visible when the virtual keyboard is shown, 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. Most apps behave in this manner. Unfortunately, Corona apps do not have this ability. But I think that’s what you’re really after, right?
Well, yes. Right now I’m doing something similar to that but mannually. So basically, I want an effect on Android like what this line does:
android:windowSoftInputMode="adjustResize"
But I believe that this wouldn’t be easy to do for iOS right? And it would go against the way that Corona works?
Yeah, that’s the Android setting we would have to enable in order for it to slide the text field into view. We currently have it disabled in code because we ran into other issues with it at the time (that might no longer be an issue anymore), but that’s the right approach in my opinion. The real trick is finding a way to get iOS to do this. Normally you do it via a UISlideView, but we have to get it to cooperate with the OpenGL view that we’re using so that the text fields and OpenGL view move together. It’s been a couple years since we’ve last looked into this, but that was thing that I remember that was blocking us.
Right now we’re focusing on finishing graphics 2.0 and getting it into the next release. I know the team has refactored the iOS view/controller code. So, it might be worth looking into this again after the release.
If you can think of any other ideas, then I’d love to hear it.