Multithread: Delay & Flow Interruption by means of Itoo

Dear all,
while experimenting the power of itoo (the :muscle:great :muscle:extension by @kumaraswamy) I've found a way how to implement a delay function without blocking the app.
Many times it has happened that a user has asked how to implement a delay between the execution of two instructions (i.e. two blocks), and the answer it has been always that AI2 is a single thread and therefore when there is the need to implement a delay the unique way is to use a clock. This is still valid, but it is a bit tricky when you want to stop a procedure for a while, then to continue from the instruction following the previous one.
The annexed .aia shows how itoo, running in background, is capable to receive from the app the request of a delay (in seconds) and to set a "timeout elapsed" flag to the app, leaving the app to contine its flow, after the requested delay has expired.
So, greatest thanks to @Kumaraswamy for his extremely powerful extension !!!
But also many thanks to @Taifun for his TaifunTools extension.

Delay_Example.aia (163.1 KB)

A short description on how it works is here:
Description.pdf (271.4 KB)

Hoping it could be of some help.


That's a cool demonstration @uskiara maybe we can experiment further on multi threading topics :wink:

1 Like

Dear @Kumaraswamy,
thanks for your nice comments. The next step that I want to experiment is a BT comm's handled in the background by Itoo, so to allow a complete asynchronicity (without the need to poll periodically with a clock).

Your extension opens a new way of AI2 programming (I believe).

...never say never .... :grin: :grin:.

1 Like

A "true" delay by means of itoo

unfortunately I have to disappoint you... it does not work...
the while loop no matter how you will use it will block the user interface i.e. the app gets unresponsive... you will not be able to close the keyboard anymore...

and after a while the error "app is not responding" occurs... just try it with a large number, for example 500

therefore the correct method to wait is still the old method from 2016 by @ScottFromScott from the old Google Groups forum

Why is a wait procedure generally a bad idea? by @jos
The model of event processing in App Inventor by @Franklyn_A_Turbak


I had a similar understand initially, though it is indeed true that the app gets unresponsive, he told me that it was intentional that way.
Ugo wanted to demonstrate the concept of interruption and preserving state.

It is to demonstrate a situation where a thread constantly enumerates data from an external source to be interrupted.

You may synonymize this with calling a Thread.sleep(), but in this case you are constantly evaluating conditions, giving you control.

I'm quoting Hugo:

What the users often require is to have to possibility to have a delay that waits for a while, and then to continue from the same point (the instruction after) which is not obtainable with a a clock.
Your extension allows a "secondary" task to run in background, while the main app is frozen, then to wake up the main app than can restore its job from the exact point where it has been frozen.
In other words you can do a loop waiting for an external event to happen, what is not possible with the standard behaviour of AI2.
In the embedded systems this is typically obtained with "interrupts".
The next step that I wish to do with itoo is, for example, to receive in background a BT communication, without the need to periodically poll the incoming buffer.
In my mind your extension has added the possibility to overcome the "single thread" limitation of AI2.

These things will be more relevant when multi threading functionality is introduced to App Inventor. In that case it would make more of relevance to use thread sleeping and interrupting.

this was his comment earlier

which is incorrect


Yes, in one way it may be incorrect to say without blocking the app. But it is also important to note that the user still has enough control of flow on the parallel running Itoo thread.

Sorry, I was out and I read only now.
My intention was to verify if a "neverending" loop, waiting for an external event, could instead be iinterrupted by an event generated by Itoo.
I knew that the foreground app is frozen in the while loop, but the process in background is still alive and it can generate the event that releases the foreground app.
In other words: events generated by Itoo in the background can be collected asynchronously by a foreground running app. In this example to exit a while loop whose control variable is set outside the loop by a task running in "parallel".

At last, I agree that the original title could have been misleading, I then thanks @Kumaraswamy to have modified it.

Have a great weekend to all.

1 Like