Do I really need to implement the BACK button for Google Play or Amazon?

Solar2D Android
#4

For game apps, I think back button is not always necessary. I see many games don’t have back button implemented. When playing games, the user might click on the back button “unintentionally”, so it’s better not doing anything. Especially for landscape mode app, it’s really weird to have back button.

But it really depends on your game style. If your game has many levels of menus, the user might like to use the back button. Especially for business app (like mine), the user would demand the back button implemented. At the beginning, I didn’t implement back button, there were tons of requests/reviews complaining about the back button is not working, so I have to implement it later.

I don’t think Google would review this. It’s really depending on you & the app. If it’s convenient to have back button feature and you have the time, do it. If it doesn’t help much and users are fine without the back button, no need to do it.

Just my two cents.

#5

I think going to the main menu is a very rational thing to do. But if you are on the menu scene, you probably should make the requestExit() call that I think the blog post recommends.

Rob

#6

Hi, Cant you use something like subclass storyBoard.newScene and add an event listener there then use getPrevious ? Potentially you can have a property to the scenes to prohibit going back or overwriting the behavior Let us know what you do and the response from the stores, I havent dealt with this issue yet Atanas

#7

The problem with getPrevious() is that it creates a cycle:

Scene 1 -> Scene 2 -> Scene 3

now you use getPrevious() you goto Scene 2 as expected.  However getPrevious() will then take you back to Scene 3.  Then back to Scene 2 and the back to Scene 3.

There would need to be some type of history, similar to what a webbrowser does, but we don’t support that in Storyboard.

Rob

#8

Rob, you are right - but we can maintain a stack based list of the scenes in our descendant of storyboard, no?

And have an added parameter to each scene to specify the tabBar button index, so our storyboard would be able to update the tab bars selected button as well when going back?

Thanks,

  Atanas

#9

Atanas, that certainly would help but could also be a hindrance in some business apps. In a typical database driven app we have situations like this : 

1st Scene - Customers List  -tap on a customer->

2nd Scene - Orders for the chosen customer -tap on an order->

3rd Scene - Order details for order # -tap on an item in the order->

4th Scene or overlay - Item SKU details etc.

So in a situation like this you are typically staying on the same tabBar button all this time (ie Customers) and drilling down on the customer’s order history. You would expect the Back onscreen or Hardkey button to traverse you back the same order you drilled down maintaining the filter criteria of the records presented. 

Currently I make heavy use of the parameter passing capability built into Storyboard (params) as discussed here : 

http://www.coronalabs.com/blog/2012/08/07/managing-state-between-scenes/

and here http://www.coronalabs.com/blog/2012/04/27/scene-overlays-and-parameter-passing/

This approach is a little tedious to setup but works well once all done. I usually name a function goBack() and put all the code setting up params in there including a storyboard.gotoScene or storyboard.hideOverlay call in there. This function is linked to my onScreen < Back button in its onRelease setting. For Android, all I need to do in addition is to catch the hardware Back button press (listener?) and route it to the same function. 

Just sharing this use case so that you can hopefully accommodate it as well in your excellent Storyboard mods. 

Thanks & best regards

#10

Just wanted to add that when working on both iOS and Android apps for enterprise clients, and they want to use the same design for both apps, there will still always be a difference because typically an Android business app should not have a Back button. Android users expect the hardware back button to serve that function, and they use it automatically. So generally, as far as my experience goes, a Back button is not expected in an Android UI. 

#11

I’ve built a stack based implementation for a game I did and the back button popped scenes off the stack.  It really wasn’t hard to implement.   My logic is if there is an overlay showing, hide the overlay.  If I care, I’ll build the stack system, but in most cases, its simply go to the menu/home screen and then exit.

Rob

#12

Thank you SO much guys for the great info! Giving your feedback, I decided to forget about it for now. Plenty of others issues to deal with when converting an ios app to Android/Amazon!  making good progress with the help of the community. THANK YOU:)

Mo

#13

In general Google does not review your apps, so there is no one there to do that.  However they do on occasion pick apps to highlight/promote at which point they go over them with a fine-toothed comb and you can expect them to request changes.

Amazon tends to spend more time looking at your app but I don’t know if they have a back button rule. I’ve never had an app rejected for it.  Samsung however will reject your app if the back button doesn’t behave.  Barnes and Noble has never complained about it that I’m aware of.

If you do not implement the back button, it will exit your app.

Rob

#14

Fantasic Rob. I appreciate the info. Makes me feel MUCH better. I can see that you responded bunch answers about how to implement the back buttons on the forum. It seems that there is need to have to have some kind of logic (using Storyboard) I was going to use it to just always go back to the main menu of the game but since it is not strickly neccessary, I may postpone the implementation. Do you see any issue in having the back button always go back the main menu not matter where the user is in the app? (game) I was thinking about using something like this, taken directly from one of your answer (in main.lua)

local function onKeyEvent( event )
    local keyName = event.keyName
    local phase = event.phase

    if (keyName == “back” and phase == “up”) then
        print( “Back pressed” )
        storyboard.gotoScene(“menuScene”)
        return true
    end
    return false
end

Runtime:addEventListener(“key”, onKeyEvent)

#15

For game apps, I think back button is not always necessary. I see many games don’t have back button implemented. When playing games, the user might click on the back button “unintentionally”, so it’s better not doing anything. Especially for landscape mode app, it’s really weird to have back button.

But it really depends on your game style. If your game has many levels of menus, the user might like to use the back button. Especially for business app (like mine), the user would demand the back button implemented. At the beginning, I didn’t implement back button, there were tons of requests/reviews complaining about the back button is not working, so I have to implement it later.

I don’t think Google would review this. It’s really depending on you & the app. If it’s convenient to have back button feature and you have the time, do it. If it doesn’t help much and users are fine without the back button, no need to do it.

Just my two cents.

#16

I think going to the main menu is a very rational thing to do. But if you are on the menu scene, you probably should make the requestExit() call that I think the blog post recommends.

Rob

#17

Hi, Cant you use something like subclass storyBoard.newScene and add an event listener there then use getPrevious ? Potentially you can have a property to the scenes to prohibit going back or overwriting the behavior Let us know what you do and the response from the stores, I havent dealt with this issue yet Atanas

#18

The problem with getPrevious() is that it creates a cycle:

Scene 1 -> Scene 2 -> Scene 3

now you use getPrevious() you goto Scene 2 as expected.  However getPrevious() will then take you back to Scene 3.  Then back to Scene 2 and the back to Scene 3.

There would need to be some type of history, similar to what a webbrowser does, but we don’t support that in Storyboard.

Rob

#19

Rob, you are right - but we can maintain a stack based list of the scenes in our descendant of storyboard, no?

And have an added parameter to each scene to specify the tabBar button index, so our storyboard would be able to update the tab bars selected button as well when going back?

Thanks,

  Atanas

#20

Atanas, that certainly would help but could also be a hindrance in some business apps. In a typical database driven app we have situations like this : 

1st Scene - Customers List  -tap on a customer->

2nd Scene - Orders for the chosen customer -tap on an order->

3rd Scene - Order details for order # -tap on an item in the order->

4th Scene or overlay - Item SKU details etc.

So in a situation like this you are typically staying on the same tabBar button all this time (ie Customers) and drilling down on the customer’s order history. You would expect the Back onscreen or Hardkey button to traverse you back the same order you drilled down maintaining the filter criteria of the records presented. 

Currently I make heavy use of the parameter passing capability built into Storyboard (params) as discussed here : 

http://www.coronalabs.com/blog/2012/08/07/managing-state-between-scenes/

and here http://www.coronalabs.com/blog/2012/04/27/scene-overlays-and-parameter-passing/

This approach is a little tedious to setup but works well once all done. I usually name a function goBack() and put all the code setting up params in there including a storyboard.gotoScene or storyboard.hideOverlay call in there. This function is linked to my onScreen < Back button in its onRelease setting. For Android, all I need to do in addition is to catch the hardware Back button press (listener?) and route it to the same function. 

Just sharing this use case so that you can hopefully accommodate it as well in your excellent Storyboard mods. 

Thanks & best regards

#21

Just wanted to add that when working on both iOS and Android apps for enterprise clients, and they want to use the same design for both apps, there will still always be a difference because typically an Android business app should not have a Back button. Android users expect the hardware back button to serve that function, and they use it automatically. So generally, as far as my experience goes, a Back button is not expected in an Android UI. 

#22

I’ve built a stack based implementation for a game I did and the back button popped scenes off the stack.  It really wasn’t hard to implement.   My logic is if there is an overlay showing, hide the overlay.  If I care, I’ll build the stack system, but in most cases, its simply go to the menu/home screen and then exit.

Rob

#23

Thank you SO much guys for the great info! Giving your feedback, I decided to forget about it for now. Plenty of others issues to deal with when converting an ios app to Android/Amazon!  making good progress with the help of the community. THANK YOU:)

Mo