Testing the next release of MIT App Inventor (nb187)

[ewpatton]

@Taifun

also is gone, which means, it is a table arrangement issue

More specifically, the bug in the TableArrangement throws an error, so any components that are in the Screen after the TableArrangement won't be instantiated correctly. I've submitted a patch to fix this and it should be in the next test release.

[Patryk_F]

What happened to the apsolute arrangement? I can't see her on the list

[ewpatton]

Unfortunately I ran into a bunch of issues that I haven't had time to resolve, so it won't make it into this release. Hopefully once the Appathon is wrapped up I will have more time to devote to getting that finished.

[ewpatton]

@Taifun

however after building the project then the errors occurred, because now in SDK30 it is not possible anymore to for example copy a file to a random directory of your choice...
it would be great to get the errors already while using the companion app...

This may be due to the fact that existing apps are grandfathered in during the upgrade to Android 11 whereas newly installed apps will not be allowed to write to restricted locations. If you uninstall and reinstall the companion, it should lose the exception and behave similarly to the compiled APK.

[BeksOmega]

@ABG

One thing I did not fix was the reference to a missing Screen at the bottom.

It did not appear on the warning or error counts and it showed its status with a new, unique error indicator: a red border.

Using the pulldown list to select a Screen removed the red border.

I wonder why the potential error (opening a nonexisting screen) did not get flagged with a red or yellow X and appear in the error block navigation lists and counts?

Honestly I don't know why I didn't use errors for this haha. I looked back at the git history, and it seems I just didn't think of that. Maybe it was because I had fixed deprecation around the same time? But yeah this should use errors. Sadly I don't have time to put in a fix for this right now but if someone were to put up a PR I'd be more than happy to review it.

Thanks for trying out the new dropdown blocks I really appreciate you giving them a look and finding those bugs!

[Anke]

@Taifun

the tests in the companion app did not result in any error... also the files could be copied and deleted as previously

1. If the file "foto.jpg" already exists in the folder /Download then it is possible to copy it to "foto.jpg" or → foto2.jpg:
   

   
   
   

2. If "foto.jpg" does not exists in the folder /Download:
   

   
   
   

@ewpatton

If you uninstall and reinstall the companion, it should lose the exception and behave similarly to the compiled APK.

No, un- / reinstalling Companion app doesn't change anything.
It behaves in exactly the same way - as described above.

But if I create the APK and run it, it is (of course) not possible to write (save, copy) to /Download (because on Android 11, targetSdk=30), WRITE permission is ignored - does no longer exists).

So for the Companion app WRITE permission might be declared this way (to avoid this issue with Companion):

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" />

as I already I mentioned here:

File component - save (all types of) files in the Private dir (→ internal storage)

It is currently not possible to request READ or WRITE permissions, because the File component (incorrectly) no longer declares these permissions in Manifest. But it should do it like this: <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" /> I checked it on Android 9 after declaring the permissions in the Manifest.

[ewpatton]

We have updated http://ai2-test.appinventor.mit.edu/ with some new fixes based on earlier reports. Thanks for everyone who has reported issues so far.

Bug fixes:

• Fix an issue where closing the ListPicker caused a stack overflow (@MohamedTamer94)
• Fix issues related to the updated behavior of the File component
• Fix typeblocking for some dictionary blocks
• Fix a bug related to the TableArrangement
• Fix a bug preventing assets and extensions from loading properly in the companion

[Anke]

Again: Listing of the assets does not work (tested with the APK):

So please show the block(s) how to list the assets.

Note:
You don't have to be a prophet to predict that there will be chaos after the update if even seasoned users have trouble understanding the new filesystem.

[Taifun]

@Anke

show the block(s) how to list the assets

Try it with an empty textblock as directoryName
Edit: the old logic // for assets is now obsolete...
Taifun

[Anke]

Light slowly comes into the dark:

[Patryk_F]

Were helper blocks tested with extensions? Because I am getting an error.

What is *your* opinion about helper blocks in App Inventor? (GSoC Project - User Feedback)

As for extensions, the truth is that you will still need to use green blocks for constant values to ensure compatibility with other builders. Unless other constructors also introduce helper blocks. [helpers] After checking in Companion and APK, however, it doesn't work. [helpers] [Screenshot_20210801-190716] Everything according to the descriptions of @BeksOmega. Tested on NB187 release test server.

I am using the UCR source to build the extension

[TIMAI2]

You already suggested it in post #27

Testing the next release of MIT App Inventor (nb187)

Hello, I would like to make a proposal: I would set as default the device default theme instead of classic, because I think it gives a more professional look to the apps. Thank you very much [image]

now there are three four posts cluttering up the topic.....

[Meulencv]

@TIMAI2

now there are three posts cluttering up the topic.....

Ok, sorry, as no one had answered me I didn't know if you had seen it, I'm really sorry.

[ewpatton]

Here's an example where I copy files from the assets to the app private directory. You could also use the private directory, but that's more complicated to verify. This worked in both the companion and APK on a Samsung tablet running Android 10.

HelloPurrAssets.aia (186.0 KB)

[Anke]

@ewpatton

Here's an example where I copy files from the assets to the app private directory. You could also use the private directory, but that's more complicated to verify.

Tested on Android 11, Companion:

[Boban]

Since I don't have the ability to upload to GooglePlay I had to extract the apk from aab file..

Player component doesn't play sounds from assets, neither do I get any error.

Can someone confirm this.
MusiPlayMIT.aia (3.4 MB)

P.S. It works if build as apk..

[Anke]

@Boban

Player component doesn't play sounds from assets, neither do I get any error.

Obviously the same problem as Kodular.

[Temporarily solved] Error 701 when installing app from the play store

Audio cannot be played - Unable to load (Only with AAB)

[Anke]

@Boban

Player component doesn't play sounds from assets

Did you also check this with the TaifunPlayer?

[Boban]

@Anke

Did you also check this with the TaifunPlayer

Just tried and neither does Taifun's player work but this one at least tells me that it can't load audio file..

[ewpatton]

Thanks for the AAB reports. I've put it on my calendar to look at it this afternoon. If I had to guess, my first thought is that the assets are ending up in a different location when the APK is reconstructed from the AAB than where App Inventor puts them by default in the APK structure.