Is there a better way of forcing the app to reload to see the latest changes in the Retool iOS app?
Right now, after I make changes to queries and layout, I have to either force quit the app on the iPhone and launch it again, or switch to another app and then back again to see the changes.
When setting event handlers, there is an option to open an app. What if there was a similar option to Reload this app?
Thanks.
Not quite yet, unfortunately! But stay tuned 
Ok, I think i just figured out a workaround that works pretty well.
I created a bare secondary app that I called "Force Reloader" that simply has a Screen Event Load handler on the main screen, configured to Navigate to my main app. So all it does, as soon as the main screen loads, it opens another app. There are no other queries or components on this bare app.
Then, I created a "Left" action on my main app's home screen configured similarly with Navigation/Open app > Force Reloader.
So when I click the left icon on my main app, it opens the reloader app, which then opens the main app again. It's basically a redirect, but it works. Obviously, I'd need a secondary app for every app I want to use this on, but it's suitable for now.
I made it even better. Forget about needing a "reloader" app for every app you want to refresh. One is enough. Here's how, for anyone who may be interested:
navigator.openApp(localStorage.values.redirectToApp);
localStorage.setValue("redirectToApp",retoolContext.appUuid);
navigator.openApp("MYAPPUUID"); //replace MYAPPUID with the actual uuid of Force Reloader app from retoolContext global
The logic is simple. We create an action that first sets a value in localstorage with the current app's uuid, then we open the reloader app. The reloader app reads the previous app id value from localstorage and opens the app corresponding to that appid.
If you want to add reload functionality to another app, simply redo the above step 4 in that app.
PLEASE NOTE:
It's important mentioning that now every time you will attempt to open or even edit the Reloader app, it will redirect to whatever app uuid was last set as value in localstorage. There are ways to overcome this, but it would probably be best to add in a flag check to determine whether the redirect/reload should happen.
Thus, the script in step 4 should have a new line added:
localStorage.setValue("redirectToApp",retoolContext.appUuid);
localStorage.setValue("disableRedirectToApp",false);
navigator.openApp("*MYAPPUUID*"); //replace *MYAPPUID* with the actual uuid of Force Reloader app from retoolContext global
And the screen load event in step 5 (in the reloader app), should include a condition to run only when the disableRedirect flag is false (or otherwise put, do not run if disableRedirect flag is true).
With this approach, if you ever need to make further changes to the reloader app, simply modify the code of step 4 (of any app you added reload functionality to) by setting the disableRedirectToApp flag to true, and tapping the associated action that calls the reloader app.
This will cause the run condition of the screen load event of the reloader app to fail, allowing you to open the reloader app without it automatically redirecting to another app.
localStorage.setValue("disableRedirectToApp",true);
To restore reload functionalityafter, remember to switch back the localStorage.disableRedirectToApp flag to false.
Kia ora
This solution also seems to be the best option for our situation - in which, we need the user not to be able to swipe left to regain access to a screen - after our "Log out" process to keep the data secure on their phone. Even if elements or screens are subsequently hidden, the user still is able to swipe back to the screen and see it just as it was.
I'd be keen to know if there's another way of preventing this from happening, as it's a security issue for us.
The above genius solution works sometimes for us, but sadly, frequently, it just gets stuck showing the little spinny wheel, and not returning to the original app. Have you experienced this at all @27shutterclicks ? Any ideas or suggestions? I'm just using your original post suggestion, as we only need this for one app....
With thanks, Jamie
I think it did happen to me once but I didn't investigate it further. There may be more than one reason.
Basically, what happens is you're loading one app and then another app based on an event (page load of the reloader app). If any of these stages fail (either loading the reloader app failed, or the page load event wasn't triggered or the original app wasn't loaded), then I guess the spinny wheel would keep showing.
The fix is easy when you have access to the sidebar, but when you don't, as you described, I am not sure at this moment if there are any other options.
The spinny wheel shows when it's loading another app. I guess it would be important to know at which stage it gets stuck - when it opens the reloader app or when it opens back the original app.
You could try investigating by creating an intermediate action, like a notification or alert, on the reloader app that runs right before the navigate back (maybe even conditionally for certain users or roles so not everyone sees it).
So if you get to see the notification/alert, the reloader app loaded and is about to trigger the redirect - meaning the spinny wheel gets stuck on loading the original app.
And if you don't see it, then the spinny wheel is there because it didn't finish loading the reloader app.
Thank you:)
I came up with another way of fixing our issue, nabbing the concept of your idea:
Very satisfying! Thank you for your help - much appreciated:)
Jamie
Creative solution, but I wonder if there are simpler ways to go about it, without presenting blank screens to the user.
Also a blank screen with a redirection may not be a secure way of preventing the user to access data he should no longer have access to. What if the user taps back twice fast enough before the redirection kicks in?
Why not simply this: on the page "at risk" to be revisited by the user after logout, add a "Load" or "Visible" event handler (whichever kicks in sooner) that redirects the user to the login page with the condition to "Only run when" user is not logged in.
Even better would be, as part of the logout process, to destroy the data that would be visible if the user somehow makes their way back to the screen. Say your data comes from a temporary state or is maybe dependent on something in a temp state, after or right before the logout call, set that data to null ( or replace with a generic message, on top of the redirect to the login screen), so that there is nothing to see anymore.
Just an idea
Thank you:))
We've been running this as a solution for a couple of weeks now, and it seems to be working fully effectively:) The navigation event happens instantaneously, so the user never gets to see a blank screen - it simply bounces back to the landing page if they swipe left. There's definitely not scope to swipe past that, so the data is all good.
Because there are so many functions available on the screen we want to avoid them going back to, it's far less of a headache this way, than having to null everything and then deal with the error conditions of them being nulled....!
Very much appreciate your reflections and wisdom, though:)