“This is the 11th day of my participation in the Gwen Challenge in November. See details: The Last Gwen Challenge in 2021.”

preface

The hitTest method is modified to handle click events.

But I’m sure some of you can see that this is a palliative. To be clear, the data that is passed through the SliverList process is not changed. For the rest of the SliverList process, it’s still based on the data that items are sorted in a ListView fashion.

This part is sure to be confusing and misleading as more and more custom ListViews become available;

Now let’s change it from the data source perspective;

assessment

First, let’s confirm the data in ParentData and its role:

SliverList parentData is SliverMultiBoxAdaptorParentData, in which the storage index and the keepAlive; It works, literally:

Its parent class puts the commonly used layoutOffset argument:

There are also two mixins, one to hold the child list relationship:

The other one is keepAlive… What’s the difference between keepAlive and keptAlive? It doesn’t seem to make any difference. Get has been overwritten…

Now I’m going to focus on layoutOffset, and my initial idea was to modify layoutOffset; However, layoutOffset provides not only to indicate the position, but also to know the relative position relationship between items. LayoutOffset tells you how much of the previous child preceded the current one;

So the way we’re going through lastChild in this case, we know the relative position of each child before; If all child layoutoffSets are actually on the canvas, how do we know which child scrolloffSets correspond to?

After a little agonising, I realized that in the source code there was a variable called paintOffset; Like this:

Since there is such a thing in the source code, maybe trace it to know how to do

There’s one thing that confuses me

First, let’s look at the notes:

According to the comments, this is exactly what I need to show the position of child relative to parent;

One thing that confused me a little bit, though, is that the comment explicitly states that this is best used on views with a small number of children; Now, if you set a paintOffset, it’s not much different than setting a layer to ffset, it’s just going to calculate it based on scrollOffset;

If you look at the call location, it is true, as the comments indicate, that parentData is used by views that hold only one child;

The call location is also performLayout; For example:

One of the call locations looks like this:

Why specify a View that holds a small number of children?

design

My plan is to calculate the layoutOffset of each item in the section of performLayout, and also calculate the paintOffset based on the situation. Take the page turning that is currently planned to be realized as an example:

So what needs to be done is clear:

  • Provide to set a new ParentData to hold the paintOffset;
  • Provide a method to calculate the paintOffset, provided to LayoutOffset;
  • Change the paint method to paint according to a paintOffset.
  • Modify the hitTest method to also calculate according to paintOffset;

CTRL + CV warrior fearless;

At the end

At present, no performance loss has been found after a simple test. So that part in the notes really confused me