CareerCup

Classes:
1. a DownloaderUI class which takes care of inputs from user and shows him the progress bar. This class can furthur be broken down to subclasses. This class maintains a list of current and past downloads.
2. A downloaderController class. This class is responsible for firing the download class which call the network class and replying to DownloadUI class. It also manages the Flisystem class.
3. a downloader class which fires network class. it gets data from network class and stitches it back . this class also interacts with a cache class.
3. A networkManagerclass which initiates the download function and follows standard HTTP protocol to download and
4. a filesystemclass which manages interaction with file system.

Requirements:
1. Download file for a URL
2. Allow multiple download
3. Cache results (if one Url is downloaded maintain in cache for sometime)
4. Handle break in connection
5. Should have a UI that shows basic field to enter URL and download button. On clicking download should check if file is able to download.
6. If able to download should ask where to save file and save as. If no input is received should abort download.
7. Should show a download progress bar

Use case: A user entity and the system can be thought of. The user can perform following actions.
1. Input a URL and click download.
2. Stop or cancel a download in progress.
3. Should be able to open files downloaded by clicking button on each download.
Advanced Use cases:
The downloader can get added as a plugin in browser and options are added in right click context menu of the browser

The basic objective of the HHTP Downloader
-	Doesn’t block execution (Enables simultaneous download)
-	Cache results
Probable objects:
-	Request
o	This encapsulates the download request
o	For example, the URL, credential etc
-	DownloadController
o	Manage a pool of Request object
o	Process each request in sequence either from cache
o	Or forward the request to Downloader with a callback
Downloader
o	Downloads the data
o	Cache the result
o	Notify DownloadHandler once downloaded
-	Cache
o	Maintain a map of the URL:File



Some code snippet:
public interface JobCompletionNotifier {
	public void sendNotification(String jobId);
}

public class Download implements Runnable {
	private DownloadController dc;
	Request request ;/* Encapsulates the request object */
	public Download(DownloadController dc, Request r)
	{
		this.dc = dc;
		this.r = request;
	}

	public void run() {
		System.out.println("Processing RequestID ="+r.getJobId());/* Actual download code to be executed*/
		
		try {
			Thread.sleep(5000);/* Just to simulate a time delay to proove DownloadController is not using a blocking call */
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		dc.sendNotification(request.getJobId()); /* Call back*/

	}
}


DownloadController implements JobCompletionNotifier {
public void process()
	{
		while(true)//Continious ready to process request
		{
			if (downloadRequest.size() > 0) 
			{
				if(requestCanBeFulfiledFromCache(request))
				{
					sendNotification(request.getJobId());
				}
				else
				{
					Request r = downloadRequest.get(0);
					downloadRequest.remove(0);
					Download d = new Download(this,r); //Creating a new thread and dumping the job to him
					Thread t = new Thread(d);
					t.start(); //let the download , ntify me when he is done, I can process other request during that time
				}
			}
		}
	}



	public void sendNotification(String jobId) {
		System.out.println("Sending notification to "+jobId);
		
	}
	....
}

We basically need to use the NSURLSession and all his delegates to approach this design.

I would create a View controller to handle all the UI stuff, input the url and showing the progress bars for each download. each progress bar will be shown below each other and will be created by a dynamic method (no .XIB needed).

to handle the callbacks from the UITextField we need to implement its delegates so when we click search, the delegate is triggered.

NSURL session class will be created in a singleton. here we will create once the session and all its configuration, timeout and all its delegates. The necessary delegates here are NSURLSessionDownloadDelegate,, NSURLSessionTaskDelegate, and the NSURLSessionDataDelegate.

we mostly need to implement callbacks in our singleton for all of the delegates. So basically we can create wrappers methods with also blocks pattern to respond to all delegates actions.
this way we can call our singleton from our UIViewController with a block pattern and wait for any inconvenience , progress, or end download callback. we can handle all the states they are asking by blocks. This way we can call the block and handle several downloads simultaneously, also using background threads and cache storage since NSURLSessions allows us to do all that for free.

NSURLSession also allows us to stop, pause and resume a download at any time, also it allows us to recover a failed download from a specific point.

we could also extend our explanation saying that NSURLSession handles authentication and we could actually handle URL redirections for specific authentications.


to extend this for a browser, we would need just to create a button in our UIWebView navigation bar and then pass the url to our downloader, and handle, through delegate pattern, any new callback necessary to the UIWebView. the rest of the download process and error handling can be managed in the background.

this is a design question, so apart form some UML, I don’t think they require much code.

I'd like to divide the functionality into 4 classes:
Downloader, Session, LRUCache, CacheEntry

1. Downloader: singleton, active object which has its own thread and manages Sessions and Caches. internally opens a unix domain socket so that it can receive download request. It runs with event loop by calling select or poll API for ongoing download session fd and its domain socket to allow non-blocking operations and simultaneous multiple downloads. We can use multi-threaded downloader but typically user callback for downloads does not involve complex processing. So event-driven processing is enough and good thing with this approach is to avoid most synchronization overheads.
It keeps fd to Session map.
It should store downloaded data via LRUCache by giving LRUCache class url and downloaded data buffer and notify Sessions of timeout, downloaded data size, success, and/or failure.
It provides download(url, path) method which will run in the context of client's and do following things.
1. check whether the url already exist in cache and it does not expire by calling LRUCache.
2. if the test is passed, create session and notify download complete event and success event with cache data path
3. Otherwise, open the url and request a new cache entry and create a session. store the fd and session into the fd-to-session map. send a new download request with information about fd & url through the unix domain socket.

In the event loop, it should do following things.
call select() for all fds with the fastest timeout.
if there are readable fd sets,
- if the fd is its domain socket, process a new download request.
- otherwise, read the data and find out the mapped url and request LRUcache to store the data for the url.
if timeout event occurs,
- notify the mapped session of the timeout event.

2. LRUCache: maintains caches. Each cache entry keeps information about requested url, expiration information, cache data path.
Caches are organized as two different data structure: linked list of url and hash map of url and cache entry. This should store information persistently whenever an update is made.
If total data size is over maximum allowed data size, it should pick a LRU entry and extinct it. This process is done when a download is completed.

3. CachEntry: as mentioned above, keeps information about requested url, expiration information, cache data path

4. Session: keeps track of each download request status. It should keep requested url, requested local path, downloaded data size, progress callback, success callback, failure callback. When a download is completed, it is given a cached data path and should copy it into requested data path.
It should call user's callback as per events like timeout, process, download complete, download failure. We may just return cache data path but in that case, it become much harder to manage cache consistency between real cache data and cache metadata.

One more word.
If we want to support operations like suspend(), resume(), stop() on Session, then multi-thread downloader is more convenient to implement and Session can interact with LRUCache directly. In that case, LRUCache should be implemented in a thread-safe way.

asdf