After a 2-3 week break, I open the project and see that a simple loop in Live on Android 8 starts working after the third or fourth click on the button? After that, the white screen. On Android 9, the situation is the same except that there is more memory on it and the white screen does not appear. Did something happen during that time?
Why doesn’t this code work? There is nothing special here, but the second row of blocks in the loop is executed when want it (every other time)
How large is the text string you put in _part1 ?
@actech If you re-open the project now, do you see the same behavior? We’ve accidentally introduced a bug in the execution engine, that I think we’ve fixed for your situation above.
Using the function type variables can end up causing issues due to the block execution speed. this is both a good thing and a bad thing it seems. Still though, making thunkable faster is what was desired! try switching back to app variables!
Text string 1.5 kb so that’s not the problem.
Paul, thank you for your attention to my question, but the problem hasn’t been fixed. The impression is that the blocks for working with lists do not work and there are some problems with calling functions, because I do not see a list in the function, but I see undefined.
If I click the button several times, an empty string is displayed instead of undefined. How can this be? I get the impression that there was a change in the mechanism of local variables and they just stopped working. But there are similar problems with global blocks. I had to make a project in App Inventor because I was ashamed to send the customer a broken project.
I tried global variables, but blocks also work with them every other time.
I remembered that at the beginning of the project I uploaded about 800 kilobytes of data to the text block. Perhaps this has had an impact, there were no such problems before. The blocks of local variables worked well.
I’m sorry the first fix didn’t solve the problem. Your second image led me to another fix that I’ll deploy soon.
The problem in this project is that the variables in parseData are not fully set before the setTitles function is called, leading the parameter to be undefined. An ugly (temporary) fix is to put a wait block before the call block is called, which would give the variables time to be set.
I’ll get out a fix as soon as I can.
@actech Let me know if the problem is/isn’t fixed for you now (you need to open the project and go to the blocks page for the code to regenerate).
The reason I asked about the size is not because the system is running out of space, but because it may simply not have the time to finish parsing the text into a list before the list is passed as an argument to another function, which will then get a not ready yet memory reference.
Try to wedge a slight time delay in your routine and see if that helps. If it does, then you would begin to understand where the real issue might be.
I agree with this. the blocks are executing so fast that it is causing issues wiht our standard practices of thunkable code
The problem was definitely a bug I caused. Indeed, execution was happening too quickly. Now those variables should be processed before the call block is reached, which should lead to what you would expect from the execution. Wait blocks shouldn’t be needed anymore to make this work.
@paulmw for the win! 
Yes, Paul, everything is working well now, thank you!
I understand you, but then it turns out an extremely incomprehensible situation that will lead to very big problems.
If the subsequent block is executed earlier than the previous block, then we are dealing with an asynchronous mechanism for working blocks in a linear algorithm. But in this case, this must use either a callback function or a signal in order to be able to keep track of when this operation is complete. Using a delay block in this case will result in either errors if the delay is not large enough, or a significant performance loss if the delay is too large. The amount of delay will depend on the phone’s power, the complexity of the algorithm in the previous block, and other parameters. This results in unstable and unreliable applications.
I think developers should give a clear answer to the question of how built-in blocks for lists work. If they work synchronously, there is no problem, if they work asynchronously, then I see a huge problem. I think you also understand this.
I read the last message from Paul, which makes it clear that the blocks are working synchronously, as they should be.
@actech Glad to hear it’s working. Thanks for posting about the bug - also thanks for your post on Thunkable’s performance. http://droidscript.ru/main/statyi/thunkablex_base11.php
This bug was caused by an unintended side-effect of fixing some of those problems. Now app variables work at a reasonable speed (so you don’t need to use procedure parameters outside of their proper scope). Cloning is also faster. Canvas blocks are still slow.
Thank you for your explanation and your work! I see that Thunkable X becomes a better and more functional!
