ListViewCachingStrategy in UI for Xamarin

This is a migrated thread and some comments may be shown as answers.

ListViewCachingStrategy

10 Answers 84 Views

ListView

This is a migrated thread and some comments may be shown as answers.

10 Answers, 1 is accepted

answered on 03 Aug 2017, 10:45 AM

Hi,

The RadListView does not extend the native XamarinForms ListView component. We rely on our native Android, iOS and UWP implementations. This is why the performance improvements implemented in the XamarinForms component cannot be applied to our RadListView.

Could you please share more details about your setup? How are the items loaded? How is the Template of the items defined? How much items you try to visualize? What makes you think the performance is not good enough?

If you share more details about the scenario and the requirements we might be able to suggest a better approach to achieve the required setup.

Regards,
Pavel R. Pavlov
Progress Telerik

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items

answered on 04 Aug 2017, 09:21 AM

And...? Do you have any performance issues? Maybe your performance issues (if appears), are related to usage of OOTB Xamarin Forms **Image** element.
I suggest to use FFImageLoading, which has loading/caching/downstamping mechanisms against **CachedImage** (you can use it, instead of default **Image**).
TL;DR - use at least Aspect="AspectFit" +DownsampleToViewSize="True" properties on it.

For me, usage of:
-Telerik RadListView + Image == laggly UI during fast scrolling, even for 5 elements at list

-Telerik RadListView + FFImageLoading == smooth UI during during fast scrolling, even for 30 elements (haven't test in on hundreds or thousands)

answered on 04 Aug 2017, 04:46 PM

Also, FFImageLoading fails OOTB on iOS with an UIKitThreadAccessException... useless...

UIKit.UIKitThreadAccessException: UIKit Consistency error: you are calling a UIKit method that can only be invoked from the UI thread.
at UIKit.UIApplication.EnsureUIThread () [0x00023] in /Users/builder/data/lanes/4691/d2270eec/source/xamarin-macios/src/UIKit/UIApplication.cs:88
at UIKit.NSDataAsset.get_Data () [0x00000] in /Users/builder/data/lanes/4691/d2270eec/source/xamarin-macios/src/build/ios/native/UIKit/NSDataAsset.g.cs:117
at FFImageLoading.DataResolvers.BundleDataResolver+<Resolve>d__1.MoveNext () [0x00369] in <8242b6346c404272a5f37bad37b4ee65>:0

answered on 08 Aug 2017, 02:37 PM

Hello,

We are aware that the performance of the RadListView can be improved. We have exposed a feedback item which is related with the described setup. Customers can vote and follow the item so that they will be notified when we provide a fix.

At the moment of writing we cannot bind to any specific time frame for providing a fix. The implementation priority depends on the votes of the item hence every vote counts.

Regards,
Pavel R. Pavlov
Progress Telerik

answered on 09 Aug 2017, 10:58 AM

[quote]Michael said:

Also, FFImageLoading fails OOTB on iOS with an UIKitThreadAccessException... useless...

[/quote]

I'm using **FFImageLoading** without any issues at Android and iOS.
In many ways - inside mentioned Telerik RadListView (at attachments thumbnails), inside Telerik RadListView (as customer logo image) as well as outside Telerik components - as app logo at standard Xamarin Page etc.

answered on 23 May 2018, 11:50 PM

[quote]Namysław said:[quote]Michael said:

Also, FFImageLoading fails OOTB on iOS with an UIKitThreadAccessException... useless...

Can we please stop discussing FFImageLoading? I clearly described the faulty and expected behavior when I use RadListView. The behavior is completely agnostic of content of the list views cells... It is 10 month now and nothing has been done about this...

answered on 28 May 2018, 07:34 AM

Hi, Michael,

I am sorry to hear that you are still experiencing performance issues in the described scenario. Actually, the feedback item that my colleague has provided is already fixed. We would like to investigate the scenario you have in more details so we can identify what exactly might be the root of the issue. Would it be possible to create a ticket and attach a sample with your specific setup so we can test it from our side?

In the meantime, as you have mentioned previously that you suppose the issue is that the RadListView control creates all the necessary visual elements for all of the items within your source collection - the control supports UI Virtualization and would reuse the visual elements for the different items within its ItemsSource. Please make sure that the control is not placed within a layout that will measure its height with infinity(such as a StackLayout) as this would break the UI virtualization and would result in such slow performance.

Regards,
Stefan Nenchev
Progress Telerik