UX Policies — Part 2
This is an article part of a series. For objectives, fundamentals, project structure, and articles summary, see Android::Simplified
Make sure to read article UX Policies Part 1: The Problem first!
Based on Part 1, your app should have a standardized structured according to your requirements, defining main UI components for navigation and interaction that applies to all screeens, with some exceptions.
At this point, you probably are already quite familiar with these patterns and components, but keep reading! At the end, I’ll show you what the strategy will look like in order to provide structure to the whole project. Plus, there’s a twist at the end.
First, there are 5 important things to consider:
NavigationViewitems are defined as Menu
<item..>within an XML resource. The
android:idmust be the same as the one used within a navigation-graph — in this way, when an item is selected, it will automatically signal the
nav-controllerto navigate to such destination
NavigationViewmay contain their own
MenuXML resources, depending on how you want to organize your
Toolbars(either top or bottom) and
Drawercan be synchronized to work together — for top-level
Toolbardisplays the 3-bar icon, while for non-top-level, a back-arrow icon
- The Navigation-Graph must be considered the source-of-truth for all your navigation requirements — this means, no more Fragment Transactions or custom solutions to create Fragments — the app must always use a
destinationto go over a “screen”
This structure will allow you to add new modules without any effort since all the components will be in sync without having to add custom code — thus, this should be your long term strategy when adding new features:
- Define a new module (Fragments, View-Models, etc) grouping related classes within a package — focus only on the features for the module
- Add your
destinationsinto the Navigation-Graph
- Add new entries into the
Second, define the UX pattern you want to use for the app using out of the box components to simplify development — later you can improve as you get familiar with the architecture.
The following are six common UX patterns (as of April 2021) you can implement right now using standard Android Material Components:
- Toolbar+Drawer: the traditional approach. Just a top-toolbar with a left
Drawerthat contains the navigation items. Nothing wrong here, only thing is that this pattern looks and feels old. On large screens your app is difficult to use — users have to “reach" the top-left corner to activate the
Drawer, or switch hands to swipe the left edge — which collides with system-wide gesture navigation.
- Bottom-Navigation-View: a new approach, but only useful when you have up to 5 destinations. To accommodate other destinations, you will have to introduce a top-toolbar. Use this approach only if you are 100% sure you can fit all your destinations at the the bottom — people may argue that
BottomNavigationViewshould only contain top
destinations, and other secondary screens should appear using different mechanisms, like Menus.
- Toolbar+Drawer+Bottom-Navigation-View: A mix from the previous two patterns. This kind of addressed the issues when using only a
BottomNavigationView, since the
Drawercan display additional
destinations. In some cases, you may want to display all destinations within the
- Bottom-App-Bar+Drawer: Pattern that is becoming the norm over the last years. Makes easier to interact with your app since everything is accessible with on hand, even on large displays. A
Draweris usually included, and by default it appears on the left-hand side, which makes a little difficult to activate for right-handed users. You can solve this by using
android:layoutDirection, but beware since you will have to explicitly set such attributes on child components, which can be messed up if the user is within a right-to-left locale. The nice thing when using a
BottomAppBaris that the
FloatingActionButtonnicely fits in a craddle which can also be modified at runtime to be at the right, and the transition to be
- Bottom-App-Bar + Bottom-Sheet-Dialog: Just like the previous one, but instead of a
BottomSheetDialogFragmentis used. The animation below displays a header within the Bottom-Sheet, which probably you shouldn’t include into your app.
- Toolbar +Drawer + Bottom-App-Bar + Bottom-Navigation-View: This is kind of a non-standard pattern, since it’s mixing up all the previous patterns (except for Bottom-Sheet). The main intention here is to provide the user with quick access to certain modules. I would advise against this pattern if you have 3 or 5 main
destinationssince one of them will be cutoff by the
FloatingActionButtonat the center — see animation below. In this case, the
FloatingActionButtoncraddle has been pushed (offset) some DIPs to avoid cutting off some items. Use this pattern only if you really need that
Now, the twist. All the animations are actually for the same app. And no, the app does not have multiple
Fragments, just one
- Each UX pattern has been defined using an independent XML layout
- Each XML layout uses ViewBinding, allowing us to define extension-functions for each one — see Decoupling Binding
FragmentSettings, users can change the UX style
FragmentTestArchitecturealso allows to change the style, aside from other functionality we will describe on the next part
- The animation shows how the overall structure changes while maintaining both, the
Fragmentand the navigation state
Of course, your app doesn’t need all this complexity — you just need to choose one UX style. This UX switch at runtime has been added only as a proof-of-concept to show how easy it is to implement a simple yet effective Android Architecture.
I will describe how you can achieve the same simplicity, without compromising your deadlines on the next part. Stay tuned!
Coming later this week ~ April 9th?