So we just recapped different layout managers and
looked at how you'd use various layouts together to create some example screens.
As you probably noticed we started using these circles and buttons and toolbars.
Let's start diving a little deeper into what some of those elements were and
why they keep appearing all over the place.
Now each application is an individual snowflake
with different content and goals.
Just because they're unique though, it doesn't mean that we should force users
to learn new conventions to operate them.
By following some established patterns of the platform, you
can accelerate your users understanding of the app, making it feel intuitive.
Imagine if every model of car had a different layout of the pedals,
the steering wheel and the levers.
While you might be able to learn one model you'd have
a hard time moving to another.
Your UI is exactly the same.
By following some conventions users can quickly get in and drive your app.
Here is some of the most prevalent patterns used on Android
to organize your interface and navigate around it.
A Toolbar is a horizontal bar,
which provides a standard way to present titles and actions in your lab.
It's made up of a navigation area on the left, a title area,
and the menu of actions.
It's a very flexible widget, and each of these function is optional.
A nice feature is that the toolbar can show actions either directly within
the tool bar, or they can be collapsed under a sub menu known as an overflow
if there isn't enough room.
And it will base it's decision on whether there's enough room
to show everything.
Tapping the overflow item itself yields this overflow menu of additional actions
you can take.
The toolbar itself is a view group, so you can add children to it.
For example, I could add a Spinner Control
as a child view to provide some kind of navigational control.
Now, toolbars are used extensively in Android.
So they're very recognizable to your users, and a common place to look for
actions or present them.
They generally use a standard height which varies by screen size,
and can be queried using the actionBarSize Free match P.
They're also a great place to embed your brand's color.
Next, the App bar.
The app bar is just a special case of a toolbar,
where it's placed at the very top of the screen.
As such, the title field often provides a screen title.
And the navigation icon provides access to screen level navigation options.
The app bar often uses an extended height to provide more space for
branding or to contain a header image.
In this case it's using multiples of the standard height.
Next up Tabs.
Tabs let you organize and
navigate to different sections within your screen or app.
On Android, tabs always appear at the top of the screen.
And you can switch between them using a horizontal swipe gesture.
Generally, they sit on the same surface as your app bar, if you're using one.
Now, tabs can be a great way to provide the main way of navigating
about your app.
Or providing sub-navigation if you're using a different top-level
navigation construct.
Such as a Navigation Drawer.
Now a Navigation Drawer is a panel that slides in from the left of
the screen and it contains the top level navigation options
to different parts of your application.
The drawer itself can be divided into sections and
frequently provides access to account information here in this top area.
Now, the drawer is closely associated with the so-called hamburger icon.
This three-line icon in your toolbar.
Either pressing this or
dragging from the left edge of your device will open the drawer.
The drawer can work well if you have a number of different sections
that you want to provide quick navigation to
without taking up persistent space on every screen.
However, if you don't need this, say if you only have a few sections to navigate
between, then a different pattern, like tabs
might be more relevant as they're going to be more obvious to your users.
It's also important to use restraint and
thoughtfully select items to put in the navigation drawer.
It shouldn't become a dumping ground for all the things.
Android also has pretty common patterns around Scrolling and Paging.
Users are typically comfortable with scrolling vertically to see
more information on the screen.
Horizontal scrolling is less common, especially with text content,
as it can be frustrating to read.
More common is to use a horizontal gesture to page through content.
So, each gesture takes you to one screen page, back or forward.
So for example, if you're reading emails or
news stories, then it's a very useful pattern.
Horizontal Paging is especially common for a details view launched from a list,
where you have a mental model of what the next page of items might be.
Note, that as we just covered in the tab section,
horizontal swipes should change pages between tabs.
So the effort is kind of incompatible to use both tabs and
horizontally paid content.
Another extremely common pattern on Android is List to Details,
where you would show a list of individual items and
clicking on one would take you to a subsequent detail screen.
You've probably used this 100 times.
Such as viewing your contacts or reading news stories for example.
A variation on this pattern is to show both the list and
detail sections on the same screen on larger devices.
So here these two screen would be separate on a small device and
brought together on a larger device.
Showing just a list on a large screen can look awkward and
leave a lot of empty space.
Additionally, showing both items at once can allow you to obtain more context
about the activity you're performing and prevents what we call Pogosticking.
Where the user is forced to go into details and back up, and
into a details and back up.
We'll go into much more detail on other patents for
larger screens in lesson five.
Now it's absolutely okay to deviate from these patents if and
when it makes sense for your specific use case.
These are patents after all, not strict rules.
But make sure you're doing so for
good reasons, as you'll be asking your users to learn a bespoke interaction.
The phrase I like to use here is deviate with purpose.
Picking an application's structure and
navigation scheme depends on the content in your application.
A good exercise is to sketch out an Entity Relationship Diagram.
This shows the objects in your application and
how they relate to each other.
Once you understand this, you can pick an application structure to match.