[Feature Tracker]: Offline reading/action queue support

[Fmstrat]

Since 2-column tablet mode was easier than expected, I'll be moving on (slowly, in my spare time) into the next big feature on my bucket list, offline synchronization for reading. This issue is for tracking that progress and for conversation on the implementation methodology. As it stands now, this will come in the form of many step-wise PRs. I'm sure there are things I'm missing, and this issue will be updated accordingly as we go. If you'd like to help support this long-term initiative, let me know, as I may be able to reorganize things in a less linear fashion.

PR1: Online detection

Before anything else, we need a reliable way to detect if the user is online or not. This should occur in two stages:

• Android/iOS reporting: The first is via the standard OS report to determine if the device is online
• Server polling: The second is with an array of status booleans to indicate if the server for each account is accessible. We will need to take into account new installs with no account added yet, too.
• Error messages: For now, any clicks on buttons/etc should go to a central file, and from there push out a message that the system is offline, or conduct the action. This way we are prepped to handle a future queue of actions.

PR2: Action queue

Next up will be the action queue. Right now, when a comment is made, an upvote occurs, or any other action is taken, it is submitted to the API immediately. To support offline use, this will need to be migrated in a few ways.

• The queue: The queue itself should be an array of actions against an array of servers, this way the queue can operate independently for each logged in account.
• Background job: A background job to monitor the queue will be required to actually make the API calls. This will need a way to report back to the UI if there are issues, and should have retry logic that pauses the queue processing for a particular server if there is an issue, which would take over for the above error messages.
• UI use of queue: Once those are in place, the UI can be migrated button-by-button until the queue is fully leveraged.

PR3: In-memory storage

Use of in-memory storage for loaded data can happen before the official offline support. This would mean the system would need to store pulls from the API as objects in memory (including images), so they can later be migrated to local storage.

• API response cache: API responses should be stored in memory variables in a centralized file, so that this can be the staging ground for offline local-storage.
• Image and URL cache: In addition to the JSON data, image data will need a location in these central in-memory variables, too. An option to consider could also be caching the web pages via a browser call, too. This will likely morph as we get into it, since memory will be at a premium. It might need to wait until local storage support is implemented.

PR4: Offline support

The final step is actual offline support. This requires multiple elements as well

• Use of local storage: This includes cross-platform support, including SD card for Android. Local storage should always be loaded on app-start, and then replaced with the results of new API calls if the device is in online mode and has access to the internet/servers. Of course, the settings screen would need to be updated for storage location, too.
• The button: A button should be created on the left-hand drawer that allows for "going offline". It should exist only when the user is online, and give them the option of changing their default feed and how many articles (in page increments) should be saved for offline reading. Once offline, it should switch to a "go online" button.
• Downloading: This would be pre-populating the in-memory variables, and saving them to local storage. Surprisingly the easiest part of offline reading (most likely). Memory use of images will need to be evaluated vs on-disk storage.
• Queue pausing: The queue will need to pause, but actions taken against the queue will now need to show up in the UI even if the queue isn't firing. For instance, if the user upvotes, we should show the upvote in the UI now, even if the queue hasn't fired for it. The reverse is also true if an error for that call occurs. A complexity here will be tiered-actions, such as creating a post, then commenting on it (since one must be successful before the other). Lastly, when going back online, the queue would need to process.