When you enter my app, you always go to the main screen with some quick details/information. There is a navigation drawer which contains 3 items: Recordings, Videos, Settings. I would prefer navigation work where Recordings and Videos are the top activity actions, so if you navigate down either and press Up/Home or Back button, you would ultimately navigate back up to the Main Screen. So if you switch from Recordings to Videos, and press back, you should go back to Main and vice a verse. Main should always be the ultimate top activity.
If you hit Settings, you should go back to where ever you previously came from (i.e. if on videos, go back to videos, if on recordings go back to recordings or if on main, go back to main). Settings is cross-cutting and should always take you back to where you previously were.
How do I best implement this with the Navigation Drawer? I believe it will be something with clearing the stack once you enter either Recordings or Videos, but I am unsure what it is I need to search for to find this.
The fix was to override onBackPressed to navigate back to the main screen, so long as the appropriate launchMode is set in either the Android Manifest or Intent flags.
Thanks #cricket_007
Related
My problem is illustrated by this screen record.
When I click the FAB on FinanceFragment, it will open AddTransactionFragment. But when I navigate to ReminderFragment and go back to FinanceFragment, the AddTransactionFragment is destroyed.
How could I -- similar to the YouTube app when one switches between fragments -- keep AddTransactionFragment visible while I navigate to another fragment?
I tried to add addToBackStack() but this turned out not to be what I was looking for.
I have two fragments (for ex. fragmentA and fragmentB).
first , in fragmentA use findNavController().navigate(R.id.action_fragmentA_to_fragmentB) to navigate to fragmentB .
then , in fragmentB if you want to back to fragmentA. there are two ways in below :
just press back button : fragmentA's onCreate() won't be called
findNavController().navigate(R.id.action_fragmentB_to_fragmentA) : fragmentA's onCreate() will be called
why?
The reason that the back button doesn't call onCreate of the fragment is by design. Users would not expect the back button to call the onCreate, or create, your fragment again.
As an example, think about when you open the YouTube app on Android and you are shown your home screen, populated with videos based on your interests. When you tap on a video after a bit of scrolling and then midway through the video decide to go back by pressing the back button, you expect the app to go back where you tapped on the video, with the same amount of scrolling you had done, instead of reloading your entire home page again filling with new videos and resetting you to the top of the screen.
Similarly, back button in your app should do the same. If however, you want your back button to behave differently, android does provide a way to do this. Refer to this for that.
The navigation design guide explains:
When the previously viewed screen is also the hierarchical parent of the current screen, pressing the Back button has the same result as pressing an Up button—this is a common occurrence.
up vs back - navigation guide
I have a MainActivity A which opens another activity B when touching a navigation entry in the NavigationDrawer. Activity A is set to be the parent of activity B in the AndroidManifest: android:parentActivityName=".MainActivity"
I followed this android documentaion to add up navigation to activity B. It shows how to implement onOptionsItemSelected in activity B:
override fun onOptionsItemSelected(item: MenuItem): Boolean {
when (item.itemId) {
android.R.id.home -> {
// Respond to the action bar's Up/Home button
NavUtils.navigateUpFromSameTask(this)
return true
}
}
return super.onOptionsItemSelected(item)
}
When I press back from Activity B the state of Activity A was saved and the NavigationDrawer is opened. If I use the up navigation though, onCreate()of activity A is called and it lost its state (the drawer is closed etc.).
This is not the quoted "same result".
When I replace the NavUtils.navigateUpFromSameTask(this) with a simple finish() it has the same behavior as pressing back - the state of activity A is kept.
Naturally I would prefer the way using finish. So what is the intended behavior? Do the guides contradict each other or am missing something?
It is an unfortunate reality that Google leaves documentation up for longer than it is relevant, and will even post two different pieces of documentation that directly contradict each other.
In the case of the Up button, your link says
The Up button appears in the app bar and is used to navigate within an app based on the hierarchical relationships between screens. [...]
The Back button appears in the system navigation bar and is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy.
However, there is also this article, which says
When the system Back button would not exit your app, such as when you are on your own task and not on the start destination, the Up button should function identically to the system Back button.
So... which one should you trust?
I assert that you should trust the second one. The first one was posted years ago; I don't know its exact age, but you can tell that it's old because the screenshots all use the Holo theme. The second one, on the other hand, is part of Android's Architecture Components, so is significantly newer. In general, I'd go with the newest piece of documentation.
Additionally, I think that Google was wrong to say for all these years that the Up button should work differently from the Back button. As someone who spent a lot of time thinking about navigation in my app, I see where they were coming from, but real-world users always get confused when Up did something "different".
So I'd go ahead and just finish() your activity when the user presses the Up button, and not worry about those two articles you found.
I think the change of policy to suggest consistency between the up icon and the system back button is a good idea. However the advice that you should:
"navigate in reverse-chronological order through the history of screens"
Is too crude, or at least should be clarified what they mean by "screen".
eg. When you have a bottom nav bar, the back button / up icon should take you back up the hierarchy within your tab section before jumping to the section previously visited. And you should preserve the previous state when revisiting a tab section (which may be drilled down into a lower level screen).
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.
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.