Open mphill opened 8 months ago
Good point. Currently, the workaround would be to encode your data as base64 and store it as such. Handling binary data directly through CloudStorage would be much better performance-wise though, obviously. However, I think taking a Blob as a parameter for binary data would be better than a local file URI, since the latter would require the user to store the file to the local filesystem first before uploading it to the cloud.
I'll take a look at this within the next few days.
I think that is a good compromise as long as the Blob
can be streamed.
One potential downside is Blob
support is nonexistent with the stock expo filesystem library:
https://github.com/expo/expo/issues/7122
It seems people have to use fetch
as a work around
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Please keep open
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Please keep open
I am also experiencing this on Android. I am currently encoding/decoding to base 64 but am encountering Out of Memory problems when files exceed 20 MB.
I am trying to use Expo filesystem downloadAsync as a workaround to download the file straight to the documents directory.
Is your feature request related to a problem (i.e. user experience)? Currently, this library only supports UTF-8 strings. If you want to upload images, documents, or any binary files you cannot.
Describe the feature you'd like to suggest Instead of taking a string as a content parameter, it would be better to use a file URI from the local filesystem. That would allow the library to upload any type of content.
Additional context None
Thanks!