Several users report on their inability to compile with the current API 28 release in Classic. I have actually validated that this is indeed an issue by attempting to compile a version of my app as it was saved last April, when everything was going OK.
Perhaps Thunkable should consider retaining the PREVIOUS version (Api 26) as a choice so that we could still develop and test while waiting for a proper fix of the 28.
Right now, we don’t have anything to fall back on.
1 Like
I performed a bunch of tests on one of my app that fails to compile under the API 28 update.
This app (already a simplified, development version of an app that IS published) features 217 components (arrangements, buttons, labels, etc.) and 5846 blocks in Screen1.
If I disable ALL blocks, the .apk is properly compiled.
I therefore entered a rather long experimental process of re-enabling blocks in order to determine when the compilation would transition from success to failure.
Here are my findings:-
with those 217 components, I had success compiling when 1934 blocks were enabled.
I had a compilation FAIL when I enabled an additional 9 blocks (i.e. 1943 enabled blocks).
With 1934 blocks enabled, adding one button (without any associated event blocks) caused the compilation to fail.
When the app was on the threshold of failing (i.e. 1943 enabled blocks in Screen1), downgrading the other screens (disabling logic there) had no effect.
It is therefore concluded that
- introduction of API 28 was accompanied with a SEVERE reduction of the memory space allocated to processing components and logic, perhaps by as much as a factor of 3.
- the Thunkable Classic development team seemingly lacks an array of possibly taxing, yet still valid and even already published, test apps to validate the capacity of any new compiler release to handle large apps
- the release of any new version of the compiler without the capacity for users to dial back a previous version of the API is hampering any development effort by users while new issues are (hopefully) identified, investigated, and resolved
- the lack of properly published limitations (maximum number of components/logical blocks that can be supported; or a quantitative “load” factor that combines the memory requirement of those – presumably, a list picker has more attributes and features than a label, and should reasonably be expected to require more ressources and take more memory, while a block unit in the logic page is likely to be less demanding) is making reaching the limit a hidden trap that will hit a developer late in the development cycle, without offering much in terms of possible work around.
Recommendations:-
It is therefore recommended that
- memory allocation of the compiler be assessed and restored to the level it had with the pre-API 28 version thereof
- that a mechanism be developed that would pre-compile an app while in development and return a % of maximum compiler memory load, so that developers know how close to the current limit their app stands
- that the compiler is revised so that out-of-memory condition due to excessively complex projects be properly flagged by the compiler, as opposed to being issued generic warnings that fail to identify the root cause of the problem
- that a mechanism be introduced so that users could tune back to a previous version of the compiler (i.e. do not take out what works until several weeks, if not months, has gone by without error being reported; and ideally retain at least the previous production proven version of the compiler)
- that an array of system-stressing apps be assembled, said apps to be test compiled and validated prior to the release of a new version of the compiler
1 Like
Hi there,
We are working on fixing bugs with the API 28 release as they are identified.
Thunkers have the option to download their Classic apps in API 26 or API 28.
When a Thunkers clicks ‘Download app’, they will see the download options of ‘App’ (API 26) or ‘App for Google Play’ (API 28).
Thanks,
Jane
Without the specific of announcing the API level, the choice and consequences thereof is not made obvious. A casual user may be tempted to select “for Google Play” because that is the final goal, and not even know that this will lead to a compilation error.
The fact that the current API 28 compliant compiler presently has restrictions is not properly documented at this level, and needs to be.
do you want to share your app (aia) with us, me and Jane?
Best,
Wei
If you want it as a representative ressource intensive model for testing purpose, to qualify future version of the compiler, sure. How can I pass it along to you?
You need to share your project’s .aia file with them through Personal Message :
Thanks! 
I dare presume, if Jane and Wei wanted me to share my code through private message, that they could have asked for it through private message.
At this point, it is not a technical issue as much as a legal one.
After these two option have been given for API 26 and API 28 i was able to successfully update the existing app(built on API 26) which is already published on play store but there is an issue that i am facing. When a user updates the app from play store the existing app version on his phone is not taking the update instead he has to completely uninstall the previous app from his phone and go with a fresh installation from the play store for the new update to take effect are you also facing this issue or is it only me??
Did you increment the version number of your app?
yes i did. I think it was a temporary issue it got resolved automatically
Thanks anyways