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
Related
I noticed an insanely big bug with the Shell navigation. Am I doing something wrong?
Let's say we add 3 FlyoutItems to the Menu. After that navigate to the first one, then the second one, and finally the last one using the menu items.
Then press the back button of the mobile phone (I have Android 11). It will collapse the whole application to the background instead of navigating back to the second Page.
What do you think? That is a huge-huge UX bug In my opinion.
When I do the navigation with the await Shell.Current.GoToAsync(nameof(MyPage)) then the navigation stack is builded, so the back button will bring the previous page. But why not with menuitem navigation?
I'm developing an app for Wear OS.
It has 2 screens, both extending from AppCompatActivity, both havingandroid.support.wear.widget.BoxInsetLayout as the root of their layouts.
From the first one i can navigate to the second one and in the second screen use left-right swipe to navigate back without problems, i didn't need to do anything for this to work.
For the first screen the same left-right swipe is not doing anything, and i can't understand why, as the documentation says:
An activity automatically supports swipe-to-dismiss. Swiping an activity from left to right results in dismissal of the activity, and the app navigates down the back stack.
Witch makes sense after seeing the default behaviour of my 2nd screen.
I've tried to put a SwipeDismissFrameLayout as the root element of that screen, that make the swipe work, but, instead of showing the watch face that is below, it's showing a gray screen and it's also not finishing the activity (unless i explicitly do it implementing the callback)
From what i can understand in the docs this should be working without having to do anything, but for some reason it's not...
Both activities have the same style and same layout root element.
Is there something i'm missing to make this work?
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).
Will be obliged if someone can help me with this.We were working on some android application,while designing its prototype we came across some issues.A little description of the application's prototype is as follows:
A Log in screen
a Home screen with logout at its top right
Every other activity is having a home button on top right corner.
Now going from one activity to the other in my application, I just called finished on the current activity and started the other(so there is no stack of the activities is being created) and when home button present on each activity's top corner is pressed i finish the current activity and move to the home screen.
More precisely,i can say that i am overriding every activty's onBackPressed() method
.By doing this i am not letting android to keep a stack of the activity's but by doing this I have a feeling that, I am loosing efficiency and degrading performance.Because on every backpress or home button click one activity is finished and the other is created.Hence some lag can be seen as the acivity is recreated.
Please suggest that should I continue WITH THIS or there is some other way out to handle this
Thank you for Giving your time
It is depends.
If you are giving option on each screen to to go home this approach is good.
Because if you are keep activities in stack it will be in RAM which is limited so it may create memory issue if to many activities in stack.
I would like to suggest one more thing.
As you say you have overridden onBackPressed() method in each activity.
Rather doing this there is a option you can specify parent activity in manifest tag.
So you no need to manually handle by overriding onBackPressed() method.
EG.
<activity
android:name="com.xxx.DetailActivity"
android:parentActivityName="com.xxx.src.ListActivity"
android:screenOrientation="portrait"
android:theme="#android:style/Theme.Translucent.NoTitleBar.Fullscreen" />
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.