Now the situation is the background sever only provide me a original large image.
Which means I can't choose to download an appropriately sized version of the image.
But I need a thumbnail in the List which in...such as 100*100
With Glide,I can simply use a into(100,100) method to fit the ImageView
Here comes my question 1 :If I do in this way , dose Glide have to download the full
size image then transform it into 100*100,is it correct?
If it's correct,then my question 2 : the full size image is surely in the disk cache,but
obviously I also need the thumbnails cache when I later want to reuse it cause
the list use thumbnail for display
is there any way to save the thumbnail in the cache File _( maybe use override(w,h)? )_
if I use override(w,h) I won't have the full size image in cache?
in conclusion , I just wanna have both thumbnail and original image in cache and there
is no thumbnail at first
Sry for my English ,hope you guys could understand me.
and I am still new at using Glide , so could u give some specific guide...
any help will save my day :P
Glide v3 has two caches SOURCE and RESULT, reading from and writing to them is toggled with .diskCacheStrategy() on individual requests. You don't need to manually enter the size for the thumbnail, Glide will determine the view size and decode the best size to fit that view (incorporating the appropriate android:scaleType).
So in the list where you bind the list items and show the thumbnail:
Glide
.with(context)
.load(url) // original large image's URL
// save both the original and the resized thumbnail to cache
.diskCacheStrategy(DiskCacheStrategy.ALL) // default is RESULT, so this adds SOURCE
.into(holder.imageView);
and in another activity/fragment where you display the full image:
Glide
.with(context)
.load(url)
// read original from cache (if present) otherwise download it and decode it
.diskCacheStrategy(DiskCacheStrategy.SOURCE)
.into(this.mImageView);
Note that in the second code RESULT cache is not included to prevent saving a potentially big image unnecessarily. For example if your original image is a FullHD wall-paper and your phone is FullHD as well, then Glide would decode the original image file and then encode another one with the same size. However if the original images are 4K, you may win some apparent speed by caching the FullHD image, on the account that the first load of the full image will be slower.
If you want to be specific about your thumbnail sizes you can add .override(100, 100) to the first code, but then you'll have to deal with scaling the thumbnail size to all possible screen sizes (using dp for example. It's much easier to let Glide decode an image large enough to fit the view. override can be useful to hit the cache on rotation see #598.
Most helpful comment
Glide v3 has two caches
SOURCEandRESULT, reading from and writing to them is toggled with.diskCacheStrategy()on individual requests. You don't need to manually enter the size for the thumbnail, Glide will determine the view size and decode the best size to fit that view (incorporating the appropriateandroid:scaleType).So in the list where you bind the list items and show the thumbnail:
and in another activity/fragment where you display the full image:
Note that in the second code
RESULTcache is not included to prevent saving a potentially big image unnecessarily. For example if your original image is a FullHD wall-paper and your phone is FullHD as well, then Glide would decode the original image file and then encode another one with the same size. However if the original images are 4K, you may win some apparent speed by caching the FullHD image, on the account that the first load of the full image will be slower.If you want to be specific about your thumbnail sizes you can add
.override(100, 100)to the first code, but then you'll have to deal with scaling the thumbnail size to all possible screen sizes (usingdpfor example. It's much easier to let Glide decode an image large enough to fit the view.overridecan be useful to hit the cache on rotation see #598.