You can go through my check list too - much of it applies equally to the Project file as it does to the App.
https://www.professorcad.co.uk/appinventortips#TipsApk
Hi,
I found out what was causing the problem. It was that Chrome's and Edge's memory cannot load all the data. I installed and tried Firefox today. That worked out well. No lagging when editing large blocks (which was a bonus for me).
I've been working with Chrome & Firefox on at least a dozen computers / notebooks for more than 10 years and have never had a problem with it - neither with AI2, Thunkable, AppyBuilder, Kodular, Niotron etc.
However, sometimes you have to / should delete cache & history.
1 Like
Hi Kas
Anke is right - Chrome will give similar performance if you clear the catch and old browsing history. Do not use Edge for App Inventor, it has not been approved by MIT (though it practically is Chrome with a different name).
Concerning your large procedures, post your Project file here and we can look to see what optimisation could/should be applied. With that many Blocks per procedure, your App could lag.
How many screens are in the project? There is a performance issue with a large number of screens due to the overhead each screen entails in the editor so that could also be a source of problems.
PS: We are working on upgrading the blocks editor, so if your project does have a lot of blocks we'd like to include it in our performance tests.
1 Like
Seeing how close you are to losing the ability to work on your project, now is a good time to pay attention to your backup hygiene.
- daily .aia exports
- individual procedure and event block downloads as you change them
The second backup option gives you incremental restore capabilities, since the block images can be dragged (if not editted) into other projects
There is a handy browser extension for taking mass block image downloads in
1 Like
Currently, I have around 35 screens (I expect to be adding more screens in the future). The registration screen has the most blocks. The estimate amount of blocks it will have in the near future will be around 45,000+ (currently, there is a little over 20,000 blocks). The reason for this is that I am planning on adding updates for the next 5 to 7 years. The other screens have around 2,000 to 5,000 blocks (minus a hand full of screens). I haven't added any images. 5 to 6 emojis are being used as images at the end of each stage. I plan on adding images in he future, but not a lot of images.
I think you should stop developing and rethink your design. 35 screens are way to much. What is your project about and why do you need so many screens?
I guess this can be done with a lot less screens and a lot less blocks.
Show the blocks you are using.
Maybe post your aia.
1 Like
No matter what language you program your App with, 35+ screens is too great from both a technical and a User perspective. I suspect that you don't really need so many Screens nor so many Blocks, it is down to the way you have designed the Project. It is most likely possible to reduce the number of Screens and Blocks with a different coding technique, as I previously suggested in post #7.
- Make a backup of your Project
- Post the Project (.aia) here for us to take a look at it - let's see if we can rescue your idea without the bloat.
1 Like
I am having a similar problem, 23 screens, each 1,000-3,000 blocks. Are you interested in my aia file? I have tried all the tricks with different browsers, clearing cache, no big images, no other open tabs, etc. I have 64G RAM and it still crashes. This is a relative new problem.
Hi Daniel,
Are all those screens different or do they look the same? Always wondering why someone would need more than 10 screens. Most of the time I stick with 1 or max. 3. I only made more than 10 when I first started using App Inventor.
Each screen calculates growth parameters (height percent, weight percent, etc.) for different groups of kids, healthy and those with medical conditions. For each group there are different kinds of normal references and different age ranges and intervals, so the calculations are to a degree unique for each group (and therefore each screen). There are some similarities, and it would really help if we had a way to reference global procedures common to many screens without having to put them on every screen. I could probably consolidate some screens to be truthful, as the appearance of many screens is similar, but at this point those screens would get more complicated since every one would basically have to contain much of the code from the screens I've consolidated. So fewer screens, but only a small reduction in the number of total blocks.
Sharing procedure(s) across multiple screens are not possible. But, still you can experiment, taking benifit from this topic
1 Like
Thanks, interesting, I'll take a closer look. I guess maybe another way to do this would be to build an extension that does the procedures I need.
Yes, that would be possible in principle, but if almost the same procedures are required / executed on all your (real) 23 screens, virtual screens are definitely the best solution.
1 Like
May we see an example (the blocks) of one of these procedures?
This sounds like a table-driven lookup problem.
Do you load lookup tables from your Media folder at app startup?
1 Like
Yes, I have a separate lookup table for almost each screen. That works fine. The one problem is that the 20 tables are all formatted differently, in that they contain slightly different information (height, weight, etc.) and that the time intervals between rows is unique to each table (and sometime varies within a given table). These are all references from the medical literature, all from different research groups.
Yes, thanks, looks like I need to study virtual screens much more closely to see if that will work for me.