How to build an asynchronous application?

Question

Programming

• The application works with several remote web services at once, the responses from which do not come instantly;
• The application interface uses mini-animations that take time (eg panel exit);
• The actions of a neurotic user can be chaotic and unpredictable (as a hyperbole example: a child sat down at his father's computer or we just test the app, giving the noise of random clicks to the input to test foolproofing - in general, the user does not always wait for the end of a long procedure).

How to build such an application: optimally, transparently, "correctly" - to take into account all possible combinations of the states of each of the elements?

In patterns, until the dog finished eating, just started. Perhaps there is some, sharpened precisely on a similar picture?

The second question: please show a good example of a visualized algorithm diagram for such an application - whether it is a UML diagram, or a pencil sketch with rhombuses. If - Yes - No.

Answer 1

In general, this is a dataflow graph where nodes fire when data has arrived on all incoming arcs (as in (colored) Petri nets). From this point of view, callback is an arc transmitted in a message and to which a response must be sent.
Most implementations stick to the simplified actor model—nodes have only one input, so each message fires. What you need is to have multiple incoming arcs and fire when all of them are filled.
I don’t know ready-made solutions for actionscript, I only know for java - df4j (I wrote it myself, very simple).
en.wikipedia.org/wiki/Flow-based_programming
Actor_Model:
en.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B0% D0%BA%D1%82%D0%BE%D1%80%D0%BE%D0%B2

Answer 2

en.wikipedia.org/wiki/Callback_ (programming) It's not about patterns, roughly speaking, at the beginning of some action, give it a callback, which should be executed upon completion, and when executing the callback, see if this action is still needed. So the application will work asynchronously, and will not overwrite the data of other actions if the person did not wait for the previous one and clicked something new.

Answer 3

Maybe it makes sense to create an array of the requested data sets and fill them in as they are received, and periodically check from the interface pieces if the data for the current view has appeared?
Something like an array or structure:

struct my_data {
  bool received;
  uint32 request_time;
  uint32 receive_time;
  uint8 *buff;
  data_struct unpacked_data;
  ...
};

struct my_data_storage {
  struct my_data *main_data;
  struct my_data *section1_data;
  struct my_data *section2_data;
  ...
};

Accordingly, when opening any interface block (section), it requests its data from ... let's call it a "communication controller" - a thread or object responsible for working with remote servers. Next, the interface block waits, periodically checking the readiness of the data and displaying what you are displaying there (a spinning wheel or an empty plate or something else).
You can control reception timeouts, data aging, etc., the request_time and receive_time fields of the data block structure to help.
Algorithm example:
— The user opens the section1 block in the interface.
- We show this piece of the interface empty or with a spinning wheel.
- We look in the data warehouse for the section1_data field.
— — If it is NULL, the interface sends a data request to the communication controller, which in turn sends a data request to the server, creating and initializing the my_data structure with the initial values ​​in this field.
— — If it is not NULL, look at the received field (data received and parsed completely). If the data has not yet been received, we wait further. If the data is received, we look at receive_time for their relevance, if they are still relevant (the obsolescence timeout has not passed), then we display it, if not, we re-request it again (in this case, the section1_data field is reset to zero and re-created again, or simply reinitialized).
The communication controller, for example, can control the timeout for receiving data and set the flag of an unsuccessful request.
Well, etc.
Much depends on what you are writing on, under what system, on the implementation of the interface, etc. How to put it all together, you decide for yourself.
That is, the point is that each element of the interface works independently of the others: it crawls into the storage for its own set of data, initiates their request from the server, manages the display, etc.
Something like that. Do not judge strictly, this is just the first thing that came to mind after reading your question.

Answer 4

In addition to callbacks, it is worth remembering about continuations. Some of its similarity in AS can most likely be implemented.

Answer 5

On SO , the pureMVC framework was sensibly recommended - in the main implementation it is written for AS3, there are ports for JS, C, JAVA, PHP, Ruby and other languages. If you don’t use it right away, then you can at least evaluate the literacy of the implementation by watching introductory presentations about the structure of the framework. The author speaks somewhat monotonously, so stock up on coffee. But he did a really smart thing: MVC wrapped behind a Facade, the possibility of multi-entity modular constructs. Inspiring. It is likely that I will use it - both for the server backend and for Flash / Air clients.