What kind of change does this PR introduce?

Uploading large files on a spotty connection could be tough.

• Support Resumable uploads
• Retry failed requests

Resumable uploads is not yet supported on Supabase, but we can easily implement retries. This PR adds a retry logic to file uploads in a exponentially backing off manner like the following:

1. 400 ms +/- 25%
2. 800 ms +/- 25%
3. 1,600 ms +/- 25%
4. 3,200 ms +/- 25%
5. 6,400 ms +/- 25%
6. 12,800 ms +/- 25%
7. 25,600 ms +/- 25%
8. and beyond 30,000 ms +/- 25%

By default, the max attempts is set to 25, which should be roughly 10 minutes. 10 minutes was the default time set for Firebase storage. Users can change the retry count like the following. Not sure if this API would provide the best developer experience, so would love to hear comments/ suggestions about anything regarding this PR!

final uploadTask =
    client.from('public').upload('a.txt', file, maxAttempts: 8);

What is the current behavior?

If a file upload fails, it does no retry, which makes is hard to upload large files over a spotty network connection.

What is the new behavior?

File upload is automatically retried on SocketException or TimeoutException.

Additional context

This feature is not supported on JS client, but there was an feedback from customers handling large files. After some internal discussions, we thought it would make make sense to add this feature to the Flutter SDK.

I have the following code:

FilePickerResult? result = await FilePicker.platform.pickFiles();
if (result != null) {
    Uint8List? fileBytes = result.files.first.bytes;
}

In Firebase, I could call FirebaseStorage.instance.ref('uploads/$fileName').putData(fileBytes); In Supabase...? There is uploadBinary which receives a BinaryFile(!?) with the mime and the bytes. Should I call result.toInt()? Isn't that just boilerplate? Or is there a better way?

Bug report

Describe the bug

Hello team , Please add any documentation or any comment . I am unable to understand which url & header you need for this. Make an example and clear that.

Motivation

Same reason as https://github.com/supabase-community/postgrest-dart/pull/66

Implementation

Instead of passing the httpClient down to the api, I replaced the global fetch, because tests use the global variable to mock Fetch. I think this pattern is very uncommon, but I didn't want to rewrite all tests.

What kind of change does this PR introduce?

Adds mime to FileOptions, which enables the dev to set custom Content-Type

What is the current behavior?

Binary upload/update misses custom Content-Type, which causes missing preview in for example Supabase dashboard

What is the new behavior?

The dev can specify a custom Content-Type.

Additional context

The Content-Type in _handleBinaryFileRequest was previously gotten from _parseMediaType(url), which I think makes no sense, because the url has nothing to do with the new file itself.

I'm hiding FetchOptions, because it causes a duplication with postgrest-dart when exported in supabase-dart. It's only used internally, nevertheless. ~~I'm renaming StorageException to StorageError, because the other classes like GoTrueError and PostgrestError are named like this as well.~~ Just to mention, the migration note in CHANGELOG.md is wrong, because it uses StorageError

Following the update in JS SDK https://github.com/supabase/storage-js/pull/90

Also I added a List files test, because there were no test methods using FileObject.

Fixes https://github.com/supabase-community/supabase-flutter/issues/178

I am building a Flutter app using a Supbase, I am getting an issue while building app for the Web.

Below error what I got

Launching lib/main.dart on Chrome in debug mode...
Waiting for connection from debug service on Chrome...
lib/screen/dashboard/profile/store/profile_screen_store.dart:166:43: Error: The argument type 'File/*1*/' can't be assigned to the parameter type 'File/*2*/'.
 - 'File/*1*/' is from 'dart:io'.
 - 'File/*2*/' is from 'package:universal_io/src/io/file.dart' ('../../../../.pub-cache/hosted/pub.dartlang.org/universal_io-2.0.4/lib/src/io/file.dart').
            .update('$fileName$imageExt', file);
                                          ^
lib/screen/dashboard/profile/store/profile_screen_store.dart:170:43: Error: The argument type 'File/*1*/' can't be assigned to the parameter type 'File/*2*/'.
 - 'File/*1*/' is from 'dart:io'.
 - 'File/*2*/' is from 'package:universal_io/src/io/file.dart' ('../../../../.pub-cache/hosted/pub.dartlang.org/universal_io-2.0.4/lib/src/io/file.dart').
            .upload('$fileName$imageExt', file);
                                          ^
Failed to compile application.

Link to Source code

profile_screen_store

What kind of change does this PR introduce?

New image transformation feature will be added to Supabase. This PR adds support for that feature.

• transform option has been added to getPublicUrl and createSignedUrl methods.
• download method has been deprecated in favor of publicDownload and authenticatedDownload methods.

supabase-js code here https://github.com/supabase/storage-js/pull/129

What is the current behavior?

Image transform is not supported

What is the new behavior?

Image transform feature is supported where images stored on Supabase storage can be resized on the fly.

We will hold off on merging this until this PR is merged on storage-js.

What kind of change does this PR introduce?

Adds a link to the Dart doc for storage.

Closes https://github.com/supabase/storage-dart/issues/1

What is the current behavior?

There are no doc or link to any docs in the repo.

What is the new behavior?

Users can navigate themselves to the official doc.

Part of https://github.com/supabase-community/supabase-dart/issues/109

• Now errors should be handled inside of a try/catch block
• Added StorageFileApi.copy and StorageFileApi.createSignedUrls
• Renamed fetch to storageFetch, in order to avoid conflicts between other supabase libraries
• Improved documentation on methods that already had docs
• Added lints for linting