It was said in the android developers "Volley is not suitable for large download or streaming operations, since Volley holds all responses in memory during parsing." but how about uploading videos or images? is uploading is including in what they called "streaming operations"?
Please check this article : here
I think it would be better if you use retrofit.
Each project is its own and should be treated as such.
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
I am making a download manager for my app. It works fine, but as soon as network fluctuates, I have to press retry button and it starts downloading from the beginning again. Any way to resume it from last break point?
Thanks,
Rahul
As the documentation (http://developer.android.com/training/volley/index.html) says
Volley is not suitable for large download or streaming operations, since Volley holds all responses in memory during parsing. For large download operations, consider using an alternative like DownloadManager.
However you could use the volley calls to download your big file in chunks, then when you have server instability you could just request the chunks you don't have. Note this is generally a bad idea as you're basically recreating tcp and you shouldn't do that.
create a temporary directory and store the fragment of the files that is being downloaded. after downloading concatenate the files.
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);
Is there any example of using robospice library for downloading large files? I've read there is BigBinaryRequest for it but what if there will be connectivity lost/ device reboot duing file download? After next execute call download will resume/restart or request success listener will fire with reference to damaged (not completly downloaded) file?
Maybe someone have experience of using robospice for such requests.
P.S. I know that there is native DownloadManager in Android, but I think using robospice is easier. Maybe I'm wrong.
#rciovati got it right, your download, if interrupted will be lost as RS won't be able to load the result from the cache. Or even worse, you could have receive an uncomplete InputStream from the cache. In that case you should remove the cache content by yourself (using the spicemanager's method to achieve it is pretty easy).
If you download twice a large input stream using the same cache key, there is no protection against that in RS. Your cache will get corrupted.
This answer may give you the feeling that BigBinaryRequest is poorly designed and not working, but according to my own experience, it works fine in all cases I met up to now.