The following is the first few sections of a chapter from Exploring Android, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Our app works, albeit with obvious gaps. For example, all of our to-do items go away when the process terminates, as we are not saving them in a database or elsewhere. The problem is that any form of I/O — disk I/O for a database, network I/O for a server — takes time. Dealing with those slow operations gets tricky, and our current approach of just slapping up some code will start to become a problem.
So, over the next set of tutorials, we will revise the app to adopt a more formal GUI architecture. Along the way, we will add support for storing the to-do items in a database, so that they outlive our process.
The first step is to define a “view state”. This is an object that collects all
of the data needed to render our UI, for some closely-coupled portion of that
UI. In our case, we will define a view state that will be used by all three
of our fragments, as they are all part of
MainActivity and all work with the
same data. However, our view state will not affect
as showing “about” information is not related to showing to-do items.
This is a continuation of the work we did in the previous tutorial. The book’s GitHub repository contains the results of the previous tutorial as well as the results of completing the work in this tutorial.
The particular GUI architecture pattern that we will be adopting is called Model-View-Intent (MVI). Android’s Architecture Components has a few chapters on MVI. Two in particular to note:
Beyond that, you may wish to consider watching the following presentations:
In particular, Jake Wharton’s presentation influenced much of what we will be doing here with respect to MVI.
The preview of this section took that left turn at Albuquerque.
The preview of this section was stepped on by Godzilla.
The preview of this section was the victim of a MITM ('Martian in the middle') attack.