No event was triggered when the dismiss the keyboard button was pressed on Nexus 7.

Solar2D Android
#21

Did anyone ever find a workaround for this? We’re having the same problem. No event.phase “ended” is getting fired when dismissing the keyboard on android.

We also seem to occasionally get the “editing” phase when dismissing the keyboard on android. No such problems on iOS, everything seems to work nicely.

We also tried listening for events from the minimise key (which seems to be where we are experiencing the issue), but we are not getting an event back in either the Runtime “key” event listener, or the “userInput” event listener on the native text object itself.

I suspect that on android the keyboard isn’t losing focus when “minimising”, which is why we arn’t getting the “ended” phase. But we really need to have at least a key event fired so we can detect when the minimise key is being pressed.

We’re testing this on daily build 1228.

This is a real issue! Can someone shine some light on this please or share a workaround? Thanks!

#22

We are, too, trying to find a way to detect that the keyboard was dismissed on Android. Anyone?

#23

Can you make sure your event keyhandler is returning false at the end?

#24

Definitely returning false at the end of our key handler:

local keyHandler = function(event) print(event.keyName) return false end Runtime:addEventListener("key", keyHandler)

 
Although we aren’t returning either true or false on the native text input event listener. I don’t think that is necessary though, going from the documentation. Perhaps it is!?

#25

If you capture key events and do not return false, that event will not make it back to the operating system.  You should return true when you handle it and return false when you don’t.  Returning nothing would result in a state that I’m not sure what would happen.

#26

I just ran a quick test on my Nexus 7 using your code above.  Corona SDK doesn’t get key events for every key.  We don’t get the home key, the multi-tasking view key and others.  Once the keyboard shows, and you see the V chevron, I suspect that is no longer the “back” button and therefore it’s not going to generate a capturable event as it’s no longer the back key. 

Now for the native.newTextField().  I’m not an Android expert, but I suspect the V is just to hide the keyboard.  In much the same way you can call native.setKeyboardFocus( nil ) that doesn’t affect the editing or submitting events for that field, it just hides the keyboard.  I can hit the V and then tap back into the field and bring the keyboard back.  I have to hit the “Done” button to actually submit the task.   As a test, I went to the gMail app and it shows the same behavior.  Hitting the V does nothing other than hide the keyboard.  I have to interact with the button on the keyboard (“Done”, “Next”, etc.) to actually get the app to react to anything.

#27

Rob, thank you for your support.

At least for me the problem with this is that we would trigger the “keyboard dismissed” event to move the screen back to normal position, since we have a textfield that gets covered by the keyboard when it appears. Is there a better way of doing this?

#28

Sorry I’m not sure I follow what the issue is.  I don’t see why you need to know if they dismissed the keyboard with the V button because the user can bring it back by tapping the field again (or the next field.  In your case the hidden field.)

#29

Hi Rob,

Thanks again for reply this. Just let me explain why we need get the event.

Sometimes in our App, the textfield or textbox is in the bottom of the screen, when tap on the textbox, the keyboard will show up. But in the same time, the textfield will be hidden by the keyboard. As Corona didn’t provide a function that make the whole App move up to make the textfield be visiable, this need to be done by the developers. 

So we move up the App when the keyboard shows up. When user finish the editing of a textfield, of course he need the keyboard dismiss. So he click the ‘Done’ button in most cases or device, but on a android tablet, he has another option which is by clicking the ‘V’ button ( the ‘back’ button).

We can capture the ‘Done’ event in most cases, so we could dismiss the keyboard by setting keyboard nil and MOVE THE WHOLE APP DOWN. But we couldn’t get the ‘V’ button event by any means. So the app couldn’t be MOVE DOWN to its right position.

#30

I’d like to echo what hexor.dev said.

This is exactly the reason why we need to know when the keyboard is not in view. We have the same problem - the main display is being shifted when we open the keyboard so we can see the textfield we are editing, and then being moved back when the keyboard is dismissed. Not being notified when the “V” button is clicked, means the keyboard is hidden but our display is left floating in no mans land.

#31

And that will be my problem too, with a better explanation.  :slight_smile:

#32

I understand your scenario.  But if you are moving your fields up to visible areas either as part of the native.newTextField() edit process, you can safely move it back when you get a submitted or ended process.   The hiding of the keyboard with the V button should have no impact.  You shouldn’t need to move your fields back down when the V is used to hide it, only move them on a submitted event.

I’ll share this with engineering, but I suspect that this is working as expected.

#33

Hi Rob, thanks for all the feedback on this, but I don’t think you’ve totally understood the problem.

You’re right, we’re able to safely move textfields back when we receive a submitted or ended phase. But if the user hides the keyboard with the V key, no event is fired anywhere to let us know the V key has been hit. The keyboard simply minimises, and as far as our application knows, the keyboard is still in view - so it doesn’t move anything back down.

Here is a use case incase there is still some confusion:

  1. User selects a text field, and the keyboard is opened

  2. We receive an event phase “began”, so we move the obscured graphics up above the keyboard, the user can now see them above the keyboard.

  3. The user then hits the “V” key - the keyboard is minimised. 

  4. The graphics that were moved up, have not moved back down, because we have not been notified within the app that the keyboard has been minimised.

As a user, any graphics that were moved up when the keyboard was shown, should be moved back down when it is minimised. Otherwise it’s just a terrible user experience. In our case, when we press the “V” key, our whole app display object that was moved up when the keyboard was opened stays in place, but it now has a big black square occupying the space beneath it where the keyboard was, hence why we need to know when they key was pressed.

Hopefully this clears things up!

#34

I heard back from the engineers.  The OS does not provide a way to get to the state of the hide keyboard button.

#35

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.

#36

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.

#37

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.

#38

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.

#39

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.

#40

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?