I have some XC that calls Google PubSub to get values from the server (effectively a push message that we are listening for) — then I use a template column to turn that XC script value into something that Glide can handle for a component visibility condition
I have a page where I would like to do this call several times (e.g. every time an ‘agent’ in my call center clicks, I want the ‘user’ screen to change) - as right now it takes Glide 15 seconds to sync… and it would be nice to get this down to 3 - 5 seconds
but our PubSub listens once…
SO - either we can keep getting values from the script OR we keep calling the script again
—> for instance, I would like to pass a value ‘agent inc’ - as this is driving the visibility on screen (1, 2, 3…)
I was playing with @Mark 's random number generator. It seems to recalculate in the designer every time I focus on another column in the data editor… but if I click in the UX to view documents, etc, then it does not re-calculate…
I haven’t really played with XC columns yet, except for some small tests, but I’m under the assumption that an XC column possibly recalculates every time something in the row is updated. Would it work to maybe have an action that increments a value in that row, or updates an unimportant parameter that’s passed into the XC?
I do have changes in the row… BUT the problem is that I have two apps using the same Glide Table (for this part of the app) and the agent-increment alters the visibility of components on both sides. However there is a consistent 15 second lag between a key press on one side (agent) and the screen changing on the other side (user). This was the lag I was trying to reduce… but the act of a data changing in the row does not help as the refresh would be at the same pace.
But the row changes are driven by the Agent interaction, not the User, correct? I was thinking in this case, if the user performed an action that would change something in the row, then it would cause the XC to recalculate. But if the user is just sitting there waiting and not interacting with the app, then I suppose that’s not going to work.
I wonder if the XC code can be set to perform a loop action and then spin until it gets an updated value from the PubSub. Once a new value is returned, or a pre-determined timeout expires, then it will return the value and exit the loop. But I’m not sure if that would work since the user would have to do something for that XC code to trigger, so you’d probably have the same problem. Also, you’d have to be really careful with looping code, so you don’t end up in an endless loop…or call your pubsub way too often.
Yes @Jeff_Hager is right. you can add parameter to json and dummy column to update YC row via action like increment (it doesn’t matter since this value is only there for update)
This looped approach, and in my opinion very delicate,
I haven’t done a test yet, but I think there is a timeout to avoid this, we have to do some tests !!!
Code columns are not actions. Do not rely on them being called, or not being called, at specific times. Even if you can make it work with the Code column’s current behavior, it’ll break when that behavior changes.
To answer your question differently.
I did this in one of my scripts (for a somewhat temperamental and slow API call).
I made a loop of 10 maximum attempts, with a delay of 350ms between each attempt. which allows to have a chance of response
You shouldn’t try to get an answer surely either, it’s just a precaution.
It is necessary to remain modest on the number of attempts and on the delay between each call. Otherwise you risk having a blockage and the opposite effect of your wishes
we must also be careful, because if the operation hangs or and long, the entire YC column is pending!
In short, it is not necessarily a good solution !!!
It would be really useful to know. I’m about to start developing an application where the availability or not of the YC column would be decisive because it would prevent me from calling external services.
Now I don’t know if YC column will exist, and what definitive behavior it will have, so if I use it and then it changes or even disappears from the possibilities of the platform then it could be a big trouble for me.
I know the feeling … I am taking the risk now (at least it is in Production, not just Staging). I am using it in the following places (so @Mark can get a feel for the use cases):
Booking - use case: user makes a booking // in Glide, I have a Webview that opens Acuity. When we open the Booking page, we add a row in Glide to a sheet (new booking) with a fresh uid / booking ID. We then have 1 XC column for the Excel formula - to split the user ‘legalname’ into ‘first name’ and ‘last name’ using the first space (to fit into the Acuity format). Next we have the webhook at the backend through Integromat to take the data for the completed booking back into GS… and at the same time, we send a message to Google PubSub. This PubSub is the next XC column - it is listening for ‘success’ and then I use a template column (the only type that works) to control the visibility of the button to continue (and the webview).
—> reasons: 1) I cannot split text easily in Glide, so the XC excel thing is easy and immediate
there can be 45-200 seconds delay for the GS to update with the completed booking details, and I do not want to leave my users hanging that long
Payment / PayHere – same implementation basically as the Booking
Find address from GPS coordinate / reverse geocode XC (compliments of @SantiagoPerez ) - in the account setup and during a corona test (to get your current address) - the customer has the option to ‘use my current location’ - the Glide component - and it resolves in 2-3 seconds on screen with the full address
→ reason: 1) super fast (I used to collect the GPS back to GS, then a script would run in 2 seconds… but Glide UX on the user device would take 45 - 200 seconds to refresh!)
Device and TimeZone - XC columns to get the device info and time. I am not using the UTC time as much as I hoped as it seems that it does not compute on some devices, which means I cannot rely on it through the app. The device info is happy to work out what our users are doing (as we decided not to use Google Analytics)
→ reason - took just a few mins to add in the code, and ‘system time’ has been a dream of mine for a long time
Video with Agent process - use case: a customer is ready to do a Corona test, they make a ‘request’ for an agent to be assigned (webhook - integromat - GS), the backend (GS - Appscript - @Darren_Murphy ) works out which agent to assign, then a row is added and a webhook sent back to Integromat to alert agents, etc.
problem – the assigning script takes 2 seconds to get from Glide - Integromat - GS (good), then up to 1 min to run the backend script to assign (necessary right now to avoid race conditions), then 2-10 seconds to assign all outstanding calls to available agents, 1 seconds to alert the webhook - Integromat … then 15-60 seconds for the Glide UX for the agent to change (and this is with a curl script to poke Glide into action, and creating new rows in GS).
the XC being added now is:
— Google PubSub creates a ‘topic’ on the user and agent side (agent side is the agent ID)
— the Agent side will always listen for new messages (would be a new verify ID) - and the UX would change (button appear) using the template trick from Booking
— the User side would change in a similar way (but the user only has one session… the Agent listener will keep listening)
→ reasons: 1) faster assigning of agents saves a lot of time and money as our agents will be busy with customers, not waiting for tech lag (about 10-15% more time possible if I speed up this process)
better experience of the customer (faster connection, means better use of their time and happier customers)
