Detect Back Key (Android)

Other
#1

I’m using a native textbox, I slide the textbox when the keyboard displayed on the screen. My problem is when the user press “back” key in Android. How I detect this key press?

I have this function in main.lua:

function onKeyEvent( event )

  local keyName = event.keyName

  local phase = event.phase

  if (keyName == “back” and phase == “up”) then

        local alert = native.showAlert( “Corona”, “Dream. Build. Ship.”, { “OK” })

end

This function detects all “back” except when native keyboard displayed on the screen.

#2

This is by Google’s design.  The virtual keyboard is stealing the back key event, using it to close the virtual keyboard, and preventing that key event from getting to the application.  That’s just how Android works.  There is no overriding this behavior.  Not even at the native level.

#3

With the second back key I can put textbox at original position, but I don’t like it. 

Thanks for your help.

#4

This is by Google’s design.  The virtual keyboard is stealing the back key event, using it to close the virtual keyboard, and preventing that key event from getting to the application.  That’s just how Android works.  There is no overriding this behavior.  Not even at the native level.

#5

With the second back key I can put textbox at original position, but I don’t like it. 

Thanks for your help.

#6

According Corona Lab’s members told us, there is no event can be generated while keyboard dismissing, so corona sdk cannot detect when the keyboard dismissing. But all the popular existing android apps, such as facebook, twitter, LINE, etc, those apps without keyboard dismissing problem.

I don’t think native Android doesn’t provide anything to handle this issue, the problem is, will Corona Lan want to solve this ?

Check this api from android sdk: it proves that Android really provide a solution to capture “BACK” key.

====================================================================================

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

There is no 100% guaranteed way of detecting when the virtual keyboard is being dismissed.  Now, while the onKeyPreIme() method can capture the back key event before it is received by the virtual keyboard, that is not the only means of dismissing the virtual keyboard.  Virtual keyboards can also dismiss themselves depending on how the return key is set up and some keyboards have their own dismiss button, which can typically be found on tablets.  Also, you have to consider the case where the end-user might be using a physical keyboard instead, such as on a Droid.

Also, Corona key events should *not* be dispatched via the onKeyPreIme() because that method does not respect the view hierarchy.  That is, we should *not* deliver key events that are intended to be dispatched to a WebView, text box, or alert that is on top of Corona’s main rendering view.

If your intent is to prevent the virtual keyboard from being hidden, then what you’re trying to do is *hack* around the operating system’s default behavior.  I don’t recommend this.  If you want to 100% control how the keyboard is being displayed and used, then you’ll need to create and display your own onscreen keyboard, which is how phone apps sometimes handle it.  Or you could just respect the end-user’s choice to hide the keyboard if they want to, which is what I recommend.

#8

Joshua, what I think is that people don’t want to override the back key. They want to detect that the back key is used to remove the keyboard so they can bring the screen objects to its original position if they were translated (like when you have a textField that would be hidden by the keyboard).

My opinion is that Corona should give the developers that info. If Corona don’t want to pass it via the key event, fine, but pass it using another event type.

It is pretty awful to see my Corona apps where the user press the back key to hide the keyboard and the layout does not adjust it self to its original because today I don’t have any way to know that the user hided the keyboard.

#9

I understand what people want.  My point above is that there is no reliable means of detecting when the keyboard is being dismissed or preventing it from being dismissed.  What is being suggested up above is a hack, unreliable, and will ultimately be a futile effort.

The “correct” solution is to let the operating system slide the app’s focused field into view and avoid re-laying out the app, which you have no reliable means of doing.  That is how Apple, Google, and Microsoft want it to be handled.  Unfortunately, we don’t support this in Corona right now.  I know how to do this on Android, but it is far more difficult to implement on iOS and we haven’t had the time/resources to do this yet.

#10

I have the same problem. For this problem, is it possible to detect whether the keyboard is on the screen or not? For example add a keyboard is on screen variable? If the button cannot be detected, I could still work around this problem if the keyboard status is known. Now, there is no way of knowing whether the keyboard is on screen or not. 

#11

According Corona Lab’s members told us, there is no event can be generated while keyboard dismissing, so corona sdk cannot detect when the keyboard dismissing. But all the popular existing android apps, such as facebook, twitter, LINE, etc, those apps without keyboard dismissing problem.

I don’t think native Android doesn’t provide anything to handle this issue, the problem is, will Corona Lan want to solve this ?

Check this api from android sdk: it proves that Android really provide a solution to capture “BACK” key.

====================================================================================

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.
#12

There is no 100% guaranteed way of detecting when the virtual keyboard is being dismissed.  Now, while the onKeyPreIme() method can capture the back key event before it is received by the virtual keyboard, that is not the only means of dismissing the virtual keyboard.  Virtual keyboards can also dismiss themselves depending on how the return key is set up and some keyboards have their own dismiss button, which can typically be found on tablets.  Also, you have to consider the case where the end-user might be using a physical keyboard instead, such as on a Droid.

Also, Corona key events should *not* be dispatched via the onKeyPreIme() because that method does not respect the view hierarchy.  That is, we should *not* deliver key events that are intended to be dispatched to a WebView, text box, or alert that is on top of Corona’s main rendering view.

If your intent is to prevent the virtual keyboard from being hidden, then what you’re trying to do is *hack* around the operating system’s default behavior.  I don’t recommend this.  If you want to 100% control how the keyboard is being displayed and used, then you’ll need to create and display your own onscreen keyboard, which is how phone apps sometimes handle it.  Or you could just respect the end-user’s choice to hide the keyboard if they want to, which is what I recommend.

#13

Joshua, what I think is that people don’t want to override the back key. They want to detect that the back key is used to remove the keyboard so they can bring the screen objects to its original position if they were translated (like when you have a textField that would be hidden by the keyboard).

My opinion is that Corona should give the developers that info. If Corona don’t want to pass it via the key event, fine, but pass it using another event type.

It is pretty awful to see my Corona apps where the user press the back key to hide the keyboard and the layout does not adjust it self to its original because today I don’t have any way to know that the user hided the keyboard.

#14

I understand what people want.  My point above is that there is no reliable means of detecting when the keyboard is being dismissed or preventing it from being dismissed.  What is being suggested up above is a hack, unreliable, and will ultimately be a futile effort.

The “correct” solution is to let the operating system slide the app’s focused field into view and avoid re-laying out the app, which you have no reliable means of doing.  That is how Apple, Google, and Microsoft want it to be handled.  Unfortunately, we don’t support this in Corona right now.  I know how to do this on Android, but it is far more difficult to implement on iOS and we haven’t had the time/resources to do this yet.

#15

I have the same problem. For this problem, is it possible to detect whether the keyboard is on the screen or not? For example add a keyboard is on screen variable? If the button cannot be detected, I could still work around this problem if the keyboard status is known. Now, there is no way of knowing whether the keyboard is on screen or not.