We're trying to develop a simple time tracking mobile app in Retool. My initial attempt included 4 separate screens, one for each 'status' the user could be in - Selecting jobs/activities, currently working, on-break, and switching jobs/activities. The problem I ran into with this design was the 'Back' button on Android devices would allow the user to navigate between pages without changing their status.
I switched to using a single screen app, and hiding/un-hiding containers based on button presses and local variables(ex: button 'Begin Work' hides the job selection dropdown and displays the Take Break and End Work buttons). This eliminated the problem with the Android back button, but the hiding/un-hiding of containers seems to be inconsistent, especially on older Android devices. On the older Androids occasionally the elements that should be hidden stay visible.
I'm curious if there's any way to control what the Android 'Back' button does? Or, if anyone has implemented a time tracking app successfully and would have any suggestions. We're essentially trying to write start/stop times, and job code/activity to postgres.
Thanks!
Unfortunately we don't yet support preventing users from navigating back using the OS-provided back button. However one workaround is to maintain some extra temporary state and use the "Visible" event handler on your original screen to re-push the screen you want to keep the user on using a Navigation action. From a product POV, you can also have an error box telling the user they're in a bad state and to restart the time tracking flow.
Separately from this, if you have a minimal example of the hiding issue (stripped of any proprietary information you need to hide, you can either take a screen recording or share an app export), I can take a look. My email is braden AT retool dot com.
Thanks for the quick reply! I tried a few things with the Visible event, but still had some quirkiness with the multi-page app. However, I was able to apply a similar idea to my single page app with the hidden containers, where I use a page event to periodically check if the user should be clocked in or not, and update status accordingly. So far this seems to be fixing the problem we were seeing with the older Androids.
