"No such file or directory" when using `Res.getUri()` about compose-multiplatform HOT 8 CLOSED

If someone is looking for some workarounds for the MediaPlayer issue, the issue created by @Woren has some possible solutions, and I shared one additional workaround there too.

from compose-multiplatform.

It is the expected behavior, because the resource on the android side is located inside a jar archive. The Uri has the correct path but your player doesn't support files in jar archives.
You need to implement a data reading from jars.

from compose-multiplatform.

You could try something like: https://stackoverflow.com/questions/15055747/play-media-from-from-zip-file-without-unzipping

(I haven't check it.)

from compose-multiplatform.

I see in the code logic that for fonts we additionally check if file inside "assets"

is it possible to add option to store files on Android in assets folder? it will fix the issue
otherwise it make sharing files logic useless 🙁

from compose-multiplatform.

@egorikftp First of all, the font check is dirty hack I'd like to remove but it is impossible to create a font by a byte array on android.

sharing files

Files are not resources. Compose resources are part of UI.

There is no such thing as "assets" on the JVM platform. What you ask is a platform dependent solution. If you want to add file to android assets you may use the android assets folder.

from compose-multiplatform.

For anyone interested I've created issue in Media3/Exoplayer repository. I have almost same use case. More details there.

from compose-multiplatform.

is it possible to add option to store files on Android in assets folder?

BTW, there is a technical limitation for that: to read android assets users have to provide an android context. it will make the library API more complicated

from compose-multiplatform.

BTW, there is a technical limitation for that: to read android assets users have to provide an android context. it will make the library API more complicated

@terrakok I think there is still a valid use case for offering support for assets on the resources library, in addition to the reasons above (which are caused by the fact that usage of Jar resources is not common on Android), there have been some issues with the performance of Jar resources in Android (Per my testing, the performance of Jar resources has improved in recent Android versions, but they are still slower by 15% than assets or raw files).

To solve this issue without impacting the API, I think there are some approaches:

1. Require passing Context for base functions, but make the common functions Composables, and make use of LocalContext.current in the Android implementations.
2. Introduce a notion of PlatformContext in the library, and require the client apps to pass it in the APIs

What do you think about these ideas?

from compose-multiplatform.