Android Question B4A ProgressDialogShow NotShow

[drgottjr]

I have a lengthy stretch of code which can run from 1 second to 7 seconds, depending on the difficulty
of the problem it's solving. Once the solution goes beyond a couple seconds, it looks like the app is
doing nothing, so I wanted to put a "Working..." progressdialog up to show the user that everything was under control. I set a timer and when it ticks, the progressdialog is supposed to pop open. Only it doesn't. (Actually, it does open after the problem has been solved.)

I tried adding some strategically placed doevents, and while that helps a little, the progressdialog barely pops open before the solution has been reached. And the more doevents I add, the longer the app takes. Finding the best spot(s) is tough.

So I thought I would try to put the long running part in a service and put the timer and the progressdialog in the main activity. Just before I start the service, I enable the timer. I would have thought that the service would run in the background (that is, giving up some of its time slots) and the main activity would get the focus periodically and see the timer had ticked and be able to open the progressdialog. But no luck. I also tried a toast message.

And, just out of curiosity, I tried to open the progressdialog (without a timer) before starting the service. Oddly, that works best of all, even though the dialog doesn't actually appear on the screen until several seconds later. And no timer is involved. Assuming I could guarantee that the delay would always be consistent, I could live with it. But that's quite a quirky workaround to depend on.

So, is doevents (in the right spot) the way to handle this? Doesn't "run in the background" imply yielding? Services are always presented as allowing the main activity to continue while the background processing takes place. That's what I'm trying to do.

Last, I'm reluctant to use the notification feature (assuming it worked in this case). I would like a big spinning "Working..." progressdialg in the middle of the screen. A notification looks like you're getting a text message or some notice from Playstore.

Any guidance is appreciated.
-go

 

[mc73]

Strange to me that the progressDialog delays showing... Do you have any other coding after it, inside the sub that starts the service? Or perhaps setting the service to start from inside a timer could help?

 

[drgottjr]

thanks. strange to me too, but not inconsistent with a message queue issue. adding doevents inside the long bit does allow the dialog to open, but it's too late to be of any use to the user. i could be adding it at the wrong place. i'm willing to spend the time to find the right spot to add it if that's the only way. i thought the service would do the trick.

as for any code that follows opening the progressdialog in the service, there is a ton of dim's and then the actual processing. i'm guessing the call to open the dialog is put in the message queue and the start service call is made, but i don't know how android handles that. it may take priority over gui stuff. or gui stuff just takes longer. and i don't know how a progressdialog is implemented by the system. for all i know there always has been a lag, but it never mattered.

getting the service to start doesn't seem to be a problem; it's regaining control of it after 2 seconds that is.

 

[Erel]

You can call ProgressDialogShow and then call your lengthy code with CallSubPlus to allow the dialog to show: CallSubPlus - CallSub with explicit delay

What is your code processing? Maybe it can be optimized.

 

[drgottjr]

thanks. so no service, right? just call in main activity? will try. but there's that starter service of yours again! i didn't get your explanation of it when you made it available, i'm sorry. i even actually read it more than once. new things aren't coming easily any more. i do better with an example.

also, i had 2 thoughts in my sleep: 1) update the activity after opening the dialog? does that have a higher priority than doevents? and 2) look for a spot in the long running code itself and put the progressdialogshow there instead of doevents and a timer? this assumes no service, of course, but i think i see where the thing is about to start a very long looping sequence. if i open the dialog there (and it showed), that would be good.

as to optimization, i offered to put a friend's excel macro in vb on an android. i had forgotten what damage one could do with vb when left to run wild. i would like to get on with my life now. but the progressdialog would be nice to end things with.

 

[Erel]

The starter service is not related and will not help here. There are no priorities involved. As long as the main thread is busy the UI will not be updated.

Adding DoEvents will help.

 

[drgottjr]

yep. start the progressdialog before the processing, invalidate the activity and give a doevents. dialog shows immediately but does not spin. then add a *few* more doevents at key locations in the processing to allow the wheel to spin. not ideal, but not horrible. too many doevents slows things down plus android hangs and says the app is not responding. if i ratchet back to just 2 or 3 doevents - just before long loops - no hanging, plus reasonably informative spinning progressdialog.

i only mentioned starter service because the link you gave https://www.b4x.com/android/forum/threads/60877/#content says "csu is declared in the Starter service:" i thought that meant i had to do something with the starter service. i'll give your callsubplus class a try in any case. thanks.