"Global" handling of Android hardware back button

Solar2D Android
#1

Hi!

I am developing a storyboard-based applications with several scenes that show menus and different screens.

Almost all of these different scenes have a graphical back button in them. This button is created and defined centrally in one function.

What I want to achieve is the following: On Android, the hardware back button should behave, like the graphical back button was pressed. And furthermore I don’t want to code this for all scenes separate, but only once in my “back button function”.

When I add an EventListener to the Runtime at the start of the app, I already need to define a function that is going to be called when the back button was pressed. But the function I want to be called is different from scene to scene.

What I need is the possibility to throw a global “Hardware Back Button was pressed” event for the Runtime, and catch this event wherever it was pressed, individually in any given scene.

Is that possible? And if so, could you give me a small code example?

Thank you for your help!

#2

See this blog post to get you started.

The trick is you really can’t use the storyboard.getPrevious() since it doesn’t act like a history. You basically have to make your own history.  The blog offers one suggestion on how to do that. 

#3

Hi, our solution to this was extending the storyboard API to automatically handle the “back” function.

The missing piece in the storyboard API are global event handlers to handle when a scene is changed… it would look like:

storyboard:addEventListener( “enterScene”, someFunction )

If we had such a function maintaining a “history” would be a breeze… Too bad that API is not available :slight_smile:

But the good news is that with Lua it was very easy to extend the storyboard API and we actually implemented it for our games. The trick is to override the newScene() function and created a wrapped scene, that not only reacts to the default events but also dispatchs a “global” event.

We also wrapped gotoScene, showOverlay and hideOverlay just so we have full control of what scene is currently showing.

I would gladly share our code but it’s tied to a lot of other libraries we wrote and it would be quite difficult to seperate it… For example our “extended” scene object also manages loaded sounds and frees any sound loaded during the scene lifetime when it is destroyed. In the same manner it cancels any transition or timer that is still active when you exit the scene…

#4

Which blog post did you mean?

#5

Ooops:

http://www.coronalabs.com/blog/2013/03/26/androidizing-your-mobile-app/

#6

@gtt: Thx for this info, this seems to be a very sophisticated approach!

@Rob: Thx for the link!

I’ll try to work out a solution that works for my app!

#7

See this blog post to get you started.

The trick is you really can’t use the storyboard.getPrevious() since it doesn’t act like a history. You basically have to make your own history.  The blog offers one suggestion on how to do that. 

#8

Hi, our solution to this was extending the storyboard API to automatically handle the “back” function.

The missing piece in the storyboard API are global event handlers to handle when a scene is changed… it would look like:

storyboard:addEventListener( “enterScene”, someFunction )

If we had such a function maintaining a “history” would be a breeze… Too bad that API is not available :slight_smile:

But the good news is that with Lua it was very easy to extend the storyboard API and we actually implemented it for our games. The trick is to override the newScene() function and created a wrapped scene, that not only reacts to the default events but also dispatchs a “global” event.

We also wrapped gotoScene, showOverlay and hideOverlay just so we have full control of what scene is currently showing.

I would gladly share our code but it’s tied to a lot of other libraries we wrote and it would be quite difficult to seperate it… For example our “extended” scene object also manages loaded sounds and frees any sound loaded during the scene lifetime when it is destroyed. In the same manner it cancels any transition or timer that is still active when you exit the scene…

#9

Which blog post did you mean?

#10

Ooops:

http://www.coronalabs.com/blog/2013/03/26/androidizing-your-mobile-app/

#11

@gtt: Thx for this info, this seems to be a very sophisticated approach!

@Rob: Thx for the link!

I’ll try to work out a solution that works for my app!