My Project can't Export API 26 and 28 APK. PLEASE HELP!

Hello,

I have a project has 10317 blocks. File size of its last exporting apk is 6 MB. (Now maybe 6.2 MB)

But I can’t export it as API 26 and API 28. It has compile error. It says:

When I remove all blocks from my project. It can export API 26 and 28. But when I add global variables and only two procedures(totally have 939 blocks), it again has the compile error. I attached the two same projects have compile error and have not. You can try to paste the procedures from the app which works fine to the app which has compile error. You will see the healty app will has same compile error too.

I’m very confused for that. Please help me. I’ve spent two months for this project!

THANK YOU

The API 28 compiler is suffering from limitations (bugs) that need to be addressed, being unable to handle projects that compiled fine with the API 26.

However, there was limitations in the API 26 compiler as well, as I can assure you, from first hand experience, that if your application is too memory intensive (bearing in mind that a component takes perhaps as much memory as 10 logic block – this being highly variable as a label will have less attributes and methods than, say, a text box, with the latter thus taking more memory) it will not compile.
Mine has about 100 components and slightly over 6000 logic block in one screen, and is nearing the limit.
With 10000+ block, it seems you are beyond that limit.
And judging by the number of arrangements visible on the list on the right of your screenshot, plus the massive number of non visible components (at least 4 web views? Why? Why not use the same with different URL??? And at least 12 Firebase???) you are possibly exceeding that memory limit by a factor of at least 2.
I am surprised that you had something that did work before to establish the size of the “last exporting apk”. Did you substantially increase the size and functions?

By the way, and for the record, when nearing the limit, and while the code would still compile, it may start exhibiting instabilities; that is reporting operational errors almost randomly, in a manner that is non-trackable; add a notify to see what the result is that is causing the issue, and the error moves around and affect some other part of the program.

Your trimmed-to-939-blocks-aia file does compile with API 26, but fails with API 28; so at least there, you are in the same boat as many of us waiting patiently for Thunkable to fix the memory issue.

But even when (they stated a couple of weeks, we are at the end of the 3rd already…) the 28 compiler gets fixed, you’ll still have to deal with the issue that your code is way too big.
And there are several things that you can do about it.

1- spread your functionalities over several screens. The memory limitation (number of components + logic blocks) seem to apply on each screen separately. Of course, you may have to add a bit of code to harmonize and manage the screen opening and closing and information exchange between them, so splitting a program between two screens make the total size larger.
2- optimize mercilessly. For instance, one of your only surviving procedure “activeinactive” is doing the exact same processing to split, select first at index, split at split and split for a few different test string being requested. Why reinvent the wheel multiple times? Have the split-select-split handled by a SINGLE generic procedure, called multiple times with merely a different argument. You’ll save dozen of blocks like that. Also, if you have long extraction thing to make a test, and then if the test is positive, you perform the same extraction but this time to do something. Why not extract the value that is part of BOTH the test and the processing, save it in a local variable, and then do the test. Then the processing is done on the SAME local variable, without having to re-extract again.
To give you an idea, there were several instances in my program where a value needs to be incremented by 1. Instead of having “set’value’to get’value’ + 1” (4 block), I created procedure “plusone”, which takes “value” as argument, and returns it incremented by one.
The procedure add 4 blocks overall, but each call is now 3 blocks. If you think that this excessive, think again. It was necessary, along with several other tricks.
3- if you are STILL stuck with more processing that can be accepted by the compiler, then you may consider getting the processing done outside of Thunkable, by having the computation done by an HTML/Javascript called by a webviewer, using the webviewer string to exchange information. I use this in my app as well, not only because it reduces the block count, but because Javascript is processing data about 700 times faster than the equivalent in Thunkable.

2 Likes

Thanks for your help!

Okey, I will reduce my blocks and components. Size and functions of the last exporting apk for API 26 (6 MB) has been increased substaintially. I’ve firstly spread my functionalities over several screens. But passing from one screen to another screen has caused an error. There, I try to remove all block for this activity excluding the “open another screen” function. And surprisingly “open another screen” alone gave me an error which alerts “End Application”. And this error appears at only the third attempt is consecutive. (I click 3 times open another screen functions, the third click ended my app while there is nothing around). So I’ve decided to not use more than one screen. But I will use more than one screen again.

I think Thunkable suffers webviewer component too. I can’t try some html in Thunkable works fine in sites. For Google Drive database to use sending and getting pictures functionality, I used Web App (Google Script) with Javascript. Could you send me some javascript projects in Thunkable? I have firebase javascript code. But I should work on it.

I will be back, after reducing blocks and spreading blocks over several screens by the way you said.

You should never open another screen without closing it later, except for screen1.
If you need to open screen2 and then move to screen3, you need to have screen2 closed and pass the information back to screen1 that screen3 should be opened next. That means managing screen control through start and return arguments. Or passing information through tinyDB, which every screen should visit if required when starting.
The issue is that opening a screen creates ANOTHER instance of the screen. If you never close them, you have an ever increasing number of pending settings and variables that keep accumulating, and eventually the device simply runs out of memory.
It is suggested that this precisely is what happened when you opened another screen 3 times, you basically had at least 4 screens pending.

2 Likes

Okey thank you.

For the feedback, I reduced my blocks from 10317 to 7777. And I can export API 26. But to not get limitation error, I spread my 1300 blocks another screen. So I have aproximately 6500 blocks in one screen. I suppose I have no error from limitation.