Navigation graph with multiple top level destinations
I am implementing an android app (in Kotlin, but that is not relevant to the Problem) in my free time and I try to use android jetpack and new libraries. I have a single Activity with a navigation drawer. I try to follow the sample sunflower app. It uses the following combination in the main activity to enable the logic behind the navigation drawer:
appBarConfiguration = AppBarConfiguration(navController.graph, drawerLayout)
setSupportActionBar(findViewById(R.id.toolbar))
setupActionBarWithNavController(navController, appBarConfiguration)
Note on this code: This automatically will navigate to the correct fragments when clicked in the navigation drawer and close the drawer and keep them selected etc. All that boilerplate code. That is pretty neat and also works. As far as I understand this, the IDs of the navigation drawer menu items have to match the ids of the fragments in the navigation graph and this way they are connected.
The problem I have: When I use the navigation drawer to go to any fragment other than the starting fragment of the navigation graph, it will display a back button instead of the hamburger item. That is not what I expect, I would expect it still to be the hamburger item since the navigation drawer is for navigating between views on an equal level and not nested in each other, right? I expect a back button if I navigate to a subfragment of any fragment by clicking on elements in that fragment (for example list -> detail) but not if I navigate using the navigation drawer.
Now I traced that problem back to the AppBarConfiguration builder which reads on the constructor taking a navgraph The NavGraph whose start destination should be considered the only top level destination. I can fairly easily fix that by overriding AppBarConfiguration to return different top level destinations than just the starting destination of the navigation graph.
However my question is, why is there this behaviour default? Is it a bug? If I override this will I violate some design guidelines by Google? Should not every element in the navigation drawer be on the same level how I expect it? Is there a different solution inteded for I want to do?
add a comment |
I am implementing an android app (in Kotlin, but that is not relevant to the Problem) in my free time and I try to use android jetpack and new libraries. I have a single Activity with a navigation drawer. I try to follow the sample sunflower app. It uses the following combination in the main activity to enable the logic behind the navigation drawer:
appBarConfiguration = AppBarConfiguration(navController.graph, drawerLayout)
setSupportActionBar(findViewById(R.id.toolbar))
setupActionBarWithNavController(navController, appBarConfiguration)
Note on this code: This automatically will navigate to the correct fragments when clicked in the navigation drawer and close the drawer and keep them selected etc. All that boilerplate code. That is pretty neat and also works. As far as I understand this, the IDs of the navigation drawer menu items have to match the ids of the fragments in the navigation graph and this way they are connected.
The problem I have: When I use the navigation drawer to go to any fragment other than the starting fragment of the navigation graph, it will display a back button instead of the hamburger item. That is not what I expect, I would expect it still to be the hamburger item since the navigation drawer is for navigating between views on an equal level and not nested in each other, right? I expect a back button if I navigate to a subfragment of any fragment by clicking on elements in that fragment (for example list -> detail) but not if I navigate using the navigation drawer.
Now I traced that problem back to the AppBarConfiguration builder which reads on the constructor taking a navgraph The NavGraph whose start destination should be considered the only top level destination. I can fairly easily fix that by overriding AppBarConfiguration to return different top level destinations than just the starting destination of the navigation graph.
However my question is, why is there this behaviour default? Is it a bug? If I override this will I violate some design guidelines by Google? Should not every element in the navigation drawer be on the same level how I expect it? Is there a different solution inteded for I want to do?
add a comment |
I am implementing an android app (in Kotlin, but that is not relevant to the Problem) in my free time and I try to use android jetpack and new libraries. I have a single Activity with a navigation drawer. I try to follow the sample sunflower app. It uses the following combination in the main activity to enable the logic behind the navigation drawer:
appBarConfiguration = AppBarConfiguration(navController.graph, drawerLayout)
setSupportActionBar(findViewById(R.id.toolbar))
setupActionBarWithNavController(navController, appBarConfiguration)
Note on this code: This automatically will navigate to the correct fragments when clicked in the navigation drawer and close the drawer and keep them selected etc. All that boilerplate code. That is pretty neat and also works. As far as I understand this, the IDs of the navigation drawer menu items have to match the ids of the fragments in the navigation graph and this way they are connected.
The problem I have: When I use the navigation drawer to go to any fragment other than the starting fragment of the navigation graph, it will display a back button instead of the hamburger item. That is not what I expect, I would expect it still to be the hamburger item since the navigation drawer is for navigating between views on an equal level and not nested in each other, right? I expect a back button if I navigate to a subfragment of any fragment by clicking on elements in that fragment (for example list -> detail) but not if I navigate using the navigation drawer.
Now I traced that problem back to the AppBarConfiguration builder which reads on the constructor taking a navgraph The NavGraph whose start destination should be considered the only top level destination. I can fairly easily fix that by overriding AppBarConfiguration to return different top level destinations than just the starting destination of the navigation graph.
However my question is, why is there this behaviour default? Is it a bug? If I override this will I violate some design guidelines by Google? Should not every element in the navigation drawer be on the same level how I expect it? Is there a different solution inteded for I want to do?
I am implementing an android app (in Kotlin, but that is not relevant to the Problem) in my free time and I try to use android jetpack and new libraries. I have a single Activity with a navigation drawer. I try to follow the sample sunflower app. It uses the following combination in the main activity to enable the logic behind the navigation drawer:
appBarConfiguration = AppBarConfiguration(navController.graph, drawerLayout)
setSupportActionBar(findViewById(R.id.toolbar))
setupActionBarWithNavController(navController, appBarConfiguration)
Note on this code: This automatically will navigate to the correct fragments when clicked in the navigation drawer and close the drawer and keep them selected etc. All that boilerplate code. That is pretty neat and also works. As far as I understand this, the IDs of the navigation drawer menu items have to match the ids of the fragments in the navigation graph and this way they are connected.
The problem I have: When I use the navigation drawer to go to any fragment other than the starting fragment of the navigation graph, it will display a back button instead of the hamburger item. That is not what I expect, I would expect it still to be the hamburger item since the navigation drawer is for navigating between views on an equal level and not nested in each other, right? I expect a back button if I navigate to a subfragment of any fragment by clicking on elements in that fragment (for example list -> detail) but not if I navigate using the navigation drawer.
Now I traced that problem back to the AppBarConfiguration builder which reads on the constructor taking a navgraph The NavGraph whose start destination should be considered the only top level destination. I can fairly easily fix that by overriding AppBarConfiguration to return different top level destinations than just the starting destination of the navigation graph.
However my question is, why is there this behaviour default? Is it a bug? If I override this will I violate some design guidelines by Google? Should not every element in the navigation drawer be on the same level how I expect it? Is there a different solution inteded for I want to do?
edited Nov 27 '18 at 16:33
findusl
asked Nov 19 '18 at 10:23
finduslfindusl
746926
746926
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
You don't have to override AppBarConfiguration. Since version alpha7 AppBarConfiguration has a constructor with a set of ids for all top level destinations.
Set<Integer> topLevelDestinations = new HashSet<>();
topLevelDestinations.add(R.id.fragment1);
topLevelDestinations.add(R.id.fragment2);
appBarConfiguration = new AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build();
NavigationUI.setupActionBarWithNavController(this,
this.navController,
this.appBarConfiguration);
This is not default as the navigation graph has only a single start fragment which should always be the single entry point of the application.
Editing the default behavior with AppBarConfiguration does not make it behave as before, every top level fragment is placed on the back stack so back button will go to all top level fragments. It is unclear how I can make top level fragments as the first element of the back stack.
Oh I didn't notice the AppBarConfiguration only uses the nav_graph to get the top level destination and then discards it. At least that is what I assume as the AppBarConfiguration has no getter for the nav_graph. Thanks I will try it when I can. Since it is a free time project I will need to see when I find time.
– findusl
Nov 20 '18 at 10:26
Obviously we need to deep dive into JavaDoc in order to find out, that this solution exists. I was looking for top level destination specification for about 2 hours. This is only SO answer targeting this issue. Hopefully many upvotes upcoming
– VizGhar
Nov 23 '18 at 9:54
add a comment |
I made simple example for this issue.
https://github.com/isaul32/android-sunflower
Create set of top level destinations at first
val topLevelDestinations = setOf(R.id.garden_fragment,
R.id.plant_list_fragment)
appBarConfiguration = AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build()
and then override onSupportNavigateUp function like this
override fun onSupportNavigateUp(): Boolean {
return NavigationUI.navigateUp(navController, appBarConfiguration)
}
The last step to overrideonSupportNavigateUp()is only required if you use the defaultActionBar. If you add your ownToolBarthis behavior is already implemented when callingNavigationUI.setupWithNavController(Toolbar toolbar, NavController navController, AppBarConfiguration configuration).
– Elias DC
Dec 12 '18 at 12:42
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53372539%2fnavigation-graph-with-multiple-top-level-destinations%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You don't have to override AppBarConfiguration. Since version alpha7 AppBarConfiguration has a constructor with a set of ids for all top level destinations.
Set<Integer> topLevelDestinations = new HashSet<>();
topLevelDestinations.add(R.id.fragment1);
topLevelDestinations.add(R.id.fragment2);
appBarConfiguration = new AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build();
NavigationUI.setupActionBarWithNavController(this,
this.navController,
this.appBarConfiguration);
This is not default as the navigation graph has only a single start fragment which should always be the single entry point of the application.
Editing the default behavior with AppBarConfiguration does not make it behave as before, every top level fragment is placed on the back stack so back button will go to all top level fragments. It is unclear how I can make top level fragments as the first element of the back stack.
Oh I didn't notice the AppBarConfiguration only uses the nav_graph to get the top level destination and then discards it. At least that is what I assume as the AppBarConfiguration has no getter for the nav_graph. Thanks I will try it when I can. Since it is a free time project I will need to see when I find time.
– findusl
Nov 20 '18 at 10:26
Obviously we need to deep dive into JavaDoc in order to find out, that this solution exists. I was looking for top level destination specification for about 2 hours. This is only SO answer targeting this issue. Hopefully many upvotes upcoming
– VizGhar
Nov 23 '18 at 9:54
add a comment |
You don't have to override AppBarConfiguration. Since version alpha7 AppBarConfiguration has a constructor with a set of ids for all top level destinations.
Set<Integer> topLevelDestinations = new HashSet<>();
topLevelDestinations.add(R.id.fragment1);
topLevelDestinations.add(R.id.fragment2);
appBarConfiguration = new AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build();
NavigationUI.setupActionBarWithNavController(this,
this.navController,
this.appBarConfiguration);
This is not default as the navigation graph has only a single start fragment which should always be the single entry point of the application.
Editing the default behavior with AppBarConfiguration does not make it behave as before, every top level fragment is placed on the back stack so back button will go to all top level fragments. It is unclear how I can make top level fragments as the first element of the back stack.
Oh I didn't notice the AppBarConfiguration only uses the nav_graph to get the top level destination and then discards it. At least that is what I assume as the AppBarConfiguration has no getter for the nav_graph. Thanks I will try it when I can. Since it is a free time project I will need to see when I find time.
– findusl
Nov 20 '18 at 10:26
Obviously we need to deep dive into JavaDoc in order to find out, that this solution exists. I was looking for top level destination specification for about 2 hours. This is only SO answer targeting this issue. Hopefully many upvotes upcoming
– VizGhar
Nov 23 '18 at 9:54
add a comment |
You don't have to override AppBarConfiguration. Since version alpha7 AppBarConfiguration has a constructor with a set of ids for all top level destinations.
Set<Integer> topLevelDestinations = new HashSet<>();
topLevelDestinations.add(R.id.fragment1);
topLevelDestinations.add(R.id.fragment2);
appBarConfiguration = new AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build();
NavigationUI.setupActionBarWithNavController(this,
this.navController,
this.appBarConfiguration);
This is not default as the navigation graph has only a single start fragment which should always be the single entry point of the application.
Editing the default behavior with AppBarConfiguration does not make it behave as before, every top level fragment is placed on the back stack so back button will go to all top level fragments. It is unclear how I can make top level fragments as the first element of the back stack.
You don't have to override AppBarConfiguration. Since version alpha7 AppBarConfiguration has a constructor with a set of ids for all top level destinations.
Set<Integer> topLevelDestinations = new HashSet<>();
topLevelDestinations.add(R.id.fragment1);
topLevelDestinations.add(R.id.fragment2);
appBarConfiguration = new AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build();
NavigationUI.setupActionBarWithNavController(this,
this.navController,
this.appBarConfiguration);
This is not default as the navigation graph has only a single start fragment which should always be the single entry point of the application.
Editing the default behavior with AppBarConfiguration does not make it behave as before, every top level fragment is placed on the back stack so back button will go to all top level fragments. It is unclear how I can make top level fragments as the first element of the back stack.
answered Nov 20 '18 at 10:17
Elias DCElias DC
865
865
Oh I didn't notice the AppBarConfiguration only uses the nav_graph to get the top level destination and then discards it. At least that is what I assume as the AppBarConfiguration has no getter for the nav_graph. Thanks I will try it when I can. Since it is a free time project I will need to see when I find time.
– findusl
Nov 20 '18 at 10:26
Obviously we need to deep dive into JavaDoc in order to find out, that this solution exists. I was looking for top level destination specification for about 2 hours. This is only SO answer targeting this issue. Hopefully many upvotes upcoming
– VizGhar
Nov 23 '18 at 9:54
add a comment |
Oh I didn't notice the AppBarConfiguration only uses the nav_graph to get the top level destination and then discards it. At least that is what I assume as the AppBarConfiguration has no getter for the nav_graph. Thanks I will try it when I can. Since it is a free time project I will need to see when I find time.
– findusl
Nov 20 '18 at 10:26
Obviously we need to deep dive into JavaDoc in order to find out, that this solution exists. I was looking for top level destination specification for about 2 hours. This is only SO answer targeting this issue. Hopefully many upvotes upcoming
– VizGhar
Nov 23 '18 at 9:54
Oh I didn't notice the AppBarConfiguration only uses the nav_graph to get the top level destination and then discards it. At least that is what I assume as the AppBarConfiguration has no getter for the nav_graph. Thanks I will try it when I can. Since it is a free time project I will need to see when I find time.
– findusl
Nov 20 '18 at 10:26
Oh I didn't notice the AppBarConfiguration only uses the nav_graph to get the top level destination and then discards it. At least that is what I assume as the AppBarConfiguration has no getter for the nav_graph. Thanks I will try it when I can. Since it is a free time project I will need to see when I find time.
– findusl
Nov 20 '18 at 10:26
Obviously we need to deep dive into JavaDoc in order to find out, that this solution exists. I was looking for top level destination specification for about 2 hours. This is only SO answer targeting this issue. Hopefully many upvotes upcoming
– VizGhar
Nov 23 '18 at 9:54
Obviously we need to deep dive into JavaDoc in order to find out, that this solution exists. I was looking for top level destination specification for about 2 hours. This is only SO answer targeting this issue. Hopefully many upvotes upcoming
– VizGhar
Nov 23 '18 at 9:54
add a comment |
I made simple example for this issue.
https://github.com/isaul32/android-sunflower
Create set of top level destinations at first
val topLevelDestinations = setOf(R.id.garden_fragment,
R.id.plant_list_fragment)
appBarConfiguration = AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build()
and then override onSupportNavigateUp function like this
override fun onSupportNavigateUp(): Boolean {
return NavigationUI.navigateUp(navController, appBarConfiguration)
}
The last step to overrideonSupportNavigateUp()is only required if you use the defaultActionBar. If you add your ownToolBarthis behavior is already implemented when callingNavigationUI.setupWithNavController(Toolbar toolbar, NavController navController, AppBarConfiguration configuration).
– Elias DC
Dec 12 '18 at 12:42
add a comment |
I made simple example for this issue.
https://github.com/isaul32/android-sunflower
Create set of top level destinations at first
val topLevelDestinations = setOf(R.id.garden_fragment,
R.id.plant_list_fragment)
appBarConfiguration = AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build()
and then override onSupportNavigateUp function like this
override fun onSupportNavigateUp(): Boolean {
return NavigationUI.navigateUp(navController, appBarConfiguration)
}
The last step to overrideonSupportNavigateUp()is only required if you use the defaultActionBar. If you add your ownToolBarthis behavior is already implemented when callingNavigationUI.setupWithNavController(Toolbar toolbar, NavController navController, AppBarConfiguration configuration).
– Elias DC
Dec 12 '18 at 12:42
add a comment |
I made simple example for this issue.
https://github.com/isaul32/android-sunflower
Create set of top level destinations at first
val topLevelDestinations = setOf(R.id.garden_fragment,
R.id.plant_list_fragment)
appBarConfiguration = AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build()
and then override onSupportNavigateUp function like this
override fun onSupportNavigateUp(): Boolean {
return NavigationUI.navigateUp(navController, appBarConfiguration)
}
I made simple example for this issue.
https://github.com/isaul32/android-sunflower
Create set of top level destinations at first
val topLevelDestinations = setOf(R.id.garden_fragment,
R.id.plant_list_fragment)
appBarConfiguration = AppBarConfiguration.Builder(topLevelDestinations)
.setDrawerLayout(drawerLayout)
.build()
and then override onSupportNavigateUp function like this
override fun onSupportNavigateUp(): Boolean {
return NavigationUI.navigateUp(navController, appBarConfiguration)
}
answered Dec 9 '18 at 18:57
iSauliSaul
1
1
The last step to overrideonSupportNavigateUp()is only required if you use the defaultActionBar. If you add your ownToolBarthis behavior is already implemented when callingNavigationUI.setupWithNavController(Toolbar toolbar, NavController navController, AppBarConfiguration configuration).
– Elias DC
Dec 12 '18 at 12:42
add a comment |
The last step to overrideonSupportNavigateUp()is only required if you use the defaultActionBar. If you add your ownToolBarthis behavior is already implemented when callingNavigationUI.setupWithNavController(Toolbar toolbar, NavController navController, AppBarConfiguration configuration).
– Elias DC
Dec 12 '18 at 12:42
The last step to override
onSupportNavigateUp() is only required if you use the default ActionBar. If you add your own ToolBar this behavior is already implemented when calling NavigationUI.setupWithNavController(Toolbar toolbar, NavController navController, AppBarConfiguration configuration).– Elias DC
Dec 12 '18 at 12:42
The last step to override
onSupportNavigateUp() is only required if you use the default ActionBar. If you add your own ToolBar this behavior is already implemented when calling NavigationUI.setupWithNavController(Toolbar toolbar, NavController navController, AppBarConfiguration configuration).– Elias DC
Dec 12 '18 at 12:42
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53372539%2fnavigation-graph-with-multiple-top-level-destinations%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown