Hi!.
I've added yet another web component and my app does not compile (see error below) while it runs in Companion. AIA size is 1057kB. It hase several extensions (I started to build extensions so to lower number of blocks on main screen - now 8100. 6 screens, remaining much smaller.
Any help appreciated
Thanks @Taifun.
Of course I've searched Community 1st and read that article and none of specific conditions apply.
By asking this question I hope somebody has found:
a) how to find what to reduce how extensions count agains blocks what is reasonable limit of resources (as e.g. I tried to build extensions in Niotron to limit number of block on Screen1 at 8k i.e. well below 10k and to reuse code between screens)
b) a way out. eg. local server, wait next release we are optimising, choose test server at ...
c) Maybe I've used AI2 past it's purpose and for my purpose AI2 is blind-end and I must migrate to AS/Flutter before I can do next release ? Hope not.
Thanks for asking dear @ABG.
This amateur radio logbook storing (and viewing, exporting) data in sqlite db.
The aia package is 1.1MB comressed.
Inside, there are assets consisting of 20 extensions (uncomressed ca 700kB) couple of png's (one big 129kB I can size it down) and 3 text files - all assets (including extensions) are ca 1MB uncomressed.
Screen controls (lists) are max 15 entries long and other text boxes keep short texts (most of them under 20 chars) and it did not change for a while.
Dynamically some lists grow big when fed from external web sources but it is nothing in compile-time.
Latest (breaking) change was adding to Screen1 ca. 100 blocks and 1 web object (4th instance of standard web component but to keep OnGotText event handlers short and because I can't tell if for same url it returns result of GET or POST I keep them separate). Screen1 has now 8175 blocks.
There are 5 other screens having 1300, 1300, 13, 322, 1870 blocks respectively.
Dear @Taifun ,
I try but AI provides no way of DRY between screens. I can only copy blocks or make extensions (this is the way I've chosen for pieces tested and stabilised after a while).
Best regards, Kuba
When we define virtual screens, we use one 'real' App Inventor Screen (most often Screen1). Screen-sized Vertical Arrangements on it are displayed/hidden as required - they are the Virtual Screens. This is generally a better approach for multi-screen Apps, they share data without having to "pass" it between screens and it also reduces code duplication, making the App more efficient and the code easier to follow if you have to return to it at a later date. So, instead of separate "houses", virtual screens are "rooms" of the same "house".
I'm working on a large program with several virtual screens and a massive list of images in Assets - 1490 Blocks, 3.75 MB Project file, 7.17 MB APK
There must be some room for optimization in your code blocks.....
Also, are there any unnecessary features? Things that do not contribute to the core mission of the App?
Sorry for posting so late but I did my homework.
Thanks again for all hints, comments and questions that inspired me to find fix (I hope). Finally:
The only aspect that did seem to cure DX execution failed (in my case described above) is lowering Screen1 number of blocks below 8000.
Complexity, number of objects, number of extensions, number of screens (6), total blocks on all screens did not seem to matter. My fix was to remove over 500 blocks used in constants definitions by:
Load (lengthy) dict driving sqlite databes automatic upgrade to resource files (JSON) and load it when upgrade runs,
Have all needed config dicts in config file/db and load then on Init.