Hello,
I've been away from the devel. side for a few years doing other work. Just got back around to MIT App Inventor yesterday, located my account info and backups, and Imported my .aia app files to https://ai2.appinventor.mit.edu which went quite well, and the interface looked the same with all my components showing up for each .aia, but I found that when I went from the "Designer" screen to the "Blocks" screen (tried this with both Firefox and Google Chrome (on Ubuntu Linux v22) the browser started to consume big resources, and the interface was essentially locked up, and had to stop the tab and the browser to stop it. This didn't used to happen. But my apps for Android written entirely in MIT App Inventor 2, were fine in 2014, so has anything changed that would no longer like the Block Code and so forth from 2014?
UPDATE: I just went in and checked ai2.appinventor.mit.edu again, and it happened to say it was updated, and I needed to reload/refresh which I then did.... I then starting checking my .aia apps again, and while the heavier duty apps (uses sounds for aspects of the program) did start to use disk resources again for a short time while the Designer was loading, this time it actually came back just fine, and I was able to get around in my block code just fine... So, I suppose this is the "new" ai2 code in this thread? If so, it definitely helped.
Second thing, I tried to locate the local running version of App Inventor, found the .tar version (which did not have very good install instructions) and was very old, as well as the .deb package install, which I got installed, and even got it running, but pointing the browser to the interface resulting in a web page error as well as the log output on the shell session mentions something about /home/mckinney/* something or other path errors, and this also is very old, like from 2014 as well. So I would like to find out of this is a newer version available somewhere for 2024?
In cased you missed the announcement, a higher capacity AI2 server is at
code.appinventor.mit.edu
(It costs more to MIT to run, so we reserve it for our special users like you.)
This board does not support non-MIT distros, but one of the other Power Users might point you to the support board of whatever offline distro survives.
How many blocks does your project contain? We updated the blocks editor environment in 2017, and some larger projects render more slowly in the newer version. Some users have had success using Firefox rather than Chrome under this scenario. Another update to the blocks editor is coming down the road and we are always looking for larger projects to help our colleagues on the Google Blockly team stress test the blocks environment.
Thank each of you for your input on the several items I was asking about, many thanks. I will definitely look at trying out code.appinventor.mit.edu with my .aia programs, look at AI2Offline for local use and the Release Notes for AI2. My musical instrument apps (concert zither and cello with motion sensors) have many blocks and also uses small sound files which I suspect(?) might be what causes the brief - a minute or so - disk usage load when going to the "Blocks" screen/interface (the Design interface was fine) in both Firefox and G. Chrome (when I first tried it yesterday, the ai2 interface would really get locked up, but after I reloaded ai2 at one point - per my UPDATE in the original post - it worked much better so it appeared to me maybe the ai2 code was updated), but will definitely look at using code. rather than ai. to see the difference. In 2014 I used both the local and online versions, and never noted Blocks had any issue. Many thanks again. And I see my post has been moved to this "Dusting off..." topic, so thank you for that too.
Here's a view of my Blocks... don't know if this will upload, I made it small as possible but still make out blocks...
If you would like to send me a copy of the project, I can ask someone from our team to analyze why the performance might be so poor when loading it in Chrome.
It's actually the same thing in both Firefox and Chrome, and also in the AI2Offline local version... click "Blocks" button and it's about 1-2 min. of audibly disk winding up, but then it calms down and Blocks load up after that and can be used no problem, so it is consistent which is good. Below I've provided a 'top' output during the issue, and right after it has wound down. You can see the processes involved. In the second screenshot, it shows Threads for the Isolated Web Co process, and one of them gets hammered at 100%CPU. So this is FYI if it helps.
8 of these vCPUs with Ubuntu 22... should give you an indication. But the computer I used in 2014 was not this one. (FYI I can l live with the delay as it is consistent, and I know what to expect, so this is just informational for you.)
You have not told us how many blocks are in your app (especially Screen1), or what you are running in Screen.Initialise on Screen1?
Note: do not move aia projects back and forth between MIT AppInventor (online) and your offline AppInventor clone. You will have problems. Stick with one or the other.
I'm sure that would not hurt however, the interesting thing with the top readings I posted before, is the only thing that went up was the one process thread going to 100% CPU and I see it using up to 3 - 11 GB of virtual memory as User mem goes up (not Swap though so it appears to be actual Memory), but the Load only slightly went up, while the Wait% did not go up, which I would expect if the disk was really having issues keeping up. So based on that, it seems more about a process using a lot of CPU time during loading the Blocks screen. The Isolated Web Co process looks multithreaded, but only one appears t be doing all the work during load up, though I didn't note if that is the parent.
Well, I posted a screenshot to given an overall idea, because honestly did not really know how you count "Blocks" unless you are literally counting all the puzzle pieces small and large. Looking at that screenshot which you can enlarge (and it is Screen1) it's estimate 400 pieces per screenshot (scrolling down), so x4 so maybe 1600. I do have a suspicion it is the sound files doing it, as I have mentioned before I think.
Far as using online AI2 vs. CODE vs. local AI2Offline, you are just seeing me evaluate those platforms, and what works best, etc. before selecting which one... will likely be CODE, as was mentioned to me early in this thread. I have no intention of using all or more than one, would be a headache.
Anyway, as I said, I can live with the pause during the loadup, since it is consistent, so no worries.
Ok, the closest right-click item seems to be "Delete 2937 blocks" (yikes!) for a Concert Zither app., and 1438 blocks for a "Fussball" (Soccer) app. Both of these also use code that uses the position sensors to update the screen items. Thanks for pointing this out, I had not discovered that blocks count, yet.
If you mean Screen.1 referring to how many Designer screens there are, there is just one Designer screen in each application... those apps change what goes on in the same screen, so the logic and settings are about that, such as changing the notes+colors+sounds, and as the phone is rotated, and similar for the football app changing the location of players based on an algorithm.
blocks unreadable
The screenshot of the blocks was to give an idea of how many there are before I knew about the blocks count item... You have to understand I was not giving away the code (yet)...
So again, I am not worrying about the 1-2 min. wait for Blocks screen to come up, as it is consistent, and it is less of an issue for the football app which has far less sound files, which is why I keep wondering if it is that. Also, something that I think is getting lost, is in 2014 on a lesser computer system, I was not experiencing this wait on loading the Blocks screen, but now on a better system it is happening. And I believe it's already been mentioned that in 2017 the AI2 code was updated and may load slower with large AI2 apps.
We are in the process of updating to the latest version of Blockly (the library that renders the blocks workspace). You could try loading your project there and seeing if there is any improvement in the performance:
Note that this is still experimental and it could introduce bugs in your code, so please make sure to keep backup copies of your projects.
(FYI I can l live with the delay as it is consistent, and I know what to expect, so this is just informational for you.)
however, the interesting thing with the top readings I posted before, is the only thing that went up was the one process thread going to 100% CPU and I see it using up to 3 - 11 GB of virtual memory as User mem goes up (not Swap though so it appears to be actual Memory), but the Load only slightly went up, while the Wait% did not go up, which I would expect if the disk was really having issues keeping up. So based on that, it seems more about a process using a lot of CPU time during loading the Blocks screen. The Isolated Web Co process looks multithreaded, but only one appears t be doing all the work during load up, though I didn't note if that is the parent.