I am looking for the best way in which you would setup navigation in an Android game; a best practice for Android Game Activity Navigation. I have the following scenario:
A Main Menu Activity (Greets the User on Start and gives them options)
A RunLever Activity (This runs a level of the game)
A Transitional Menu Activity (This appears between levels and shows scores and stuff like that while providing a button to go to the next level)
Therefore, if the player starts the game and completes two levels they might have an activity stack that looks something like this:
The problem that I have here is one of expectations when the back button is pressed:
If I was on the last In Between Menu and I pressed back then I would expect to go back to the Main Menu. Instead it would probably take me back to the level that I just won.
I would not expect the last levels that I have played and previous In Between Menu activities to stay sitting there in the Back Stack. I would only expect the Main Menu, the Current Level I am playing and one instance of the In Between Menu to be sitting in the back stack at any one time.
As far as I can tell everything else will work properly and as the user expects. I guess I just want to know what the best options are to solve this kind of problem. To make sure that the activities in this game occur as expected. Should they even be separate Activities? Thanks.
Rather than pushing a new In Between Menu Activity after completing a level, can you instead pop the activity stack, and detect that (e.g.) level one has been completed when the already-there in between activity becomes active again?
That way, the first "back" would always go back to the in-between, the second "back" would go back to the main menu, and the third "back" would leave the game. All of which is probably what the user expects.
Related
Hi Guys I have 2 activities, 1 is in Android Native(Extends Activity) and 2 is in LIBGdx extends AndroidApplication.
I go from activity 1 to activity 2 and then come back to activity 1 by pressing the back key, then I come back to activity 2 again. This time activity 2 is black and black in color.
Does it has anything to do with libgdx or its an android issue?
Thanks
This sounds like libGdx is losing the openGL context. libgdx will get this back automatically when the app goes out of focus (incoming phone call, user presses home key, etc) and then comes back into focus, but here the app never loses focus--only the activity does--so libgdx doesn't know to restore itself.
Does the user need to go back to the first screen? If not, I would mark the first activity android:noHistory="true" in the manifest. That makes the back button skip the activity, so the app itself will lose focus.
Otherwise, put debug statements in your ApplicationListener's create(), resume(), pause(), and dispose() methods so we can see how that life cycle is playing out.
I am working through Android programming tutorials and am trying to learn "Up" navigation. I got it to work by adding setDisplayHomeAsUpEnabled, but when I remove this statement, clean the project and re-deploy, up navigation still works. Why does this happen? I should just see a static, go-nowhere child activity screen, shouldn't I?
Activities are automatically pushed onto a stack, the up/back button naturally pops the stack.
Life cycle of Android Activity after pressing Back button
I am implementing a dashboard plus action bar UI, like in the Twitter app:
Each button on the dashboard takes the user to a different activity. A few of these activities are more important than the others, and I could imagine the user switching between them via the dashboard reasonably often.
I feel like I have two options:
Keep an activity cycle going using intent flags, so that when the user goes back to the dashboard it just pushes the dashboard activity to the top of the stack. Then when the user returns to another activity, it pushes that one to the top of the stack. No activity would be destroyed until the OS does it to gain back memory, which would be fine.
Let the activities be destroyed when the user goes back to the dashboard, then recreated later.
Which option is better in terms of performance and best practices? I like option 1 but am not sure if I'm abusing the purpose of those intent flags. And if I do go with option 1, should I also override what the back button does so that finish() isn't called?
Personally I like the first option better. This way, you would easily remember the state of the other activities when the user returns to them.
For example, if in a child activity the user scrolls some list, then goes back to the dashboard, and then returns back to the child activity, the scroll position will be where he left it off.
Regarding memory, I don't think it's an issue. Let's take a tab component for example (which is a parallel navigation controller to your dashboard). With a tab control, all the child activities (the tab activities) are never destroyed as well.
If memory does become an issue, I would combine your two ideas. For the less important activities I would implement approach 2 (destroy them on back), and for the more important activities (where state is important for the user for example), I would implement approach 1.
When an application has a single view, the Back button probably resumes whatever previous application was running/suspended. I'm tempted to provide an explicit button which says 'Back' right there on the UI ...
Should I provide an explicit back button in my view, or should I simply override the navigation button provided by the OS? My gut says the latter would be counter-intuitive. Are there any recommendations on this by the android community?
That entirely depends on your application. Normally, your application is made out of multiple activities (Activity objects), and the back button will go to the previous activity.
So if your app has a main menu (activity A), which has a button to go to search (activity B), which will lead to search results (activity C), then pressing the back button on the search page gets you back to the main menu. This is fully automatic, you don't need to write anything for this to work.
That's how Android works, and that's how you should write your app. All Android devices have a device button (physical or on-screen, in case of Honeycomb), so don't waste precious screen real estate on a "back button". Don't be like the iPhone.
I have read into the finish(); commands and the FLAG_ACTIVITY_CLEAR_TOP commands and also checked out Common Ware's answer on killing app, but I am not sure how to put this into my app.
Basically, I have a user click a button that takes them to the camera. The user then snaps a photo and it brings them to a layout view. The user then clicks a button that takes them to one of 2 views, depending on a some conditions.
The user is then allowed to either retake a photo, or go to the main menu (depending). My problem is, if the user goes back to the main menu, and snaps another, then another, etc...the activities stack, so when I click the 'Main Menu' button the app goes back through eached stack activity until finally it goes back to the main menu. Is there a way to kill each activity with one of these lines, so even if a user retakes a photo, they will only need to go back once to get to the main menu?
Thanks for anyhelp.
You could use the noHistory flag which would end each activity once you're away from it.
Probably though, what you really want is singleTop launch mode, that will return to your previously opened activity rather than making a new instance of it.