it seems to be, you reached a point, where only one screen will not help anymore for your requirements... 30-40 arrangements in one screens seem to be too much... therefore let me suggest you to split the screen into 2 screens and have 20 virtual screens in screen1 and another 20 virtual screens in screen2...
In fact, my app only has 4 virtual screens. The rest, are inner Vertical and Horizontal arrangements to help distribute the labels and textboxes properly on the right location (centered, etc.).
At any moment, there is only one virtual screen visible and the other three are invisible. I do not explicitly set visible=false for the inner arrangements, labels or textboxes as it is not needed, but I will give it a try just in case it can save processing effort.
Hello, I managed to reduce the number of arrangements to only 17 and I still can reproduce the crash of the companion app.
Could someone test the Crash8.aia file to confirm that it also crashes in their environment please? If this is the case, I would like to propose it as a bug.
What does "crash" mean here? Which error is displayed.
Does this happen with Companion and / or the APK?
The aia opens with no issues (Companion) (but there are no blocks).
Hi Anke, thank you for your time. I removed all the blocks and resources (image files) to demonstrate that they were not the cause of the problem.
In my environment, the companion app closes immediately, without displaying any message on screen. Please see the log of the exception in my previous post (I obtained it using the adb tool).
Could you confirm if you can launch the companion succesfully in your environment?
Do you have the same issue if you create a fresh project with just a Canvas?
A deeper inspection of your stack trace from adb logcat indicates that a null object is being referenced, but according to the Android documentation the call that sets that value should never return null. What version of Android are you running, and on what device?
Perhaps it worths to comment that everything works fine until the moment I add the 17th arrangement. I mean, if I delete one of the arrangements, the issue disappears and everything works fine (with 16 horizontal/vertical arrangements). But if I add it again, it starts to crash again.
In the adb logs, do you see anything about memory issues before the null pointer exception? I could imagine that it might be failing to allocate memory for the scaled bitmap and returning null instead of throwing an OutOfMemoryError (although the latter would make more sense).
@ewpatton, I have checked the logs thoroughly but I have not found any other error log related to the app, nor any other log in general related to memory issues.
However, I have somehow managed to “fix” the json of the graphical interface, after a trial and error process that took me a few hours. By simply rearranging the arrangements, I manage to avoid the crash!
IMHO, my intuition after 25 years programming in java tells me that there must be a bug. But I would need the help of someone skilled in the field to finish finding it.
Please examine the files in the order I have uploaded them: The Screen1.scm.works-fine1.json file is processed correctly. But if I move either of the two components VerticalArrangement8 or VerticalArrangement9 just before VirtualScreen1, the crash occurs (Screen1.scm.causes-to-crash1.json and Screen1.scm.causes-to-crash2.json). However, if I move the VerticalArrangement8 and VerticalArrangement9 components right after Menu, it is processed correctly again (Screen1.scm.works-fine2.json).
I cannot understand why, but I have observed two things that have surprised me:
Some Uuids have a negative number
Some arrangements are missing Height, Width, or both elements
UUID here is a bit of a misnomer that's carried through App Inventor over the years. It's just a unique identifier, not a true UUID. The UUID in App Inventor is just a 32 bit signed integer.
We only store values for properties if they differ from the defaults, so if you don't see a Width or Height value, the value is usually "Automatic" by default.
If you could dump the whole adb logcat from launching the companion through the crash, that might give us some additional information to look at w.r.t. the crash.
I have little idea of it, but I noticed that the "Width": (eg "-2") of some arrangements is missing. (Logcat: “E Bitmap : width and height must be > 0”)
Hi Anke, thank you for your hint. As far as I know, values -1 and -2 (meaning “Automatic” and “Fill parent”) have a special treatment. I am confident that it is not causing the problem, although it is true that the message registered on the logs can be a bit confusing.
Height and Width have the following interpretations:
Non-negative values indicate a specific pixel value for the dimension.
For negative values, there are three potential interpretations. -1 indicates Automatic, -2 means Fill Parent, and values < -1000 are used to encode percentages, e.g. 75% = -1075.
For any property in App Inventor, we don’t store the value if it is the default value. This keeps the files smaller, which decreases the time to load/process/save files.
@ewpatton, I am attaching the full log (adb logcat) corresponding to the 23 seconds that it takes from the moment I launch the companion, I scan the QR code and finally the app crashes. I apreciate your time. adb_logcat.txt (652.0 KB)