What does developer.android.com say about RecyclerView

Greetings to you, dear habrazhiteli! This post pushed me to write an article (or rather, the feeling of a sharp local temperature increase in the region ... hmm, backache, usually arising when someone is wrong on the Internet).

Let's start from the beginning. I fully agree that "there is something in common between the life cycle of an activity and the work of RecyclerView" - this is "something" - the need to understand what we are doing and why. And read the documentation. And the failure of these two necessities, like the sleep of the mind, gives rise to monsters. Only here with the fact that the previous author proposes to fight these monsters, I strongly disagree.

Consider 2 conditions.

Condition No. times

If you hang up a listener somewhere, then somewhere else you have to unplug it. This is usually done in symmetric functions - we attach it in onViewAttachedToWindow , we remove it in onViewDetachedFromWindow . Attached to onBindViewHolder ... Do not attach to onBindViewHolder . This call is not symmetrical, it can be called several times depending on different conditions. Do not complicate your life.

If, like the author of the original article, you get the idea: "But there are cases when ... in the listener it is necessary to take into account the position of an element in the list that is accessible in the onBindViewHolder () method and is not in onViewAttachedToWindow ()" , then chase this thought away. So you can not do. Even if you really want. As stated in the documentation , this method will not be called if only the position of the element has changed, but not its content, so we risk getting the wrong position in our listener. Use getAdapterPosition .

Condition number two

RecyclerView is a pretty complicated thing. No need to complicate your life even more. If you are not engaged in performance optimization, it should not be important for you whether this element is in the common pool or not.

Result

Under these two conditions, you are unlikely to need to reinvent the wheel in the form of a flag such as viewWasRecycled .

What's happening?

What can happen to an item in RecyclerView ? First, we must bear in mind that there are 2 "storages" - a cache and a pool. An item gets into the cache if it goes beyond the screen, but at any time can return again - without even re-linking this item (i.e., the onBindViewHolder method will not be called). If the cache is full, or for some other reason, RecyclerView decided that we would not need this element in the near future, it will go to the pool ( onViewRecycled will be called onViewRecycled ). The item recovered from the pool will be rebound (because most likely its position has changed), and we will receive an onBindViewHolder call. But if the element is out of the pool, then the new element will go through the entire cycle - onCreateViewHolder , onBindViewHolder , onViewAttachedToWindow .

Total, we have 3 options for the development of events:

• there was no element before: create, bind, attach;
• the item was in the pool: bind, attach;
• item was cached: just attachable.

Where and how?

What and at what stages it is better to do with the element?

• onCreateViewHolder . Create, hmm, ViewHolder . There is no need to bind a listener, fill with content, etc. Simply determine which type we need and create it.
• onBindViewHolder . Perform the actual binding of content - text, pictures. The position parameter can only be used in the method itself - do not save it, do not send it to the closure, remember that this method will be called again if the data has changed (and not if the position has changed). Listener, I also would not hang here - for reasons of symmetry.
• onViewAttachedToWindow . The element will now be visible on the screen, the user will be able to interact with it - a good time to attach the listener. Remember that if inside we need the position of the element, then we get it through getAdapterPosition .
• onViewDetachedFromWindow . The item will not be displayed on the screen. The user will not be able to interact with him. Remove the listener.
• onViewRecycled . Item is sent to hell pool. Here you can release heavy resources (cached images, for example). If the item is reused, then, most likely, for a different position.

That seems to be all. I hope I did not forget anything and did not confuse, but if anything - poke your nose, do not hesitate.