mobile-system-design
mobile-system-design copied to clipboard
File Downloader Library updates
- Supported iOS versions
- Network stack verification (certificates, etc)
- Native (C/C++) vs system libraries
- BLOB vs file system is confusing
- Expand download tracking:
- Describe the component
- Discuss data clean-up (by state, id, etc)
- SOLID principles?
- Design for other features that were treated as out of scope for the exercises, like authorization
- General cases when the interviewee could go wrong with the design.
- Details of how this design can address concerns like testability, scalability, extensibility of this design.
- Estimates on expected traffic and storage requirements?
hi @weeeBox
I'm confused about the terms (download task, download job & download worker) you use in the design of file downloader library.
-
Download Task
represents an asynchronous download operation -
Download Job
containsDownload Request
,Download Task
and state -
Download Worker
is expensive and handles blocking I/O
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 :)
Thanks, @chipbk10! I'm currently on the road - would take a closer look after Christmas.