I meant only browser and internet related problems. The first question you ask is about the number of blocks. Compiling has nothing to do with the computer, but internet quality has a lot to do with recording transactions or not.
Phone/tablet/monitor: just to be used on these devices. The memory problem is one of the problems associated with navigating a lot, using high resolution image files, and repetition too much. I say without hesitation: The memory problem is the problem of new users.
.... Was your solution with those buttons to use an 'any component' Block, effectively 1 event instead of 1000? Interestingly, Oliver reported in Post#22:
@ewpatton, Profi's findings concerning the DX error are very interesting - it seems to point to an App Inventor limitation that perhaps should not be there.
Builds are performed on dedicated servers at MIT (sometimes AWS). The only part of the build process that happens on the user's computer is the generation of the YAIL (Scheme) files from the corresponding Designer/Blocks files. Once the YAIL files are saved to the App Inventor server, the server packages up the project and sends it to the buildserver for processing. The client simply checks back in with the App Inventor servers for status updates every second or two to update the progress bar until the build has completed and the APK (or IPA for iOS builds) has been sent back to the App Inventor servers, at which point the dialog is shown with the QR code (APK/IPA only).
Maybe I missed it in this thread, but is there an actual AIA for us to look at?
If I deactivate the red marked "Join" statement (it has a lot of blocks below), the project builds successfully for me.
But I do not see a pattern that exactly THIS join statement has an error, e.g. I can have it activated and deactivate something else instead, then it also builds.
All strange...
Misused when any Taste.Klick. If you have many buttons, you need to use a different argument. You should do your work by missing some buttons from triggering when any Taste.Klick.
Let's say you have 500 buttons, 10 of which you are going to trigger alone, run the rest with when any Taste.Klick, but specify those buttons at when any Taste.Klick.
for example, I am calling functions of 70 individual buttons with the following block. The article is in german and sample codes, but nothing changes.
if some specific button's click event is defined seperately, you can excluded it from the any button click event by using if (not already handled) then ...
no need to check if (component !==some specific button)
I pulled a thread from the blocks area and started to expand it.
It's still unraveling ...
It's the set_visibility procedure, with 797 blocks.
(It was too big to upload to this board, when halfway expanded.)
Here's the draggable compacted form:
This appears to be an explicitly coded recursive visibility management scheme covering a tree of nested Arrangements, with +/- Labels (Buttons?)
I have yet to encounter any tables of components in the Blocks workspace.
This procedure might benefit from being table-driven, from a component table with columns:
@Profi & @Kevinkun thanks for your effort and input. I appreciate it.
But I have to say that your findings are in my opinion not the reason (or at least not the only reason) for the DX error, as i can build my apk with all those finding being enabled.
Hi @ABG , yes, your observation is completely right. It is a procedure that I call to show or hide certain screen elements, some of them even nested.
But i have to say, the whole procedure is completely enabled - and my APK still builds!
So this procedure itself, stand-alone, seems not a problem.
KR, Oli
So I've looked into it on our end, and the issue appears to be that the DX process runs out of memory as we only give it about 2 GB of RAM. When I increased the amount of RAM to 3 GB it built fine.
Evan, thank you!
Does that mean that now 3GB RAM ist the new setting?
And if so, does that mean MY poor app lead to that increase from 2 to 3GB?
KR, Oli
No, we have not adjusted this in production. This was just using App Inventor built locally to understand what was going on. I need to talk with our team about whether this should be adjusted in production.
Hi Evan (@ewpatton) , i want to check in on that topic again. A month ago you said that my project failed to build b/o 2GB RAM running out, after increasing it to 3GB it worked.
I have been able to work on my project for the last weeks sucessfully, the DX error did not appear anymore.
Did you increase the RAM in production too?
KR, Oliver
We've replaced the build server instances with some newer ones that should be more efficient, but we're still keeping the cap on memory usage per build to 2 GB (each buildserver tries to serve up to 30 users at a time).
