I’m looking for best practices for multi-person development in AppSheet
For example, one person can set up a column while another member creates a View at the same time.
Currently, I think there is a version conflict when two people open the Editor at the same time and work on it.
Are there any plans to update AppSheet to support multi-person development in the future?
Or is it better to think of it as a platform for single person development?
Solved! Go to Solution.
One thing I’ve learned over the years; there may be best practices in general - but there’s never a one-size-fits-all for every scenario, there’s an element of customization and adaption.
Not possible. Only one person can be modifying a given app at once.
Not to my knowledge.
Yep.
As a workaround and from my experience, it can be wise to make multiple apps instead of one very big app.
This way you can also give responsibility to others for certain specialized apps.
Thank you @Steve @Ratatosk
Your findings always light the way for me to go.
it can be wise to make multiple apps instead of one very big app.
That’s one best practice.
Table Specialist
appA table setting → appB table setting → appC table setting
View Specialist
appX View setting → appA View setting → appB View setting
We’ll keep working on ways to make AppSheet fun for the team!
Granted there are a few use cases where having a dedicated simple data-collection (or display) app is helpful.
I’ve often included a table directly inside the app that fellow app builders can flag when they’re working on an app.
So if you’re going to have a multiple people working on an app, you need some way of people to indicate to others that THEY are working on that app.
I’ll make use of a Current_User system, and have a flag on the user record that people can set - this then causes some view to show (for dev types of course, not the normal users of the app) letting them know someone’s editing the app.
It depends.
If you have as me, 20 different sheets that takes on different tasks, but all is under the umbrella of my company, it’s quite critical for us if everything breaks and people in the field don’t get the information they need.
When a problem is reported in, it’s much easier for me to find the problem in a small app, than in a huge one, even if some use the same spreadsheet.
To have 90% of the “app” working fine is better than 0%.
A very good point; brings to mind that saying, “don’t put all your eggs in one basket”
Hi @MultiTech_Visions , @Ratatosk
Thank you for sharing your valuable insights with me.
For me, I am impressed by all of your experience-based development policies.
So, please forgive me that I am not in a position to judge which one is the best solution.
I would like to try both of the methods your mentioned, splitting the application and using Current_User.
Thank you for giving me a lot of information to find a better team development style.
One thing I’ve learned over the years; there may be best practices in general - but there’s never a one-size-fits-all for every scenario, there’s an element of customization and adaption.
@MultiTech_Visions
That’s it!
I got the ultimate best practice!
User | Count |
---|---|
33 | |
29 | |
29 | |
20 | |
18 |