Hi,

One of the screens in an iPad app consists of a list of cards (FlipContent widgets). Each card contains an image, loaded from the iPad's file system. Because they wanted to scroll through the whole list easily, we currently load the whole list. The images are shown in a smart way, to only show when they're in view.

This works nice for normal amounts of cards in the list, but when we use a larger list (e.g. 1200+ items), then the app crashes when you navigate away from the screen. It seems like this has something to do with the large object that remains in the memory. Debugging, also with remotedebug, doesn't show any log entries.

Does this issue sounds familiar to any of you and does anyone have an idea of how to solve this.


Regards,
Lennart

What version of OutSystems platform?

What version of Service Studio?

Has the issue been tested in the in-browser emulator? 

Has the issue been tested on more than one device?

Sounds like it could be an issue with cleaning up large amounts of memory use. Might be interesting to see if you can figure out where the breaking point is (that is, how many items you can load before the issue occurs).

Loading large lists of items is rarely a good pattern, since it's inefficient, and if you're in a memory-constrained environment can lead to performance issues as well.

Hi Lennart,

The issue doesn't sound familiar to me, but as you are most certainly are aware of, mobile devices have limited processing power and memory. As such optimizing your logic for performance is for mobile even more important than for web applications. User expectations on response times are much higher on mobile.

Why not try to change the logic to not have such a huge list of items. Only so many will be visible at a time to the user. Using some paging logic on your aggregate you could limit the data set dramatically, and probably above your problem.

Regards,

Daniel

Hi Daniël, 

You're absolutely right. This was the way we had built it before, exactly for that reason. But during tests users find that they couldn't easily scroll from A to Z, so we tried this. It takes some more time to load, but after this it works remarkably well. 



G. Andrew Duthie wrote:

Sounds like it could be an issue with cleaning up large amounts of memory use. Might be interesting to see if you can figure out where the breaking point is (that is, how many items you can load before the issue occurs)

I suspect that this is indeed the case, that it's the cleaning up that causes the issue.


Hi Lennart,

Sounds like you have two solutions tried and the solution you need is maybe some hybrid solution.

You need to limit the amount of items in the list,but then you still want your users give a feeling they can quickly scroll from A to Z. 

Someone else already did came accros your problem and tried some alternatives to make it perform better:

https://www.outsystems.com/forums/discussion/42220/outsystems-mobile-list-slows-down-as-user-scrolls-down-with-scroll-ending/

There is also a topic on large list Optimizing the loading of lists in Mobile Best Practices that you can look at

https://success.outsystems.com/Documentation/Best_Practices/OutSystems_Mobile_Best_Practices

Did you ever use a windows mobile phone? I had and it would represent a screen with only A - Z by the press of a button, then pressing a letter it would jump into the list. Maybe that would be an alternative UI pattern that can help you beat the performance problem, by not let the user just scroll but quickly jump to a letter in the list.

Regards,

Daniel

Hi Folks,

A bit interesting discussion & appreciate good sharing of Daniël Kuhlmann.

Well the below is not an exact solution but just an addition to the same from my side:

Even when it comes to Native Platform for showing a Bulk List of Items either consisting data or a List-Item with Image; which is more heavy although. It is always a recommendation & standard practice to use the RecyclerView in Android & TableView in iOS, rather than using the normal ListView.

The difference of the Recycler/TableView compare to the normal  ListView is, ListView create a particular View for each List Item, no matter whether it is 100 /1000; even though if you are using pagination which is a different topic.

And this methodology results in a major consumption of Application memory which is initiated by the ROM of Device for our particular app & thus the App show APNR i.e sometimes called App Not Responding & it gets crashed/closed. And as of in your case, it Images so. Imagine the Pain!!!

While on the other hand the RecyclerView/TableView generate the view only for the 'X' number of List Items which are displayed on UI Screen Initially, Probably it ranges between 10-20 Max. Now when you scroll up to see more List Items, the beauty of these components is Instead of generating a new UI View for the Further Rows it start re-using the same view which is generated Initially & that's how no matter you have 1000 rows but at a time there's only 10-20 Item view generated & resued.

  • Now coming to the Image loading, you can try to show the thumbnail i.e small image instead of loading a full actual image coz that will hold more size compared to the thumbnail.
  •  Find how to configure LargeHeap in Manifest Settings for Android/iOS on Outsystem, so that you will get more memory than normal allocation.
  •  Try to implement with Pagination perspective like, showing 20 records at a time & then reloading the screen before you load the further 20, this way you can release the existing records & memory can utilize effectively.


Hope it helps,

Assif


Hi all,

It seems like I was able to tackle the issue. In the end the list itself with the images remained the same. I noticed that the crashed happened when I went to the previous or next screen. For this we used a webblock that determines to what screen to go. One of the options van 'Previous Screen'. My suspicion is that in order to be able to use this screen, the app holds it in its memory or something. I've replace this webblock with normal link or a normal action, and this seems to have solved the issue.

@Assif: When you use a List and each row uses the fill width, it seems to optimize by using virtualization of the list. Only the records that are within the viewport exist in the DOM. This also makes the list mucht lighter.
Furthermore I don't think it's possible to use LargeHeap in iOS, only in Android (as far as I could find)

@Daniel: We have this vertical alphabet-bar next to the list. We optimized it before to act as a filter, but they didn't like this. Now it links to anchors in the list. 

Thanks for thinking along!

Hi Lennart,

Nice you could solve it and thanks for the feedback.

Regards,

Daniel