First, because these are web apps subject to Internet speeds, we need to think of the AppSheet apps as a view window into only a PORTION of the overall data. These apps cannot handle the ENTIRE dataset associated with large sets of tables. Therefore we have to be a little creative in how we present the data to users in these situations.
Having said that, there are two main culprits that affect the actual App UI performance:
- The amount of data being loaded.
- Virtual Column processing - especially any that performs iterative processing over large tables.
#1) Reduce the amount of loaded data
The very first thing I would concentrate your efforts on is reducing the amount of data that is being loaded into a users device.
I don’t know your app data and what that 160K records might be so at the moment I can’t give specific recommendations…so I’ll give some common adjustments that work for most people.
Most of the time a table with 160K rows is one that has been built up over time with a history of past activity AND generally users are only interested in the most recent records. The most common way to reduce the loaded data is to implement a Security Filter that loads only the necessary recent records. For example, a user may only ever need to access records that have been inserted over the past week, so instead of loading years worth of history for that table, only load in past week.
Another common example is analytical data and then creating a summarization of all the data rows for tracking trends in the data. For this type of scenario I would STRONGLY recommend building some back-end process that creates the summary table and then the app loads ONLY the summarized data. If a user needs to view details related to some summary data point, then implement the app such that only records within the area of the data point are loaded.
If you care to describe the content of your app and what the 160K rows represent, someone here in the Community would be happy to help with ideas on how to reduce data and improve the app performance for your situation.
#2) Avoid lengthy (or unnecessary) Virtual Column processing
If you don’t already know, Virtual Columns (VCs) are recalculated every time a Sync is performed which can significantly reduce Sync times. But VCs might also need to be recalculated whenever some data change is made that impacts the VC results - for example a new child row is inserted and there is some VC result that needs to change to immediately account for the added row. If these VC’s need to process over large tables, they can impact the UI performance.
UI performance can also be directly impacted by expressions, in column definitions or actions, that iterate over large number of table rows. For instance, if a column that shows a drop down list needs to make complicated decisions on whether a row is displayed or not and there are a lot of rows, that will slow down the opening of a Form view.
The good news is that there are always way to make things more performant. However, it can take time to identify those areas and implement an alternative approach.
Helpful Tip
In the Performance Logs, there are SOME details and app profiling that help to identify the areas that are most impacting your app. After considering tip #1 above, I would next concentrate on using this Performance log to find those problem areas.
I hope this helps!