I tested different CachingStrategy but it did not accelerate anything. The code in c # / xaml is standard simple, it does not contain anything complicated, the only thing that worries me is the number of bindings. Is there any known trick that allows you to speed up operations on them or reduce their number in xaml.
200 bindings in a ListView... Really? Sounds like that could probably be re-imagined. I can't fathom how a ListView record could be at all manageable or viewable on a mobile device - even a PC screen - with over 200 elements in a single record.
It sounds more like someone knew how to do one thing: Binding... And used it as the only tool in their toolbox - as a way to handle everything from business rules to data validation.
Why is your cell so ridiculously complex? How many of these visibility bindings are ever going to be true at the same time? The XAML you posted is only for one of three columns, I feel like if all three of them are visible it would be impossible to read anything.
You really need to look into simplifying your model and using a DataTemplateSelector to define a few different cells instead of cramming them all into one.
@ClintStLaurent said:
200 bindings in a ListView... Really? Sounds like that could probably be re-imagined. I can't fathom how a ListView record could be at all manageable or viewable on a mobile device - even a PC screen - with over 200 elements in a single record.
It sounds more like someone knew how to do one thing: Binding... And used it as the only tool in their toolbox - as a way to handle everything from business rules to data validation.
@JoeManke said:
Why is your cell so ridiculously complex? How many of these visibility bindings are ever going to be true at the same time? The XAML you posted is only for one of three columns, I feel like if all three of them are visible it would be impossible to read anything.
You really need to look into simplifying your model and using a DataTemplateSelector to define a few different cells instead of cramming them all into one.
I'm going to be more frank....
What a mess.
Pure and simple no sugar coating. What a mess.
Every item has its own fontsize and margins set individually instead of defining styles.
Every item is micro-managed to within an inch of its life. variable25 ... variable 37... You have got to be kidding.
A bunch of these
The StackLayout IsVisible is binded to one property. Its only has two items, and they are binded to the same different property. Let's just add 3 times the amount of computing required. Bind just the StackLayout to the one property you care about variable23.
Total rendering engine nightmare. Whatever graphic designer did this UI needs to be fired. Whatever developer did those variable names needs to be demoted to intern and go back to school.
I'm surprised the app runs at all and the phone doesn't just burst into flame.
This has got to be something out of a Mumbai outsource company.
That's why we needed to see your XAML. From your original post, you might have had four bindings per item and 50 items. Seeing your XAML shows that is not the case and that you actually have a serious design issue.
Immediate thoughts - I'm using "may" and "might" here, as you'd have to pay me to go through this in detail to give definitive answers:
(1) You might want to use a DataTemplateSelector
(2) You may not need the granularity of control over IsVisible that you currently have
(3) You might be able to use Styles to simplify things
(4) You may not need to control IsVisible on Views that are inside Layouts for which you already control IsVisible
What you currently have is crazy complicated. I seriously doubt that it needs to be anywhere near that complex. That it's slow to render is no surprise. Assuming that you are in a corporate environment, I'd suggest getting somebody in to look at the requirements and to come up with a design that copes on devices that have limited CPUs.
Or, if you don't want to deal with templates or styles (even they're reccomended), just separate it in views, and work with blocks. That's easy even for total noobs. Just take a look on how they work, because is a very basic feature.
That XAML remembers me the old HTML pages and the way they were programmed years ago.
Answers
@tomek.1101
See https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/listview/performance for information about caching strategy.
If you are already using the most appropriate caching strategy, post your XAML/C#
I tested different CachingStrategy but it did not accelerate anything. The code in c # / xaml is standard simple, it does not contain anything complicated, the only thing that worries me is the number of bindings. Is there any known trick that allows you to speed up operations on them or reduce their number in xaml.
Nobody will be able to tell you how to reduce their number in XAML without seeing your XAML :-)
200 bindings in a ListView... Really? Sounds like that could probably be re-imagined. I can't fathom how a ListView record could be at all manageable or viewable on a mobile device - even a PC screen - with over 200 elements in a single record.
It sounds more like someone knew how to do one thing: Binding... And used it as the only tool in their toolbox - as a way to handle everything from business rules to data validation.
Part of ListView in Xaml file:
MyList - is generate and modify in ViewModel very fast.
I have a lot of elements isVisible, this explains why the entire list has as many as 200 bindings.
Why is your cell so ridiculously complex? How many of these visibility bindings are ever going to be true at the same time? The XAML you posted is only for one of three columns, I feel like if all three of them are visible it would be impossible to read anything.
You really need to look into simplifying your model and using a DataTemplateSelector to define a few different cells instead of cramming them all into one.
I'm going to be more frank....
What a mess.
Pure and simple no sugar coating. What a mess.
Every item has its own fontsize and margins set individually instead of defining styles.
Every item is micro-managed to within an inch of its life.
variable25
...variable 37
... You have got to be kidding.A bunch of these
Then there's junk like this.

The
StackLayout
IsVisible is binded to one property. Its only has two items, and they are binded to the same different property. Let's just add 3 times the amount of computing required. Bind just the StackLayout to the one property you care aboutvariable23
.Total rendering engine nightmare. Whatever graphic designer did this UI needs to be fired. Whatever developer did those variable names needs to be demoted to
intern
and go back to school.I'm surprised the app runs at all and the phone doesn't just burst into flame.
This has got to be something out of a Mumbai outsource company.
Thanks for the laugh
I really needed it today.
@tomek.1101
That's why we needed to see your XAML. From your original post, you might have had four bindings per item and 50 items. Seeing your XAML shows that is not the case and that you actually have a serious design issue.
Immediate thoughts - I'm using "may" and "might" here, as you'd have to pay me to go through this in detail to give definitive answers:
(1) You might want to use a DataTemplateSelector
(2) You may not need the granularity of control over IsVisible that you currently have
(3) You might be able to use Styles to simplify things
(4) You may not need to control IsVisible on Views that are inside Layouts for which you already control IsVisible
What you currently have is crazy complicated. I seriously doubt that it needs to be anywhere near that complex. That it's slow to render is no surprise. Assuming that you are in a corporate environment, I'd suggest getting somebody in to look at the requirements and to come up with a design that copes on devices that have limited CPUs.
Or, if you don't want to deal with templates or styles (even they're reccomended), just separate it in views, and work with blocks. That's easy even for total noobs. Just take a look on how they work, because is a very basic feature.
That XAML remembers me the old HTML pages and the way they were programmed years ago.