The test server has been updated with a release candidate for the version nb194 of App Inventor. This version includes the following changes:
Android SDK 33 support
Fixed an issue listing shared directories with the File component
Added support to components to make use of content: URIs
New FilePicker component (Android only at the moment)
ChatBot and ImageBot have ApiKey settable in the designer. Any component with an ApiKey property will have its property obfuscated even when set in the designer.
New buildserver infrastructure refactored to support new build targets (new targets, e.g., iOS, will come in a separate release) (@Diego)
User interface internals have been refactored to support making new editor layouts (new layouts will come in a separate release)
Add folders to project list to help organize projects (@austenjoa, @Vishwas)
New data science component category with anomaly detection and regression calculators (@HanyaElhashemy)
Fixed an issue where screens would change orientation back and forth when opened
Fixed a bug where loading extensions would throw an internal error
Fixed a bug where ImageBot would not make connections on Android 13
Implement grouping of properties in the properties panel
Add a help widget to property names for fast access to reference info
Fix a bug where an internal error would occur when procedures were stored in the backpack
This thread will be updated with any known issues that come up.
Known issues:
Data science help links are broken in the designer. See the documentation here. should be fixed as of 2023-08-23
The FilePicker documentation is mangled in the component palette. You can access the documentation here. should be fixed as of 2023-08-25
The Regression's CalculateLineOfBestFit block will not accept an empty string in its value socket in spite of the fact that the documentation says it can. should be fixed as of 2023-08-25
There are web editor layout issues on small form factor devices.
The delete account button is missing should be fixed as of 2023-08-23
View the trash in the top toolbar does not work when a project is open.
Default File Scope help text is truncated. should be fixed as of 2023-08-25
Regards,
Evan W. Patton, Ph.D.
Lead Software Engineer, MIT App Inventor
The Clean Data block operates on parallel lists of x and y data, along with an index for the anomaly to be removed.
However, the Anomaly detector block makes no mention of working on lists of (x,y) pairs, and I have yet to encounter the definition of a z-value of a two-dimensional point in a set of two dimensional points.
DetectAnomalies(dataList,threshold)
Calculates the mean and standard deviation of the data, and then checks each data point’s Z-score against the threshold. If a data point’s Z-score is greater than the threshold, the data point is labeled as anomaly.
The Anomaly detector worked fine on a one dimensional list of numbers.
Further experiments needed to see if it works on two dimensional data...
However the helper block
only offers 4 possible values, and not the alleged missing option.
If I try a blank text block for the value socket, it gets spit out by the blocks editor, probably expecting a different data type. An empty value socket gets an error message.
So the dictionary return is not going to happen.
This is an oversight. In an earlier version of the component the function took a string argument rather than the LOBFValues block. I will look into fixing this, but in the meantime you should be able to do some type laundering using a variable:
Which is good, but it would be nice to have a built-in convertor block to get the file path, for those situations where one may need it. This would be helpful in many other situations as well, e.g. when using the activityStarter to PICK files. Or to at least return the filename....
The challenge is that, as far as I know, Android does not provide a way to convert content URIs to file URIs directly. In fact, there is no requirements for a content provider's content URIs to actually represent files in the file system. It would be better for folks to think of content URIs as opaque things and that component authors update the logic to support them rather than forcing the more abstract content provider model down to the file system level.
Another problem is intention. If we always copy the content URI to a corresponding file URI, then (1) we use more storage than otherwise might be needed, and (2) it would prevent updating existing files if the write permission is requested. The following is an example of how you might do what you want using the built-in capabilities of App Inventor (although there is a bug in current test server where this doesn't work that will be fixed in the next test server update):
This is a simple test app I had made to copy an image picked using the file picker to the app storage and then copy it back when I selected a destination.
