Chromebooks hang waiting for blocks

I hope someone has an answer for this.

I got the mit app inventor app installed on district chromebooks, but now when my students try to run their apps, it just hangs on "Running using the emulator or USB, waiting to get blocks..."

These are district chromebooks. Is there something I can do to get around this?

"mitapp

Have you checked FAQ Section: Chromebook ?

Also, if this is your first time with AI2, did you go to ai2.appinventor.mit.edu and start a new Project? The thing you installed is just a debugging aid.

Perhaps I'm a little confused by your statement.

This is from a project that students were working on. They built an app (so yes, started a new project), then went to connect, then Chromebook.

The app we downloaded was the ai2 companion as dictated on this link:
http://appinventor.mit.edu/support/chromebooks

This message is showing on the ai2 companion app

I did check the FAQ, but was unfortunately unable to find this specific error.

I honestly wouldn't even know where to find the debugging aid is I looked

Never seen that happen before Russ - but it looks like ticking the option 'Use Legacy Connection' is worth a try?

When running App Inventor on a Chromebook, you should get a Chromebook option under the Connect menu. Use that to connect to the companion installed on your Chromebook rather than the Emulator option. If for some reason you don't see the Chromebook option under Connect, start the companion separately then use the AI Companion option and type the 6 character code into the box when prompted.

Please also let us know what Chromebook make and model you are using if the issue persists so that we can acquire one to test with.

1 Like

We don't have the emulator option under the connect. Only the chromebook and the other one (ai2 companion?).

We tried entering the code, and it still just hangs. However, it just hangs at the screen to enter the code.

I'll see if I can get the make and model for you. I'm pretty sure that we are running several in our district though, and it seems to be an issue across the board

Same issues, a little more information. Hoping someone has solved this already, as we have lots of students waiting for this.

Some information here - in my testing of this with my IT team, we have made the following observations:

  1. Student devices appear to operate differently than staff devices. On student devices, we hung on the "connect with code." On staff accounts, while the progress bar does take a minute, it will connect.
    Be aware that you have to look for the progress bar. Once you click on "connect with code" you, you have to click back to the browser to find the progress bar. It may appear hung because the progress bar for the connection does not immediately pop up.
  2. the progress bar can take up to several minutes to complete the connection. This can also feel like it is hung, but we found that the test devices did eventually connect. This may be an artifact of slower internet speeds at the user's location (my students are all at home in distance learning.
  3. in student accounts, no action happens after clicking on "connect with code." No progress bar appears.

I never resolved the issue, and decided to rewrite my curriculum for code.org's applab.

I believe it is a school filter issue. We were able to get past the hung screen, but then my students apps started crashing as soon as they opened them. Unfortunately I didn't have a student chromebook of my own to debug this issue, and trying remotely just didn't work. It became to frustrating for me and the students, so we just moved to a different platform.

Just a quick note on Phillip's comment:

I originally could not even get the progress bar to pop up. We did after a IT went back and white listed it, but then the apps started crashing as soon as it opened

If you could have your IT team reach out to us to describe what they did regarding blocking, we can try to replicate it on our end and make the companion app more robust to this in the future.

I asked, and his response was:
All I did for you was to whitelist .MIT.EDU.

Some things to consider while ya'll are lamenting.

  • Student's often do not get the 'quality' hardware issued to teachers. You need to test using the student's possibly lower quality cpu etc. and his/her network.

  • Part of the chain of unfortunate events is the school's connection to the outside world. The school network was probably under powered prior to the pandemic. With significantly more Internet usage, App Inventor is competing with Zoom, online learning, and all the other software the school uses. Consider an anemic school network.

  • hang waiting for blocks. Oh no..... test this during off peak hours, the performance might improve dramatically

  • Every day, since online learning began a week ago, my Fios fiber connection goes 'soft' and sometimes, if not already connected is impossible to connect to; presumably because of high levels of Internet traffic. When the home network is shared (particularly when a family member is streaming video), my Win10 late model I7 struggles (but doesn't gasp like those Chromebooks)

  • For the past two weeks, compiling has been very slow as nascent developers and commercial developers use up band width. MIT has load balancers; these take time to kick in meaning things are very slow until they kick in and then still slow. App development contests contribute to heavy usage.

  • the prime reason for poor response using the MIT server until recently was the user simultaneously developing, streaming audio or video etc. with lots of browser windows open. To maximize use of the Web App Inventor app, turn off this stuff. Schools then had issues with students connecting to App Inventor. Often, after lots of haggling with their administration and IT people; the network was upgraded and the grumbling was mitigated if not eliminated.

  • students, working from home often do not have decent Internet. Whether they are on dial up, sharing bandwidth using a fast food outlet, a portable 'hot spot' (which is certainly slower than a fios fiber Ethernet) means the students get the shaft.

  • students, naively build video streaming apps and apps with lots of over sized images (which usually means the Project takes a long time to load using Companion and the Project's almost gag using an emulator. I can't imagine how much slower a Chromebook might respond to running the emulator versus a modern desktop Win10 or Mac. MIT hopefully has a low priced Chromebook to test performance compared to their Macs.

MIT is going to continue to improve App Inventor performance. Keep in mind, schools etc. can do things to improve their performance and the hardware issued to students and student's Internet options at home. My home Internet is fast; I have a new Win10 and I too have issues connecting to App Inventor on occasion, and I don't have a Chromebook (I got rid of my lemon). I don't share bandwidth with a class of 20 (in person) or have the lowest quality Interned speed. Try to make the best of less than top of the line hardware and Internet connections.

This might help with ITdepartments * School IT/Network Admins: Information specific to school networks (also helpful for conferences and hotel situations)

Regards,
Steve

1 Like

Thanks for your comments, everyone. We will update this thread if we find any solutions. So far nothing.