We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. (Last updated on: June 24, 2019).
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Heights of some cells are not correct

Thread ID:

Created:

Updated:

Platform:

Replies:

151292 Feb 6,2020 01:44 AM UTC Feb 19,2020 04:38 AM UTC Xamarin.Forms 9
loading
Tags: SfListView
Adam
Asked On February 6, 2020 01:44 AM UTC

I am using the SfListView with:
 AutoFitMode=Height
 LoadMoreOption=Auto

I am finding that some cells are being rendered slightly too short, causing the content to crop. It seems to always be the second cell in the list, and the last cell that was created during the LoadMore command - meaning that as you're scrolling throught the list, you repeatedly come across truncated cells.

Scrolling the "bad cell" off the screen, then back on the screen, appears to reevaluated its required height, and fixes that cell for a time.

Screenshot attached...

Attachment: Screen_Shot_20200206_at_2.39.11_PM.jpg_11511c25.zip

Chandrasekar Sampathkumar [Syncfusion]
Replied On February 6, 2020 01:33 PM UTC

Hi Adam, 
 
Thank you for using Syncfusion products. 
 
We have checked the reported query “Heights of some cells are not correct” from our end. We have prepared sample based on the provided information and listview items loaded without clipping as expected. We have attached the tested sample for your reference and you can download the same using the following link,  
  
Sample Link : SfListViewSample 
 
Please check the attached sample and let us know if you are still facing the same issue? If yes, please modify our sample and revert us back or share the following details which would be helpful for us to check on it and provide the solution at the earliest.   
   
  • Xamarin.forms version used in your application
  • Specific platform the reported issue reproduced
  • Replication procedure to reproduce the issue
 
Regards,  
Chandrasekar Sampathkumar 


Adam
Replied On February 7, 2020 12:03 AM UTC

Hi there,

Thanks for the response.
These are the changes I made to your example to trigger the problem.
1. Set AutoFitMode=Height
2.Set LoadMoreCommand
3. Set LoadMoreOption=Auto
4. Alter the ViewModel to generate more items while scrolling.

You will see the bug.

XF version: 17.4.0.47
Platform: iOS 13.3 SIMULATOR . on Mac OSX 10.15.2

Process - run the application. Scroll until you see a "bad" cell - you will see one within a couple of screens.
See attached screenshot.

Attachment: SfListViewIncorrectCellSizing_2fcea1c6.zip

Chandrasekar Sampathkumar [Syncfusion]
Replied On February 7, 2020 11:21 AM UTC

Hi Adam,  
Thank you for the update.  
We have checked the reported query “Issue in ListView item size with loadmore” from our end. We have prepared sample based on the provided information. We are unable to replicate the reported issue from our end.  
 
We have attached the sample for your reference and you can download the same from the following link. 
 
Sample link : SfListViewSample 
 
 
Can you please share the code snippet of LoadMoreCommand execute method. Since there will be a chance to get issue if you are loading items without delay in LoadMoreCommand. Hence, It would be helpful for us to check on it and provide the solution at the earliest. 
 
Regards, 
Chandrasekar Sampathkumar 
 


Adam
Replied On February 7, 2020 06:51 PM UTC

Hi,

Thanks for the sample.
I see now what the difference is, you have a "await Task.Delay(1000)" in your LoadMoreItems method.
If I take out this line, your sample also has the cell height problem.

I never put this delay in because, well, why would I put an artificial pause in my code?

I put an "await Task.Yield()" in my code at the same location, and the problem went away.

I do see all your examples have a delay in the load-more, but I expect most developers (who are not copying and pasting) would omit this code as an unnecessary bottleneck in the initialisation of the application.
Can you point me to where in your documentation you explain why awaiting is necessary?

Thanks,

Chandrasekar Sampathkumar [Syncfusion]
Replied On February 10, 2020 11:57 AM UTC

Hi Adam, 
 
Thank you for the update. 
 
We have analysed the reported issue “ListViewItem does not layout properly when use LoadMore without delay” and already logged the issue report for the same. We will fix the issue and include the issue fix in our Weekly Nuget release which is planned to roll out on February 18, 2020. We appreciate your patience until then. 
 
You can track the status of this report through the following feedback link, 
 
 
Note: The provided feedback link is private, you need to login to view this feedback. 
 
Please let us know if you want patch earlier which will be available after February 14, 2020. 
 
Regards, 
Chandrasekar Sampathkumar  


Adam
Replied On February 17, 2020 10:23 PM UTC

Hi,

Apologies I did not receive an email notification that you had responded.
Thank you for taking action, I can wait for the public nuget.

Best regards,

Lakshmi Natarajan [Syncfusion]
Replied On February 18, 2020 05:55 PM UTC

Hi Adam, 
 
Sorry for the inconvenience caused. 
 
We have analyzed the reported issue from our end. On further analysis, we would like to let you know that this is the expected behavior in SfListView as per the implementation LoadMore should be used with delay. Please find the details of the complete analysis below, 
 
Case 
Behavior 
LoadMore with delay 
When ListView reaches the end while scrolling, ListView will check for load more operation, if CanLoadMore returns true, the execution method starts in the thread, and indicator layout completes and the call goes to collection changes if any items added in the execute method of the load more. And layout the visible items added at load more which to be displayed in the view. 
LoadMore without delay 
When ListView reaches the end while scrolling, checks for load more operation, if CanLoadMore returns true, the execution method starts in the thread, and directly it started to layout the items, added in the execute method of LoadMore. And layout the visible items added at load more which to be displayed in the view. The added items are measured as excepted, but on layouting, the first item which added on each load more call, gets the line of indicator view and layout with that size (48d). 
 
We suggest you to set minimum delay for LoadMore to overcome the reported issue. We will update the same in our UG documentation also. 
 
Meanwhile, we suggest you to achieve your requirement without using LoadMore. You can add the items directly by listening to the end of the list is reached as suggested in the following kb document, 
 
 
Regards, 
Lakshmi Natarajan 
 


Adam
Replied On February 18, 2020 09:11 PM UTC

Hi Lakshmi,

I see what is being described - however the fix is not a delay per-se - it's just the yielding effect that a delay has.
As such, the following code also works perfectly, without causing any delay:

await Task.Yield();

Perhaps your developer team could investigate this as an option, and put it in the docs?

Thanks,

Lakshmi Natarajan [Syncfusion]
Replied On February 19, 2020 04:38 AM UTC

Hi Adam, 
 
Thank you for the update. 
 
We are glad that the reported issue has been resolved at your end. We will update our UG document regarding the same as mentioned in our previous update and also we will check with that await Task.Yield(). 
 
Please let us know if you need further assistance. 
 
Regards, 
Lakshmi Natarajan 


CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Please sign in to access our forum

This page will automatically be redirected to the sign-in page in 10 seconds.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon

Live Chat Icon For mobile
Live Chat Icon