LinkedIn
Twitter
I’ve noticed that many of the official sample apps from AppSheet are NOT built using good practices.
Take the “Workstation Tracker” sample app, inside I’ve found the following “bad practices” on one table alone
- The RED outlined VCs shouldn’t be VCs
- The GREEN outline VC should use a (slice)
- The “Related Distance Checker” columns don’t need to be REF’ed
The RED outlined VCs shouldn’t be VCs
- They should be physical columns
This is because they don’t contain data that changes dynamically; the data they contain only change based on changes to the record.
- When you’ve got data points like that, you don’t store that computed value inside a VC - you store it in a physical column with an app formula.
The GREEN outline VC should use a (slice)
The Occupied column uses a brute-force SELECT() (ported into a FILTER formula) to pull any ongoing workstation checkouts.
- This should instead be a REF_ROWS() to a slice of the ongoing workstation checkouts.
When you implement a (slice) to create a sub-set of data like this, AppSheet uses internal systems to increase efficiency when doing all the “sorting which child records go with which parent.”
- If you leave it with a brute-force SELECT() like that, you’re forcing the system to work harder than it needs to
The “Related Distance Checker” columns don’t need to be REF’ed
I assume the “Distance Checker” table was implemented before enum base-type refs were a thing. The references on that table should be replaced with enum columns to remove the unecessary reverse references inside the workstation table.
These are the problems I’ve found with just one table in one sample app.
I wouldn’t assume that what you see in an “official sample app” is necessarily the “right” way to go
- Same can be said for “unofficial” sample apps too
That being said… I agree with @Steve - using actions for your external links is definitely the way to go.
