Chapter 7. Creating Overview Screens

Overview screens, or dashboard screens, are layouts that allow the user to get a quick look at their data within an application. As such, they are also screens that the user will return to again and again. Most often, they are positioned as the first screen the user will normally see when they open the application, like the Inbox in an email application, or the list of files in your Google Drive. In apps, navigation is usually goal-oriented; the user starts with an overview, and then navigates to perform a specific action. Once they are finished with their action (for example, writing and sending an email), they are redirected to the overview screen.

Overview screens can be complex systems to build as they should be reactive, and they will often depend on large amounts of application data. As it's the screen your users will see the most often in your app, an overview screen needs special attention in the design process. It's important to present the user...

Designing an Overview screen

Overview screens and dashboard screens are not only the first thing your users will typically see, but they're also the most common point of contact with your user. They need to be functional, beautiful, and also very fast. An application that takes too long to load its first screen will only frustrate its users. If your application is frustrating to users, they will avoid using it. As such, it's very important to consider what information your user will need, and what are the most important actions they will take from the overview screen.

The Material Design guidelines have excellent recommendations to help you decide on these aspects of your application, which in turn will help you produce better applications. Remember that while it's fun (and important) to get creative with your designs, it's also very important to stick to the rules. Common patterns in design help your users understand what you're asking them to do, and how to use your application. This understanding...

Elements of an Overview screen

Overview screens have certain common elements that let the user know what it is they're looking at, and how they're expected to use the screen. It's helpful to know how people look at a screen when they see it for the first time. Studies by groups such as Neilson show that most western people follow a sort of F shaped pattern when looking at the screen for the first time. Starting in the top-left corner, their eyes track right and downwards, as shown in this diagram:

This means that when designing an overview screen, the most important information should be at the top of the screen, with the second most important information to its right, and as you work down the screen, the information becomes less important. The preceding diagram uses a graph at the top of its screen; this is also an important element: favor using graphics and indicators over raw numbers where it's applicable. A user can get a much quicker overview from a graph than they can from a table of...

Creating layouts for ViewHolders

A RecyclerView does just what its name suggests--it recycles or reuses its children to present different data to the user. This means that while it appears to have a long list of child-widgets (such as cards or images), it actually has the ones that the user can actually see. When a widget is scrolled off the screen, the RecyclerView changes its data, and then scrolls it back into view. The RecyclerView doesn't directly bind the data to the child views; however, it instead goes through a ViewHolder. The job of the ViewHolder is to help speed up the data binding process. Think of the travel claim app again; if we want to display each claim item in a RecyclerView, each one will look something like the following:

Each of the preceding items will require a different Android widget, and every time you want to populate them, they need to be looked up and bound to their new data. A ViewHolder implementation is a convenient place to look up, hold, and bind data for...

Creating a ViewHolder with data binding

As you can see from building a traditional ViewHolder implementation, there is quite a lot of work and boilerplate code required just to put the data from a single item onto the screen in a layout. Further, it's actually quite expensive in its own right, because every one of the ViewHolder instances creates and holds an instance of the DateFormatter where they can easily be shared between all the ClaimItemViewHolder instances for a RecyclerView.

In cases like this, data binding can make a huge difference. Using a few tricks, you can actually create a completely generic ViewHolder implementation that will work for any data object in your application (assuming that you can bind it to a layout file). First, you'll need to create a nice generic ItemPresenter, and then modify the layout, and then you're ready to create a generic data-binding ViewHolder implementation. Follow these instructions, and you'll only ever need one ViewHolder implementation:

1. Right...

Creating a RecyclerView adapter

In order to get data into a RecyclerView, you need an Adapter class, not unlike the PagerAdapter you wrote to display the attachment previews for the CaptureClaimActivity. However, RecyclerView does a lot more of the heavy lifting than ViewPager and as a result, what you can and can't do inside the adapter is far more restricted than with PagerAdapter. Also, unlike a PagerAdapter, a RecylcerView adapter has two actions that are involved in displaying each element: create and bind. When the RecyclerView needs a new child widget for an element, it will invoke onCreateViewHolder, which should return an unpopulated ViewHolder, which will then be passed to onBindViewHolder where the data should be mapped into the View from whatever data source the adapter uses.

First off, the RecyclerView maintains the list of its child views completely, so the adapter must never add or remove them directly. Secondly, the RecyclerView expects the adapter to be stable, that is, the...

Creating the Overview activity

The travel claim example app needs a nice overview activity to tie together the allowance overview, a list of the claim items, and a way for the user to create new claim items. As we have a Room database, things can become significantly more decoupled, and that's a really good thing. Having a central reactive source of data allows different parts of your application to always reflect the actual state of the application as it changes, without having to coordinate with each other.

The first part of building the OverviewActivity is creating the Activity class itself and populating it with the claim items that the user has entered. Follow these steps to create a skeleton OverviewActivity and register it as the main Activity for the application:

1. Start by right-clicking on your main package (that is, com.packtpub.claim) and selecting New |Activity |Empty Activity from the menu.

2. Name the new class OverviewActivity.
3. Leave all the other fields as their defaults and select...

Test your knowledge

1. An instance of RecyclerView will create one View instance for which of these?
   • Every item of data
   • Every item of data visible on the screen
   • Each type of data element that is also visible on the screen
2. When attaching an observer to LiveData you need to do which of the following?
   • Detach it when its LifecycleOwner is destroyed
   • Attach it on the main thread
   • Provide a valid LifecycleOwner
3. Overview / Dashboard screens should have which of these features?
   • They should only use graphs to display statistics
   • They should not scroll if it can be avoided
   • They should display an overview with the most important information first
4. The ViewHolder class is used by the RecyclerView to do what?
   • Improve the data binding performance
   • Reference the views that will be garbage collected
   • Store the View objects in a Bundle
5. When using LiveData objects to reference data used by multiple Fragment objects, which of these is true?
   • The Fragment instances must share the same LiveData reference to see changes
   • The LiveData...

Summary

Overview screens are the first thing a user will see and interact with in your application, and will be the area of the application they will spend most of their time in. It's important to keep the screen focused and opinionated on what data is displayed to the user, and how it's displayed. Always consider how long the user has to look at your screen, and what information they will need easy access to. Make use of the RecyclerView and LiveData classes to provide the user with detailed views arranged with the most important information first, and allow them to quickly scroll through their most important recent events.

It's also important to consider the navigation of your application, the various ways the user will leave your overview screen, and how they will get back to it. As far as possible, keep the Overview class responsible for just arranging the data on the screen. Any logic that takes the user away from the screen, for whatever reason, should be encapsulated in Fragment classes...