Upgrade SDWebImage 5.0, using SDAnimatedImageView instead of FLAnimatedImageView for better animation support

[dreampiggy]

Also, fix the bug of cacheOnly behavior on iOS

Changes

1. The dependency of iOS(SDWebImage) upgrade to 5.0
2. The FLAnimatedImage implementation is dropped, since SDWebImage 5.0 provide built-in solution for animation images, which is better than FLAnimatedImage (Tied to GIF only, no APNG/WebP support), learn more here: Wiki - Animated Image
3. Fix the bug of cacheOnly attribute, it should not request any network. However, previously, it does a wrong behavior, which request the network, but only store to memory cache (This option now renamed to SDWebImageContextStoreCacheType[@(SDImageCacheTypeMemory)] context option)

Related

#447

[codecov]

Codecov Report

Merging #454 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #454   +/-   ##
=======================================
  Coverage   94.73%   94.73%           
=======================================
  Files           1        1           
  Lines          19       19           
=======================================
  Hits           18       18           
  Misses          1        1

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2a3438c...14b19cc. Read the comment docs.

[codecov]

Codecov Report

Merging #454 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #454   +/-   ##
=======================================
  Coverage   94.73%   94.73%           
=======================================
  Files           1        1           
  Lines          19       19           
=======================================
  Hits           18       18           
  Misses          1        1

Impacted Files	Coverage Δ
src/index.js	94.73% <0%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 14ea01c...cc1a03d. Read the comment docs.

[dreampiggy]

@DylanVann Hi there.
I'm a collaborator of SDWebImage, Could you please have a review for this ?

SDWebImage 5.0 provide many many feature from 4.0, for better customizable, better animation support (A brand new solution for all animated image), better decoder plugins for massive image format. I think it's better to migrate this upstream dependency.

See more : https://github.com/SDWebImage/SDWebImage/releases/tag/5.0.0

[dreampiggy]

In 5.0, all external image format (Not supported by Apple's built-in framework), is a coder plugin.

The user, can choose to use any format, don't need a CocoaPods subspec for this. Which make it more modular and under control. See more on : https://github.com/SDWebImage/SDWebImage/wiki/Coder-Plugin-List

For example, if user want to use WebP format, they can do this:

pod 'react-native-fast-image', :path => '../node_modules/react-native-fast-image'
pod 'SDWebImageWebPCoder'

Then register the coder plugin, in AppDelegate.m

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// ...
// Register WebP format support
[SDImageCodersManager.sharedManager addCoder:SDImageWebPCoder.sharedCoder];
// ...
}

[DylanVann]

This would mean that by default this module would no longer support as many formats though right?

[dreampiggy]

This would mean that by default this module would no longer support as many formats though right?

Whether SDWebImage supports some format, or not. It's now, totally controlled by the users (the Pod integrator). If users want, they can supports all the format, listed in : Coder Plugin List.

The main repo (SDWebImage pod itself), only supports the built-in format by Apple's SDK. Typically the JPEG/PNG/APNG/TIFF/GIF/HEIF, etc.

As I see, react-native-fast-image SDK, didn't rely on any dependency on what original image format is. Isn't it ? We just care about the animation, and their meta info (loop count/ frame count), but not what detailed the original compressed data is. Both APNG/GIF/WebP/BPG(more) supports animation, they can be abstracted as the same.

[dreampiggy]

Hi. Seems this PR is update to the master branch. And I've answered that question. Any new update about this ?
@DylanVann Do you have time recently ? If there are anything I can do to make this merged, please feel free to reply.

[DylanVann]

I think this is good assuming it supports formats we used to support without manual steps. Just need time to test it out, maybe tonight. Thank you!

[DylanVann]

Had to make some modifications but it's in. I wish there was a better process for this kind of thing using semantic release...

Thank you @dreampiggy !