Question about cache

[Tolriq]

Hi,

I've tried to read docs but can't find easy answer to a complex need :

• My app displays lot's of images downloaded but in multiple places with potentially different size and transformations.
• Users should be able to pre load image cache for offline usage.
• Sources images could be quite big so should be cached at a limited resolution depending on device.
• Image cache path should be available for sharing purpose.

From what I read SOURCE cache strategy would cache the original image at full size.
And it does not seems to be possible to have a different cache store for SOURCE and RESULT to have a permanent source cache and an lru for result.

Have I missed something in the docs or could all those requirement be handled currently ?

Regards,
Tolriq

[sjudd]

Although Glide can handle most of this, it sounds like what you really want is to build your own image cache where the user can configure the number and sizes of images, and then use Glide on top of that cache to load images with different transformations etc.

If so, a similar to issue has come up a couple of times on the discussion list and the suggestions/answers there may be helpful: https://groups.google.com/forum/#!topic/glidelibrary/M2H-9EN-284.

[Tolriq]

Not as straightforward as I thought :) But I guess that if the library allows that it's better to take time to learn it instead of implementing my own bitmap reuse now that I'm API 14+.

Thanks for feedback will look into all this.

[TWiStErRob]

If you manage to do it you could also share it with the others who demand such a feature set via a Glide extension library in a similar way as https://github.com/wasabeef/glide-transformations does, that is outside the Glide core.

[Tolriq]

Well it will take time before I work on this, and my code will be quite specific due to some special cache handling but if I find a good way I'll push some gist for that :)

[Tolriq]

@sjudd Ok So I've started to look a little closer on how Glide works and the GlideModule and the link you gave me.

It seems this does not really cover the need in a simple way.

The link you gave offer a way to implement a custom loader to load from another store.

My need would would more be :

• Have a persistent cache not LRU.
• When requesting an image, if not in normal glide memory / disk result cache then override the target size to a defined maximum size depending on device, then use normal glide to download the image and resize to this new size but store this image in the persistent cache as a source cache or load from this permanent cache.

In fact it's a little like a source cache strategy but persistent and with a resize while keeping normal result cache behavior.

But from what I read in the sources you use the same cache for both source and result and just use different keys and use the strategy to know the one to use.

I suppose I could handle the download / resize persistent cache in the loadData of the DataFetcher but this duplicate a lot what glide offers.

Did I miss something obvious somewhere ?

[TWiStErRob]

define:cache "a collection of items of the same type stored in a hidden or inaccessible place."

I've always look at caches as a temporal fast way to access stuff. It looks like you're trying to stretch that with persistency. A cache should never be unbounded (hence LRU), just think about what happens if your system changes some content and some of the images will never be accessed again. In that case LRU would evict those sometime later, but your app will just grow. You can work around this by defining a big enough, but still constrained size.

My idea for your second point would be to load the url resize and save, and then only pass the resized one to Glide, something like:

class ResizingFetcher extends HttpUrlFetcher {
    private File temp;
    private FileInputStream stream;
    public ResizingFetcher(GlideUrl glideUrl) {
        super(glideUrl);
    }

    @Override public InputStream loadData(Priority priority) throws Exception {
        InputStream stream = super.loadData(priority);
        Bitmap decoded = decodeAndResize(stream);
        temp = write(decoded);
        return stream = new FileInputStream(temp);
    }
    @Override public void cleanup() {
        stream.close();
        temp.delete();
        super.cleanup();
    }
}

This way using ALL: SOURCE cache will contain the "maximum size[d image] depending on device" and RESULT cache will have all the ones that are sized for the particular targets.
This is essentially faking server-side resize, like "http://example.com/image.jpg?w=200&h=300" would do.

[Tolriq]

Well for the cache my need is more or less common I suppose.

My app sync it's database with another application that will have a fixed dataset.
Users want to be able to pre fill the cache to match all the application dataset so they can work offline.

The app can display the images in quite a lot of place and different size (depending on device orientation and part of the application used), but if the source file are cached there's no need to have a very big result cache as long as they can work from the source cache and do not need slow network fetch.

This mean that even if I go with a very large source cache to avoid pruning, I still need a different cache for source and result as having a very large result cache is a non sense for this usage.

When the application sync a new dataset it's the application job to cleanup this persistent cache if it can. (I'm not sure it's really possible right now, but being able to remove named file from cache should be possible in my implementation).

Anyway your solution is what I imagined (except no temp file but going to the offline permanent cache) , but this require that I code the decodeAndResize and the caching key system but since all is already present in Glide it's not cool that I can not just hook somewhere to do my stuff :(

And I wonder about performance since image load would start sooner than directly by glide I guess and would need a careful handling of cancels to stop downloading and everything, all that is already handled by Glide too.

[TWiStErRob]

I put the temp file there so there's another InputStream (though new JPEGInputStream(bitmap) would be an interesting concept). The idea I gave based the solution on SOURCE being your permanent cache and RESULT is not even necessary for most places as you're saying: I hope it's clear that you can set the diskCacheStrategy on a request basis, depending on where you're loading (e.g. adapter1, adapter2, single imageview, other single imageview, etc...), so some views with complex transformations can have ALL cache while the other simple downsampled ones can just use SOURCE. Don't give in just yet @sjudd may have an insight too (e.g. Can v4 help with this?).

[Tolriq]

Well I'd need to see performance impact but even if the application can display tons of different sizes most of the time users will follow the same path on the same device so result cache could be quite beneficial on low end devices.

But from my current implementation (not glide at all) file access costs a lot on most device so reading minimal set of data instead of source cache when possible should be better.

As from first test the gain with result cache and image reusing (in fact using glide) is really impressive against my old implementation I'll push on finding a solution even if I end up plugin my old code into Glide.

[Tolriq]

@TWiStErRob @sjudd After looking more deeply, nearly all can be done within Glide with multiple models and associated loaders.

The only problem is that the cache is defined at the Glide instance level and the cache API only receive the computed key.

I don't know if it's possible to propose things for Glide v4.

But the only missing piece to allow way more customization for users would just be to extend the cache API to pass in the model and the cache strategy used.

With those added params all would be possible and solve my problem and surely others ones.

[TWiStErRob]

@Tolriq what did you end up doing with this? Should we change this to an enchancement? If so are those extra params all you need?

[Tolriq]

I used a dual layer cache system that duplicate some Glide code :(

I've not enough think about the perfect solution with pure Glide, but the need is still here.