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


We just had this happening and we fixed it by changing the version of MABS from 6.1 to 5.2. 

Hey Brett,

You downgrade to MABS 5.2, which is about to obsolete by end of april & it's been deprecates already.

Better you should use MABS 6.1 i.e the latest & most important it's stable when it comes to uploading your app on Appstore.



assif_tiger wrote:

Hey Brett,

You downgrade to MABS 5.2, which is about to obsolete by end of april & it's been deprecates already.

Better you should use MABS 6.1 i.e the latest & most important it's stable when it comes to uploading your app on Appstore.



Conceptually I agree with you. A little background first. I manage a center of excellence and our older version of MABS (5.0 i believe) stopped working for developers sometime over the weekend. The developers were complaining that the app would download and just stay grey on their devices. So I went ahead and upgraded to MABS 6.1. The app would complete the download but when users tried to open it, it would crash immediately. I noticed that MABS 5.2 was still technically supported to i tried it. It solved the issue. So i may have kicked the problem down the road a bit but my users have a working app right now. 

Question: Why is 6.1 crashing and 5.2 working for them?


I do agree it's a bit tricky to move with MABS versions coz you have to make sure that every plugin you are using is supported n at the same time stable with Mabs version you want to use.

For instance in my case last month I was ready but didn't move from mabs 5.2 to 6.0 coz of one plugin not stable.l, but now we are using the latest mabs 6.1


Now in your case the app was getting greyed out.. I too faced this kind of issues in past n for this we need to refer the logs, to fix the issue.


Sometimes it can be Incompatibility of plugin due to conflict or instability of plugins with the mabs version.

Specially in most cases the plugin are the root cause when u see issues while upgrading mabs, because forge plugins are also published by folks n most of the time they maintain as per there availability.

You can give a try with mabs 6.1 n lets see how it goes with you.

Hope we will try to find a solution for u.

Else, anyhow in future you will stuck coz once a mabs version obsolete then even OS support will tell you to upgrade..