Dear all,
while experimenting the power of itoo (the great 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.
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).
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...
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 while..do 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.
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" while...do 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.
great 
