[Offline Apps] How to speed up offline render?

[Offline Apps] How to speed up offline render?

Forge Component
Published on 2015-11-19 by Labs
26 votes
Published on 2015-11-19 by Labs


I have a page with offline record list and it is working fine however it takes long to render the page. The version of page with normal elements (without offline components) renders almost immediately. Is there a trick how to speed it up ?

Thank you.



Hey, Nick,

The Offline Apps component has some limitations in what concerns performance. But if you're willing to sacrifice some completion on the screen load, then "OfflineLoadMore" might just solve it for you.

It generates a link to fetch additional records to add to an Offline Table Records. If you need to automate this and load when you reach the end of the screen, have a look at this and make it click the LoadMore link.

Would this solve it for you?

Carlos Simões

Hi Mykola,

Just to add to what Carlos said: since record lists are built by the browser using JavaScript when using Offline Apps, the amount of records displayed impacts performance directly. It is not recommended to render large lists; search functions should be used instead, to keep the number of rendered items to a manageable size.

Hi João and Carlos, 

The problem is that I have a small list and even with 2-3 records it's pretty slow. Other screens are fast, but probably because on this particular screen there are 3 REST_records list  are combined to get data from... 

Mykola Tkachenko wrote:

Hi João and Carlos, 

The problem is that I have a small list and even with 2-3 records it's pretty slow. Other screens are fast, but probably because on this particular screen there are 3 REST_records list  are combined to get data from... 

Hmm, that might be it: if you're using 3 different REST endpoints and combining the data from them, why not try to create a customized end-point which would do all the logic server-side?

I predict this will create a new entity on Local Storage, which in turn will create a corner case where this dataset will be off-sync in relation to the original entities. If this is not critical, then it might be the solution for you.

If not, can you be a bit more specific on your set-up? I got that you're joining 3 different REST end-points, but maybe a bit of context would help understanding it.

Best regards,

Carlos Simões

I have a list of items that have related items list with logos and another related list with feedback with categories .. and there is some logo images (optimized) stored as base64 in REST lists... 

So initially on screen there is only basic information dispalyed and when user clicks on certain buttons it shows list of related items or feedback items list...  first I've tried to combine that in one huge record but got lots of problems because of custom structure bugs (some names became corrupted - first letters truncated for example) so I've ended up having three lists for each data type. 

As the lists are dynamic it's not possible to have separate screens for each item "details" list as there was a problem passing a parameter in offline mode. The hash parameters # seemed to work only with simple data structures like record details screens.

but when screen is loaded its very fast in displaying data and custom js processing (search in REST lists for example)

PS: just in case - it is all version 9 . Maybe in version 10 there is no such problems, but we didn't migrate yet as there some problems with our third-party cordova plugins...

Is that a normal behavior of Ready state change event?

...so I take it is not a viable solution, then :\ . If doing details in a separate screen is not an option, then trying to overcoming the issues you had getting a single REST endpoint to work would be the best choice. (we usually call this scenario "master-detail")

This, of course, if you're not willing to wait for OutSystems 10 to arrive. You would need to build a new mobile application from the ground up, but the good news are:

  1. A LOT LESS JavaScript to perform trivial tasks, such as conditional formats, data refresh, etc...;
  2. Screen navigation is going to perform a lot faster: all Mobile applications are built according to the SPA paradigm, which removes quite a lot of network latency from the equation;
  3. Offline data will be both easier to develop, as well as more flexible, since every screen would be able to have a different aggregate to populate its data.

Regarding this master-detail scenario specifically, it may not be 100% direct, but it'll be definitely simpler than what you'd have do with Offline Apps.

Best regards,

Carlos Simões

Hi Carlos,

I agree that v10 is the best solution here and we definitely will use it. It seems that we are managed to setup plugin that we need so looks like we will migrate smoothly:) 

Anyway thank for your hints as we might still be working with version 9 for some time.