Hi all,
Do we know what the recommended maximum amount of cells/items may be inside a Short List for a native app?
”Avoid using for large datasets” is a bit vague, unfortunately.
It’s hard to put a number on it, as it depends on the amount of data you are loading (which is not just the number of records, but the amount of data in each record).
I call this data weight, in my books, and explain it in some detail in this article. Essentially, what the caution in the docs says is just that this thing loads all data at once, as opposed to lazy loading or paginating it. This in itself doesn’t mean that any search with a lot of records will be dead slow or burn out your workload; it just means you should be aware that while repeating groups have a kind of built-in protection for downloading massive amounts of data, short lists don’t – they’ll simply download everything you tell them to (but still contained to your search constraints, privacy rules, etc).
Performance aside, there’s of course the UX perspective: super long lists may not give a great user experience, but again there’s not really any hard limit that users find acceptable. Scrolling to a list of countries is an example of a list that from a UX perspective is frustratingly long, but of course you kind of have to list them all.
So I’d see this more as a UX and performance decision that you have to make: do you want to load and display a lot of data at once (with the performance and UX ramifications that creates), or do you use this option just for short list?
Experimenting with it and seeing for yourself how it affects performance, workload and UX is probably the best approach here, rather than setting an absolute limit.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.