Basic structure

In order to draw our screens (note that I am not referring to activities or fragments yet; by screen I mean what the user can literally see on screen at any point during the execution of our app), we need to identify the key points of our idea. We need to establish the use cases, speaking in software development terms.

Let's start by giving shape to the app that we will build during the course of this book: MasteringAndroidApp. It's difficult to visualize all the details in your mind at first, so we will start by identifying the components that we know we need for sure and later fill in the gaps if there are any.

We know from the previous chapter that we have a presentation screen, which shows the logo of the app for a few seconds while downloading data from the Internet if needed.

In this app, we will also have a screen with a list of the information coming from the Internet, with individual items that the user can click on to get more detailed information.

As the main option, we will show a contact screen with MapView showing my location and contact data.

To finish, we need a Preferences or Settings screen, where we can turn on and off the notifications and deactivate ads or purchase extras.

Now, we are ready to create a mock-up. Have a look at the following image:

At the top, we have the entry point of our application, which is the splash screen. The navigation here is straightforward; we can navigate to the next screen in a straight line, and there are no buttons or any other possible flow.

On the next level, we have a screen with the list of items (which is a screen with contact information), a map view, and a settings screen. These three screens are at the same level in our app, so they have the same importance.

Finally, we have a third level of navigation, which is the detailed view of an item of the list.

The only way we can open this screen is by clicking on an element of the list; so, the entry point of this screen is the list screen.

Now that we have a basic structure and flow created, we will look through the different extensively used navigation patterns in order to decide which one would work best for our app.

The dashboard pattern

The dashboard pattern is one of the first patterns used in Android. It consists of a set of elements displayed on the main screen as a matrix of icons. In the following image, we can see one of the first versions of the Facebook app on the left-hand side, and to the right, a customization of the pattern from Motor Trend:

This view is great for apps that aim to display a very limited number of options clearly; there are no more than two elements per row with a number of rows that fits on the screen.

These icons clearly display symbols of the main functionality with all the options at the same level. It's an ideal pattern for apps that have a large target audience; it's straightforward and self explanatory, so anyone can navigate it.

Even though this design seems old, given that it was extensively used in the first versions of Android and is used less nowadays, its usage depends on your needs, so don't let this put you off. The Motor Trends app shown in the preceding image had a very original implementation of this pattern.

If the elements don't fit on the screen and we need to scroll in order to discover them, we need to reconsider the pattern. The same thing applies when we have too few elements; there are better options for these cases. In our particular example, we have three main elements, so we will not use this pattern.

The sliding panel

This pattern is well known thanks to apps such as Gmail and Facebook. It presents a layout at the top level of the UI; screens come out from the left or right when we perform a swipe gesture or click on the top left or right button, which usually is an icon displayed with three horizontal lines—also know as the Hamburger icon.

This pattern is perfect if we have a large number of options at the same level in our app, and it can be combined with other patterns, such as the tabs pattern.

The implementation of this panel can be done with the DrawerLayout class, which is composed of two child views: a FrameLayout with the content and the navigation drawer, which can be ListView or any other custom layout containing the options.

For this, execute the following code:

<android.support.v4.widget.DrawerLayout xmlns:android="http://schemas.android.com/apk/res/android"   
   android:id="@+id/drawer_layout"   
   android:layout_width="match_parent"   
   android:layout_height="match_parent" >   

   <FrameLayout   
    android:id="@+id/frame_container"   
    android:layout_width="match_parent"   
    android:layout_height="match_parent" />   

   <ListView   
    android:id="@+id/drawer_list"   
    android:layout_width="240dp" 
    android:background="#fff"  
    android:layout_height="match_parent"   
    android:layout_gravity="start" />   

  </android.support.v4.widget.DrawerLayout>

Once we select an element in this side panel, a child appears in the middle of the screen; this child can help you navigate to a subchild but never to an element of the main menu. The child and sub child navigation can be managed with the back button or the up navigation in the action bar.

We can close the panel by clicking on an item and know whether the panel is closed or open by setting a drawer listener, ActionBarDrawerToggle, which contains the onDrawerClosed(View drawerView) and onDrawerOpened(View drawerView) methods.

Ensure that you use ActionBarDrawerToggle from android.support.v7.app; the one included in v4 is deprecated.

Another big advantage of this pattern is that it allows group navigation via a main item on the menu that can be expanded into subitems. As you can see in the following example, Item 4 has three options inside it in a drop-down menu:

An example of a drawer layout

This would not be suitable for our app as we don't have enough options to make the most of this pattern. Also, as this pattern can be combined with the tabs pattern, it makes more sense from an educational perspective to develop our example with this pattern.

Tabs

The tabs pattern is a pattern that you have probably seen and used before.

It shows a fixed menu with components at the same level. Note that when we have tabs, the menu is always visible, which doesn't happen in the sliding and dashboard patterns. This looks very similar to a web interface and is very user friendly considering that the user probably already knows this pattern.

The following pattern has two variants: fixed and sliding tabs. If we only have a small number of menu items that can fit on the screen, the first variant will be the most suitable as it shows the users all the items at once.

Sliding tabs are usually used when all the items don't fit on the screen or when they do fit but we know that more items will be added and won't fit in the future.

The implementation of the two variants is slightly different, so we need to consider future changes when deciding the variant. Here, we can see an implementation of a sliding variant:

Here are some features and formatting specifications from the material design guidelines for you to follow:

In the following image, we can see an example of scrolling/sliding tabs with a submenu:

Now that we know the basics of app navigation, we can explore the components that we need to implement these patterns. The main components, as you know, are activities and fragments. We are going to implement an example of sliding tabs with three fragments.