Can I create a local store for my filter source data

[Griff]

I have been working on a dynamic data lookup and came across the sample app Slice based on user input which fundamentally does what I need. However I am puzzled about how to create a data source for my filter input.

That sample uses a Google based data source, presumably a spreadsheet on the cloud, to store the filter criteria. Since Appsheet syncs progressively, what happens if two users, use the filter at the same time - one enters criteria that is updated on the cloud while the other user enters different criteria. Surely I don’t need to create a different filter source (spreadsheet) for each user… Is there a way to create a local data source for an entry that basically doesn’t need to be synced, or is there some other protection in place that avoids this problem?

[Suvrutt_Gurjar]

@Griff,

Please explore if following helps.

In general , I believe one of the approach in such cases is to create a users table and assign one row to each user in that user table for such user specific data entry points. Each user’s row is assigned and accessible to only that user through USEREMAIL() expression, typically in the security filter.

However the settings data still remains in the cloud spreadsheet. All AppSheet apps use a cloud data source. If you have just a few user settings fields , then I believe you may use Quick edits in detail view for these user entries so that the sync is somewhat transparent to the user.

Hope this helps.

[Griff]

Thanks for your explanation. I understand the first option (USEREMAIL()) but not the second (use Quick edits in detail view).

All I need is a one field filter, a date. The idea is that the user selects a Week Commencing date and the display will list all the entries for that week. I was planning on using a Dashboard with the top part catering to date selection and the bottom catering to the display of related data in a table.

If I don’t do anything I could end up with two users selecting different weeks and the display listing data for whichever of the two dates gets synced. With the first approach you recommended I need to add an entry in the selection spreadsheet every time I give a new person access to my app - just another admin overhead. I am not sure how your second approach works. I was hoping there may be an easy way to create a simple filter.

[Suvrutt_Gurjar]

@Griff

Griff:

With the first approach you recommended I need to add an entry in the selection spreadsheet every time I give a new person access to my app - just another admin overhead.

Yes, you are correct. With user table , you will need to always add a new user to the table.

Also the second approach is not mutually exclusive to the first one. It is part of the first one. I request you to take a look at the following article. With quick edits, one can change the fields in the detail view itself.The sample app you referred does use the concept of quick edits.

help.appsheet.com

Quick Edit

How to use Quick Edit so that you can edit columns directly from the Detail view.

Another approach is to use user settings. In this approach , you do not need to add a new user to the user table. However I believe, the user settings need a full sync cycle and are typically used for longer duration persistent settings.

You may take a look at the articles below

help.appsheet.com

User Settings: The Essentials

Give users more control to customize app behavior.

help.appsheet.com

User Settings: Appropriate Use and Limitations

When and why to use user settings.

[Griff]

Thanks for then links and explanations.

I read the articles and, from what I can see the user settings option would seem to be a safer option with less overhead, however it has obviously been restricted. You can’t seem to create a normal view for it - only a menu item. Plus it comes with the warning “Changes to user settings will require immediate sync, which will not work when the app is launched completely offline”.

I have not done much work with Appsheet but it I find it very disappointing that I need to spend so much effort, both at design phase and later maintenance, on such a basic requirement as a user selection filter - and I’m surprised that none of the examples seem to raise this issue as a potential problem that needs to be addressed at design phase. Am I missing something or is this a common problem?

[Steve]

Griff:

Am I missing something or is this a common problem?

It’s a common problem for advanced designs.

[Austin]

How are you giving users access to the app? I have an app launcher that whenever I grant a user access to an app in the app launcher it creates a user with default properties in the user table of that app. Could also let the user make their user entry when they first load up the app.

[Griff]

Thanks Steve.

Austin, I haven’t got to that point yet but if we do adopt an AppSheet solution your approach makes sense - at least it does some of the maintenance itself.

At the moment I am still assessing the engineering risk associated with implementing an Appsheet solution to our needs. I tackled what I thought would be the difficult components first, and they were easy, but the remaining, seemingly simple, requirements appear to be very painful.

[Austin]

The joys of appsheet. What looks hard is easy and what looks easy can be hard.

[Griff]

One thing is becoming evident - it has a very helpful support community.

[Austin]

We have implement 3 major apps that replaced/do what we could not find for even remotely the same cost or flexibility and countless little minor projects that were spun up in a day while meeting the exact needs of users.
It’s a pretty good platform and very easy to integrate with others. But don’t expect the UI to look exactly how you want. I have 0 artistic ability and appsheet helps me not have to worry about that cause I can’t do too much about it.