We have some extra contact with the team but we are still just users in the end trying to make user friendly apps that have the flow and features we want. We can only express our wishes, and that’s about it. Glide ultimately makes the decisions, and I fully respect that.
Yes this would fundamentally reduce the number of updates and potentially Glide’s bottom line, but at the same time, many of us are trying to create workarounds to overcome certain shortcomings, by building things like Custom Forms, Custom Search, or real time calculators. To add…even though Swipe and Stopwatch are not overly popular and may or may not make it to Pages, I feel that there are certain cases where the swipe date or stopwatch start and duration values don’t necessarily need to be stored permanently in the database, but those values are required just to function.
I use custom forms in situations where native forms just don’t provide the functionality I need. I explain why in this post. Mastering the Mighty Single Value → WHOLE ROW - #17 by Jeff_Hager
I would gladly use a native form if it provided real time access to relation/lookup data and computed column values that I could then turn around and use to write directly to basic columns when I click on submit. Or in my case, the ability for a choice component to write BOTH the displayed and underlying value to the table.
I have a stopwatch in my app just because I can (even though it’s not really used). I don’t need the start and duration values for anything. I just wanted a functioning stopwatch in the app. If I ever wanted those values for anything, I would most likely have a button with an Add Row or Set Column action to permanently save the values…but I don’t. The stopwatch runs locally anyway, so why would it need to store anything in the database. I’m not saying this is the case for everyone. Sometimes people need those values in the database, and in those cases a Basic or USC column would be more appropriate.
Unfortunately for me, the use of custom forms, and the use of the stopwatch causes extra updates to occur. I could care less if the values are stored in a table, but I need them temporarily to get the functionality I need. All the work is being performed on my device in these cases and doesn’t really need the server to be involved. In the end, my custom form performs an Add Row or Set Column action (which should then understandably incur an update because I’m permanently storing the data). My stopwatch in my case has no reason to permanently store it’s values. Fortunately for me, I only have one fully active user, so I’m not over concerned about hitting any limits, but I also don’t think I could reasonably scale to a much larger number of users.
If certain data is only needed on the local device for a short period of time, or at least the duration of the session…and it doesn’t need to be permanently stored in the table on the server, then I see no reason for the extra overhead to sync and store the data long term.
I think there would be multiple benefits.
- Less syncing of data and communication with the server. Less bandwidth.
- Values that reset automatically whether you are signed in or not. Maybe a custom search that does hold on to your last search value.
- More freedom to build custom functionality.
- Maybe a mild security bonus, since the developer will never be able to access and see the contents of session variables.
I think the hardest part would be conveying to the app developer that the value entered in a session variable column will never be stored permanently. They would need to understand when and when not to use them. I think it’s fair to say that there are use cases when you need to use a Basic column (including USC), as well as cases when you only need a Session column (only ever used locally on the device).
My goal isn’t to score free updates. I respect Glide’s business plan and their target audience. My goal is to make it easier to expand the functionality of my app without the fear of being penalized for thinking outside the box. USC columns are halfway there when you aren’t signed in. Why not fork that ability to a different column type that acts the same way whether you are signed in or not.
Done ranting.