I’ve always thought that it’s really useful how user specific columns only store values locally and for the duration of your session while you are not signed in. This allows for those column values to “reset” after you close the app, and the data does not need to be sent and synchronized with glide servers. However, once you sign in, then those values are sent to, and stored, on Glide’s servers.
I think a new Session column type could be really useful. It would work just like user specific columns do when you are not signed in, but would never synchronize the value with Glide servers regardless if you are signed in or not. Even if you were signed into the app, it would still only be stored locally, and would reset once you close the app.
I think this could be really useful for something like a simple calculator, or for some kind of searching and filtering function, or to display a splash screen or notification every time a user initially opens the app. Sometimes it might be good to actually reset those values when a new app “session” starts, even if you are signed in.
I think the biggest advantage, would be that it would lighten the bandwidth load on Glide’s servers, since it would not have to sync the data and only store it locally and temporarily. With all of the custom forms, calculators, filtering, and what not, it seems like we are synchnizing a lot of data that just doesn’t need to be stored permanently. And maybe it would allow for some improved offline abilities, if we are allowed to update those values while offline.
I created a calculator for my app that helps with the administration of weight based medications and the only reason that I need user profiles is because there’s no other way for users to access it. Having the opportunity to create a single session - whether it be temporary or for extend periods of time - would help me out tremendously.
Well, you could still use a single row table with user specific columns in this case. You are not required to have user profiles set up to use user specific columns. With a single row table, every user will use the same row, but with the user specific columns, everybody’s values in those columns will be unique to them.
What I’m describing in this request is similar, but a little different. I’m hoping for columns that never store values long term in glides copy of the database. There was a recent post with a user asking for a splash screen whenever the app is opened. This could be easily done with a user specific column that, when set with a value, would hide a tab or screen that would be acting as the splash screen. When the user closes and reopens the app again, ideally that splash screen would display again (because the user specific column is cleared). The problem is when a user is signed in, then those user specific values are stored permanently in the database on glide’s server, so you could never get those values to reset on their own.
What I’m asking for would eliminate that unnecessary synchronization of user specific values to the glide server, even if a user is signed in. That way, they would reset whenever the app is closed and reopened, and I would assume that it would reduce the synchronization traffic between glide and the end user. I think in some cases, there can be rapid and frequent changes to the values in the current user specific column. If a user is signed in then there is a lot more traffic to sync that data from the end user to the app. I think there are cases where that sync really doesn’t need to happen, but you still need the user to be signed in.
With the change in update pricing, it has become imperative for Glide to find a way to store “session variables” – which would be User Specific Columns (USC) – on the local device, never to be synced with the databases.
This is not just for swipes, though that is the scenario most frequently given. I have apps that use USC to track menus and “last field used” – to make data entry easier for the user.
In addition to avoiding updates for what are essentially session cookies, it avoids the need of having to purge these types of fields as users drop off – delete the app from their device or whatever.
I know a LOT of Gliders like to use session cookies for visibility conditions. For example, I have a custom form that “pops up” (all other tabs are hidden) to notify users of a special event on a day. Once the date is passed, or they “dismiss” the window, it does not show again. The “dismissed” is stored in a USC, but there is no reason for it to be stored in the database.
Please implement “session cookies” that can be controlled and referenced by the App or Page.
Even “favorited” columns “is favorite” should be able to be stored as session cookies. Think about an app that is used for a conference. Once the conference is over; most users will delete the app from their devices. But that app can be re-purposed for the next conference and not have the baggage of all the orphaned USC from conference to conference.
I was thinking something local, but only for the duration of the session, but I like the idea of something that may be a little more persistent, at least until the browser cache is cleared.
I think there’s definitely a case for local variables that don’t need to be stored in the database.
Is this gonna see life anytime soon. There must be a way we could have session or user specific data that doesn’t count towards the updates count.
There is no other reasonable way to show users customized/different edit forms and detailed screens. (except new screens)
which itself is a disaster as long as there is no option to save a screen and use somewhere else or with other components.
Also agree. This causing major issues in some of my projects, where they need filter at multiple levels. I can calculate the other edits and get the price correct, but how a user will filter is very hard to predict and unless you really push up the price to build in margin, it leaves you with huge risk factor.
Is this request dying? Have users found any alternative solutions?
It was beautiful using Multiple filters in our apps, allowing users to filter a list by clicking on choices above the list in a detail view.
Has everyone replaced this with loads of custom new screens , or is there some other new design advise?
I personally have removed 99% of all my custom filters and have only relied on the built in one. Honestly there is no point to custom filters outside of a form as 1 person could just play with it and eat up so many updates.
I also made adaptations to my app to avoid updates – but we are effectively needing to ‘downgrade’ the user experience.
I had to get rid of my nice custom menus (every time they select a different option, I need to record where they are). There are just so many areas of the apps that rely on setting flags for this or that but don’t need to be stored in the database or persisted beyond the user’s device.
This is a must especially with the updates metric. It’s (updates) a "creative mind killer. Everytime you get an idea about a feature, you have to think about the effect of the updates and what it will mean for your bottom line. I had to remove all the filters using choice components because it was just not viable to have it there. Unless Glide addresses as many of the feature requests as possible, the updates thing will just keep being a pain for all of us regardless of the plan you are on…
In this video, I change the values in the User-specific cells and they are not taken into account in updates. For clarity, I made one addition and it was taken into account (to check that the calculation is not late)
If you watch the video, you’ll see the changes are being made in the published App.
I remain a bit skeptical though. If Glide were going to change this, then I think they would have made it known. I suspect the update accounting is either delayed, or maybe it’s a bug.