This sounds like a table-driven lookup problem.
Do you load lookup tables from your Media folder at app startup?
This sounds like a table-driven lookup problem.
Do you load lookup tables from your Media folder at app startup?
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.
I looked at your sample procedure, hoping it could be consolidated and parametrized into some kind of standard form, like the way polynomials can be categorized purely by their coefficients.
Unfortunately, the 1/L exponent won't fit as a polynomial, and I haven't seen the other formulae to gather them into a universal parametrized format.
If the block count becomes a problem, you could shovel some of the complexity under the JavaScript rug.
JavaScript functions for your various formulae can be loaded dynamically at run time from the Media folder by Web component blocks, and can be fed through JSON objects (AI2 dictionaries).
I have a fairly old test server at http://memopt.ai2-ewpatton-temp.appspot.com that has some experimental performance improvements to the App Inventor UI. It might be worth trying to load your project there if it doesn't use any recently added components to see if the enhancements at least temporarily address your problem so you can simplify the code a bit.
To get a FIND facility and fine grained procedure and Event downloaded backups, see the browser extensions in
As you consolidate screens, you will need them.
Thanks for your efforts. I think I will try to avoid the JavaScript angle, as I feel that might just be a bit too complicated for me. These formulae are very specific to this topic and are not used probably another areas of science. They're all relatively simple math, it's just that I have the same four or five procedures on nearly every single screen. It would be great of course if there was a way to have global procedures.
Thanks! I will try that out when I get a chance this weekend.
There is - Virtual Screens, as already suggested by ABG
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".
Hi there, tried your test server. Lots of messages that my .aia was created in a newer version, then hung at 86%.
Your Project would benefit from going virtual Daniel. Remove the duplication of procedures across Screens and consolidate similar Screens. You can copy-paste a Screen to a Virtual Screen.
Make a back-up first, plan the task and work methodically.
Hi Anke, Kas is right: I had the same problem and it gives the "out of memory" error with chrome and with Microsoft Edge. I have applications with more than 10,000 blocks and the problems started 2 weeks ago. The same thing happened to a friend. If we load FIREFOX the problem is solved (so far I have not had any problems)
Best not to use Edge, it's never been confirmed as fully compatible with App Inventor - plus it's rather bloated now (even though based on Chromium).
That's a lot of blocks and the average App shouldn't need anywhere near that many. If you have tall (long) blocks that look like crocodile teeth and use a lot of 'If then' and/or 'set', you should be using the 'any component' blocks in a 'For' loop instead.
I as well think Kas is right. I have been consolidating my code, getting rid of about 1000 blocks, and I have been also able to get rid of a few pages by setting up different initializing profiles (the virtual screens proved too hard, since it required me renaming all my elements and variables, since I would have had many duplicates. But still, many crashes (like every 3 actions) in Chrome and Edge block editor, despite clearing my cache, etc. I noticed it especially crashes if I use the horizontal scroll bar or do actions too quickly, So I tried Firefox, and I've been using it for an hour, doing actions and scrolling as fast as I can without a single crash. This was also the case with Chrome when I last edited the app a few months ago, despite its size (I haven't made it bigger in the meantime), it never crashed while editing in Chrome before. So something must be new in the blocks editor that has changed how it functions in Chrome and Edge, but not in Firefox.
I think it's actually more likely to be the other way round - both Chrome and Edge have changed recently. Edge is based on Chromium and I think Microsoft are trying too hard to make it stand out from the crowd. Mozilla on the other hand do take pride in the stability and HTML 5 compliance of FireFox.
Thanks, interesting. But Firefox seems to be the browser right now for bigger projects. It is very functional without any delays.
It is very good, but everything has a limit.
No they don't - Screens do not calculate anything, the underlying code does - so instead of moving to a different screen for a different group, you could use the same screen and change the interface as required (This is what Virtual Screens are all about). After all, you can only display one screen at a time.....