Hi there - I’m looking into the Navigation part of Android Architecture Components and noticed there is nothing regarding support for the master-detail tablet layout. I was wondering if this is something you’re considering addressing in your libraries!?
there is nothing regarding support for the master-detail tablet layout
Google has been steadily backing away from that pattern for some time. Unfortunately, IMHO, they have not promoted some alternative that is widely applicable.
I was wondering if this is something you’re considering addressing in your libraries!?
I am going to maintain some of my current libraries, and it is possible that I will expand the roster in security-related areas. Otherwise, though, I am not doing much with libraries today, so I have no plans with regards to this topic. Sorry!
No worries, and thank you anyway Mark. I’m surprised to hear Google is steadily backup away from master-detail pattern. Especially with the Android support for Chromebooks and other large screen devices. Seems like the master-detail pattern is very useful for that.
Google seems to be focused on things like staggered grids, where you can seamlessly change the UI to adapt to different screen sizes (e.g., show more columns). This has the advantage of being able to handle several incremental UI changes (e.g., as the user resizes a freeform window on Chrome OS), whereas master-detail is a bit of a “smash cut” once you get to a size where you want to show both master and detail simultaneously.
However, staggered grids IMHO are only good for collections of model objects that have a strong visual component. I don’t know what a staggered grid of invoices would look like, for example. Master-detail had the advantage of being applicable to a wide range of model objects, and I am not aware of a Google-recommended UI pattern that handles all the cases that master-detail did.
Good point regarding incremental screen sizes vs. master-detail at the crossover size for tablet mode. However, I can imagine an app running on Chrome OS might have a user setting for mobile vs. tablet mode, where tablet mode might set a minimum window size. Master-detail exists on many modern apps today - email clients spring to mind immediately. My own example is a dictionary app which fits master-detail perfectly and is the sort of app that would be commonly used on a large screen.
I can imagine an app running on Chrome OS might have a user setting for mobile vs. tablet mode, where tablet mode might set a minimum window size
Ooooo… I like that plan. It could work something like this:
- Have a
Theme.Translucent.NoTitleBaractivity as the launcher
- In there, look up the user’s preference, with an algorithm to take an educated guess based on the environment if the user has not yet specified a preference
- Based on the preference (or algorithm result), start the activity that implements the major navigation style (master-detail vs. “normal”) and
finish()to get rid of the invisible activity
- For the master-detail activity, use
<layout>to specify the minimum supported size
There was a little bit about this from Ian Lake in today’s Ask us Anything
Navigation and tablets is actually something I’ve talked to the Material and Chrome OS team quite a bit about. One factor that has considerably influenced the design space for large screen devices has been the introduction of multi-window modes, particularly free-form windows that are fully resizable as you can find on Chrome OS devices.
This puts a significantly higher emphasis on every screen of your app being responsive, rather than changing your navigation structure based on the screen size (which can be extremely disorienting when resizing your app). The tactics I covered back in 2015 are just as relevant today when it comes to adapting each screen to more (or less) space.
One thing I’d probably add now is that you can and should consider making the navigation chrome of your app (bottom nav, navigation drawer, etc) adaptive to the screen size - if you download the code for the Navigation codelab, you’ll note that the app swaps from a navigation drawer when on multi-window on phones (where space is at a premium) to a bottom navigation bar on phones to an always visible side nav on tablets.
That being said, we’re well aware that there’s more to be done.