Pushing "Structural" Edits / Updates to "Live" Published App

Ask for Help
1

Greetings Fellow Gliders,

I just wanted to ask a question for clarity as I continue to learn about Glide while building my apps. While I realize that Glide can be set to Auto-publish OR Manually Publish “Data” to app users, even if they have the app open…

How does the update pushing work for “Non-Table” data like added buttons, custom text or rich text, or other structural (non-data) changes?

It seems like if we have a “custom” hard coded Rich Text field on a details page (say some textual content changes), the app does NOT update that on an active user’s device automatically.

It ONLY seems to update if the app is actually closed and then re-opened again.

Is there a way to push a physical structural update in real-time to “custom” NON-table stored (but Glide stored) text or rich text on a details page to users who have the app open all the time without them having to close the app and re-open it?

Any guidance on this would be appreciated.

2

Actually, no. Data changes should sync to all user devices almost immediately, if they have the app open. If they don’t, it should happen the next time they open the App.

If you have auto publishing enabled, then any structural changes you make will be published almost immediately. I’m not 100% certain, but I believe that user devices are supposed to pick these changes up within about 30 minutes. But restarting the App would force that to happen right away.

No, that’s not true. Restarting the App just makes it happen quicker than it otherwise would have.

3

Hi Darren,

Thanks for your quick reply but what I am referring to is open apps that have been “installed” on users device desktops that appear to NOT receive the structural updates.

Refer to the post that @Deena posted. That is the “exact” issue I am referring to.

During a weekend conference my users generally keep the “installed” app open the entire time and don’t close it. Sure, any “Data” updates occur immediately but for those structural changes (i.e. we add a new button on the first screen to they can fill out a post event survey), the attendees don’t see that change in their open app.

4

That post is over two years old. A lot has changed in Glide since then :slightly_smiling_face:

Whilst I wouldn’t bet my life on it, I’m fairly certain that installed Apps will - or at least should - pick up structural changes without requiring a restart. But as I said, it doesn’t necessarily happen immediately. The way to force it is with a restart.

5

Yep, I realize it was an old post but it’s a recent issue that our users are seeing. On both iPhone and Android the “Structural” updates unfortunately are NOT occurring automatically for those who keep the installed app running.

Wish there was some sort of “Pull Down to Refresh” capability because we CAN’T ask 500 conference attendees to close the app and then re-open it during the weekend. Structural changes need to just “occur” just like data sheet updates do.

We try to make sure the structural design is set and won’t need to change but as you know there are always real-time requests to add this or add that and sometimes those are “hard structural” adds vs. planned data table adds.

Anyway, I hope it’s just US and not in general that this issue is occurring. All the best!

6

I always think about native app store apps. If a user wanted, they could skip updates forever and there is nothing the developer can do about it unless they add some code to disable the app until the user downloads and installs the latest update. At most, a native app will check for updates maybe a few times a day or less. It’s never an instantaneous update.

PWA’s are a little different in that they are web based, but they are also similar in many ways to native apps. As with anything web based, there is a lot of caching happening to store stuff locally on the end user’s device. That includes storing the app’s interface. Caching the interface is like installing an app. You are loading the core interface code so the app can function and communicate with the server to move data back and forth. Data travels freely in the background (just like native apps), but the interface is stored locally so it is quick and responsive. Overall, you still have the same problem as with native apps where you are at the mercy of expecting the end user to make sure they have the latest version.

While I believe Glide can forcefully push structural updates, I think one potential problem with is that the entire app needs to reload to get the latest structural updates. Just like any native app needs to shutdown to install updates. Imagine if you are working in the builder and all of your users experience the app flickering and completely reloading every few seconds while you are making changes. This would be quite frustrating. That’s why structural changes are not immediately pushed to the users. It would cause the whole app to reload and re-cache the updated interface repeatedly until you stopped making your structural changes. Closing and reopening an app allows it to check for an updated interface and download it before opening. Especially at a convenient time that won’t interrupt a user if they are actively using the app. Would hate to reload the interface on a user if they are in the middle of filling out a long form for example.

I understand the problem, but I also understand the limitation. I don’t really have any advice other than to plan ahead and make any structure changes beforehand that can be turned on or off via the data.

Or, something, I’ve never tested but may work…you could maybe add a subtle component to a screen with a visibility condition controlled by a new empty column. When you make new structural changes and are ready for everyone to see them, add a new empty column, delete the old column, and change the visibility on the component to use the new column. Maybe a scenario like this, where the old interface is looking for a column that no longer exists, would maybe be enough to cause the entire app to reload, thus downloading the new interface with the latest structural changes.

3 Likes
7

Greetings Jeff,

Thank you for sharing your viewpoints and ideas. We’re actually considering trying out your last suggestion as a possible way to “push” those structural updates.

I totally agree with all that you have stated. We are seasoned website designers who have now moved into PWA app development space. Like all of the websites we build, our visitors “Must” refresh their browser to see the changes. I just needed to be reminded that our Glide app is in fact a PWA and not a native app.

I think I got spoiled using some of the other “container” based apps that promt the Users with a pop up modal letting them know an updated version of this app is available at which point it would close the app on the device and re-open it with the updated version. But even those container based apps are native apps and not PWAs (again which is what I need to keep reminding myself of).

Our conference / event app does not require much User interaction like filling out forms, etc. but they do use that Agenda during the course of the event to know where to go next. It stays open almost always.

So, maybe we simply tell the Attendees via a data driven field that “There is a new version of the app available, so close and re-open to see the latest updates!”

Again, “Thank You” for your feedback. It’s most appreciated from All of you Glide experts! :smile:

4 Likes
8

I was a little surprised to read Jeff’s comments (and yours) this morning. Whilst everything you both say makes perfect sense, for the longest time I’ve had the understanding that it wasn’t necessary to force restart an installed App to get any structural updates loaded. I’m not sure exactly where that understanding comes from - I suspect I read it here a long time ago and just accepted it, without actually testing it for myself.

I will admit that I always do a forced restart when I’ve published new changes and I want to check them, but that’s just because I’m impatient and want to see the changes immediately.

Anyway, I decided to do a test.

I took an App that I have installed on my phone (iPhone), and conducted two tests:

The first test involved a hidden tab. I have one tab in this App that I keep permanently hidden. It doesn’t serve any purpose in the App, but I use it for experimenting with things in the builder. So I’ll often unhide it in the builder, play around with it a bit, and then hide it again - without ever publishing the App. Anyway, the first test I did was to unhide this tab and then publish my App. I had the App open on my phone when I did this, and within a few seconds I saw a brief flash and the tab appeared.

Okay, that doesn’t really prove a lot as it’s just changing the status of a tab that was almost certainly already loaded on my phone, but hidden.

For the second test, I added a button to that tab and published again. I then waited to see if anything would happen with the App on the phone. And waited. And waited… After about 45 minutes nothing had changed, so feeling a little disappointed I put my phone to one side (without closing the App) and went on with my business.

About 3 hours later, I picked up my phone and switched to the App in question. As the App came to the foreground, there was another brief flash and hey presto - there was my new button.

Now, one thing I will say is that for a period of about an hour I had my phone in “aircraft” mode, and it was shortly after I switched that off that the App updated. So quite possibly it was losing and then re-establishing network connectivity that triggered the UI refresh. But that’s just speculation.

The important point is: at no point from when the change was published to when the new button appeared was the App force closed or restarted

So I think I stand by my original comments :slight_smile:

Of course, this doesn’t help with your conference scenario, because you can’t be waiting around for 3-4 hours for changes to propagate, or tell your users to switch in/out of aircraft mode (assuming that’s what triggered it). But perhaps you might be able to use the hidden tab technique - as I was able to demonstrate that un-hiding a tab and publishing does have an almost immediate effect.

Update: So I just did a 3rd test. I added an Inline List component to the same tab, and published the App. I then opened the App on my phone and the Inline List was there immediately. Again, I haven’t closed the App or restarted it at any point. The App has just been open and “running” in the background all day. I still don’t know what actually triggers a UI refresh, but I’m quite certain now without any doubt that a forced restart is definitely not required.

3 Likes
9

Thanks Darren for the “controlled” experimentation. I’ll have to run some similar test on my end.

I have NOT tried the hide and unhide of a hidden tab because I don’t want new tabs popping up on users. I assume that was a side tab and not a main tab at the app screen bottom?

We do swap out the apps “Welcome” screen home tab for a “Farewell” home tab at the end of the event, but again cannot guarantee attendees see that without an app restart. I have had a test iPhone remain on the Welcome screen home tab overnight with the app open in the backgtound with no state change when picking it back up.

I will test the “airplane mode” on my end when i get a chance later today.

While an inline list is assiciated with data directly in your table, try if you will to simply add and update a custom “Rich Text” field to an existing visible tab (say Homescreen tab) as if you were updateing a Welcome letter to a Farewell letter on the page. Custom text, not being fed from a spreadsheet but keyed in directly in the editor. Publish and let me know your results if instant or hours.

Yes 3-4 hours in waiting will not help our conference needs in last minute structural updates. but we will continue to think creatively in our Glide app development and collectively with fellow Gliders like you, we will prevail in the end with great solutions. All rhe best! :grinning:

1 Like
10

No. The App in question normally works from a single visible tab, so there is no tab bar at the bottom of the screen. The tab that was exposed is in the main tab bar, so when the UI refreshed the tab bar appeared with two tab icons present.

I suspect this might be a bit of a red herring.

I just tried that and got the same result that I got with my Inline List test. The App was open and running in the background on my phone. I used the App switcher to bring it to the foreground, there was the same brief flash, and the rich text component appeared.

Interestingly though, just after this I repeated the hidden tab test - this time hiding it and publishing. It’s been about 10 minutes - and the second (now hidden) tab is still visible on the App on my phone. Go figure… :man_shrugging:

If there is any sort of pattern emerging, I’d say it depends on the “state” of the App when you bring it to the foreground. It seems to me that if the App is open and idle in the background for some (unspecified) period, it goes to “sleep”, and when you bring it to the foreground it wakes up and a UI refresh is triggered. Again, that’s just pure speculation on my part. Both Jeff & I are part of a Slack group that includes some of the Glide Engineering team. I’m going to see if I can coerce a response from them as to what the expected behaviour should be.

1 Like
11

Just a thought, what you could do here is have both tabs pre-loaded and then apply time-based visibility conditions. You could even do that with a single screen/tab and apply the visibility conditions at a component level. As long as you know in advance the expected end time of your conference, I’m quite confident that would work.

I do something similar with one of my Apps where employees are required to perform a safety check prior to starting their shift, and log the results via an App. So visibility of the associated tab is linked to their shift roster, and the tab only appears for a couple of hours leading up to and just after their scheduled shift start time.

12

Darren, I wish I could say I got ALL favorable results with my “Controlled” testing but in the end… I came close and learned a lot in the process!

Test 1:
Using 2 Android devices and 1 iPhone in my test. New install of app on second Android phone after a small structure update (just physically added 1 new word, 1 extra period and a heart emoji via markdown to the end of an existing custom Rich Text component and re-published the app).

Of course the new install picks up every change since it’s the initial install of the app. Other two devices with previous install of app did NOT change at all, even after roughly 2 hours leaving the app instance open, switching them to airplane mode, switching to other apps and bringing the Glide app back into focus, and switching between 5G while briefly in my car and back to WiFi in the office. No state change applied forced a structural app update thus far. Did a browser refresh in the browser instance of the app on my laptop and as expected that updated on-screen.

Test 2.
Next, I created a new “Visible” app tab (actually “Menu” item vs. tab). Dropped an Image & Hint component on this page and again published the app manually. Waited another hour…nothing on any of the devices. No Visibility conditions but a new menu tab nowhere to be found.

UPDATE 1:
On iPhone 6 , after sitting for 3+ hours, I picked it up, brought the Glide app back in focus and it did a screen refresh of the app to apply the latest updates. Sadly I can’t remember if I did the airplane mode toggle one more time, but I do remember refreshing the CNN website in the other browser window before returning to the Glide app. So, yes it took nearly 3.5 hours but on the iPhone 6 I sort of matched your outcome of auto update over time. Sadly, neither of my Android phones (one much newer than the iPhone) have updated yet when bringing the open installed app back into focus.

UPDATE 2:
About 30 minutes later, I picked up older Android phone, saw nothing updated, toggled airplane mode on then back off again, briefly looked at CNN in a separate browser instance, but noticed I still had the Glide app up in the browser as well which appeared to refresh itself and present the “install app” message at which point the app now was updated to the newest version. The same held true for the mobile “installed” version of the app. Sadly, newest & fastest Android phone is still sitting on older version of the app even after toggling airplane mode. That’s wild???

Test 3.
Last test was to add another Hint component to the same now “existing” new visible test menu item / tab but this time create two new “text” type columns in one of my sheets “Hidden Title” & “Hidden Text” and turn on edit option for the tab.

Closing and reopening the iPhone app instance to get the new published updates, I was able to enter edit mode, type into the text entry fields and save.

As expected, because it was a DATA TABLE update, it updated on all of the devices (iPhone, older Android with previous version of app & laptop web instance of the app). But for my newer fast Samsung Galaxy S20 FE 5G handset… nadda, nothing! No update from the previous 3 versions of the app nearly 5 hours later before any of the publishing. And since that new DATA driven component was NOT on the original versions of the app, the new device missed the data edit change. That is definitely saddening!

In Conclusion:
While the Glide app DOES appear to auto-update app “structural” changes over a random period of time (3-4 hours in testing) for some devices, my test case still left one device (the newest one) with NO update at all.

So given this, my recommendation is that we try to design Glide apps “with Dynamic tab components” that might require more “real-time” “structural” updates (a swap out of text on a page, or change to header or body images, or a drop in place Vimeo or YouTube video, etc.). We will try to logically plan for or anticipate those potential updates ahead of time. Perhaps taking a top to bottom look over a “Detailed” app tab page design and setting as many dynamic components as editable on the page while linking each one to a configurable data table source column on the back-end. Pre-existing “empty” components that load during the first install and show / hide when populated by data or left empty in the table.

While this may NOT be viable for every instance or every component, it will work in a pinch allowing near “real-time” structural updates to User base app installs on the fly. Not pretty, I know, but it’s an interface design solution for those of us who want more immediate flexibility in addressing potential content needs in our app’s interface on the go.

And most importantly for our needs during conferences with 500+ attendees, like the rest of our data, these planned dynamic structural interface updates in key locations on a formatted tab can be handled from a mobile device without the need to log into the Glide back-end Editor! :smiley:

1 Like
13

Has anybody ever tried this idea yet? I haven’t had a chance to try it myself. The idea is that if the old version of the app is looking for columns that no longer exist in the data, then maybe it would force a refresh. Not sure if this could be on any tab, or if it would have to be on a tab that a user is currently viewing.

14

I hadn’t tried it, but I just did now. Result was kind of interesting.

After setting it up as you described, what I found was that as soon as I removed the column, the component that was referring to it almost immediately disappeared from the device UI (without the change being published). I guess this is to be expected, because data changes are synced immediately, and when the column disappeared the visibility condition broke.

Replacing the column, updating the visibility condition and re-publishing had no immediate effect.

15

mmm, it did occur to me after posting earlier that the behaviour may vary between devices/browsers. Your testing seems to bear this out.

I’d actually consider this a best practice, anyway. As a general rule, I try to avoid static text and component labels where ever I can. Not always possible (eg. tab labels), and in some cases it doesn’t make a whole lot of sense.

So yeah, I think at this stage the answer seems to be a big fat YMMV.

2 Likes
16

The same holds true for an “existing” app Tab or Menu when I set the visibility of that tab to a certain User access level and then manually changed one of the users in the User Profile table to that same User access level. It was an instant appearance of the tab where it WAS NOT visible before, all without an app update or state change. Interesting…

1 Like
17

That’s interesting that it reacted that quickly, and didn’t do a complete reload.

My only other thought would be to add the new column and swap out the visibility condition, then publish, BEFORE removing the old column, but based on what you mentioned above, I have my doubts with that too. At this point it becomes a hack job with crossed fingers hoping it works or not.

18

The best way that I found so far is to use a flag that I can set to “1” (to all users) if there is a significant update. The flag triggers a message to users that an update is needed (new release), suggesting to go to the user tab, to press the log-out icon and then to log-in again. I use a counter to check if user did the new sign-in and to trigger off the message. After the new sign-in all the new changes are of course visible to users. In this way I am sure who has the upgrade.

1 Like
19

A variation of that idea could be to still show the message, but allow a user to dismiss it without logging out. Maybe just suggest that they force close and reopen the app. That should be sufficient, but I guess there is no guarantee that they know how to properly force close the app and could simply dismiss the message without actually restarting the app.

20

Yes this was the point. We have many users that are not familiar on how to shut down the app. I was just checking the cookies settings. It should be nice to not request a new pin every time (if done on the same device).

1 Like