Platform.ReadFileBytes(filename) and Assets dir about stereokit HOT 4 OPEN

It looks like I have actually put some thought into this one previously, #771 😅

from stereokit.

This is actually the expected behavior! The "Assets folder path" is a trick used to help prevent needing different file names on different platforms, which is why file names behave fine for Assets. But for a function as generic as Platform.ReadFileBytes, this trick could be problematic, so I didn't add it here.

The main thing here is that on Android, myfile.bin is not exactly a file, it's an asset that's packed in your APK. I don't believe it's accessible by regular file IO functions! Instead, Android uses the AssetManager to read these, and they "aren't in a folder", which is why you just use the filename here instead of the "Assets/" path. Platform.ReadFileBytes does include calls to the AssetManager to enable you to read these "assets, not files", but also calls to regular file IO functions to read those too.

It's definitely confusing, and I do believe Platform.ReadFileBytes is due for some revision. I just haven't decided exactly how to revise this in a way that isn't also confusing in other contexts! Maybe I'm overthinking it and the solution is not all that complicated 😅 I dunno! I'll try and take a look at this soon.

from stereokit.

The main thing here is that on Android, myfile.bin is not exactly a file, it's an asset that's packed in your APK. I don't believe it's accessible by regular file IO functions!

Right, I figured something like this 😄

It's definitely confusing, and I do believe Platform.ReadFileBytes is due for some revision. I just haven't decided exactly how to revise this in a way that isn't also confusing in other contexts!

Perhaps having a renamed/dedicated ReadAssetFileBytes(filename) would be an option, to at least take away the confusion on what exactly can be read and how. This call would always only read the contents of a "file" directly under the Assets dir, so can't navigate to a higher relative path.

Apart from that could be a call to read a regular file, where filename is some form of platform-native path. That at least still provides an abstraction for file I/O over the underlying platform, which can be a nice thing.

from stereokit.