native.requestExit()
http://docs.coronalabs.com/api/library/native/requestExit.html
Keep in mind that for iOS, Apple doesn’t want you exiting apps since it looks like a crash and those users don’t expect it. Android is different, back and home need to exit gracefully.
[import]uid: 199310 topic_id: 34520 reply_id: 137798[/import]
Just a random thought on this… Okay, not so random, I did a test… When I press the N button on my Nook Color, two events fire:
D/WindowManager( 958): interceptKeyTi code=4 down=true repeatCount=0 keyguardOn=false mHomePressed=false
I/Corona ( 1378): table: 0x2bf138 {
I/Corona ( 1378): [phase] =\> "down"
I/Corona ( 1378): [name] =\> "key"
I/Corona ( 1378): [keyName] =\> "back"
I/Corona ( 1378): }
D/WindowManager( 958): interceptKeyTi code=4 down=false repeatCount=0 keyguardOn=false mHomePressed=false
I/Corona ( 1378): table: 0x2bf560 {
I/Corona ( 1378): [phase] =\> "up"
I/Corona ( 1378): [name] =\> "key"
I/Corona ( 1378): [keyName] =\> "back"
I/Corona ( 1378): } Much like a touch handler where you have a began phase and an ended phase, your event handler fires twice. Your code:
// Set up a listener for the NOOK button
local function onNookPress( event )
local phase = event.phase
local keyName = event.keyName
if keyName == "back" then
-- Do stuff
-- Keep the return true line here because
-- you want to successfully return
return true
end
end
-- Attach the listener to the Runtime object
Runtime:addEventListener( "key", onNookPress) Your event handler is going to run twice, so whatever you’re doing inside that if is going to happen twice. Also, the “return true” probably should be outside the if statement. I would do something more like:
[code]
local function keyListener(event)
utility.print_r(event)
if event.phase == “up” and event.keyName == “back” then
–do stuff like:
–if storyboard.storyboard.getCurrentSceneName() == “menu” then
– native.requestExit()
–else
– storyboard.gotoScene(storyboard.getPrevious())
–end
end
return true
end
Runtime:addEventListener( “key”, keyListener )
[/code] [import]uid: 199310 topic_id: 34520 reply_id: 137804[/import]
Everyone,
The ‘n’ button on the Nook can either be a “back” key or a “home” key, depending on the state of the status bar. This is by B&N’s design.
If your app displays a status bar, then the ‘n’ button is treated like a “home” key and will suspend your app. You cannot override the “home” key.
If your app is *not* displaying a status bar (ie: it is set to [lua]display.HiddenStatusBar[/lua]), then the ‘n’ button is treated like a “back” key and will exit your app unless your override it as Rob has shown up above.
[import]uid: 32256 topic_id: 34520 reply_id: 137806[/import]
@Rob
I did include your version on my last submission , but it was rejected for the reason I mentioned above.
When I invoke the ‘reverse arrow’ in the Nook Color menu, it acts correctly.
The rejection seems to imply that there is a problem on the HD & HD+ which Is why I posed the question.
As I do not have a Nook HD, it seems there may be a difference in coding the HD & HD+ from the Nook Color with regards to the ‘soft button’ used in their menu.
[import]uid: 31039 topic_id: 34520 reply_id: 137811[/import]
—wrong thread [import]uid: 46082 topic_id: 34520 reply_id: 137810[/import]
Frank,
The onscreen “back” button works the same between the old Nooks and the new Nook HDs. I’ve confirmed this.
The one thing I would do differently is override the “down” phase instead of the “up” phase… but that is to work-around an issue on Galaxy Tabs where they refuse to give you the “up” phase if you hold the back key for too long.
[import]uid: 32256 topic_id: 34520 reply_id: 137815[/import]
Joshua,
I’ll code it your way and ask b&n for a more accurate reason, should they reject it again.
I’ll get back. [import]uid: 31039 topic_id: 34520 reply_id: 137816[/import]
So what is the final verdict then? I’m testing some of these, and still having trouble.
Which is the best way to code this so if you’re in any other scene, it goes back to the menu, and if you’re in the menu, it closes the app?
Thank you! [import]uid: 63661 topic_id: 34520 reply_id: 137824[/import]
I tried Rob’s method above, and it’s now getting rejected because the volume buttons are disabled… ugh - any fix or workaround for this? [import]uid: 63661 topic_id: 34520 reply_id: 137911[/import]
You have to specifiy the volume controls on Android. The below code is from the ansce “key event” sample.
[lua]local function onKeyEvent( event )
local returnValue = true
local phase = event.phase
local keyName = event.keyName
– Make an exception for Volume Up key and default to it’s normal function (just for show)
if “volumeUp” == keyName then
returnValue = false – use default key operation
end
if “volumeDown” == keyName then
returnValue = false – use default key operation
end
if “back” == keyName then
director:changeScene( “loadback” )
end
– we handled the event, so return true.
– for default behavior, return false.
return returnValue
end
– Add the key callback
Runtime:addEventListener( “key”, onKeyEvent ); [/lua] [import]uid: 46082 topic_id: 34520 reply_id: 137921[/import]
Thanks, I’ll give that a shot and report back! [import]uid: 63661 topic_id: 34520 reply_id: 137925[/import]
Tried implementing that, and the nook volume controls do not work… [import]uid: 63661 topic_id: 34520 reply_id: 137928[/import]
b&n was more descriptive in their rejection, as follows:
According to the tester “The app closes when pressing the back button on the NOOK System Bar when on the Page Selection Menu on the NOOK HD and NOOK HD+.”
As well as a note; If the Page Selection Menu is opened while on any page after page 1, the Back button appears to have no functionality. It appears the Back button is navigating the user back a page ‘behind’ the Page Selection Menu.
Does corona have this functionality in its api for the nook hd, to handle both the back button & page selection menu as described by b&n ? I haven’t seen it anywhere.
[import]uid: 31039 topic_id: 34520 reply_id: 137962[/import]
I’m so confused on all of this now - My understanding was that Nook just wants the ability for the user to navigate back to the menu before closing the app using either the “n” button on the old Nook Color, or the back button the Nook HD and HD+ tablets.
As far as testing is concerned, it worked on my end on the Nook Color. The issue I was having, and still have is now the volume control is disabled, and I tried implementing the above code, and the volume control still won’t work.
I think we need to get one clear message from Nook as to what they want from us in terms of navigating using their system bar, as I’m getting different answers than other people. [import]uid: 63661 topic_id: 34520 reply_id: 137978[/import]
@Joshua: If we use the method you described by displaying the status bar for the Nook apps, would we then eliminate having to override the “n” button as described by some of the code Rob provided above?
I was just reading up on another thread where this was discussed, and wondering if this is the same issue B&N is talking about, or a different one? If so, your solution sounds easy enough! [import]uid: 63661 topic_id: 34520 reply_id: 137998[/import]
I Just got another email from b&n stating that they couldn’t find a page selection menu in my app, so they approved it. This is all very confusing.
It does have another problem which I will mention in another thread.
Thanks all. [import]uid: 31039 topic_id: 34520 reply_id: 138008[/import]
I went ahead and just implemented the status bar, and moved things up a bit on my app, and they approved it. It seems like the much easier solution for now is to include the status bar, so they can go back a page, or suspend the app. [import]uid: 63661 topic_id: 34520 reply_id: 138097[/import]
I’ve got a thread going here I really need help with. Apple just published my game and I need to release it for Android, but this is stopping me. It’s another Android Back button problem.
http://developer.coronalabs.com/forum/2013/01/09/android-director-issue
[import]uid: 46082 topic_id: 34520 reply_id: 138100[/import]
The best way to handle key events is like this…
[lua]local function onKeyEvent( event )
– Default to false so that all other keys will be handled by the OS.
local wasOverriden = false
if (“down” == event.phase) and (“back” == event.keyName) then
– Handle the back key here.
– Just make sure to not override it if your app is displaying the root/main screen
– so that the end-user can exit out of your app with the Back key.
wasOverriden = true
end
return wasOverriden
end
Runtime:addEventListener( “key”, onKeyEvent )[/lua]
The above allows all other keys that you do not wish to override to be handled by the OS, such as the volume keys.
Also, the Nook’s physical ‘n’ button is treated like a Back key if your app is not displaying a status bar. If your app is displaying a status bar, then the physical ‘n’ button becomes a Home key and then an onscreen back key will appear instead. This is how B&N designed it. There are no known bugs with Corona and the physical ‘n’ button. It definitely works and there are other Corona made apps on the Nook app store to prove it. [import]uid: 32256 topic_id: 34520 reply_id: 138214[/import]