"Non-continuous" scrolling when AutoFitMode is Height

[Omar]

Hello,

My project target .Net 8.0 and I use MAUI SfListView 25.1.42.

I set the parameter AutoFitMode to "Height" each row has a height different.

On Android and iOs, when I scroll down, there is no problem.

But when I scroll (very slowly) up, I get "non-continuous" scrolling:

  - instead of going from A to C, with the ListView  "following" my finger on the screen and which scrolls very slowly

  - I go suddenly from A to B, with row 79 appearing entirely at once

Could you help me to have "natural" scrolling with rows of different sizes?

Thanks

[Suthi Yuvaraj]

Hi Omar ,  

We have checked your requirement, and we have created a sample with different item sizes and autofit mode as height, which works fine at our end. We have attached the tested sample and output video for your reference. Please have a look at the sample and let us know if we have missed any customization that you have done in your sample.

Also kindly share the details about the tested device and code snippet to reproduce the issue at our end. if possible kindly modify the sample to reproduce the issue and find the solution as soon as possible.

Regards,

Suthi Yuvaraj.

Attachment: ListViewMaui_d22f133.zip

[Omar]

Hi Suthi,

Thank you very much for your quick and relevant response!

I managed to reproduce my issue with your sample, I only made these modifications (to start directly at line 80):

I added a video to the Output folder where the issue is visible (see the appearance of the line "Danielle" at second 13, and that of "Carlson" at second 20).

Thank you again for your help.

Regards,

Omar

Attachment: SfListViewMaui_3b8c2ded.zip

[Omar]

Hi Suthi,

Can you reproduce what we see in my video?

Do you have any suggestions to f(or work around) my issue please?

Thanks and regards,

Omar

[Suthi Yuvaraj]

Omar,

We have checked your requirement, we would like to let you know that, As the control is scrolled initially, it begins displaying items from the 80th position. Consequently, only the items visible within the view are measured, while others are measured as they enter the view. In your specific case, let's say the 80th item's origin is at 500. Now, as you scroll upwards, the previous item (79th) comes into view. At this moment, the 79th item is measured, and let's assume it has a size of 110. Previously, the size was considered as the default item size (56d). Consequently, the 80th item is pushed and laid out with a new origin point at 660. This shift in origin points is what causes the noticeable jump while scrolling. This behavior is expected and aligns with our current implementation standards.

Kindly let us know if you have any concerns.

[Omar]

Hi Suthi,

First of all, thank you for all these technical details, being a developer, I understand your implementation perfectly.

But I must admit that I am somewhat disappointed because I have never seen a list have this behavior, whether on mobile or on Windows. And I'm surprised to be the only one to report this behavior to you, which cannot seem "natural" to users.

Can I offer you a solution: always measure the item preceding the one displayed at the top (if it has not yet been measured)?

That being said, would it be possible to avoid this behavior with the current version please?

By forcing, for example, the measurement of all the items on the list once and for all?

Thanks for your help.

Regards,

Omar

[Suthi Yuvaraj]

Omar,

We would like to let you know that SfListView is virtualizing control. it is not possible to measure all the items before scrolling, where you can achieve your requirement by disabling the scrolling and virtualizing the item. set the IsScrollingEnabled to False and load the SfListView inside the ScrollView. Please refer to the code snippet below for more reference.

Code snippet:

<ScrollView>

<syncfusion:SfListView

x:Name="listView"

Margin="0,10,0,0"

AutoFitMode="Height"

IsScrollingEnabled="False"

ItemsSource="{Binding ContactsInfo}">

...

</syncfusion:SfListView>

</ScrollView>

Attachment: SfListViewMaui_1e8f90a1.zip

[Omar]

Hi Suthi,

Thank you for your prompt response.

By implementing your proposal, programmatic scrolling is no longer possible, so by always starting at line 0, my problematic scenario is no longer possible.

And unfortunately, I need programmatic scrolling.

Knowing that this behavior does not exist with native ListViews from Android or iOs, nor with ListViews/CollectionViews from Microsoft or other leading vendors (like Telerik or DevExpress), can I hope that a future update will allow having a more “natural” behavior for the user please?

I greatly appreciate your help.

Regards,

Omar

[Suthi Yuvaraj]

Omar,

We recognize the challenge you are facing: measuring each item before scrolling can impact performance, and it is not feasible with our present setup. Therefore, we developed an example with a ScrollView with programmatic scrolling capabilities. In this example, you can navigate to the item of your choice by using the ScrollToAsync method within the ScrollView. We've included the updated sample for your review. Please feel free to reach out if you have any questions or concerns.

Attachment: SfListViewMaui_2049ac28.zip

[Omar]

Hi Suthi,

Thanks for this workaround, it works and allows programmatic scrolling with IsScrollingEnabled set to false.

However, a side effect makes this solution almost unusable: the drastic drop in performance.

For example, for a list containing around 200 rows, it takes me more than 40 seconds to display the page with IsScrollingEnabled set to false, whereas it is almost instantaneous when IsScrollingEnabled is set to true.

No user will want to use an app where the result of pressing a button takes 40 seconds to display 😥

Regards,

Omar

[Suthi Yuvaraj]

Omar, 

We have reviewed your requirements and would like to inform you of our current implementation. We measure the items during scrolling to optimize loading times. Measuring items during the initial load would increase loading time significantly. Therefore, the current behavior involves measuring items on scroll to enhance performance.

Unfortunately, we do not have a workaround to improve loading performance without scrolling enabled. Please let us know if you have any concerns.

[Omar]

Hi Suthi,

I understand your concerns about performance, but in the case of a bug, shouldn't we first prioritize a fully functional control?

By 'bug', I mean non-usual behavior for a ListView: I have been developing graphical interfaces for 10 years on Windows (winforms and Wpf) as well as on native Android and iPhone, and I have never seen a scrollable control suffer this kind of 'jump'.

Although all offer the possibility of programmatic scrolling.

Even as a simple user, I have never seen a mobile application behave like this.

Unfortunately, your implementation requires you to always start at the first line (to avoid getting the bug), which is not always the case in an application. There are many cases where we want to be able to start at a given line (just think about how the applications that we all use daily on our smartphones work).

Can we not consider a fix, even if it is delivered in several months?

Thanks and regards,

Omar

[Suthi Yuvaraj]

Omar , 

We would like to clarify the behavior of AutoFitMode and explain its impact on your scenario, as well as why we did not consider this to be a bug.

The SfListView is a virtualized control, which means it only measures the items that are currently in view. Let’s discuss the behavior in two different AutoFit modes:

1. AutoFitMode.None:

• In this mode, the ItemSize is set to the height of each item.
• For example, if you have 100 items and you programmatically scroll to item 80 with an ItemSize of 50, the ScrollPosition will be 4000. If you scroll up from there, the heights of the items won’t change, so there won’t be any jump issues.

2. AutoFitMode.Dynamic:

• In this mode, each item can have a different size. The ListView will only measure the items that need to be displayed, and for the rest, it will consider the ItemSize property value.
• For instance, with 100 items, if you scroll to item 80 with an ItemSize of 50, the ScrollPosition will be 4000, and the Y position of the 80th item will be 8000.
• If you scroll up to display item 79, it will be measured at that time. If item 79 requests a size of 50, there won’t be any issue. However, if it requests a size different from 50, you may experience a jump.

 

Let’s look at two cases where item 79 requests a different size:

• Case 1: Item 79 requests a size greater than 50, say 75.

• If you scroll to a position of 7999 or less, item 79 will be measured and return a height of 75.
• This causes the height of item 79 to increase, shifting the position of item 80 to 8025. However, since the scroll offset remains at 7999, this discrepancy will result in a visible jump.

• Case 2: Item 79 requests a size less than 50, say 25.

• Similarly, if you scroll to a position of 7999 or less, item 79 will be measured and return a height of 25.
• This causes the height of item 79 to decrease, shifting the position of item 80 to 7975. But with the scroll offset still at 7999, this will also result in a visible jump.

 Please let us know if you have any concerns.

[Omar]

Hi Suthi,

Thank you again for all these technical details (which I understand perfectly), but I must admit that your answers surprise me a little 😕

By "bug", I mean two things:

1. a behavior (this 'jump') which is not visible in any mobile application
2. a behavior which does not exist in:

• • the native Android ListView
  • the native iOs UICollectionView
  • both ListView and CollectionView from Microsoft MAUI Toolkit
  • List/Collection View MAUI from other leading vendors (like Telerik or DevExpress)

In all these controls, you can scroll to a given row (following a simple search for example), then scroll up without this kind of 'jump'.

This basic need is impossible with the SfListView, so I don't understand why you want to leave this problematic behavior as is, and try to convince me that "it's not a bug, it's a feature" 😓

I still hope that you will take my request into consideration.

Best regards,

Omar

[Suthi Yuvaraj]

Omar,

Sorry for the inconvenience caused,

 

Please create a support ticket using the following link so we can investigate this issue further and assist you through the ticket:

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