SfListView ScrollTo issue if list is grouped

[Ernest]

Hi,

If you have grouped SfListView and use ScrollTo method and then try to scroll back to previous records, scrolling is erratic as it jumps back and forth between rows. If you only scroll forward (down) then no such problem.

I've tested this with Xamarin ListView and CollectionView and those controls don't have this issue.

Any chance you can fix your SfListView to behave the same as now ScrollTo method is basically useless if list is grouped.

[Lakshmi Natarajan]

Hi Ernest, 

 

We regret to inform you that, according to the implementation of the SfListView architecture, when the ScrollTo method is applied to a specific item when using the AutoFitMode, the scroll offset is calculated based on the default ItemSize. As a result, the reported behaviour will occur when scrolling up the list after programmatically scrolling to the specific item, since the dynamic height will be calculated based on actual item size. Also, this behavior has been considered as a limitation in SfListView.   

 

Please refer to our user guidance document regarding limitations in SfListView scrolling,  

UG link: https://help.syncfusion.com/xamarin/listview/scrolling#limitations  

 

Please let us know if you need further assistance. 

 

Regards, 

Lakshmi Natarajan 

[Ernest]

Hi Lakshmi,

I'm not using  AutoFitMode mode. I've tried same scenario with all other lists - Xamarin ListView, CollectionView, DevExpress DataGridView and none of them have this issue.

Would you consider fixing this bug or is this too hard for Syncfusion developers?

[Lakshmi Natarajan]

Hi Ernest, 

 

We deeply regret to let you know that as per the current implementation of the SfListView architecture, the reported use case has to be marked as a limitation. To summarize, when the ScrollTo method is applied to a specific item with any item size customization, the scroll offset is calculated using the default ItemSize (40d). 

   

We had tried numerous approaches involving our senior developers, leads, and managers and yet could not come up with a stable, sustainable, and effective solution that meets all ends even after all the brainstorming.  

   

Even after willingly trying out many architecture level changes, the impact on scrolling performance was inevitable since it involved replicating and measuring all the items/views above the row index you are passing via the ScrollToRowIndex/ScrollTo method.  

   

At times when loading complex templates/layouts the application even went on to be nonresponsive for a few seconds to measure the n number of views. Adding to the complexity was to handle cases like StickyHeaders, Grouping, and LoadMore, etc especially.  

   

So after considering all the efforts put in, the obtained lesser effective results, and taking into consideration the stability, quality, performance, existing users, and in the best interest of the product we are marking this as a limitation.  

 

Regards, 

Lakshmi Natarajan 

 

[Ernest]

Hi  Lakshmi,

Thank you for detailed explanation. One thing I still don't understand - all my items has same item size set to 95, but scrolling back issue is still there after ScrollTo is called. You've mentioned 'default ItemSize (40d).' - what does 40d means? Can't you calculate everything based on whatever item size is set in ListView?

You must be calculating scroll offset correctly, because ScrollTo method works perfectly - always shows group header I scrolled to at the top, which means that your scroll offset calculations are correct. Also, if I scroll forward it always works 100%, only if I start scrolling back it starts jumping back and forth.

[Lakshmi Natarajan]

Hi Ernest, 

 

We regret for the inconvenience caused. 

 

The scroll offset is calculated using the ItemSize value from the sample. However, there is still a difference in the offset calculation. We are currently analyzing the same in our source level and update you further details on December 17, 2021. We appreciate your patience until then. 

 

Regards, 

Lakshmi Natarajan 

 

[Ernest]

Hi  Lakshmi,

Thank you. Out of all ListViews/CollectionViews I've tested, yours worked the best compared to others. Now if you could fix this one little issue it would have no competition! :)    

[Lakshmi Natarajan]

Hi Ernest, 

 

We investigated the scenario at the source level. We are calculating the scroll offset based on ItemSize. However, the problem arises as a result of grouping because the GroupHeader has different sizes. We have provided customization for the GroupHeader height using GroupHeaderSize, which has a default size of 40d. So, we regret to inform you that this scenario falls under the limitation of the QueryNodeSize/Item size customization because the ItemSize and the GroupHeaderSize have different values. 

 

Please refer to our user guidance document regarding GroupHeader height customization, 

UG link: https://help.syncfusion.com/xamarin/listview/grouping#height-customization 

 

As a result, you can avoid the reported scenario by setting the GroupHeaderSize to the same value as the ItemSize. We hope this helps, and please let us know if you require any further assistance. 

 

Regards, 

Lakshmi Natarajan 

 

[Ernest]

Hi  Lakshmi,

Thank you, but this doesn't help as setting group header size same as item size would make list look ridiculous.

I still don't understand why it is so hard to calculate different sizes of items, but if your developers can't find a solution, so be it. I wish I had source control for SfListView so I could fix it myself.

[Lakshmi Natarajan]

Hi Ernest, 

 

We have created a new support ticket for the source code requirement. Please follow the created ticket for further updates. 

https://support.syncfusion.com/support/tickets 

 

Regards, 

Lakshmi Natarajan