I’m starting a new thread here: on the problem of having asynchronous processing by default.
As with the issue I had with Alert Dialog boxes not being Modal and not waiting for user input but instead, all firing off at once: I have the same problem with my REST API DB calls.
I have a fairly complex (relational style) DB architecture. If I had a “simple” app where you push a button and store a few records, that would be all fine and dandy, but my App is not “simple”.
Uncontrollable asynchronous processing is causing unpredictable and wrong results.
One button push in this App can result in hundreds of NESTED data base operations.
ie: I create a whole bunch of “child” records. Then I need to connect them to Parent “A”. Then I need to connect them to Parent B. Then I need to connect them to Parent “C”. Basically, a Foreign Key relationship that in Backendless has to be created manually (unfortunately).
The problem is that in Thunkable: the “Do This”, And “Only” Then “Do That” is not honoured.
All of these nested operations seem to happen simultaneously, even though they are nested!!
(Or am I mistaken?)
What seems to be happening is that, for example, the “connect” to Parent “C” happens BEFORE the child record is even created!! So, “sometimes”, it never gets a parent! And the results differ EVERY time I run this, depending on the performance of the DB. This is nuts.
SO, I have had to convert these DB operations into Recursive calls as well to ensure that the child records are created BEFORE an attempt is made to connect them to their parents!
I assume that the only reason a recursive call works is that these are “forced” to be synchronous/single threaded calls? This creates unnecessary complexity. Also, what is the recursion limit? How many nested recursions can I do before the whole thing crashes?
Please…what seems to be like uncontrollable asynchronous behaviour is a potential show stopper for me.
I have prototyped this App on many platforms and finally settled on Thunkable.
I have now spent hundreds of hours and many thousands of dollars building this App.
If I have to tell my client: “Sorry” it’s going to take a few more months whilst I rebuild this App on another platform (at my expense), I have a problem…
I need some urgent and creative solutions to this problem or some guidance if I am doing this all wrong. But, if the “Do This” and ONLY THEN “Do That” is not predictable and 100% reliable, we have a problem.
We need a “Synchronous / Modal” flag on all of these kinds of operations. Which can default to “Off”, if you want, to preserve the behaviour and workarounds already done on existing Apps but going forward we need to be able to control this to make it 100% reliable and predictable.
Maybe what I’m about to say next doesn’t fit your needs, but this is just my opinion, so don’t be mad at me.
When I try to accomplish something, I take the resources that I have on disposal, and I find the solution according to those resources. I find the beauty in programming just in struggling to achieve my goal this way. Of course that the easiest way is to have resources fit to my needs, but this happens rarely.
In this particular case, your needs may not fit other’s needs (check this: [Solved] Can I cancel an alert? / Alternative alert modals).
I know, you said that we can have options on all blocks that are in this situation, to be modal or not. But I think that this will only introduce confusions. As a general rule, as @muneer taught me, purple blocks are mostly asynchronous, so when you see that, you know what to expect for (it’s predictable).
Working with asynchronous blocks and loops can be challenging, but as I said before, this is the beauty of an involved language. I remember back in '90 Basic language, with every command having numbered lines and acting in a straight line, and how confused I was 1st time when I discovered loops and infinite cycles - was like : good, how can I know where my app will go next ? 
I just want to reveal some of my thoughts, I’m sorry if this enrage you. It is not in my intention.
Hi mimostel
Thanks for your feedback. I started programming in 1974 and have probably programmed in most languages on the planet. I’ve also built some hardcore systems both on main-frames and ASP.Net C# systems etc. as well. So I’m used to making do and making things work.
I have implemented recursive routines BUT I have this moment discovered that the results are still unpredictable. Sometimes the parent links are created and sometimes not. Even if I run exactly the same data through each time.
I will have to look deeper and maybe the answer is in the Backendless DB.
I have the first delivery to the client next week of Phase 1 and this is just not helping.
The “Then Do” block should ONLY happen after a Response has been received from the REST API call. How else is one going to check the API Response to see what the Status Code was eg: = 200 and what the JSON response was. I understand that multiple purple blocks can run asynchronously but within a block itself it has to be synchronous! I have nested the API calls in the “parent” Then Do blocks and this doesn’t seem to work either.
Yap, I got you.
I’m struggling myself in some weird situations like:
or, older:
without any straight answer, so I understand your frustration 