Same for the other new component.
That /.html# looks wrong.
Not having the definition of z-value at my finger tips, I tried
I must have silently crashed the block, or Three has a low z-value in (1,2,...4).
Data type teasing aside,
is 999 really within 2 standard deviations of the mean of (1,2,999,4)?
Maybe my list needs to be much longer to get a smaller standard deviation?
I guess so.
Anomaly detection vindicated.
1 Like
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...
Result:
No anomaly found if the one dimensional list is projected onto a two dimensional list.
These components need a bibliography.
The regression block tool tip claims it will return a dictionary if no return value is specified.
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.
What about using a file path instead of a content URI for the FilePicker? (same with Camcorder).
This will provide better integration with other components (such as the File component), and also avoid the use of a third-party extension ...
3 Likes
By pressing the Back button in the FilePicker, the file picker exists, and shows this error:
Error 4501: No URI returned to FilePicker
I did not find similar problems with the ImagePicker.
The only way to get around this is to ignore the error with an ErrorOccurred event.
I think this is good because we know the file is not selected and we can handle it accordingly.
As for the display on the phone, landscape mode is even worse.
1 Like
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:
1 Like
The changes we've made for SDK 33 should allow most components to make use of a content URI automatically.
1 Like
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....
4 Likes
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.
I agree.
Hundreds of extensions still don't support content uris and it is going to be a huge problem soon.
Code taken from here:
However GetContentUri block is misleading as it returns file uri 
3 Likes