Async loading

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
dominique
Posts: 31
Joined: Mon May 29, 2017 4:16 pm
Location: St. Gallen, Switzerland

Async loading

Post by dominique » Thu Nov 29, 2018 8:35 pm

VL Web supports async reading processes which is very cool. During the waiting time it's possible to show a spinner etc. In the examples it looks like this:
Async1.jpg
Async1.jpg (16.73 KiB) Viewed 4818 times

We often use dataobjects with data collections to cache the data during a session. If we want to load the data from this dataobject we can't show the spinner because you can't do this in a simple async way. Sometimes a createinstance and data loading takes two or more seconds. During this time the user has like a frozen display. We want to aviod that.

Therefore we use the following construction. We fadein a label. At the end of the animation we load a list.
Async2.jpg
Async2.jpg (28.23 KiB) Viewed 4818 times
The handling is a bit complicated.


Questions:
1) Does this way make sense to have an async loading process? Do you have a better suggestion? (hopefully yes)
2) Is it correct that the fadein animation not starts until everything else is done (the whole call stack)?

If you try to fadein the spinner and load the data in the same Routine, the Animation does not start until everything else is complete.

Another way to visualize the loading process is to start a Dialog but you have a similar entangled situation. (but Internet explorer has sometimes problem with it)


What are your suggestions? What are your experiences about such situations?


Attached an example
QuickExportSample.zip
(17.62 KiB) Downloaded 372 times

jyoung
Posts: 642
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Re: Async loading

Post by jyoung » Fri Nov 30, 2018 1:03 am

The only way I know to do any kind of async work is with timers and then use an event to signal the work is completed.

For example

Code: Select all

function options(*DIRECT)
begin_com role(*EXTENDS #PRIM_OBJT)

define_evt name(WorkCompleted)

define_com class(#PRIM_TIMR) name(#Timer) Startup(Manual) Interval(100)

mthroutine name(DoWorkAsync)
#Timer.Start
endroutine

evtroutine handling(#Timer.Tick)
#Timer.Stop

* do work here

signal event(WorkCompleted)
endroutine

end_com
Note the use of the Timer and it being set to Manual Startup and a small Interval. This should kick off the tick almost immediately.

This give you a way toggle spinners/loading indicators etc. just like the ServerModule components.

Hope this helps,
Joe

dannyoorburg
Posts: 148
Joined: Mon Jan 04, 2016 9:50 am
Location: Australia

Re: Async loading

Post by dannyoorburg » Fri Nov 30, 2018 12:07 pm

Hi Dominique,

I downloaded your sample but I wasn't quite sure what it was trying to prove, so I'll just tell you what I know, it might help.

As a simplistic rule of thumb, the browser only does ONE thing at a time, so while it is running code it is NOT updating the screen.

When you receive data from a server module through an async call there are three parts to it.

1. Run some code to launch the request...
2. Wait, wait, wait...
3. Run some code to process the response...

During the wait there is plenty of time to update the screen, even run some more code, etc...

You're talking about a scenario where you already have the data in memory, and THEN you run lots of code and you would like the user to get some feedback about this long-running code as well.

What Joe says is fine, what you've done with the END animate is very simular.

1. Run some code to change the UI,
2. Wait (for the timer, or the animation to finish) give the browser a couple of milliseconds to update the screen.
3. Run the long running code.

BUT, what interests me is the long running code... it's all in memory, processors are blindingly fast these days, even on phones. What is it that takes enough time for you to even think about a waiting state...?

I know there were some issues with list-loading being slow, I also know most of them have been addressed in EPC140230 which has just been released.

Have a play, if you (or LANSA) is running so much code on the client, then what is really going on, are you displaying a crazy amount of information, is it just a bug, or is there something else going on...

On a side note, EPC140230 introduces material design progress bars... I know the indeterminate progress bar is actually capable of animating WHILE RDMLX code is running, so IF you end up needing some sort of visual feedback on long running code, that's not a bad one.

Cheers,
Danny

Post Reply