How does Tab Visibility work in the sense of Data usage?
Do tabs that aren’t visible get downloaded in advance?
Here is my dilemma. I want to add a new type of user in the app. To be more specific, I have implemented a paywall (kind of). Currently there are free users and premium users, based on whether they have paid or not.
I’ve added a discount code, and I want my Special users to bypass the paywall without paying, and without getting through the stall that exists between paying and refreshing the app.
The easiest way would be to duplicate my tabs and play with visibility, that’s why I ask the initial question.
Last thing. Given the paywall, where once a payment is made, the row’s info is disseminated to my User Profiles, and some seconds/minutes later, the related visibility in the app is changed. What’s the quickest way to detect a payment and apply changes in the app?
I’m not really sure about the connection between tab visibility and data usage. I think when you access the app, all tabs are “there”, and being visible/hidden based on your tab visibility.
The data is the part that depends on your settings (let’s say row owners/roles) so it gets “downloaded” or not, to the user’s device.
So as long as you construct the right tab visiblity, it should work seamlessly. What’s the payment method you are using for this?
My app has much content, which every user can access, e.g. images. Is the data usage heavier when I have more tabs, even if they are hidden? Cause I want to decrease the loading time (& data consumption for the app). If I duplicate the tabs and play with visibility, I want to avoid duplicating the downloaded data.
As for the payments, I have used Stripe. Once the payment is recorded, I transfer a TRUE/FALSE to a sheet that is visible in Glide, read user’s TRUE/FALSE and change the related visibility. It does take some time to happen to be honest.
It doesn’t make any difference. The data will still be downloaded to each users device, and just hidden or shown based on the visibility settings.
The important thing to understand here is that all the logic that you build into Glide - tab/component visibility, computed columns, etc - is applied on each users device. This is one thing that makes Glide apps especially snappy and responsive.
The only way reduce the amount of data that is downloaded (other than removing it from the app) is through the application of Row Owners. As row owners is a security feature, it protects the data such that each users device only downloads the data that they have access to.
I have applied Row Owners from Day 0, but it’s a content app, so the main volume of the content stays the same. When a Row Owner accesses another sheet through a relation, this means that only the data they have access to is downloaded, right?
So, let’s say that I have images + audio, and up to 4 nested levels in the app. Imagine a structure like Tour → List of Spots → Stories → Audio + Text. All levels have images (recycling the same ones, about 100), only the last one has audio (about 100).
When a user loads the app, how is the priority of what is downloaded defined? Which levels etc.
Row owners only applies to the table it was applied to. If a relation in a row owner table relates to a table that does not have row owners, I believe it will cache the entire related table, even though you may only be viewing a select number of rows. As far as I know, all tables that are used by the app are synchronized to the user’s device when the app is opened. Computed columns may not compute until needed by the app
As for media like images and audio. I believe those are cached as needed and only when visible on the screen.
Since I merged the payment question under this topic, do you think that there is a quicker way to detect the payment and change the visibility in the app?
Quicker than the one I describe above
@Robert_Petitto, I have implemented a solution that you have described in another topic. Thanks for that! Have you found any better way to “implement a paywall”?
I haven’t…currently, the only way to connect a third party (like stripe) to Glide is through Google Sheets. The round trip from Glide to Stripe to Sheets and back to Glide takes time that really can’t be reduced.
If Glide were to build a way to have a service like Zapier or Integromat talk directly to a Glide table, then it would be near instant.
I’m not sure if you were directing part of that question to me, but I haven’t worked with payments myself. My thoughts would pretty much be the same as what @Robert_Petitto said though.