Firebaseui-ios: FirebaseStorageUI: Add parameter SDWebImageOptions to UIImageView.sd_setImage

[ghowen]

SDWebImage has the very useful parameter SDWebImageOptions when setting an image for an UIImageView (see: http://cocoadocs.org/docsets/SDWebImage/4.1.0/Categories/UIImageView+WebCache.html#//api/name/sd_setImageWithURL:placeholderImage:options:)

FirebaseStorageUI add the possibility to pass a StorageReference instead of an URL, but it is not possible to pass SDWebImageOptions.

This limits the usefulness of the sd_setImage implementation in FirebaseStorageUI quite a bit. So I kindly suggest to add support for this parameter in a future version. Thank you.

[nathan2day]

I too would find this feature useful, particularly in order to use the SDWebImageRefreshCached option, to make use of cache control HTTP headers.

[ghowen]

Just to add to the case: this parameter is the only way to invalidate the cache automatically if a remote image has changed. We are running into trouble with user profile pictures without this parameter. If a user changes his picture, I can manually invalidate his cache and he will see the updated picture in his profile. But all other users who have once downloaded this user's picture will always see the old one (unless they manually delete their cache).

[morganchen12]

This is a non-trivial change since FirebaseUI Storage doesn't currently use the SDImageManager's downloading logic, so we'd either have to extend SDImageManager to use FIRStorageReferences or re-implement the cache expiration logic (and, for completion, the rest of the SDWebImageOptions features).

While it seems to be an important feature, it's unlikely I'll have time to get to this within the next few weeks.

[nathan2day]

I found a workaround, thought I'd share in case others find it useful:

I am now using the Download URL with SDWebImage instead of the FIRStorageReference, as I noticed that unlike the FIRStorageReference the Download URL changes each time the image at that reference is changed. SDWebImage then aggressively caches the image.

As I am already using the Firebase Realtime Database I have opted the store the Download URL for item(s) there, as I already needed to get the items from the Firebase Realtime Database there was no extra delay to obtain the Download URL. (I also use the SDWebImagePrefetcher).

The problem with changing FirebaseStorageUI is that the Download URL is not part of a FIRStorageReference, instead it's FIRStorageReference metadata, so changing to the Download URL would introduce an extra round-trip prior to SDWebImage caching the image. Also SDWebImage handles the actual image download rather than a FIRStorageDownloadTask... The workaround avoids the need to obtain FIRStorageReference metadata by storing that as part of the Firebase Realtime Database which is already being obtained in my case...

Of course this workaround results in FirebaseStorageUI not actually being used...

Hope that helps others...

[ghowen]

@nathan2day Thanks, this sound like a viable workaround. I realised that the download URL changes, but I did not find out when. If it changes only with each image update, this will work for now.

[zgosalvez]

Another workaround, that I use, is to simply remove the cache using the key, before calling the function, like so...

SDImageCache.shared().removeImage(forKey: reference.fullPath)
imageView.sd_setImageWithStorageReference(reference, placeholderImage: placeholderImage)

However, YMMV. I have a separate mechanism that caches the timeCreated/updated metadata to determine whether or not I should remove the image from the cache.

[axiom-media]

@zgosalvez thanks for your comment about removing from the cache directly using the key. It was exactly the piece of info I needed to be able to invalidate specific images in my code.

[morganchen12]

Hey all, if anyone is stuck on this issue, the workaround is to generate a download URL via FirebaseStorage and then pass that URL into SDWebImage.

It's unlikely I'll be able to get to this issue soon, since most of my attention is currently on Auth and Firestore.

[morganchen12]

Fixed in #654.