Tablet App Local data list pagination - No acceptable solution
Application Type
Mobile

We are currently building a tablet native app that used offline data sync. In one specific scenario, we want to use a table that uses the local storage data with the pagination functionality. 

So far, so good, but what we identified was the aggregate functionality for local entities doesn't have the "Start Index" input, only the max records one. This makes this task really expensive in terms of performance because since there is no way to select the start of the index, to apply the pagination, we would need to fetch all records (max records = count) and then iterate the result to show only the Nth page. 

In this case, the infinite scroll is not the best UX option. That would not work well with the UI we have, especially since it's designed for landscape usage. It has fewer visible rows, which will ask for lots of scrolling.

It seems to me that this is a use case that the platform does not support. All the examples are done against server aggregates that have that start index parameter.

I opened this thread to validate if anyone faced the same situation and found an acceptable solution. If not, it will be opened as an idea.

Solution

I ended up using the alternative I proposed. When the page number is clicked, I created a cycle to iterate and remove the first N records of the aggregate.

For those interested in the feature, I've created the idea for this functionality here: https://www.outsystems.com/ideas/10281/add-the-start-index-parameter-to-local-storage-aggregates

Hi Marcio,

how much local data are we talking about ??  Do you actually experience slow performance. 

I guess you'll have to brew your own Startindex and number of rows to fetch, but are your users really going to use pagination to the end of your data, performance on first pages can be fast, and only will slow down when retrieving data at the lower end of your data collection.

So have you tried something like, showing a localList on the screen, using a maxRecords on your aggregate of Startindex + RowsOnScreen, and then in the onAfterfetch do a foreach with startindex and maxiterations to copy the ones you want to the list that is shown on the screen.

When I try this on my phone, there is no delay at all for first pages, when using startindex 30000, i see about 1 second.  Of course on server, there is no delay, even for 30000.

Dorine

Hey Dorine,


Yes, that is my proposed alternate solution. The results will appear immediately if the device is quick enough, but the approach is far from ideal. We're talking about retrieving all the records of the local entity and iterate the list to remove the ones that are on the previous pages. The alternative, with the Start Index parameter, would be to query from the database just the records that are displayed without any iteration. If the entity has 100 records and each page has 10 rows, we would be fetching only the 10 rows instead of fetching the 100 then iterating (page number - 1) x 10 times.

I know that most projects are relying on the infinite scroll approach. I'll wait a bit more to see if we get more members with the same pain, to decide if I should open an idea with this.


Thanks! 

Yes,

But it´´ s not really iterating, the Foreach has a startindex as well, or you could even index into the aggregate result n times instead of using a foreach.

I think the startindex not being available on local aggregates has probably to do with limitations of local storage not being a full blown DBMS, so even if they offered it on an aggregate, under water they´ d have to do something similar.   

Solution

I ended up using the alternative I proposed. When the page number is clicked, I created a cycle to iterate and remove the first N records of the aggregate.

For those interested in the feature, I've created the idea for this functionality here: https://www.outsystems.com/ideas/10281/add-the-start-index-parameter-to-local-storage-aggregates

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.