example back key code

Getting Started Newbie Questions
#1

In the standard Corona docs, the sample code to detect the back key on Android seems to have a couple of flaws. Here’s the sample code:

if ( event.keyName == "back" ) then if ( system.getInfo("platform") == "Android" ) then return true end end return false

It doesn’t test for event.phase=“up”, and it tests for platform (which seems un-necessary) but it looks for “Android” instead of “android”.  This code works:

if (event.keyName=="back") and (event.phase=="up") then if (system.getInfo("platform")=="android") then --do something return true end end return false

These are minor bugs, but it’s hard for me to believe that they have gone undetected. So can anyone tell me: is there a “better” version of the documentation that I have not found yet? Or does the original code work in some context?? Thanks.

#2

There is a link at the bottom of the documentation where you can report errors with the documentation and we can then go through and address them. I understand where the “Android” vs. “android” came from. We probably changed the variant to get the platform. 

Thanks

Rob

#3

Do you know the specific page where this code came from (URL)?

Rob

#4

Sure. The original code was from here:
https://docs.coronalabs.com/api/event/key/keyName.html

#5

I fixed the case issue with “android”.  However, the other code is correct. The code is designed to prevent the back button from backing out, so not checking the up/down status lets the code avoid backing out on either state.

Rob

#6

You wrote:
“However, the other code is correct. The code is designed to prevent the back button from backing out, so not checking the up/down status lets the code avoid backing out on either state.”

I see your point. :slight_smile: If the goal is simply to catch and nullify the back key, then that’s reasonable. But if we’re processing the back key to perform some action?? Maybe not so good. And common Android apps perform their action when the back key is released --the “up” event-- so that’s standard on the platform, too.

Consider a common use case: the app is in some state, like a composer scene, scene2, and we want to get back to a prior state, scene1. That would be a really common use scenario for this code. If you include the conditional for the state (either up or down), then it works as expected. Otherwise, depending on the speed of the tap on the back key, the code in the event handler can produce odd behavior. Of course, it’s technically correct as it stands, as you note, but in docs like this, you want things that are relatively bulletproof for beginners, right? And again, it does seem to be “normal” in Android apps to ignore the back button down event and respond to the back button on release.

By the way, I’m not worried about it, and I don’t need another reply. You addressed my primary concern very promptly, and I really appreciate that!! :slight_smile:

fer
 

#7

Our code in the documents is just examples and sometimes the creator is trying to demo something in a way that you might not want to implement it or in a way where that fits the logic of your app.  This is a great example, if we did it “right”, it would involve handling closing Composer overlays, backing out of scenes to previous scenes. While that would be more practical it doesn’t really demonstrate the use of the various values and setting up the event handler.

Doing a one-size-fits-all is tough.

Rob

#8

There is a link at the bottom of the documentation where you can report errors with the documentation and we can then go through and address them. I understand where the “Android” vs. “android” came from. We probably changed the variant to get the platform. 

Thanks

Rob

#9

Do you know the specific page where this code came from (URL)?

Rob

#10

Sure. The original code was from here:
https://docs.coronalabs.com/api/event/key/keyName.html

#11

I fixed the case issue with “android”.  However, the other code is correct. The code is designed to prevent the back button from backing out, so not checking the up/down status lets the code avoid backing out on either state.

Rob

#12

You wrote:
“However, the other code is correct. The code is designed to prevent the back button from backing out, so not checking the up/down status lets the code avoid backing out on either state.”

I see your point. :slight_smile: If the goal is simply to catch and nullify the back key, then that’s reasonable. But if we’re processing the back key to perform some action?? Maybe not so good. And common Android apps perform their action when the back key is released --the “up” event-- so that’s standard on the platform, too.

Consider a common use case: the app is in some state, like a composer scene, scene2, and we want to get back to a prior state, scene1. That would be a really common use scenario for this code. If you include the conditional for the state (either up or down), then it works as expected. Otherwise, depending on the speed of the tap on the back key, the code in the event handler can produce odd behavior. Of course, it’s technically correct as it stands, as you note, but in docs like this, you want things that are relatively bulletproof for beginners, right? And again, it does seem to be “normal” in Android apps to ignore the back button down event and respond to the back button on release.

By the way, I’m not worried about it, and I don’t need another reply. You addressed my primary concern very promptly, and I really appreciate that!! :slight_smile:

fer
 

#13

Our code in the documents is just examples and sometimes the creator is trying to demo something in a way that you might not want to implement it or in a way where that fits the logic of your app.  This is a great example, if we did it “right”, it would involve handling closing Composer overlays, backing out of scenes to previous scenes. While that would be more practical it doesn’t really demonstrate the use of the various values and setting up the event handler.

Doing a one-size-fits-all is tough.

Rob