Is it possible to stress test a app?

[John_Pearson]

I am very new to app building and it might be a silly question but -

Is it possible to stress test appsheet apps to see if they will crash? I’m in the electrical service industry. I have 200+ questions I am requesting from my workers that is laid out on appsheet and I ask them to do inspections and report their findings back via the app. I am noticing small little hiccups/bugs on the app and I’m wondering if I might have gone over the top with asking the app to do to much? I personally don’t think so but my lack of experience in performance testing app’s is nil.

Is there a bandwidth test or trend/graph or performance test I can run or specifications that shows if I have to much information on the app?. I don’t know what the limitations are or how far I can push an app to breaking point and accurately measure and prevent when a app crashes.

Im assuming because appsheet is on the google infrastructure, it can take a solid beating before it crashes, starts slowing down, bugs appear, data loss etc etc etc? I could be wrong…

Any input from anyone would be greatly appreciated! Thanks

John P

[Aurelien]

Hi @John_Pearson

John_Pearson:

Is it possible to stress test appsheet apps to see if they will crash?

It won’t happen

John_Pearson:

Is there a bandwidth test or trend/graph or performance test I can run or specifications that shows if I have to much information on the app?

You may want to have a look on your app performance. Here:

John_Pearson:

am noticing small little hiccups/bugs on the app

Can you be more explicit about that ?

[John_Pearson]

Hi Aurelien

That is exactly what im looking for thank you so much! I’ll do more research on it later!

JP

[John_Pearson]

[1minManager]

My best guess with this is that the column type is changing because your slightly changing the column name in Row 1 of the spreadsheet. If you do this, then a regenerate, this would make appsheet treat it like a new column. So it would evaluate the date and give you a column type.

Sometimes if Appsheet decides that ENUM is the correct type to pick, it will also populate the values you see above.

“Auto-complete other values” means that in the ENUM choices will be a list of all unique items ever entered into that column.

Its not really a good idea to use such long column names. If I was building an App like this I’d just call the column Q21 and then type the question into the Display Name setting

[John_Pearson]

[Rafael_ANEIC-PY]

Hello @John_Pearson, I have never heard of columns resetting their configuration on their own, but I’m not familiar with working with 200+ questions (columns) on a single form, if there’s indeed a loss of information, I suggest you contact support.

[Aurelien]

Hi @John_Pearson

I fully agree with @Rafael_ANEIC-PY , I didn’t want to send you to support directly before knowing what is your issue, but this is definitely a bug.

[John_Pearson]

Hey Aurelien and Rafael

I just want to be clear. The google sheet questions do not lose the data.

The data is lost in appsheet program where my red arrows are pointing (see screenshot above) when I regenerate the data on google sheets when I am including/amending/relocating data.

I understand its an extensive form because I am looking for very specific technical things in my line of work. Appsheet has been fantastic for me to get away from paper and getting quicker reporting back from the frontline. I’m was just a little concerned I will crash it if I push it to hard; hence contacting the appsheet community.

If you still agree it is a bug then I will contact appsheet directly and ask what is going on.

Thanks guys!

[John_Pearson]

Hey Simon

That is a interesting point! I’ll be sure to review what I have done. I might have a reason to why I am seeing this “bug” now.

It would be more likely that I am doing something incorrect. Calling it a bug might be a bit of a stretch ha

Thanks again. Im checking your website out now

JP

[Rafael_ANEIC-PY]

If you’re working on google sheets, I suggest you try out the “show edit history” option for investigating your columns headers that could have been changed, if there was ever a change done to it, you’ll find it there.

[1minManager]

Added to this, also look for column names in Row 1 that use a formula to generate the name

[John_Pearson]

Awsome! will do. thanks everyone!

[SkrOYC]

Just to add to the conversation.
Column names should be just a great name to use on expressions. In my case, hardly ever they are descriptive and almost never it’s more than one word since I don’t use spaces.
A common structure of mine is something like this:

Column Name	Type	Description
ID_NAMEOFTABLE	Text	The Key for this row. I use ID_ at the begginning to know that it’s the primary key of the table that comes after it.
A_RANDOM_NAME	Text	Any other column should have a short name to just identify it from the others.
SERVICE	Y/N	I use short names for some columns, like YN, but you could add a ? at the end to remember it’s Y/N type.
NAMEOFTABLE_SHOW1	Show	I use this method for Show columns. Adding the name of the table and the number of the show column to make sure I order it correctly on forms/detail views.

This is a very short example of how I do things after trial and error in my time with AppSheet.
You can find really good info on the docs page about this an other info

help.appsheet.com

Columns: The Essentials

Once you have tables in the editor, you can use the Columns tab to categorize each column and give it a role in the app.

The docs are a little bit outdated but the info is fine in general and can be applied. AppSheet Help Documentation outdated

[MultiTech]

If anyone’s curious how to do a Stress-Test for your app:

Short Answer

• You can, but you have to do it yourself

A stress-test involves creating a TON of sample data for your app

• On an order of magnitude larger than you would ever expect
  • That’s what you’re shooting for: overkill

Then you just open the app and see how long it takes to load, press some actions, go through the motions of using your app… but doing so now with a boat-load of data.

And in this way you can stress the system you’ve built and see how well it handles everything.

[Steve]

Regenerate columns can be dicey because AppSheet is going to analyze your spreadsheet each time, to try to determine what the column types should be. The logic it uses is opaque (we don’t know what the logic is), and it may change over time as developers try to enhance it. It will also be affected by the data within the spreadsheet. The decision AppSheet makes about a column may change as the data in the corresponding spreadsheet column changes.

You have another, bigger problem, though: a single form with 200+ columns. Unless you specifically design your app for it, the user will not be able to save their form until they reach the end of it. If the user leaves the app or lets their device go to sleep, there’s a very real possibility the unfinished form will be lost when they return. Ideally, a form should be easily completable in a short amount of time. If not, you should consider other approaches to capturing the input.

[John_Pearson]

Hey Steve

You’re absolutely right and it’s something that has been sitting in the back of my mind. I’ll review what I am doing again and again and again and see if I can break it down further.

I very much appreciate your input because its a valid point.

Thanks

John