Can Android Volley (Google IO 2013) have a Bitmap cache for level one of cache and also a disk cache for level2. I am not clear on if this is an or choice or an either/or choice. Also wondering about performance of Disk cache vs Bitmap cache for images. I notice that the ImageLoader seems to take either a disk cache or a bitmap cache, but I have also read somewhere about it having a level1 and level2 caching ...
Volley, by default, caches everything on disk (L2) based http headers. If there are no cache or TTL headers available, no disk caching will occure.
You asked a question regarding caching which has an answer that'll help you understand here.
About the Bitmap Cache. In fact, the ImageLoader class expects an implementation of the interface ImageCache which should be a memory cache (L1). See this question.
Out of the box Volley has only disk cache (DiskBasedCache class), but you can provide yours (implement com.android.volley.Cache interface). There is no such term as "Bitmap cache" in Volley. All the data (bitmaps, texts, etc.) is cached on disk by default.
I know it is an old question, but I had the same problem and took me couple of days reading blogs, watching videos and scrolling up and down in Volley source code to finally figure it out. So for the future reference here is the thing in the clearest way to explain:
Volley caches EVERY response unless the response explicitly says "no-cache" or "no-store" in its header. if so, it won't be cached otherwise it will be cached according to "max-age" of the response header.
The caching system above makes sense 100% since a response wont be valid if server says so that makes you capable of setting expiration date for each response from server side (It is awesome).
if you don't like the above caching method you can override the corresponding part of code in volley source code, but it is highly NOT-recommended
All mentioned above is cached on Disk using LRU algorithm which makes it L2. so volley has built in L2 caching for EVERY request (including images)
Disk cache is blocking I/O. so lets say user swipes your ListView very fast and images should load very quickly, but the I/O blocks your main thread and you see some annoying jumping while scrolling. Then a non-blocking (in-memory) L1 cache comes handy and as you can see it is just useful when dealing with images. OK then, there is no built in L1 cache in Volley but IF you want to use the ImageLoader you can code your own and bind it to the ImageLoader. (Don't bother, thousands are already available under LruBitmapCache name, just copy one)
Conclusion: Set your server to send proper caching data for your responses (which is very easy) and define an LruBitmapCache for your ImageLoader in Volley and all is done. You will have L1 and L2 caches. if L1 failes volley checks L2 (disk) and if fails again it goes for the RPC.
Hope it helps
Related
I have an app where I take data from API (some points on map with properties like descriptions, lan, lat, and list of photos) because of offline mode. I am not sure if I should use sharedPreferences or some okHttp cache (or some ORM database). SharedPref is good for small values, not for list of objects. Do you have suggestions/best practices?
Thanks
Store your data in db with image URIs. Store Images in memory cache and retrieve them from their URI. Retrofit doesn't comes with support for image loading from network by itself. If you don't want to go into depth of all this, you can use Glide or Picasso.
Picasso saves full image and can be resized at the time of loading. Glide caches images after resizing. See what fits your case.
Storing and retreiving images directly from database will require too much processing and slow down loading of images especially if you need large images. For more information read check out developers note on Caching Bitmaps and Display Bitmaps Efficiently.
I would suggest you to use response cache if you require the response only to display. Retrofit provides a nice and handy response caching method, you can make use of Interceptors to cache response. hope you are using retrofit latest version 2.1.0. check out this link to get more.
If you wanted to perform some operations like marking favourites etc. you can go for database.
I have activity in which there is a dialog window with some images. I want to download these images into cache when my activity starts and load them from cache when dialog window appears.
My activity code:
for(int i=0; i<avataritemlist.size();i++){
Picasso.with(activity_context)
.load(item.getpath())
.noFade();
}
Dialog adapter code:
Picasso.with(mContext)
.load(item.getpath())
.noFade()
.into(holder.imageView);
I expect to cache the image in my activty and then in dialog adapter load in from cache, but in my case it downloads it again in adapter. I want to emphasize that activity_context and mContext is the same. What am I doing wrong?
Default Picasso instance returned by Picasso.with uses an automatic memory and disk caching. It is initialized with default values:
• LRU memory cache of 15% the available application RAM
• Disk cache of 2% storage space up to 50MB but no less than 5MB. (Note: this is only available on API 14+ or if you are using a standalone library that provides a disk cache on all API levels like OkHttp)
• Three download threads for disk and network access.
How default Picasso instance does LRU memory cache is something you might not be able to know, all you know is it is a memory cache which uses a least-recently used eviction policy.
However you can create a Picasso instance using Picasso.Builder that gives you a better control over image caching (over disk). Check more on this stackoverflow post on how to set up http request header property Cache-Control with max-age and Jake Wharton's answer too
Also you may also want to try out Glide which syntactically is very similar to Picasso
I am using Picasso to load images in a container. I want to cache in memory and cache in disk.
What is the best way to cache a image in disk? What http client is the best option?
These are my requirements:
First check cache in memory
Check cache in disk
Get the image from the server.
If the image is on disk -> check cache interval(max-age) and validate with server if the image is stale. The server needs in the header if_none_match: eTag.
I've read that this feature is built in the OkHttp api, but I don't know how to use it. Please I would appreciate somebody to send me some link, documentation or if any other different way of doing this that you could consider.
I am looking for an asynchronous image loading and caching library in Android. I was going to use Picasso, but I found Universal Image Loader is more popular on GitHub. Does anyone know about these two libraries? A summary of pros and cons would be great.
(All my images are on disk locally, so I don't need networking, therefore I don't think Volley is a fit)
Update Sep 2018: After several years, I needed the almost same thing for a local image caching solution. This time around, UIL has not been in active development. I compared the popular libraries, and the conclusion is pretty no-brainer: just use Glide. It's much more powerful and configurable. Years ago I had to fork and make changes to UIL. Glide supports all my use cases in terms of caching strategy and multiple levels of resolution caching with custom keys. Just use Glide!
Koushik Dutta's comparison is mostly for speed benchmark. His post only touched very basic things, and is not specific for local images. I'd like to share my experiences with Picasso and UIL after I asked the question. Both Picasso and UIL can load local images. I first tried Picasso and was happy, but later I decided to switch to UIL for more customization options.
Picasso:
Picasso's fluent interface is nice. But jumping around with "with", "into", "load" you actually don't know what's behind the scene. It's confusing what's returned.
Picasso allows you to specify exact target size. It's useful when you have memory pressure or performance issues, you can trade off some image quality for speed.
Images are cached with size in its key, it's useful when you display images with different sizes.
You can customize the memory cache size. But its disc cache is only for http requests. For local images, if you care about loading speed, it's good to have a thumbnail disk cache so you don't have to read several MBs for an image every time. Picasso does not have this mechanism resizing and saving thumbnails on disk.
Picasso does not expose the access to its cache instance. (You can get a hold of it when you first configure Picasso and keep it around...).
Sometimes you want to asynchronously read image into a bitmap returned by a listener. Surprisingly Picasso doesn't have that. "fetch()" dose not pass back anything. "get()" is for synchronously read, and "load()" is for asynchronously draw a view.
Picasso only has a few simple examples on the homepage, and you'll have to read through the unordered javadoc for advanced usages.
UIL:
UIL uses builders for customization. Almost everything can be configured.
UIL does not allow you to specify the size you want to load into a view. It uses some rules based on the size of the view. It's not as flexible as Picasso. I have no way to load a lower resolution image to reduce memory footprint. (Edit: this behavior can be easily modified by adding an ImageSize argument in in the source code and bypass the view size checking)
UIL provides customizable disc cache, you can use this to cache the thumbnails with specified size. But it's not perfect. Here are the details. (Edit: if you care about speed and want multiple levels of thumbnail caching, like my case, you can modify the source code, let the disk cache use "memoryKey", and make it also size sensitive)
UIL by default caches images of different sizes in memory, and it can be turned off in configuration.
UIL exposes the backing memory and disk cache you can access.
UIL provides flexible ways you can get a bitmap or load to a view.
UIL is better in documentation. UIL gives the detailed usages on the Github page, and there's a linked tutorial.
I suggest starting with Picasso, if you need more control and customization, go for UIL.
If you read this post on G+ by Koush you will get clear solutions for your confusions, I have put the summary of that, in that Android-Universal-Image-Loader is the winner for your requirement!
Picasso has the nicest image API if you are using network!
UrlImageViewHelper + AndroidAsync is the fastest. Playing with these
other two great libraries have really highlighted that the image API
is quite dated, however.
Volley is slick; I really enjoy their pluggable backend transports,
and may end up dropping AndroidAsync in there. The request priority
and cancellation management is great(if you are using network)
Android-Universal-Image-Loader is the most popular one out there
currently. Highly customizable.
This project aims to provide a reusable instrument for asynchronous
image loading, caching and displaying. It is originally based on Fedor
Vlasov's project and has been vastly refactored and improved since
then.
Upcoming changes in new UIL version (1.9.2):
Possibility to call ImageLoader out of UI threadNew Disk Cache API
(more flexible). New LruDiscCache based on Jake Wharton's
DiskLruCache.
Considering all this Android-Universal-Image-Loader suites your requirement (Loading the images are on disk locally)!
I would like to share my experience with these 3 libraries: UIL, Picasso and Volley. I previously used UIL but then I came to the conclusion I can't really recommend it and I would suggest to use Volley or Picasso instead which are both developed by highly talented teams. UIL is not bad at all but it lacks the attention to detail of the other two libraries.
I found UIL being less nice with the UI performance; it tends to lock up the UI thread more than Volley or Picasso. This may be in part due to the fact that UIL does not support batching the image responses while Picasso and Volley do that by default.
Also, I didn't like the disk cache system of UIL. While you can choose between various implementations, I need to point out that at the moment there is no way to limit the UIL disk cache both by total size and by entity expiration time. Volley and Picasso do that, and they use the expiration time returned by the server by default while UIL ignores it.
Finally, UIL allows you to set a global image loader configuration which includes the selected disk cache and memory cache implementations and settings and other details, but this configuration will be applied everywhere in your app. So if you need more flexibility like two separate disk caches, it's a no go for UIL. Volley on the other hand allows you to have as many separate image loaders as you want, each with its own configuration. Picasso uses a global instance by default but also allows you to build separately configurable instances.
To sum it up: Picasso has the best API but it uses the global HTTP disk cache shared between all HttpURLConnection instances, which can be too restrictive in some cases. Volley has the best performance and modularity but is less user friendly and will require that you write a module or two of your own to make it work like you want. Overall I would recommend them both against UIL.
Edit (Dec 18 2014): Things have changed since I wrote this initial answer and I felt it was necessary to improve it:
Picasso 2.4 is even more configurable than older releases, and when used with OkHttp (which is highly recommended) it is also able to use a separate disk cache for each instance so there is really no restriction in what you can do.
More importantly, I noticed that the performance of Picasso and OkHttp has improved a lot and in my opinion it's now the fastest image loader solution for Android, period. Please note that in my code I always use .fit() in combination with .centerCrop() or .centerInside() to lower memory usage and avoid bitmap resizes on the UI thread. Picasso is actively developed and supported and that's certainly a big plus.
Volley hasn't changed that much but I noticed two issues with it in the meantime:
Sometimes under heavy load, some images are not loaded any more because of some disk cache corruption.
Thumbnails displayed in a NetworkImageView (with its scale type set to centerCrop) are quite blurry compared to what you get with the other libraries.
For these reasons I decided to stop using Volley.
UIL is still slow (especially the disk cache) and its API has a tendency to change quite often.
I also tested this new library called Glide 3 which claims to be more optimized than Picasso with a Picasso-like API. According to my personal experience it's actually slower than Picasso and Volley during network requests under heavy load, even when used in combination with OkHttp. Worse, it caused a few crashes with my apps under Lollipop when leaving an activity. It still has 2 advantages over its competitors:
It supports animated GIFs decoding
It puts the final downscaled bitmaps in the disk cache, which means reading back from the disk cache is extremely fast.
Conclusion: I now recommend to use Picasso + OkHttp because it provides the best flexibility, API, performance and stability combined. If you need GIF support you can also consider Glide.
I have implemented an app that should constantly get and show images from the internet. I was about to program an image cache mechanism, before that a friend recommended me the universal image loader.
The UIL is very good customizable. It's so customizable that a newbie can easily make something wrong. However, the UIL was slow in my application and it became a bit slower. My use case was a ListView with images.
Yesterday I was looking for an alternative to the UIL, and I discovered Picasso. Picasso was easy to integrate and to use: Just Picasso.context(context).load(url).into(imageview) and the image could be faster and smoothly be integrated.
For me, Picasso is definitely the API to use. My experience with UIL wasn't good.
I think ImageLoader is more customizable and flexible comparing to Picasso library.
I'm looking for an open source image loading/caching solution.
I am looking in to:
Google's Volley,
Square's Picasso
Universal Image Loader
I want to be able to handle async image loads from disk as well as network, however I'm not sure if Google's volley handle's loading from disk.
Does Volley allow resource loading from disk??
An example of what I would like to do is available with AQuery.
If you're ok with newer/less stable software, I just released an open source library called Glide: https://github.com/bumptech/glide
It's designed to allow you to efficiently load any image you can get an InputStream to. It includes some basic http/file loading implementations, but also allows you to plug in your own or use some external library (like Volley) via callbacks.
It includes memory and disk caching, as well as bitmap recycling on newer devices. All you need to do is implement an interface to get an input stream for your data model (path/url/uri etc) and pass it along with whatever transformations, placeholders, or animations you want to the Glide singleton.
Happy to speak with you or anyone who is curious, we've used it extensively at Bump to interface with a variety of libraries.
I have collected few important information from http://blog.bignerdranch.com/3177-solving-the-android-image-loading-problem-volley-vs-picasso/
(the comparison between older ver Picasso 2.0 vs volley)
Picasso is totally focused on image loading. As a result, if you have
quirks in your image loading process
Volley, on the other hand, is totally focused on handling individual,
small HTTP requests. So if your HTTP request handling has some quirks,
Volley probably has a hook for you. If, on the other hand, you have a
quirk in your image handling, the only real hook you have is
ImageCache. It’s not nothing, but it’s not a lot, either.but it have
more other advantages like Once you define your requests, using them
from within a fragment or activity is painless. And unlike parallel
AsyncTasks
Picasso does just one thing, while Volley tries to solve a more
general problem.
Android does not handle high-res images well at all. I have a small
obsession with the pattern of catching OutOfMemoryError in Android
apps. It seems like a ridiculous tactic, but Volley is the only way
to reliably handle some image scenarios compare to hassle with
Picasso's scaling and fitting big images correctly. Picasso doesn’t
respect the scaleType attribute on your ImageViews(not sure it's is
fixed in latest ver).
Test Ex: I found that Volley catches OutOfMemoryError while loading
the original resolution image instead of the thumbnail version,
comparing to the Picasso version doesn’t blow up (it catches
OutOfMemoryError, too), but picasso fails to load any images that are
too large. Not only does Volley not blow up, but Volley displays all
these large images!!!.
According to Android Hacker Koushik Dutta:
Testing ALL the Android Image and http Libraries
I've been testing and benchmarking a bunch of the various image
loading and http request libraries available, since a couple of them
were released in the past week.
Lineup:
AndroidAsync + UrlImageViewHelper (koush)
Volley (Google)
okhttp + Picasso (Square)
All support cached and conditionally cached responses, keep alive,
etc.
Thoughts:
Picasso has the nicest image API. I am going to steal their currying API style for my future/current stuff. Picasso is also
noticeably the slowest. Especially on 3g vs wifi. Probably due to
their custom okhttp client.
UrlImageViewHelper + AndroidAsync is the fastest. Playing with these other two great libraries have really highlighted that the
image API is quite dated, however.
Volley is slick; I really enjoy their pluggable backend transports, and may end up dropping AndroidAsync in there. The request priority
and cancellation management is great.
Update These aren't really http libs. Just image loaders. but there
were requests for comparisons in the comments...
Android-Universal-Image-Loader is the most popular one out there
currently. Highly customizable.
AQuery; like jquery, but for Android? I guess it's nice, if you're
into that sort of thing. Don't use this one though; it craps on the UI
thread or something. Loading a bunch of images on my Nexus 4 in a
listview made it seem like I was back on my HTC G1 all over again.
Major stuttering.
Tests with caches clear:
Cold is fresh app start. Warm is caches clear with http connections
presumably kept alive.
Cold/Warm (in milliseconds, avg of 10 runs, clearing data every run):
Picasso 12142/11892
UrlImage 7378/4525
Volley 8292/7520
Android-Universal-Image-Loader 14484/11243
AQuery 11341/9637 (this one seems to lock up the UI thread... don't use it)
Here's the test code base:
https://github.com/koush/AndroidNetworkBench
Conclusion: These tests are hardly conclusive. I just tested concurrent network access with many images. Admittedly, there's more
to testing a library than that. I like how Volley plays nice with the
Activity lifecycle, for example. None of the other libraries do that.
So, whatever floats your boat really. I(Koush) want Volley with
Picasso's API.
volley' Request class deal with all network requests. I have not yet found any class loading resource from disk..
Out of the box Volley does not include its own disk cache implementation. You need to take a DiskLruCache (or a hybrid memory/disk cache if you prefer) and have it implement the Volley ImageCache interface.
This blog post sums up how to implement a disk based cache with Volley to load images: http://blogs.captechconsulting.com/blog/raymond-robinson/google-io-2013-volley-image-cache-tutorial .
Just use Picasso library :
Picasso.get()
.load("/images/oprah_bees.gif")
.resize(50, 50)
.centerCrop()
.into(imageView)
This will allow you to load specific file from SD and you can pass the imageView too where u can set this image.
To Read more feature into Picasso Library
Volly can also be used to load files on disk.
Use:
networkImageView.setImageUrl(Uri.fromFile(newFile(filename)).toString(),mImageFetcher);