UX Policies — Part 2

The UX Patterns

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!

Repository: https://gitlab.com/migueltt/simpleandroid

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:

1. Drawer and BottomSheetDialog contain a NavigationView
2. NavigationView items are defined as Menu<item..> within an XML resource. The android:id must 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-controller to navigate to such destination
3. BottomNavigationView and NavigationView may contain their own Menu XML resources, depending on how you want to organize your destinations
4. Toolbars (either top or bottom) and Drawer can be synchronized to work together — for top-level android:id the Toolbar displays the 3-bar icon, while for non-top-level, a back-arrow icon
5. 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 destination to go over a “screen”

UI Components Relationships

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 destinations into the Navigation-Graph
• Add new entries into the Menu resources

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.

Toolbar and Drawer

• 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 BottomNavigationView should only contain top destinations, and other secondary screens should appear using different mechanisms, like Menus.

Bottom-Navigation-View

• 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 Drawer can display additional destinations. In some cases, you may want to display all destinations within the Drawer.

Toolbar, Drawer, and Bottom-Navigation-View

• 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 one hand, specially 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 BottomAppBar is that the FloatingActionButton nicely fits in a craddle which can also be modified at runtime to be at the right, and the transition to be scale or slide.

Bottom-App-Bar and Drawer

• Bottom-App-Bar + Bottom-Sheet-Dialog: Just like the previous one, but instead of a Drawer, a BottomSheetDialogFragment is used. The animation below displays a header within the Bottom-Sheet, which probably you shouldn’t include into your app.

Bottom-App-Bar and Bottom-Sheet

• 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 FloatingActionButton craddle has been pushed (offset) some DIPs to avoid cutting off some items. Use this pattern only if you really need that FloatingActionButton craddle.

Now, the twist. All the animations are actually within the same app. And no, the app does not have multiple Activities or Fragments, just one Activity.

Simple::Android project defines these all these six patterns using multiple XML layouts that can be changed at runtime — check ActivityMain in variant debug.

UX Style Switcher

• 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
• From FragmentSettings, users can change the UX style
• FragmentTestArchitecture also 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, theFragment and 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.

Check UX Policies — Part 3: The implementation to find out how you can achieve the same simplicity, without compromising your project deadlines.