Yes, indeed! But I can’t easily extract just the image to integrate in an html/css if need be.
My initial strategy to use Glide Table for User Profiles (and any table not complex to edit in Glide) was to stay within the 500 rows limits. As my purpose-driven app must remain Free. Which will be challenging to defend in front of my next project examinator, but I’m confident there’s nothing he/she can blame me for. I have a die-hard responses team : ME.
I have mixed feelings concerning the display of User Name: there’s always a pending time, even without any visibility conditions (at first I thought it was visibility latence). And other customized messages I compute with Template Cols in User Profiles: always a pending icon showing before display, which perturbs the overall layout - things that pushes one another - until every component is in place (you cannot specify width and height to stabilise the placeholders while waiting for everything to load, or preload before displaying the whole screen).
So if I use columns of User Profile, I’m afraid I’ll get the same pending latency and “perturbations”.
I would suggest avoiding Zapier and spent a little extra time learning Integromat. It is much cheaper, and gives you the option of running every minute for time-scheduled scenarios, rather than every 5 mins with Zapier.
Using Glide Tables won’t help you stay under the 500 row limit. ALL rows count towards the limit, regardless of whether they are Glide Tables or Google Sheets. All that matters is that they are used in your app, and they will be counted.
I’m afraid that you’ve lost me there, I really have no idea what you’re talking about
I don’t see what Zapier has to do with your question, so obviously I misunderstood that one.
ah, Ok So If the Row ID is fixed once and for all (without exceptions?), whatever the row edits, we can ref this row via url. But not a specific column by name or nth of columns count?
Here’s the loading latency of the User First Name.
It only happens on 1st Screen.
In the next one, the First Name (Ly-Mei) appears twice with sentences, and there’s no delay.
The difference is that there’s a IF THEN ELSE on 1st Screen, whereas the others ref Template Columns that ref this IF THEN ELSE (which should be slower, but are not, oddly enough). All columns are in User Profiles Glide Table.
Is that the first screen the user sees after signing in?
Do you get that same delay when you view the app on an actual device?
My guess would be that the delay you see is part of the initial loading and calculation of computed columns. Which would also explain why you see no delay on the next screen, as by that time everything is fully loaded.
What happens if you replace that name on the first screen with a basic (non-computed) column?
No, nobody needs to sign in to enter.
Yes, this is the very 1st tab of the app.
Yes, the behaviour is exactly the same on my phone.
I’ll pay attention to the case where nothing is computed.
Update 14 h 17 Paris Time: OK, I just tried: Your guess was a good one. If I remove the computed text, there’s no delay. The central position of the pending circle could have meant a general loading issue.
As I intend to slide that door, I’ll be able to display the First Name after. Which would solve the latency issue, for a better 1st impression.
Thks, Darren
Well, actually, as my rows don’t appear in the UI, but serve as Add Row user trackings, it worked the first 2 weeks or so, when I “Add row” to capture user clicks wherever possible, so in every customizable actions, which exclude icon menu tab clicks (free plan, workaround without GA4 and I cap even anonymous clicks, which GA4 does not for apps, for what I learned): the rows count didn’t budge at all! Then it suddently counted (somewhere beginning of October, I had to backup copy the app to keep the tracking for my exam, and delete the past rows from my production app, to avoid seeing the message “You’ve reached the limits…” that pushed my layout for 3 top lines, otherwise that would not look good in front of my student project examinator), and from 295, it rocketed to 1028 for ex.
Besides, I also needed to anticipate with the edits limits, that only count GSheet edits, including the login tab 1-2/user to keep in mind in thr estimation.
BTW, when I hide the top app bar, it also hides any Glide messages like “You’re offline…” (even when the z-index is -1 and the background set to transparent, but not the space (2 lines or so) that it occupies on screen.
Yes, using Glide Tables will definitely help minimise your sheet edits.
But as I said, they won’t help at all with row counts. A row is a row, and if it (or the table/sheet it lives in) is referenced anywhere in your app then it counts. It doesn’t matter if it’s a Google Sheet row, or a Glide Table row - they both count the same.
I’m not 100% certain of this, but I believe it still counts. Just because you don’t display the data in the app, the table/row is still being referenced by the app through the Add Row action. And because of this, it would be counted.
This is where you could actually leverage Google Sheets to minimise your row counts. ie. If you’re collecting data via the app (eg. your logging) but you don’t need to display that data in the app, then what you could do is log all that data to a Google Sheet and then regularly move it into another sheet that isn’t visible to the app. It would be very easy to automate this with a bit of Apps Script or something like Integromat.
Actually, I’m considering to replace most of the Add Rows - it has always been a “quick and working for sure” temporary solution to get the metrics my “damned examinator can’t accept without”. As I had no idea how Glide would deal with multi users connecting at the same time, clicking on same stuffs = concurrent access has always been an issue, except in RDBMS (theoretically). And it was cool to be able to reproduce the entire user journey, even with time-zones.
I’m considering Set column instead, provided I can manage how to separate the counts for anonymous users (so email - the dummy Glide email - col empty as well). It’s a tedious (methodical, but still) rework in every custom action and 10 tables with at least 60 columns or so that are significant in all to set. But that would buy me some time and remain below the 500 rows limits (my app is a knowledge base (Glossary, Best Practices, Job Interview Questions), so I already need rows of contents > 300, and that’s incompressible), until I really gain a significant users base before upgrading to 9 US$/month yearly instalments.
So you can ref a table row via an URL via its ROW ID (make sur there’s one and once auto-populated)
But you cannot ref a Glide UI Tab via an URL. Right? @Darren_Murphy
: ME.
So If the Row ID is fixed once and for all (without exceptions?), whatever the row edits, we can ref this row via url. But not a specific column by name or nth of columns count?