No, it does not.
Ok, thanks. But… Are you going to fix this?
No, those extensions are not my. This is @Helios responsobility, and if he doesn’t care of anything, that’s his problem.
Ah ok thanks for the info!
As a side note, I would recommend everyone to have a backup plan or a plan B when designing your app. I mean a version of your app that might not look so cool or have a different way of achieving something without using that crazy amount of extensions, just 2 or 3 tops. I don’t think is a good idea to have so many in one projects, but I might be wrong.
Hi @Italo…do you mean that is not possible to do a great project?..one with 10.000 or 15000 blocks and lot of arrangements?..why?
In my personal experience, at around 6000+ logic elements in the block page of a screen, your app may start displaying instability, i.e. some stuff does not work properly, and attempt at tracking it move the error to some other place.
At that point, you may have to add screens and bundle some functionalities to be done out of screen1 (despite having multiple screens requiring to add yet more logic blocks to manage screen transition).
The load on the compiler combines the logic blocks and the components; you can have more logic processing blocks if you have less components (and each components varies in term of of how many logic blocks it may equate to–a label would take a less ressources than a textbox for instance, as it has less ‘options’ that require defining; even if you use only the default values, they still must have the associated elements).
But this is all academic at present anyway, since the newly released API 28 compliant compiler is failing to compile apps that worked just fine with the previous release. I established that my 127 component and 5846 blocks app (in Screen1, the other screens are smaller and are not the contributing to the current problem) will only compile if I disable most of the blocks: with 1934 active block, it compiles; with 1943, it fails.
The conclusion is that the memory allowed is perhaps 1/3 of what it used to be with the previous release of the compiler that was on line last week.
Thanks by your complete and clarifier answer…but too bad for me.
Do you think that it shall run with an offline version like AppyBuilder?
AppyBuilder works very similar to Thunkable to the point you can import an .aia file that will require very limited adjustments to work, but I do not know if they have implemented the API 28 level compiler yet.
If they haven’t, you are going to be facing the same issue there as you do here.