Tracking Our Load Status

There are three logical states that our RosterListFragment and its RecyclerView can be in:

• We have to-do items, and we are displaying them
• We do not have to-do items, because the user has not entered any, and so we should show the “empty” view to help guide the user
• We do not know whether we have to-do items or not, because we have not yet loaded them from the database

That third state is not being handled by the app. Instead, we treat “do not know” as being the same as “we do not have to-do items” — we show the “empty” view if our RosterListAdapter is empty, no matter why it is empty. Plus, it would be nice to show some sort of “loading” indicator while the data load is in progress… such as a ProgressBar.

So, in this tutorial, we will fix this. For most Android devices, and for shorter to-do lists, the difference will not be visible, as the data will load very rapidly. However, on slower devices, or with large to-do lists, the difference may be noticeable.

This is a continuation of the work we did in the previous tutorial. The book’s GitLab repository contains the results of the previous tutorial as well as the results of completing the work in this tutorial.

Step #1: Adjusting Our Layout

We need to make a couple of changes to the layout used by RosterListFragment.

Open res/layout/todo_roster.xml in the IDE. In the design view, click on the empty TextView in the “Component Tree”. In the list of all attributes, find the visibility attribute, and set it to gone:

Next, choose the “Widgets” category in the “Palette” view. You will see two labeled “ProgressBar”, one with a circle and one that is an actual bar:

Typically, the circular ProgressBar is used for indefinite progress, where we do not know how long the work will take. The horizontal ProgressBar is more often used for cases where we can let the user know how far we have progressed.

In this case, the work is fairly atomic: either our data is loaded or it is not. We have no intermediate steps with which to provide progress updates, so we should use the circular indefinite ProgressBar.

However, we cannot drag and drop a widget into the preview area, since the preview is mostly our RecyclerView. The IDE will attempt to make our widget be a child of the RecylerView, and that does not work very well. Instead, drag the circular ProgressBar from the “Palette” and drop it on the ConstraintLayout entry in the “Component Tree” view. This will add it as a child to the ConstraintLayout, which is what we want.

Then, use the grab handles on the ProgressBar to set up constraints to all four edges of the ConstraintLayout. However, there is a decent chance that you will sometimes get a constraint that ties the ProgressBar to the items RecyclerView, instead of to the parent ConstraintLayout:

  <ProgressBar
    android:id="@+id/progressBar"
    style="?android:attr/progressBarStyle"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:layout_constraintBottom_toBottomOf="@+id/items"
    app:layout_constraintEnd_toEndOf="parent"
    app:layout_constraintStart_toStartOf="parent"
    app:layout_constraintTop_toTopOf="parent" />

Here, app:layout_constraintBottom_toBottomOf wound up being set to @+id/items instead of parent. The simplest thing to do is to change the XML manually, so that all four constraints are set to parent.

Also, change the widget’s ID to loading.