Android 'back-button' behaviour

I couple of years ago I started a little project in Processing, just for the fun of it. Now, after learning masses amounts of coding and with help from a lot of you clever brains on this forum I have a little game running on my Android that I would like to publish. But there's one thing holding me off and bugging me: back button behaviour.

My game has a menu screen from where the player can pick a level, this will take him to the level. On screen I have a back button scripted to take the player back to the menu. But the default instinct of any Android user is to use the 'Back-Button' on the bottom of the device to step back in his navigation, expecting to navigate back to the menu. But with Processing this results in exiting or killing the application.

I know this topic has been discussed in the past, but it seems there have not been any decent solutions. People have suggested overriding or catching the behaviour and killing the buttons functionality before they get executed. I've tested these methods, but none of them work. At least not for me. And rightfully some of you have pointed out that this is the native behaviour of Android, which can't be changed (the back button either steps back in activity, if available, otherwise it kills the application).

I respect that, but I very much would like to find a solution in whatever form. I wouldn't want to launch a game that throws people off because it doesn't respond as they would expect.

Are there any clever ideas, any work-arounds, anything I've missed? Anyone that encountered the same issue and managed to resolve it in whatever way.

I'm on currently on Processing 3.3.6 And unfortunately I have little to no experience with Android Studio or Eclipse (yet).

Thanks!

Answers

  • @geerd====

    i have already explained in this forum that there is not any way to "kill" the back button because it is against all android principles; as for "workarounds" depends of your app and needs: what you can do is to get the back event and do stuff at this moment (save data, info....)(open an alertDialog...).

    Anyway what i dont understand in your description is the exact logic of your app: at launch you have (fragment A) your screen menu (i suppose) where you choose a level; then what happens??? Do you create an another B activity?? Another B fragment??? - Because if "yes" the pressed back button in the B activity or B fragment will not "kill" your app, the user goes to the Fragment A via onResume().

  • Another suggestion is to use toolBar menu buttons. I have seen some posts in the forum within the last 6 months. it is possible they are easier to integrate with the latest Android Mode 4 (Untested). For the toolbar button, you offer the user an option to go back as a expandable menu.

    I haven't done much about integrating fragments but akenaton's idea makes sense. If you are creating multiple fragments, then you can manage the fragments by using the back stack. My understanding is that for fragments, you need to place the fragment in the back stack if you want to recover it (navigate back) using the back button. However, consider this. If the user wants to move back and also wants to move forward in your game (for instance, undoing a back action), you won't be able to accomplish this using the back button physical button. The expandable menu option will be a more natural solution.

    More about the back stack, check this: https://developer.android.com/guide/components/activities/tasks-and-back-stack.html

    Kf

  • How do you create multiple fragments in Processing though? This seems beyond what Processing is designed for ... a way into simple programming for artists!

  • @hudson_m4000

    I don't know if it is possible. Maybe you have to start by using the java file generated by Processing so there is no transpilation from processing code to java. This is just a guess and it will require to dig into the source code that codeanticode and his team maintains. Is it possible? If it is not, then my suggestion is to move to AS. Upfront, I cannot tell if my suggestion is 100% correct. I see it as a possible design, and it is a behavior I have seen in other apps.

    I can only see it would be great to have a simple example and most of the times, I will put some effort to generate one. However I am not in a position to do one atm.

    Kf

  • Thanks for the response!

    The menu and 'levels' in my app are part of the same sketch. I simply keep track of a variable and render the menu if this is 0 and render the level if it's 1. When the player finishes the level I set the variable back to 0 in order to render the menu again. As simple as that.

    Without any knowledge of Activities and Fragments I was thinking I could change the state of the variable when the back-button was pressed. But I see this is slightly more involved then expected. And the back-stack principle makes sense.

    I haven't done much reading on activities, fragments and back stack, so will start there. But if anyone has a similar example of how this is with Processing feel free to post.

  • @kfrajer, @ hudson_m4000===

    you can create a fragment or an activity with p5, though it is not as simple as with eclipse or AS.

  • Misunderstanding .... I don't want to create any new fragments or activities. I was suggesting that Processing isn't the IDE to use if that's what a user needs .. as you say @akenaton use AS !

  • @hudson_m4000===

    ha! - ok: i agree with you, what i only said is that it is POSSIBLE, even with P5 - loosing a lot of its qualities and a couple of hours: which means that this "POSSIBLE" is rather "STUPID"!

Sign In or Register to comment.