I have a button which, when clicked calls a very slow background task and I want that until the task is completed, a loading spinner is displayed to the user because I want to display the return value of that background task to the user. I’m using a background task and not a server function for this because the server functions have a 30 second timeout limit and the background task runs approximately 35~40 seconds only.
So, my question: just like how you can suppress a spinner, is there also a way to display the spinner during such processes?
I don’t recall a way to do that, but you might want to search the Docs.
You could provide a more informative message, explaining the wait, via Notifications. Otherwise, users might think your App has gotten stuck in a loop.
If you want to also provide something like a progress display, perhaps with an option to Cancel, you can display your own active Form. See Alerts.
I search the docs, and I’m actually using multiple async threads so I have no way knowing how far along the task is.
I can maybe display a notification saying it’ll take a minute and hope that that is enough for the users.
I have a timer in the app that calls a server function every 3 seconds to see if the process is completed. If the process is not completed, a label is updated with the current step, otherwise something else happens.
In one app I have a Notification that shows the progress and it’s closed at the end. It looks good, but I’ve never used this technique again. I don’t really like it.
In all other apps I have a label that shows the progress and, when the process is completed, something else happens in the UI. For example some buttons are enabled or some panels appear.
In the first app, the one with the notification, I have a form that shows part of the status of the server with a notification that shows another part of the status of the server. It just doesn’t feel right.
In the other apps I have the UI that shows what’s going on. Each app has its own way, but the point is I feel it’s better to use the form to show both the status and everything else all together, rather than making my life difficult managing a notification that floats above the rest, and making the UI more complex, which is never a good idea.
Even having a form with two panels, one containing the status label and one containing whatever I need at the end of the task, and showing either one or the other, I feel it’s a better solution that having a notification floating above.
Using a notification or the form is matter of personal preference. Showing a label that tells you what’s going on and changing the text in the label every 3-4 seconds is very useful, even if it doesn’t tell you how long you need to wait. The user doesn’t think something went wrong and you have a little feedback about what was happening when it crashed.
Yeah I ended up doing something similar, but I did it using time.sleep in a server call to block the user, and displaying a Notification that displays the progress. It’s a poor workaround but it worked for me.
Might try to go with the Label method instead, but I want a loading spinner to be displayed the entire time while the process is running so Notification works better for me.
Good luck with that. I have a bad feeling. Using time.sleep usually pushes the problems a little farther, and later you end up using a timer anyway.
I would show a notification and keep it open until the timer that polls the server to check the status finds out that the notification needs to be closed. The timer can both update the message in the notification while the task runs, and close it at the end. A message that changes, even if it changes from “working on it” to “almost done”, even with no useful information, gives a much better feeling than a spinner.
I don’t have the big picture of what you are doing, but I have the feeling that you are thinking sequentially rather than event driven. When dealing with the ui, instead of thinking “I’m doing something, let me show the spinner, wait until I’m done, then close the spinner”, it’s better to think as a bunch of independent events: “a button has been clicked, let’s start a task”, “a task is running, let’s check and show what’s going on”, “a task just completed, let’s close the spinner”. The ui has nothing to do with what the server is doing, they are two different beasts. The server does something on its own, while the ui should show something to the user and allow the user to interact with it. If the ui happens to show the status of a long running task on the server side, it can do that with a timer.
That’s exactly the shape I was in, coming from Windows desktop development. The GUI framework is event-driven, as is the browser, but the user’s workflow is (usually) not. They have a job to do, step by step, and that sequence gets reflected in the application code as the “natural” way to code it all. (At least for me. A carryover, perhaps, from my pre-event-driven punched-card days.)
It’s not a bad way to write the code, but it leaves some opportunities unmet. In my app, for example, users request what can be a ten-minute calculation (in the worst case). (Longer, if other jobs are already queued up and waiting.)
I don’t keep the user waiting, though. Instead, I keep a table of (their) pending jobs, that they can check in on, at their leisure. In the meantime, they can do other things with the app.
My Queue Manager app runs the tasks on 3 uplink machines. Only one task can run on each machine, because they can’t share certain resources. Some tasks last 1 minute or less, some last hours.
There is one panel with a repeating panel showing all the uncompleted tasks, another showing the list of users with pending tasks. You can look at the list of users to see how many tasks of yours are still pending, or you can look at each task and see its current condition, who’s is updated every 2 seconds by a timer.
But this is fundamentally different from @crul’s app, because my ui doesn’t allow to start tasks, only shows their status.
My tasks are started by cad plugins, excel macros and other tools, using an http endpoint.