Devlog #11: Cloud Provider File Actions 2 (WIP)

Google Drive Cloud Provider Actions Complete

Since the last devlog, I’ve successfully completed the logic required to sync files and folders to Google Drive accounts using the Google Drive .NET REST API.
Using the .NET REST API involves first building a drive client service object, through which you’ll use to interact with the REST API for actions like uploading files or deleting them.
The logic is written to keep an exact carbon copy of the local version of any watched folders on the cloud. It does so by storing a queue of all of the changes a user makes to a folder and its children, and automatically ignores any conflicting changes from FileSystemWatcher that could be simplified (e.g. if a user changes an item before deleting it, we can just delete it instead of first updating the changed file AND THEN deleting it).
As the REST API does not support uploading multiple items or entire folders, every file is uploaded one-by-one via a stream. All cloud items are tracked not by their cloud IDs, but rather through their hierarchical relationship with the overarching folder parent (WatchedFolder).

Google OAuth2 Flows

Since the drive client service is created via access tokens (which expire), there’s a very real possibility of our cached access token expiring in the middle of an operation. Thus, I decided to use the Google OAuth2 Flows library to automatically refresh the access token when it expires.

Microsoft Graph and Dropbox File APIs (WIP)

The Microsoft Graph and Dropbox File Action APIs should follow mostly the same high-level structure as before, with minor changes made to accommodate differences in how each of the APIs work.

Microsoft OAuth2 access token expiry handling

With the Microsoft API, I instead implemented a custom class TokenManagerAccessTokenProvider which inherits from IAccessTokenprovider, before passing this into building the GraphServiceClient.