Have an article cache controller that performs the duties of caching an article should a user tap the bookmark icon throughout the app.
1. Article cache controller will fetch mobile-html & mobile-html-offline-resources and cache the response via FileManager. Remove cache when user toggles bookmark icon off. Keep track of cache via PersistentCacheItem & PersistentCacheGroup Core Data objects, similar to CacheItem & CacheGroup manner that current ImageController uses. Only delete resource if it is not shared by another article. [DONE]
2. Have SchemeHandler attempt to pull from URLCache.shared for happy path. If nothing comes from URLCacheWhen bookmarking on article screen, trywe should not be fetching with session.all the resources again, Iseveral of that fails (i.e. connection error),em should already be in URLCache.shared because we use Session behind the scenes in SchemeHandler. try pulling from persistent cache via Article Cache Controller. [DONE]Dig into why this isn't happening if it isn't.
3. Ensure caching process can continue if ArticleViewController is deallocatedHave SchemeHandler attempt to pull from URLCache.shared for happy path. If nothing comes from URLCache, try fetching with session. If that fails (i.e. [DONE but with singletonconnection error), would like to rework if possible].try pulling from persistent cache via Article Cache Controller. [DONE]
4. Ensure caching process can recover (or database is cleaned out and user is notified) if pieces of the saving fails (i.e. they tap bookmark without a connection,continue if ArticleViewController is deallocated. let it try again when a connection restores).[DONE but with singleton, In general do an error handling/todo audit on all of thiswould like to rework if possible].
5. Make general enough so other things canEnsure caching process can recover (or database is cleaned out and use this caching system, not just articlesr is notified) if pieces of the saving fails (i.e. [DONEthey tap bookmark without a connection, stretch goal is we could subclass CacheController and write a StandardCacheController that say,let it try again when a connection restores). the diffing endpoint could refer to that DiffController hooks into upon fetching.]In general do an error handling/todo audit on all of this.
6. Save ETAG in caching and send in the request header so we can lean on server-side caching.Make general enough so other things can use this caching system, not just articles. [DONE, stretch goal is we could subclass CacheController and write a StandardCacheController that say, the diffing endpoint could refer to that DiffController hooks into upon fetching.]
7. Pull fromSave ETAG in cache on state restoration - it is ok if it is stale asing and send in the request header so we want them to see data as quickly as possiblecan lean on server-side caching.
8. Set excludeFromBackup when setting up caching directory so that user is in a consistent state when migrating to a new devicePull from cache on state restoration - it is ok if it is stale as we want them to see data as quickly as possible.
9. When pulling from cache via SchemeHandler, be sure to take full URLRequest as input to consider variant logicSet excludeFromBackup when setting up caching directory so that user is in a consistent state when migrating to a new device.
10. After SchemeHandler changes, test other areas of app that lean on it to be sure we didn't break anything (SectionEditorViewController, PreviewWebViewViewControlWhen pulling from cache via SchemeHandler, AboutViewController)be sure to take full URLRequest as input to consider variant logic.
11. After SchemeHandler changes, test other areas of app that lean on it to be sure we didn't break anything (SectionEditorViewController, PreviewWebViewViewController, AboutViewController)
12. Write tests.