weeeBox / mobile-system-design

A simple framework for mobile system design interviews
Other
4.05k stars 427 forks source link

File Downloader Library updates #3

Open weeeBox opened 2 years ago

weeeBox commented 2 years ago
chipbk10 commented 2 years ago

hi @weeeBox

I'm confused about the terms (download task, download job & download worker) you use in the design of file downloader library.

For me, Download Job is the same as Download Task, and also the same as Download Worker. No need to split it up. I saw your argument like "There might be an unlimited number of jobs and only a handful of workers (limited by the pool size)." However, I can say the same like "There might be an unlimited number of requests, but only a handful of active simultaneous download tasks, the remaining tasks are in the waiting queue"

in iOS, I don't see the terms like Job & Worker. There is a similar implementation of Download Task like URLSessionDownloadTask class in iOS.

- open var currenRequest: URLRequest { get }
- open var state: URLSessionTask.State { get }
- open func resume()
- open func cancel()
- open func suspend()
// for reporting
- open var countOfBytesReceived: Int64 { get }
- open var countOfBytesExpectedToReceive: Int64 { get }

The request & state are put in the same class. No Job, no worker. May be, this way is simpler.

About the issue of how to keep track of downloaded files, Apple implements the same as you do. Apple stores the raw files in the cache folder, and meta data of this file (probably like url, path, created_at, total_bytes, ...) in a SQLite database.

I think we are still missing the discussion about caching (in-memory, disk cache) to avoid the unnecessary network calls. Thanks for a great solution for this topic. I love it :)

weeeBox commented 2 years ago

Thanks, @chipbk10! I'm currently on the road - would take a closer look after Christmas.