Examining the Other Fragments

While most of the code that we have reviewed so far was common for all three fragments, it is worth mentioning the other two fragments, as they have some different wrinkles.

DisplayFragment

DisplayFragment does not publish any actions itself. It is simply a passive consumer of view states.

However, its view state logic is a bit more complicated than is the RosterListFragment. While the user may think that the DisplayFragment is only displaying one to-do item, in reality it uses a RecyclerView to display the same roster that RosterListFragment does. While RosterListFragment displays the roster in a vertically-scrolling list, DisplayFragment displays the roster via horizontal swipes, akin to the behavior of a ViewPager. The DisplayFragment needs to know what particular to-do item to be displaying. That can be determined by:

• the RosterListFragment and MainActivity, if the user taps on an item in the list
• the user, via swipe gestures

As a result, DisplayFragment has two view-models. AbstractRosterFragment handles most of the logic for working with the RosterViewModel, as it does for RosterListFragment. DisplayFragment has its own DisplayViewModel that keeps track of the currently-viewed page in the “pager”, so we can restore this after a configuration change.

EditFragment

EditFragment publishes three actions:

• If the user saves the form, and this is a new to-do item, it publishes an “add” action
• If the user saves the form, and this is an existing to-do item, it publishes an “edit” action
• If the user taps on the “Delete” toolbar button and confirms this request, it publishes a “delete” action

Unlike DisplayFragment, EditFragment only ever works on a single to-do item. The ID of the ToDoModel which it is editing arrives via the newInstance() factory method and is saved in the arguments Bundle, so we do not need a separate view-model for it.