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 increase in temperature 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, as the previous author proposes to fight with these monsters, I strongly disagree.

Consider 2 conditions.

Condition No. times

If you hang a listener somewhere, then somewhere else you have to unplug it. This is usually done in symmetric functions - we attach to onViewAttachedToWindow, we remove to 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 you, as the author of the original article comes up with the idea: "But there are cases where ... in the listener must take into account the position of the element in the list, access to which is, in onBindViewHolder () method, and is absent in onViewAttachedToWindow ()" , then the 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 contents, so we risk getting the wrong position in our listener. Use getAdapterPosition.

Condition number two

RecyclerView- the piece is quite complicated. Do not complicate your life even more. If you are not engaged in performance optimization, you should not be important whether this element is in the common pool or not.

Result

При соблюдении этих двух условий вам вряд ли понадобится изобретать велосипед в виде флага типа viewWasRecycled.

Что происходит?

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

So we have 3 options for the development of events:

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

Where and how?

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

• onCreateViewHolder. Create, uh, ViewHolder. There is no need to bind a listener, fill it with content, etc. Simply determine which type we need and create it.
• onBindViewHolder. We perform the actual binding of content - text, pictures. The parameter positioncan be used only in the method itself - we 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 would also 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 it 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 tohellpool. Here you can release heavy resources (cached images, for example). If the item is reused, it is 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.