Now I am wondering which is the most proper way of implementation when want to combine BottomNavigation with the new Android Architecture Navigation Component?
For now found two approaches:
Single Navigation Graph which maintains all BottomNavigation items and which is shown here from Google Codelabs: https://codelabs.developers.google.com/codelabs/android-navigation/#1
Multiple Navigation Graphs where every BottomNavigation item has its own navigation graph which maintains only its behavior and backstack which i shown here: https://proandroiddev.com/mastering-the-bottom-navigation-with-the-new-navigation-architecture-component-cd6a71b266ae
My opinion is that the second one is more clear and understandable, but maybe you have another opinion.
Having separate backstacks or not is a decision based on user experience but if you do want multiple backstacks for bottomnavigation then follow the link for correct approach by androidx developers.
https://github.com/googlesamples/android-architecture-components/tree/master/NavigationAdvancedSample
I think it depends with the number of nested fragments you will have per each navigation item. The fewer the fragments then i would use the first approach and the more the fragments then i would use the latter approach
Related
The new android navigation component is what seems to be recommended. Im follow the official tutorial on graph nesting.
To group destinations into a nested graph, do the following:
In the Navigation Editor, press and hold the Shift key, and click on
the destinations you want to include in the nested graph. Right-click
to open the context menu, and select Move to Nested Graph > New Graph.
The destinations are enclosed in a nested graph. Figure 2 shows a
nested graph in the Navigation Editor:
Everything works well so far, I just have one issue.
The nested graphs are all part of one big xml file, this is an issue because it can lead to merge conflicts when using source control.
So my question is can we have this same functionality if we simply create two navigation graphs and include the new graph as a destination?
Will everything work as expected or would there be unintended consequences to doing this.
For example poping back to the root of navigation controller? I'm not very familiar with Android but my fear is that a new navigation controller is created and I cannot easily navigate when having two navigation graphs.
Nothing in the tutorial seems to mention this.
As per the Reference other navigation graphs with <include>:
While this is functionally the same as using a nested graph, include lets you use graphs from other project modules or from library projects
An <include> is expanded at runtime to function identically to a nested graph - there is no difference in what you can do regarding popping up to other destinations, etc.
However note that Safe Args does not work across separate navigation graph files (as you could include that graph in multiple other graphs, so there's no guarantee that anything outside of that file actually 'safely' exists), so you would need to confirm that any use of Safe Args is within a single file (using other mechanisms, such as manually navigating or navigating by deep link to navigate to graphs you know exist, but cannot be verified at compile time).
In the new android studio version there is a new big change. I read the documentation about "Implement navigation with the Navigation components" but can somebody explain to me which is the main difference between this method and the classic one?
The navigation architecture component is part of JetPack is a new way to navigate your app.
The main different is that before you have multiple activities in your application -still you can- to move to different content areas in your app, now with the nav arch component you can have only one activity and the rest of the features of your app is based on fragments, keeping the single activity as a the main container.
In this link Ian Lake the creator of navigation architecture explains why we should use this approach.
Also, here is the guide to Navigation Architecture
https://developer.android.com/topic/libraries/architecture/navigation/
Give a look at these resources.
Best regards.
Pedro Varela
I need to implement an app through fragments.
Based on my requirements,i have a menu panel one side and other side i need to display different ui screens based on menu selection.
My Screen contains heavy ui.That why i design each screen separately.
How should i display screens based on menu selections through fragments.
If any one know the solution,Please help me
Thanks in advance.
If you mean the NavigationDrawer you find the official Tutorial on the Android Developers Website
There is also an example to download, which uses the NavigationDrawer to switch Fragments.
If you want a fixed, self-designed Menu and just want to swap out Fragments (holded by a FrameLayout) check out this Tutorial
Android officially doesn't provide more than one sliding menus (navigation drawers). You can implement SlideMenu or choose one of many such libraries for more than one sliding menus.
Once the menus are implemented, it's just a simple case of fragments and activities. There is no "direct way". Read the documentation and understand how they work. Here are some good links
Fragments - Introduction on developer site
Tutorial on multi-pane development using fragments by Mr. Vogel
Basically what you have to do is, create an Activity extending ActionBarActivity (from support library) or FragmentActivity.
create fragments and replace them in FragmentManager from your main activity.
See this for reference:
Creating a navigation drawer
If you are using an Actionbar with Tabs for navigation, should we be using fragments only?
When I'm looking at the developer site, I only see examples where they are switching Fragments, not Activities. The guidelines tell us to use a ViewPager when using tabs, so you should use Fragments to make that work.
The problem is that these fragments will contain quite a lot. They should have other fragments as well. Nested fragments. These are supported when using the Support Library (or targetting api level 17).
My main concern is how the communication will run between the fragments at the bottom of the hierarchy. Will it all run through that one Activity?
You won't have problems. Just treat your fragments as something independent that will be placed in a container. That fragment can have more fragments and so on.
Some people are developing fragment based applications with a single Activity and sometimes makes sense, however I don't like that approach much.
That said, just use all the fragments you need. If you have complex data to pass between fragments you could use the activity to host it and access it in your fragments.
I really don't know what is the difference between these two approaches of creating navigation menu. So I read that both can be used as a container for two fragments (main fragment, detail fragment). So can you help me to understand which approach is better and why? I can't find out relevant information.
thank you.
The session was "Android Design for UI Developers" by Roman Nurik and Nick Butcher:
https://developers.google.com/events/io/sessions/326204977
Pretty much what CommonsWare said, essentially, Navigation Drawer is for chrome and top level navigation, so it overlays app content. SlidingPaneLayout is for content navigation, thus it doesn't overlay content.
EDIT:
The video is still available here - https://www.youtube.com/watch?v=Jl3-lzlzOJI
So can you help me to understand which approach is better and why? I can't find out relevant information.
This was covered in a Google I|O 2013 presentation, though I forget which one.
SlidingPaneLayout is for content, such as the master-detail pattern. You might use it in place of two layouts for master-detail structures for smaller and larger screens.
DrawerLayout is for navigation. You might use it in place of the dashboard pattern, or using action bar items for navigation, if you have a fair bit of navigation in your app.