Develop Reference

Glide caching behaviour

I have simple caching problem:
I have old "name.jpg", then customer uploads new "name.jpg" and clients dont see any changes, for them its still cached old "name.jpg".
I know how to turn off caching, but its not good decision, so I try to find better.
So question is:
How does caching work if I add get parameter after question mark?
For example I have url
http://example.com/name.jpg?cache_time=111
And then I replace it to
http://example.com/name.jpg?cache_time=222
Will it download second name.jpg and replace existing or not? I know its work with css or js files in browser, but know nothing about glide behaviour.

Whatever parameters you pass in the url query will be sent to the server serving the image and only if that server handles that exact parameter (cache_time) can there be any difference in behavior.
The caching glide does however is not based on what you send to the server, but rather on the configuration you give to glide.
I suggest you look up how glide handles caching, and perhaps manually invalidate the cache for a specific image when you know it has changed.
This is a good place to start: Remove image from cache in Glide library. It also has examples how to use signature()that is mentioned in the comment above.

How to properly implement feed(similar to Facebook/Instagram) in Android?

I am very new to Android. I am trying to create a social app which contains lot of images and some metadata. It has a screen which is similar to the feed on Facebook. I want to make this screen as smooth and standard as possible.
Here are the libraries I am using: OkHttp, Picasso, Retrofit, Gson.
Right now, I am fetching all the json in one go, since I have seeded dummy values in backend and the response is small enough. But, in future, it will have the previous and next fields to limit the json response.
Some of the questions that I have right now:
I am using Picasso with OkHttp. Does that cache images in disk too or only in memory?
What are the best practices on caching the feed? Since the majority of content is images, should I just let Picasso handle the caching or should I cache some items on my own? Heard about DiskLruCache library from JakeWharton but not tried it. Should I go with it?
How to keep some feed contents(like 3 or 4) in either direction of scroll in cache so that scrolling appears smooth and that images don't start loading after coming in the view.
How to automatically handle json response using previous and next fields when the user scrolls all the content that was fetched in this one go. Basically I want to trigger requests based on the number of contents scrolled based on cursors.
Suppose there is a like button and the user click it, should I change the number of likes in the UI and side by send a POST request to update counter or should I send the request and wait for the updated counter from server before updating it in the UI?
I have already gone through the source code of Instamaterial and got to learn some amazing things. But it does not demonstrates the whole backend integration.
I just want to know if there are any other open source apps which I can study or learn from. If you know any tutorials that would help too. I just want to make the app experience as smooth as possible and want to learn some best practices.

This will cache to disk as well as memory. If you set Picasso to debug mode it will display an indicator that describes where the image was loaded from (memory/disk/network)
If you don't mind Picasso having control over how long things are cached etc. then it should be fine to let it handle the caching. I'm also pretty sure that Picasso uses DiskLruCache
If your main concern here is the images, they will all be cached and shouldn't need to load after they have done so once (until it updates). You can also register a callback with Picasso in order to change the logic around showing or hiding placeholders.
I think that what you are looking for is a scroll listener on your listview (I assume you are using a list view). When it gets past a certain position (5/6) start loading the next 10. If you are using a recyclerview you can do this with the onScrollStateChanged function in the scroll listener and use the LinearLayoutManagerto call findLastVisibleItemPosition
It shouldn't really matter which approach you go with. If you think that it will take a long time for it to update the server counter (which it shouldn't) then it is probably best to update it locally first.

1.I would suggest you to checkout Image Management Library by Facebook that is Fresco that is pretty awesome and mature as compared to other Image Loading Library.
2.Fresco handles all the things caching of images with 3 Tier architecture ( BITMAP_MEMORY_CACHE, ENCODED_MEMORY_CACHE and DISK_CACHE). It also reduces OOM(Out Of Memory) issues. When image in a view goes out of screen it automatically recycles the bitmap, hence releasing the memory.
3.For that you have implement Pagination, yeah for sure you might have to send the previous record item position or index, so that you can fetch the items succeeding it.
4.For providing user the smooth experience in your app, you should increment the counter and send the post request to your backend simultaneously.
you can also checkout this tutorial Facebook like Feed.

I would prefer you some approaches for some of your questions:
For handling JSON:
You can use library called Retrofit, so adding and removing stuff in server side, will be easy to handle in your android client side. Just removing or adding variable in a Java class will be enough!
For cashing images:
I suggest you to use Fresco, facebook library, It will ease your job alot. since it can handle rounded corner conversions, downloading Progress bars, Circular images and many more features. So, Not only handle the Memory and Disk cashing for you, but also works better with different image formats.
(I used picasso in my last project, Some pictures and some URIs did not work well, I tried Picasso, Glide, and Universal Image Loader, on exactly same image and same link..ONLY Fresco could work fine for me)
It is not exactly answer to your questions, however, i wanted to share my experience with those libraries that may help you.

Saving and retrieving images from internal or external memory in android

I want to save the images fetched from server for once and from next time i want to check first whether images are stored or not in device, if not then again it should fetch from server and store in user's device again, and if yes then application will use images directly rather than fetching from server again and again. It will be useful for enhancing the speed of application. Basically my application is fetching multiple images from server so i want to save those images on user's android device and from next time application should fetch from device. I think you got my question.

The simple way:
You can use Picasso.
It is a simple lib which provides image downloading and caching.
In my opinion it might not be the fastest, but it is pretty simple and intuitive. It does its job well and none who I asked complained about it.
Picasso
Other libs:
UIL
Volley
Glide
fresco
To make it short. There are lots of other libs. An awesome comparision of the most Populat ones can be found here and here
The do it yourself way:
You can also write you own caching logic with a LRUCache. Which is also pretty simple.
Take a look at:
https://developer.android.com/topic/performance/graphics/cache-bitmap.html
The LRUCache is just a Memory Cache so you might also want to use a DiskLRUCache

Android volley library, where to use and where not to

As our typical old asynctask network connection is getting replaced by volley. It's fast as I have used so I know. I downloaded images and showed. When I again restarted the app it didn't take time to download. So is it caching images for sometime ? And as it is recommended not to use in heavy download, any reason ? Or it is the reason that it keeps images and all in memory ? I saw I/O video of volley. But I need clear explanation. Thanks

I mostly use Volley for only GET, POST api calls because Volley holds all responses in memory during parsing. For large download operations, consider using an alternative like DownloadManager. Source: https://developer.android.com/training/volley/index.html

I have used Volley in one project and it was simple for normal POST,GET but I think that I had quite some problems when I tried to upload an image.
So I would say that is quite good for making just POST,GET where you don't transfer a lot of data.

Local image caching solution for Android: Square Picasso, Universal Image Loader, Glide, Fresco?

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.