Sorry my english is bad.
I have a question about Grand Central Dispatch implementation.
I want to implement a slide show of photographs.
Imagine you have a list of urls to download photos from the cloud and show it.
My idea is to write the following concurrent code:
1) Download a fist photo
2) Show the picture and parallel start downloading the second
3) Wait 4 seconds or wait to download the photo (which last longer)
4) Go back to step 2
How I implement this in GCD?
Should I use Groups?
I think you should use SDWebImage.
It will remove your overhead of managing multithreading.
It is providing Asynchronous image downloader with cache support with an UIImageView category.
It provides track image download progress as well.
See Here.
One solution can be if using AFNetworking
Use UIImageView+AFNetworking ,once image downloaded with a url gets cached using AFImageCache (NSCache).
If you by chance use same url to download image but it will not opt for download but provide you cached image.
Take a look at this category of imageView UIImageView+AFNetworking's setImageWithURLRequest:placeholderImage:success:failure:
Related
My app displays images in tableView cells What I want to achieve is to load the image in sequence even if the cell has disappeared off the screen. For example, I have cell 1 to 100, the cell is displayed and the images starts to download in background from 1 to 100 even if the user have already scrolled to cell 78. I'd also want to only download one to two image at a time so I don't bog up the network. With these criteria in mind, I was wondering what sort of setup would be most appropriate?
At the moment, I am using AlamoFire to download image. Would a combination of Alamofire with some sort of NSOperationQueue be suitable. I am very un familiar with NSOperationQueue at this stage. So I thought I'd try to find a recommended industry practice before I start going deep into setting NSOperationQueue
I'd also like to combine the functionality to continue the download even when the app is in background
Note. Any alternative library or framework solution is also welcome
The best solution out there is SDWebImage. The link to this repository is here.
If you wanna do it your own way without having any dependency then you have to follow the same things that SDWebImage does.
In short,
Asynchronously start download in thread, which downloads the images from the URL concurrently.
Then after downloading, use NSCache, to store the image and use the
imageURL as the key.
After storing the image in NSCache, also write the image in NSCacheDirectory, with the imagename same as that of its URL.
Now while fetching you have to check, whether the image exists in NSCache, using the imageURL as the key you can easily search that. If found, return image or then search NSCacheDirectory, whether the image exists there or not. If not then you must download the image and follow the steps once again.
Now NSCache is like the RAM. The data stored there will remain there as long as the Application is active. Once terminated, the data in NSCache will get cleaned.
Hence we also write the file in NSCacheDirectory, as data over here is persistent to as long as the app is not deleted from the device.
I hope I could make you understand as to how this thing works.
Cheers.
I am using Alamofire as my networking library for my Swift app. Is there a way to keep a "priority queue" of network requests with Alamofire? I believe I saw this feature in a library in the past but I can no longer find it or find other posts about this.
Let's say I open a page in my application and it starts to make a few requests. First it gets some JSON, which is fast and no problem.
From that JSON, it pulls out some information and then starts downloading images. These images have the potential to be quite large and take many seconds (~30 seconds or more sometimes). But the tricky part is that the user has the option to move on to the next page before the image(s) finish downloading.
If the user moves on to the next page before the image downloading is done, is it possible to move it on to a lower priority queue? So that when the images on the next page start loading they will go faster? I would even be open to pausing the old one entirely until the new requests are finished if that is even possible.
Keep in mind I am open to many suggestions. I have a lot of freedom with my implementation. So if this is a different library, or different mechanism in iOS that is fine. Even if I continue to use Alamofire for JSON and do all my image downloading and management with something else that would be alright too.
Also, probably irrelevant but I will add it here. I'm using https://github.com/rs/SDWebImage for caching my images once they're fully downloaded. Which is why I don't want to cancel the request completely. I need it to finish and then it won't happen again.
TL;DR I want a fast queue and a slow queue with the ability to move things from the fast queue to the slow queue before they are finished.
Have you considered managing a NSOperationQueue? This tutorial might be helpful. In his example, he pauses the downloads as they scroll off the page, but I believe you could adjust the queuePriority property of the NSOperation objects instead.
I am Not Using: ASIHTTPRequest, AFNetworking, RestKit.
I have multiple images/files to be downloaded via Asynchronous call to web service for downloading.
I am showing SVProgressHUD (Activity Indicator, NOT Bar) during the download process.
Till this point, everything works fine.
Now, my client wants me to show the single ProgressBar on the view for file(s) being downloaded, so as to make user aware about the approximate time it would take.
Problem: How can I get consolidated time/size for the files being downloaded Asynchronously.
I am open for using any API that serves the purpose. I hope I am making sense, here.
Hard Time. Any Hints?
Take a look at NSProgress, it's not a UIKit class but will allow you to crate multiple instances of NSProgress (one for each activity) and then get a combined progress value which you can hook up to your UI.
There a good write up about it here with examples:
http://oleb.net/blog/2014/03/nsprogress/
You basically use KVO to read the progress value and then update your UI element i.e. progress bar.
One option is to get length of all files with "head" request, then just calculate it yourself:
amount of data downloaded/total-data-length.
This post will help you to get total content length: Objective-c Check file size from URL without downloading
Other option - start downloading each file in separate thread and use shared variable to get consolidated time.
Hope this helps.
I have created a simple testing app to learn how to use NSURLSession. This App has to download images from a webservice and present them into a UITableView.
I've already written the first part of the App that reads a list of images urls from the web service, now, I want to display this list.
My doubt is:
given that the list of images could be a really long list, is it ok to create a NSURLSessionDownloadTask for each image?
I thought to create the session in the cellForRowAtIndexPath function and store the NSURLSessions in a NSDictionary using as key the IndexPath of the cell (and probably relying on NSURLCache to avoid to download the same images more than once).
Other solutions:
I can see three more solutions:
Using GCD with dispatch_async
Subclassing NSOperation and essentially store an NSOperation for any image I need to download.
Using a third party library like AFNetwork... but since it is a learning purpose app I prefer to go completely with my code
.
If the multiple NSURLSession isn't a good solution, I'd choose one of those options.
What do you think about this approach?
NSURLSessionTask is fine for a large number of downloads. One advantage of it over some of the other methods you mentioned is that downloads can be cancelled or paused. It also correctly implements concurrency for network operations, which is more difficult than many cats on the internet will lead you to believe (if you don't believe me, view the eskimo's 2010 WWDC session and sample code. NSOperation for network connections is not trivial).
NSURLSessionTask and friends are designed for exactly the kinds of problems you are trying to solve, and it's very well tested.
For a tableview, start the task in tableView:willDisplayCell:forRowAtIndexPath: and cancel (or pause) a task in tableView:didEndDisplayingCell:forRowAtIndexPath:. That will limit the active downloads to the currently visible cells.
Suggestion:
I also came across a similar situation were I need to download about 2000 Image files and 100 Video files. For that purpose I implemented a custom download manager using NSOperationQueue and blocks.
I have added this library to GitHub, please feel free to check the implementation.
IMO whilst it is ok to create an NSURLSessionTask for each image a standard first in first out implementation will cause problems when scrolling through your cells. The reason for this is that downloads will be queued on your NSURLSession and tasks will be executed in the order they've been added to the queue, in other words in a FIFO manner. Imagine a scenario where you've scrolled through a vast number of cells and you have to wait for all downloads to complete in order. You would not only have to wait a long time, you would be making unnecessary network requests for image assets that may no longer be relevant to your user.
Nick Lockwood created a great NSOperationQueue subclass called NSOperationStack that reverses the order of operations so that the the last operation is executed first (LIFO). IMO for a large number of downloads a LIFO implementation is a must.
NSOsperationStack is available here
If you combine this with an implementation that uses cellForRowAtIndexPath to initiate and NSURLCache to store downloads, you should end up with a very streamlined and efficient solution.
I would use (or at least take a look at) SDWebImage's SDWebImageManager.
Besides downloading you can set priority and continue in the background options which I think you'll want to have.
I am working on an app where I need to download lots of images locally (so that they are available offline). The number of images can be 100 - 10,000. Each image may vary from 100K- 250K
I can do this via a NSOperationQueue and I have the code to make this work already but this question is more of a conceptual nature. I am not sure what is the best approach to take here.
1) Do I download all images as soon as the user logs in for the first time ? Based on the number of images, this could take a long time and what if the user closes the app meanwhile. I understand there is a limit on the time that can be spent by a background process in this case? Honestly, I dont want to do anything in the background (ie when app is closed)
2) Do I download images when a particular category is selected by the user? If a category has 800 images, then what happens if the user selects another category before all of those 800 images are finished downloading? I can always start threaded downloaded but will the thread keep on running if the user selects another category ?
3) Put something in "Settings" to let the user decide this themselves. Something like "Total Images: 8000" Images Available : 2000 and a button to say "Download All" which would display a UIProgressView of what's going on....so the user will probably wait till it's all done.
Or some other approach?
Thoughts?
As far as I understand from your description, including comments, I think that the best approach would be downloading all of your images in a thread and make the download process resumable. In this way, you are going to mirror a remote database of images for offline use.
What this entails is:
you keep track of which images you have downloaded;
each time the app starts/resumes, you start the downloading thread exactly from where you left;
you should also provide a mechanism so that the user is suitably informed when he is trying to access an image which has not been downloaded yet, but I think this should be no problem (you might also provide a progress indicator somewhere).
I would only download the image when the user actually needs to do something with the image. Your users will hate you if you download all the images upfront. :)