Ensuring App Stability by Forcing User Syncs with UserSettings After Updates

[11198]

The app we developed requires continuous updates even after its initial deployment.

When performing these updates, such as adding or deleting columns or changing the table structure, errors can easily occur on the user's side.

This happens because, while the app on the development side is in its latest version, the user may be running an older version. If the user tries to add data using the old version’s table structure, the discrepancy with the new structure causes the action to be rejected, leading to errors.

To prevent these errors, it is necessary to ensure that users perform a sync.

Even if the app is upgraded during non-operational hours at night, as recommended, there is no guarantee that the app will automatically sync when the user opens it the next day. Therefore, users need to be instructed to perform a sync before using the app in the morning. However, in reality, users often fail to follow these instructions, leading to errors, which is a significant problem.

Based on my understanding, the following methods can be used to force a sync on the user's side, excluding the "Sync on start" option:

1. When the Sync button is pressed.
2. When performing Add, Edit, or Delete operations within the app.
3. When the UserSettings are modified and saved.

Pressing the Sync button (1) is practically difficult, and performing Add, Edit, or Delete (2) in an older version will lead to errors, so this is not a viable option.

I believe the only way to force users to sync is to implement a mechanism where something in UserSettings is modified.

For this, I propose adding a "Last Update Date" column in UserSettings and setting its formula to Today(). This way, every time the user saves the UserSettings, the current date is recorded.

In the View's "Show if" condition, use the expression usersettings("Last Update Date") = TODAY(). This will return true and display the View if the last update date in UserSettings matches the current date.

Conversely, when the date changes, the last update date in UserSettings remains as the previous day's data, while TODAY reflects the new day. This will return false and hide the View.

By using this mechanism, you can make all Views disappear after the date changes, making the app unusable until the user opens UserSettings, presses save, and performs a sync.

This ensures that even if the app is upgraded at night, users will be forced to sync the next day, thus preventing errors caused by table structure changes.

In practice, I have successfully used this method to significantly reduce problems.

I would appreciate any feedback on this solution or suggestions for better alternatives.

[WillowMobileSys · Accepted solution]

There could be one "gotcha" with this approach...

AppSheet has a feature where they will return a user to the last accessed view.  The functionality to hide views will not take affect until the user performs some navigation action once they have re-opened the app. 

However, if the user re-opens the app and there is some kind of data entry capability within that view (buttons, Form View, Detail View with QuickEdits, etc), that DOES NOT require the user to perform some navigation function first, the user can still perform (attempt to perform) edits, without a Sync, based on the old data structure leading to the same issues.

The best solution I have seen is to simply get users in the habit of tapping Sync each and every day before they begin using the app, just in case there might have been an app update for which they missed the notice.  The next best is some pre-communication to the users that a Sync is required the following day.

I will say that moving to a database has lessened the impact of these errors.  If the columns are added to the end of table schema, older versions of the app will continue to run just fine.  Once the new version of the app is deployed (in a Stable version configuration), I have only seen an occasional error where one or two users will get an "Invalid Sync Token" error message for some unknown reason (reported to AppSheet).  Most other users are Synced/Updated automatically using a force sync function. 

[11198]

Thank you for your response.

Indeed, the issue you mentioned could occur since the app might stay on the same View as when it was last closed. I appreciate you pointing out this potential problem.

As you said, instilling the habit of syncing every time in users is undoubtedly the best approach. However, with a large number of users, some of whom have low IT literacy, it may be challenging to ensure that they always perform a sync.

I don't expect this UserSettings feature to resolve all possible errors, but I believe it can be effective in significantly reducing the number of errors that occur.

Additionally, as you mentioned, adding a final column when increasing columns is another effective strategy to prevent errors from occurring in the first place.

Thank you for your valuable insights.

[イルカのえっちゃん]

There appears to be a way to set the length of your team's AppSheet session.
I wonder if a combination of the above method and Sync on start would work?
I have not tried this method as I do not subscribe to an Enterprise plan, but I hope this information is useful.

Configure team settings 

Now Available: Set Custom Session Length

[11198]

I’m also not using the Enterprise plan, so I can’t apply it this time, but I think the combination might work well.

Thank you for the suggestion.

[イルカのえっちゃん]

This video may be useful.

https://www.youtube.com/watch?v=bwNm5P4tks8

[11198]

Thank you for the great tip! This is an interesting idea as well