Is there/what is the point where performance becomes an issue? The app I am working on is going to have over 200 tables (95% of which will be used for filling out forms in the app) and each will have between 50 and 200 columns in them (most around 100). Is this too big to work smoothly on phones? Should I figure out ways to break this into several apps? Any suggestions?
Yes, I strongly recommend to break it into several apps; I would be personally reluctant to work on an AppSheet app with more than maximum 15~20 tables.
I worry that your app or apps may be too complex. Consider what happens if you leave the project and someone else has to step in. Perhaps there is some redundancy than can be reduced? One place to look is tables that are nearly identical except for the who uses them or how or when they are presented. Such tables might be combined and other means used to affect how, when, or who sees them.
@RezaRaoofi Thank you for the reply. That is kind of terrifying, because I don’t know if I’ll be able to break it down that much. That is a lot of different apps that our guys have to keep track of and a number of the tables would have to be used by each app. Has anyone else had a different experience?
+Steve Coile I completely get what you’re saying, and we will be combining/reducing tables as much as possible. The apps aren’t really “complex” they are just collecting a lot of data.
These are all check lists for custom pieces of equipment and each column represents something that our field service personnel have to check. Each piece of equipment has at least two check lists (a dry check and a wet check). More than half of the questions are simply Yes/No.
Not a trivial problem to solve, to be sure.
One workaround that I have used few times… if all your fields are text fields even if the value is a number, you could do your app with one table only if you set the size like 200 columns (the maximum). If you now create a template table where one record is your form with all it’s questions, you can read the questions with the deref formula into your “Display name” field.
What this would mean… you have one app with two tables, template table for form’s questions and one for responses. You can even use separate dropdowns for your questions form by form. And when you need to create a new form, just add one record to your form table and it’s done.
What you should think about more is are you able to handle the data amount with the spreadsheet or should you use SQL for this app.
I strongly support @RezaRaoofi’s original reply. Let me pose the question this way — let’s say you had a business with 200 different forms to fill out, each of which has approx 100 questions and is printed on paper. Would you print them all in one massive booklet? Or would you print them as separate forms? If it is a massive booklet, it would make sense only if all the forms have to be filled out by each user every time. Otherwise, in any specific scenario, if the person only needed one or two forms, then you’d make sure that those are together. Right?
Apply the same principle to your software. That is what you get by breaking the “single” app into many different apps. You can still have a single entry point (an app launcher) that lets the user install just one thing. The first step in the app would be to choose the scenario (i.e the sub-app) and then that would contain just a few forms for a particular scenario.
The best user experience, especially on mobile is to have the smallest number of options that are specific to the problem being solved. It also leads to a lighter and faster app.