Update StorageUI integration with SDWebImage

[dreampiggy]

Hey there! So you want to contribute to FirebaseUI? Before you file this pull request, follow these steps:

• Read the contribution guidelines.
• If this has been discussed in an issue, make sure to mention the issue number here. If not, go file an issue about this to make sure this is a desirable change.
• If this is a new feature please co-ordinate with someone on FirebaseUI-Android to make sure that we can implement this on both platforms and maintain feature parity.

This PR add the following features:

1. Use SDWebImage 5.6.0 's loader context option, instead of dummy manager instance. This is easier to use. And can avoid user who overrde the default manager's property (like transformer), which cause the undefined behavior when using with FirebaseUI Storage
2. Add the support to load gs:// URl directly, not always need to create a wrapper FIRStorageReference.
3. Add the support to progressive downloading and decoding of images, this can be the use case who want to load partial images and display for users.

The dependency of SDWebImage bumped to 5.6.0, beucase of the PR feature 1 need the new API.

CC @morganchen12

[morganchen12]

Thanks for updating the README!

[dreampiggy]

@morganchen12 Hi.

After I update the demo to try the code, I found the strange exception thrown from Storage. I use the URI gs://hackemist-sdwebimage/joy.gif

However, the official documentation told me it's OK to pass the Full URI into the storageWithURL:

https://firebase.google.com/docs/storage/ios/create-reference

Which is correct ? Is this exception the designed behavior ? And whatever, this need to be fixed (I need another PR)

[dreampiggy]

If I can not init a full URI into the FIRStorageReference directly, what can I do now ? Should I parse the URL path and use this arg to call child: ?

---

Found solution, currerntly I use the gs:bucket/object pattern to construct the FIRStorageReference, it works for multiple storage bucket. But looks a little tricky (isn't here any other way ?)

Tetsted two bucket's URI, works fine. It's public bucket so you can test it as well.

• gs://hackemist-sdwebimage/joy.gif
• gs://lizhuoli941126.appspot.com/joy.gif

[morganchen12]

@dreampiggy the reason the crash happens is because you're trying to initialize a bucket with a full path to a specific file. The bucket is just the host (as you've found out).

I'm not sure why we don't allow creating a reference without first initializing the bucket.

[dreampiggy]

However, the official documentation told me it's OK to pass the Full URI into the storageWithURL:

@morganchen12 So you means this is the correct behavior but not bug, that it's not allowed to init a full gs URI into StorageReference ? But seems we need to update the documentation there. It cause misunderstanding, because actually, you can not write code like this in document:

// This is equivalent to creating the full reference
let storagePath = "\(your_firebase_storage_bucket)/images/space.jpg"
spaceRef = storage.reference(forURL: storagePath)    

This will cause crash on exception, and worse, Swift can not even handle Objective-C's NSException, dangerous.

---

PS: Actuallly I think it's really convenient to construct a full gs URI into StorageReference, not a bug. What reason cause the Core Firebase iOS Team make decision to disable this usage ?

[dreampiggy]

Seems the code comes from the Day 1 of FirebaseStorage 😭

https://github.com/firebase/firebase-ios-sdk/blame/master/FirebaseStorage/Sources/FIRStorage.m#L132

The documentation does not write correctly for that storageWithURL: behavior.

[morganchen12]

I'll see what we can do to change the behavior of Firebase Storage.