An Attempt to make reading Chapter 8 simpler


#1

First, let me say that I really like this book. The book is very well-written and I sat down and read straight through chapters 1 - 7 and wrote all the code.

Of course, chapter 8 covers a lot of topics all at once and I understand that, because you have to get it all working to get it working at all. That’s fine.
My Experience With Chapter 8
I read the chapter and then spent long hours converting the first version of the app into the one which shows the initial list of items. I finally got it but I still wanted more understanding of how all those classes worked together. I analyzed it closely and I believe the following overview and details will really help other readers see what is actually happening.

The Class Diagram
I am going to add a diagram, however, the diagram itself only provides an overview. The diagram can add to understanding, but it cannot explain everything. For that, I will also provide the details of what happens when the app starts. Together I believe you’ll see that you can better understand what is going on.
The other thing that the diagram makes evident is that there is a lot going on. There are a lot of classes involved and even some somewhat circular references in there which is why the code feels so terribly difficult.

Diagram Overview
First, just take a look at the class diagram, as an overview. Don’t try to understand everything about what is going on, instead just recognize that there are a fairly large number of classes.
After you examine it I’ll point out a few things in an attempt to clarify.

Reading the Diagram
First of all, notice that the arrow heads that are open indicate where one class uses another class. The one closed-head arrow does actually indicate inheritance. You can see that my CrimeListActivity is a SimpleFragmentActivity.

Also notice that the class listed in upper right corner of each box is the type of each class (if there is a superclass). For instance, the CrimeAdapter class is a RecyclerView.Adapter. Also, notice that the +(plus sign) indicates public methods. - (minus sign) indicates private methods/properties and the # (hash) indicates protected methods.

However, the rest of the arrows are just indicating where one class uses another class. For example, the CrimeAdapter uses two classes (Crime and CrimeHolder). The CrimeListFragment uses the CrimeAdapter and of course the CrimeAdapter uses the Crime class. These levels of indirection (a class uses a class that uses a class) can be quite confusing.

Diagram Summary
Instantly, one thing the diagram does is provide you with an overview of all the things (classes) involved and all the actions (functions) that occur.

What The Diagram Helps Clear Up
I also believe the diagram begins to clear up the convoluted code that we see in the actual sample.
Keep in mind, I am not saying the authors made the code too complex. Instead, it is the Android API that has really done that. What I mean is that to use the RecyclerView you automatically step into a higher level of complexity because of what is required. But, even after you get the code working you may not understand exactly what is going on. I think the diagram helps in this way to see how the classes interact (use each other).

Confusing Redundancy Is A Bit More Clear
I also believe that a point of confusing redundancy is made more obvious by the diagram. You can easily see that there are three different classes which use the Crime class (CrimeLab, CrimeAdapter and CrimeHolder). It feels odd in the code and it’s difficult to get your head wrapped around it. However, here we can see that each of those classes needs to use the Crime class for its own purpose.

What About Class Behaviors?
The class diagram gives us a good structural look but says little about behaviors so now I’ll list how the classes are used when the app starts.

My main Activity class is CrimeListActivity. It is registered as the Launcher in the AndroidManifest so that is where everything starts. Of course, it is derived from the SimpleFragmentActivity so when the app launches it starts CrimeListActivity which calls the base class (SimpleFragmentActivity) onCreate() method.

The SimpleFragmentActivity.onCreate() calls createFragment() which we have overriden in our derived class (CrimeListActivity).
Inside createFragment() the method simply creates a new CrimeListFragment().
When it does that, the CrimeListFragment.onCreateView() fires which does the work to create the RecyclerView.

After it creates the RecyclerView, the CrimeListFragment calls the UpdateUI() method.
UpdateUI() makes sure a CrimeLab (list of crimes is created). This is the list which will eventually be displayed in the RecyclerView.

To display the list of crimes we have to use an Adapter class, so at this point the UpdateUI() method creates a new CrimeAdapter which takes a list of crimes. A CrimeAdapter is actually a special RecyclerView.Adapter. But notice that is is actually defined in the following way:
CrimeAdapter extends RecyclerView.Adapter<CrimeHolder>

Using natural language we would say that CrimeAdapter is a RecyclerView.Adapter of CrimeHolder.
Or, we might say, “A container of CrimeHolders”.

A lot happens when UpdateUI() news up one of these with the following code:
mAdapter = new CrimeAdapter(crimes);

That actually causes the onCreateViewHolder() method to fire after the CrimeAdapter constructor.
When onCreateViewHolder runs it :

  1. creates a new inflater object that can is used in the call to the CrimeHolder constructor
  2. news up a CrimeHolder() and returns it

When CrimeHolder() gets constructed it :

  1. inflates your list_item_crime.xml(two textviews - title and created date)
  2. sets the title and created textview to the value of the displayed crime

The CrimeHolder constructor is called 10 - 13 times depending upon how many Crimes will fit on your screen.
Then, each time you scroll a new item onto the screen the CrimeHolder constructor will fire again to inflate the list_item_view and display the data for the new crime.

That’s about as far as I have gotten at this point. I hope this helps to add some clarity to Chapter 8, although it also should help to show that chapter 8 covers a lot of territory. This part of the Android API works a lot of magic and there’s a lot going on underneath everything. I will study this more in an attempt to be able to implement these views on my own, because I do see how fast they are.


#2

Thank you for putting this out there. I’m sure this will help people understand that chapter better.

This RecyclerView chapter is one that we’ve had a hard time simplifying. I know that we lose a lot of people in this chapter and it’s significantly harder to understand than all of the chapters before it.

We introduced the chapter in the 2nd edition of the book (shortly after RecyclerView came out). Then significantly reworked it for the 3rd edition. We’ll probably rework the chapter again in the next edition. This write up will help us do that, so thank you.


#3

Glad to help. Writing that up really helped me to process everything that was going on in the chapter. I ended up adding log.d() statements to every method along the way so I could see exactly when each event fired and that really helped.

There is just so much to absorb related to RecyclerView – due to the nature of the thing.
I am working on isolating that functionality out so I can further understand it. I think that if you paired a straight flow diagram along with a class model it might help to set up the reader’s expectations that yes you are going to cover a lot of material but here is an overview of it.

RecyclerView is amazingly smooth though and I’m not sure I would’ve ever known about it without reading this book so kudos to you for covering it.

This book is fantastic, because it draws the reader through these tough foundational Android concepts and provides solid ground that I know is making me a far better Android dev. I’ve read / perused a large number of books but the strength of this one is that it really builds the story of Android programming very well.

Also, this is probably the best book community I’ve seen. Great stuff. Thanks.


#4

I really like the book too. Chapter 8 was a real challenge to follow along. Things started to go wrong for me when I saw mThumbnail on page 168. That instance variable name didn’t relate to anything that had come before and flipping through the remainder of the chapter, I couldn’t find anywhere that mThumbnail was later used. I was just left thinking “What the heck is this mThumbnail thing?!” It really through me off.


#5

That diagram is amazing. Clears up so much, and that description underneath. Doing god’s work.
Thank you.


#6

Thanks a lot,
I used your strategy of using Logs: I found out that the order in which Adapter methods are called is :

1 - getItemCount : gets called before displaying each item in the list. i was assuming that it get called only once at the beginning.
2 - getItemViewType: also gets called before displaying each item which is logical. the fact this method gets called before onCreateViewHolder gives so much flexibility.
3 - onCreateViewHolder
4 - onBindViewHolder

I also noticed that once the screen is filled, everything is put onHold till i start scrolling through items then the sequence start again. and after creating 9 viewHolders, i did not see anymore calls to onCreateViewHolder.

Amazing!!!


#7

Glad it helped. Thanks for letting me know. The RecyclerView, etc takes a lot of work to understand.


#8

@raddevus Kudos for such a great explanation :clap:
Could you help clear my doubt with this chapter, it seems you are quite strong with concepts. On page 173- last paragraph below, the highlighted xml file, should it not be list_item_crime instead.

Many thanks