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

Solar2D Android
#1

On Nexus 7, when click a edit area( textbox or textfield), the Android keyboard will pop up. And the Android back button will become to the dismiss keyboard button ( cause it’s a tablet ).  

But when the dismiss button is pressed, I can not capture the pressed event.

In this way,

function onKeyEvent( event )     local keyname = event.keyName;     print("main.lua got a key event",keyname) end Runtime:addEventListener( "key", onKeyEvent )  

or this way,

   local function subjectFieldListener( event )         print("got event",event.phase)         end     end     self.chatInputField:addEventListener( "userInput", subjectFieldListener )  

Both ways couldn’t receive a event when the dismiss keyboard button was pressed.

And on iPad, iPad’s keyboard has a dismiss key too. When the dismiss button was pressed, the textfield will get a ‘end’ event of “userInput”. So the dismiss button works will on iOS tablet.

Why the android tablet can’t get a event when the dismiss button was pressed as the iOS devise?

Or is there other way to get this event captured ?

Thank you guys for reply. Good day.

#2

maybe the keyboard absurd the ‘back’ event, but in corona, it said: 
"Key events will not be received if a native object such as a TextField, TextBox, or WebView handles them. This can only happen if these native objects have the focus and if they choose to override that key. For example, a TextField and TextBox typically handles all keyboard keys, preventing the application from receiving those key events, but will not handle a “back” key event.

"

#3

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!

#4

maybe the keyboard absurd the ‘back’ event, but in corona, it said: 
"Key events will not be received if a native object such as a TextField, TextBox, or WebView handles them. This can only happen if these native objects have the focus and if they choose to override that key. For example, a TextField and TextBox typically handles all keyboard keys, preventing the application from receiving those key events, but will not handle a “back” key event.

"

#5

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

#6

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

#7

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!?

#8

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.

#9

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.

#10

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?

#11

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.)

#12

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.

#13

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.

#14

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

#15

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.

#16

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!

#17

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

#18

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

#19

Hi Rob,

Thanks for you response, but how could i solve my problem?

#20

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.