Mvvmcross: A new download cache implementation for Android -> Remove DownloadCache

[slodge]

The initial download plugin for android images has lasted quite well... but it might be time to consider an alternative soon....

Possible inspirations include:

• #393 (this would open up ExternalStorage)
• https://github.com/xamarin/monodroid-samples/blob/master/MonoIO/Utilities/BitmapUtils.cs
• http://stackoverflow.com/questions/15193463/monodroid-loading-images-efficiently

I'm sure there are plenty of other Android Java ones too....

[Cheesebaron]

3 years later, I think we should revisit this.

It brings so much pain on Android, especially in async contexts.

[alexshikov]

Are we talking about general downloading or Bitmap-only?

[Cheesebaron]

Download cache is currently only used for Bitmaps.

[kjeremy]

Akavache?

On Mar 15, 2017 7:54 AM, "Tomasz Cielecki" [e-mail] wrote:

Download cache is currently only used for Bitmaps.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MvvmCross/MvvmCross/issues/416#issuecomment-286720219,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEIBRBloWTCXP-Dm09ux9KNBNw69jJpeks5rl9F1gaJpZM4A-E5j
.

[softlion]

FFImageLoading

[Cheesebaron]

We could just say bye bye to DownloadCache and tell people to use FFImageLoading, Picasa or whatever else for loading and caching images in their apps.

[promontis]

+1 for what @Cheesebaron said

[martijn00]

Just saying goodbye doesn't make it easier for people. We could instead offer MvvmCross bindings for FFImageLoading or one of the others.

[promontis]

@martijn00 there is already a binding for FFImageLoading for Mvvmcross

[martijn00]

Hmm, ok. Where can i find that? What about making an official binding?

[promontis]

@martijn00 https://github.com/luberda-molinet/FFImageLoading/wiki/MvvmCross

[Cheesebaron]

MvxImageLoadingView is in FFImageLoading :)

[softlion]

Note that both FFImageLoading and MvxImageView have issues. MvxImageView does lots of operations on the main thread. Its downloadcache can not be customized easily and is not fully async. FFimageLoading has issues with the HttpClient it uses OOB. This HttpClient can not be customized easily. But it implements caching of pixel-resized images. Its caching mechanism is not customizable easily. They claim to support SVG, but the svg implementation is catastrophic. Use XamSvg instead.

[Cheesebaron]

How is this not easy in case of FFImageLoading?

            ImageService.Instance.Initialize(new Configuration
            {
                HttpClient = new HttpClient(new NativeMessageHandler()),
                LoadWithTransparencyChannel = false
            });

Also @softlion the discussion is not what to use instead, but to drop support for DownloadCache.

[softlion]

Ok for HttpClient.

[heytherewill]

I wrote target bindings for using Picasso with MvvmCross. I've used then in many of my own apps, so I made the code available here. NuGet package coming soon 😄

[alexshikov]

I've used https://components.xamarin.com/view/sdwebimage a lot in my iOS projects. It could be a good base to wrap Mvx plugin around.

[PaulVipond]

I agree with @martijn00: if you just drop DownloadCache then you're forcing an alternative adoption on those who may want to upgrade in future. From what I'm hearing none of the other solutions cover all the bases. How about listing all of the pain points first and see if anyone has bandwidth to redesign / rewrite the implementation - I have some time to look at an android implementation. The reason I say this is that displaying images in lists a fairly basic feature of most apps these days. So pain / improvement points I can see from the thread and elsewhere are:

• Fully async implementation
• Ability to override the default http client handler
• Progress updates for image downloading
• Cache control (storage location, size, expiry, individual file removal / force update, possibly per file type control - e.g. by regular expression)
• Multiple cache support
• Support for SVG
• Ability to reuse cache for general download would be nice
• For me, ability to load images from resource DLLs (not sure if that is possible currently)
• Make sure continue to dispose / resample as appropriate
• An efficient means of creating circular images

Any more?

[Cheesebaron]

@PaulVipond that is true, dropping it will force someone to have to find another solution. However, if we are good enough to warn people about this and give them descriptions on how to migrate to an alternative I would think that would be good enough.

As for fixing the DownloadCache plugin instead, that, as you said yourself will require "bandwidth", i.e. someone picking it up throw it on the ground and piece it back together along with all the new things you suggest.

Problem currently is, that the plugin is horrible to maintain as it is so many onion layers, so it is just easier to give up on it.

If someone actually has the time to create a new one that works on Android and iOS, sure go for it. In the meantime I still vote to nuke the old DownloadCache plugin and provide a migration path for people.

[PaulVipond]

@Cheesebaron Having spent some time integrating FFImageLoading into my app, I'm now convinced that reinventing the wheel is not the thing to do :-) It turned out to be pretty easy, though I did raise a question about whether the transforms (circle in particular) could be applied in XML rather than code. It was a very good alternative for my use case (local contact images) but note the concerns that @softlion raised above.

[Cheesebaron]

Well SVG's are not compatible with our DownloadCache either. Not sure what @softlion's affiliation with XamSvg is, but that Xamarin Component is not free, neither as in beer or speech.

As for issues with FFImageLoading, I suggest we help the author iron these out when we decide to drop DownloadCache.

[promontis]

What Cheesebaron said!

I've tried to use the image implementation of Mvx, but FFImageLoading is far superieur and easier to setup. Currently using it in an incremental loading collection, and works perfectly. When I tried Mvx's imageview it isn't as snappy.

I think most people don't use SVG's, at least not for profile pictures or photos. The question I would ask is, what are the use cases for SVG?

I would probably split the use cases into images and json. For images I would either use FFImageLoading or something that can handle SVG (but I don't download SVGs, they are assets in the bundle). For json I would use something different altogether like Realm.

[softlion]

SVG are mainly used for icons and background gradients, and for placeholders for missing pictures :)
They can also be used for your business cases like footprints.

FFImageLoading supports SVG but is very bad at them. I will write a XamSvg plugin for FFImageLoading. I know someone done it already.

XamSvg is able to use embedded resources for SVG. So you put them once into your PCL and it's done for all your platforms.

[daniel-luberda]

To avoid confusion I just want to let you know that FFImageLoading MvxImageLoadingView is obsolete and replaced with MvxCachedImageView which is far more stable and feature complete. There's also an example how to use it on our wiki: https://github.com/luberda-molinet/FFImageLoading/wiki/MvvmCross. Also SVG support is improved a lot now.

[alexshikov]

We've started a new project and decided to use FFImageLoading's MvxCacheImageView because apart from different image sources (remote, resource and base64) and cache it also has fancy features like fade-in and transforms (that we needed).

Accessing cached images from the Core project is also a good stuff.

[nmilcoff]

Let's remove DownloadCache for v6!